Final Personal Reflection

From my standpoint there were a few things that definitely I felt as though were good and bad with the project as a whole, but to start the idea of the project itself was fairly interesting, it had a succinct identity of making another puzzle game in a multiplayer formart whilst incorportating the idea of non-direct contact between players. In order to create the concept as it is now that would have meant the game leant into an asymmetric game. The amount of players that was initially going to implmented from the beginning to keep the idea simple to understand and show off the game was 4 players.

Good

The initial idea of the project was to create a different experience and as a team we all came up with ideas, I wanted to create an experience in light of certain game that use Twitch chat to be a part of the experience, so developing a game where the actual game that was being played was a completely different from the other player group where Players would be going against the ‘Spectators’. So there would be a difference in playstyle. Thankfully this was my concept and I became the head of the team, the amount of research conducted by all of the members of the team was fairly extensive, taking many inspiration from many different games taking insight into how we could’ve implemented this dynamic. Eventually it lead to us taking heavy inspiration from game such as Crawl, It Takes Two, and Nintendo Land, but even with these inspirations it took a turn to become a puzzle game for one group and other to simple stop them from completing it.

Essentially discussing the game at the beginning of the concepts was good for the time being, but later on during the process, the game’s design started to become abitious because of this asymmetric nature of the players and the ‘spectators’. Later on these got changed to Rangers and Aliens, Rangers being the actually players who will be solving the puzzle ans the Aliens being the ‘spectator’ players who will slowing down the progress of the game state. With the design being big, the abilities that each player group has differs and overall, was quite a lot. So with the amount being there, I felt as though onboarding wouldn’t have done the game justice in anyway, now normally this is a bad thing to not include onboarding, so I delibrrated and tried to make tutorials for the game, which seem like the actual game is being played and for that I took inspiration from Overwatch to implement to the these tutorials. One thing I did understand though is that these levels might not make it into the prototype of the game, so I took the extra step to make it just in case and if we had the time.

The method in which I designed both the tutorials and the main levels for the game were the same, first make a guide to understand what the player needs to do, in the case of the tutorials also include a section where it shows the text that should appear on screen to understand fully what needs to be done, sketches of the levels with key, explaining each object and then finally translating it into Unity making those placeholder levels that also had a key (both in the hierarchy and in text format). I prepared myself each step of the way to I could make the correct result at the end of it. In addition, the main levels designs needed three different variations which all took time to create and to understand which I documented every step of the process too.

In terms of the Economy, I feel like that was desiged fairly well, taking into account that Money in the game has to be restrictive as possible. My method of thinking in terms of this was the create an Economy that can only be obtained one way by completing challenges and having a set amount of challenges in a day instead of the player just obtaining currency in the game from just playing it, which would lead to inflation, additionally adding a secondary premium currency that is in relation to real world money to keep it afloat so in theory it works, obviously we would have to test that.

Finally, the one thing I know which was good was receiving regular updates from a certain team member showing the progress of all the things he was able to achieve in video format, so that way I was able to communicate what was needed to be change or anything of that caliber at least to that one programmer, and now we will move on to the bad.

Bad

Ultimately, I realised there were some problems with the overall development of the project, even though I understood the basics of the game it mainly came down to time-contrainsts the feasibility of concept.

Designing the mechanics for the Aliens was initially difficult especially when it came to implementation. I tried to incorporate different methods of the Aliens to use the their abilities in the game, designing cooldowns as well as a resource management system and a switch. So the Alien players have three methods of activating all of their abilies initially seems too much, the players should be able to understand a simple control rather than having juggle multiple methods of activation. Essentially for the Alien players it becomes a ‘Tower Defence’ game with the understanding of the indirect contact with the players, the reason for the different types of resource management systems was designed with Balance in mind, where assuming the Rangers would easily get to the end of the puzzle without much of problem, the Aliens should be able to react somewhat easily and quickly when necessary but then wait for better abilities to be more impactful .

My method of thinking was that with the cooldowns for specific abilities, which would be the Enemies or making simple damage to the Ranger players (if it hit) they need to be easy to access and giving them a resource amount that would be small would overal make them able to do so more often making the game unplayable for the Rangers. Additionally. having a place for the final ability to work should cost the most and it should take time to activate, to mitigate the time that needs for it work or in this case balance the concept, Alien player would have to go to their original Spawn Point and activate it there and it would cost the maximum amount of resources, but this switch in the spawn point can only be activate if you can pay for it. Unfortunately, the resource managment for the simple abilities did make it into the prototype which came with the expected result and the other abilities did not.

However, one thing I do understand is that the design was extremely ambitious so in order to implement the differences of utlising the Alien abilities alongside the other gameplay loop of the Rangers was difficult.

The design and all of the things that made it work was a lot to undertake, but as a team I felt initially it was possible with all the amount of experience in team, however I was also wrong, the main issue I found was when it came down to communication and workflow management. As the team initially were good, comminication between the tasks and the time management suddenly broke down, I was assuming a Leader role within the team and had many instances where it became frustrating to the point, it honestly felt as if 2 out of the 4 people were working on the project. Because of this, it also lead to a lot of delays within the work and gave us what we had.

Designing the game should’ve have been the main priority and the other designer and I got to work as I assigned him and myself tasks to complete during a set period of time. In terms of our time managment tool, I opted to use the SCRUM methodology to help use proceed with the project and in terms of designing a puzzle game, already had experience and I provided all the material I learned in how to make them to the other member, however I wanted to push him to learn these attributes and design puzzle as well. The creation of these puzzles took the most amount of time as for whatever reason, the other designer failed to complete these step-by-steps for the puzzles in the amount of time I gave him which lead to me overtaking most of the design work. In hindsight, I wanted to complete the design of the puzzles as quickly as possible in order to streamline the process of making the GDD and the placeholder levels to give to the developers and make their work easier. Even with the communication problems, I did manage to keep in contact with one of the developer/programmers during this time, but I think he would also agree that the other member on the programming team, helped much later on rather than when it was more beneficial during the process leading to delays with the production, testing and finally to the prototype.

Another thing, that doesn’t involve the team, specifically was to do with my skill set, again for this project I refrained from helping with some aspects such as creating the prefabs for the environment as well as coding, which is something as a designer I need to have key insight into. I’m not someone who engages in art or coding for much, so it would benefit me more in order to do so and I always like a challenge and for this particular project I didn’t uphold that end of informing many of the visual choices. Additionally, the one thing that wasn’t implemented or made for the game was the varying cosmetics as the main objective as with these cosmetic items it would lead into customisation and monetisation, although mentioned heavily in the GDD, there wasn’t any created as it would’ve taken time to do create all of these assets.

Finally, one little thing as well when it came down to the organisation of our thoughts, Miro was useful however, the end result of the board doesn’t look entirely organised to someone who spectated it, so this would have to be something to improve on, overall, I knew where things were but then if another member of the team joined and there was more information that before, they would have to ask for where it is but this also came over the plan of the Live-Ops, although created in Miro and fairly understandable, it isn’t extremely descriptive either.

What I learned

  • I need to develop my skills paritcular in code and shaders/textures in Unity to make more compelling games, at least visually.

  • Sadly, never really got to touch the Unity file and should’ve been more intuitive in messing around with the functions in the game engine and really change whatever I need to change.

  • Sometimes I understand that I’m too ambious and I need to consider the feasibility, although for this project I was assured it was all good, it didn’t end up that way. So basically toning it down

  • In terms of working with teams, I think clearer communication needs to be necessary but this does also rely on team member from completing task. Now what I’ve learned is to be intuitive as if the work isn’t completed I will conduct the workload myself despite differences.

  • Again to do with communication would be to improve on work management tools, by keeping on top of the tasks and arrange weekly meetings to do so.

Next
Next

Testing