PROJECT EVALUATION
For the project evaluation I will begin by summarizing how things went throughout the four-month development process. I have created a walk through the game narrative in order to explain how specific design decisions were made in an attempt to showcase mechanics and other game attribute that would be included in the finished game. Next I will compare the first and last weekly breakdowns and speak about my role in trying to stick to the plan. To conclude I will give a personal opinion about how things went, and how I came out of the project as an improved games designer and creator.
Project Summary
The project kicked off and the first thing we had to do was decide what the vision for our vertical slice (VS) was going to be. This was done in consultation with the games design document (GDD)creator Bernardo Correia. Even before I knew I was going to work on his game idea, I already liked some of the characteristics it had. I made it a point to bring across some of those as a tribute to the designer. Once a vision was agreed on, I started looking into assigning specific roles to the group. This is also where I wrote out my first weekly breakdown. Read more about the first week in my blog.
The second week I focused on budgeting whilst the other team members began working on creating specific designs and ideas for what their role required them to create. I had to switch things up a little as soon as the third week when we were given a 7th group member. In my reflection I write about how I hope that the addition of this member will add some qualities to embellish the game. I didn’t know how the Janice would do that, but that goal was fulfilled when I realized that she could work on lighting, which can make a big difference in the feel of the game.
As people were working on their ideas of how things should look like in detail, discussions began. One of them was whether we should have the town whose sole purpose in Bernardo’s GDD was to act as a piece of UI in between battles and narrative. My group wanted to have this menu in 3D at first but when we broke it down into a weekly process, it was going to take too long. Now we have an entire town (as opposed to just a menu) in 3D. It is not being used as a menu but its learning occasions like this that show me that clearly our weekly breakdown way overestimated the time it would take to make things in 3D. More discussions arose around how skills and experience would work, whether to have a skill tree, and if we should have visual customization on top of stat customization and so on. In the end, what matters is the result, and what I learned from getting there. I definitely think that avoiding constant back and forth is good, but since we were all new to it I think it allowed me to make the observation myself, and will do what it takes to take the negative aspects of such discussions out. I think experience is key to getting good at that.
As a next step, I set up the QA testing document. With the help of Safwan we made a list of what needs to work with what, and how? Defining what the ‘correct’ or errorless version of our game would be allows quick recognition if something isn’t fulfilling its function appropriately. The QA testing aspect of our game was not propelled as it should have been throughout the entire development process of the game. This is also a learning area for me, and obvious in hindsight, testing has to be done at each individual stage to make sure it works not only on its own, but as a part of the bigger picture. Putting together that bigger picture is the point at which you notice how good your QA testing had been up to that point.
As the project continued, things were getting created and talked about and design decisions were still being made along the way. When it came to finalize a certain aspect of the project, a lot of discussions arose. The processes were note structured and issues in communication and productive collaboration between some team members were showing. I did take quite a few steps to try to improve the situation and keep people focused. When Easter break started (we were all home due to COVID) I implemented a more structured format to the Trello, assigning specific roles and delegating the responsibility of decision making a bit more efficiently.
I created a information flow chart of how decisions should be made based on which core aspects of the game we need to cater to first. Those were the mechanics, environments and skills. All other project aspects had to create their designs around those three pillars.
Another thing that I did to aid communication is organize group meetings. To my surprise it went really well even through the Easter break. We actually spoke more than we did when we were all still in the UK. Not only did I organize group calls, but I spoke individually to people to check up on them. This allowed me to be on top of the ball with each process of the project, and when communication between two people whose processes overlapped was weak, I could jump in and make decisions by speaking to each person separately and identifying what they need to continue. With my overview of the project as a whole, I could also guide people into making decisions that would not only benefit them, but the other processes as well. I believe I did that well because in a moment of stress about character textures and scale, we came out with a perfect solution and could continue working.
Finally, the most useful thing to me personally is the error booklet I created. Essentially it is a log of all the things that caused trouble, like the character textures. I also logged how I solved the problem and what the result was. This will be useful in the future because I will be able to tackle such issues first, or even better, prevent them in the first place.
Overall, we did a great job as a team, staying in touch, communicating and most importantly getting things done. There was however a team member who seemed to be stirring up trouble. This team member was pessimistic about many things, one of them being the result of the project if people didn’t communicate more. The criticisms that were being made by the group member about the quality and prospect of the project were in no way reflected in reality. The group member seemed to have a personal issue with the fact that people didn’t always respond immediately. This is understandable in some cases, but not necessarily in the case of a bunch of students making a game. Although the last point is debatable, what isn’t debatable is that the team members approach to addressing the concerns was unprofessional and unproductive. The issues were not resolved throughout the entire project, even with the multiple interventions of our PAT. Nevertheless, if it was a real professional environment, things would have been handled differently.
Towards the end of the Easter break, we started to put together a master file in Unity, where everything would be in one location. For a month we all had access to the Unity file where live changes could be made. I helped out with the decoration of some buildings in the town environment. Production and problem solving otherwise was continuing as before, although they did arise from time to time.
After Easter break, we began actually finalizing things to the point where we knew there would be no changes made (for example the maps). This was a satisfying part of the project because we could start ticking things off the to-do list. How all things go however, the enjoyment of ticking off boxes was countered by the concerns arising when trying to make things work together. Finding game breaking things is never nice and solving them can be scary because you can’t really predict the magnitude of an issue until it pops up in practice. This is where the absence of our applied QA testing sheet became visible. The game was not working because there was an issue with the models. We, or at least I thought, that the issues were going to prevent us from making a playable game, so following the advice of our PAT we started re-structuring the final layout of our VS. Since we did not know exactly why the game wasn’t working, we were going to showcase the technical aspects of the game independently from one another. As oppose to a playable game, the project parts do not have to function together (code, models, animations, textures, lighting, UI, sounds, particle effects all simultaneously). This is what the layout looked like. More on this topic in my blogs.
Very late on in the project however, my team identified what was breaking the game, and just took it out. Now we have a game that works with all aspects of our production except the animations. We now have a layout that’s a hybrid of both. We still have the playable game, and in addition we will give the player an opportunity to look at the character animations separately. In addition to that, the player will also be given the opportunity to appreciate the maps in more detail through a first-person free roam option, separate from the game. Finally, if curious, the player can also take a look at each individual 3D asset used to make the game.  This way, literally everything we created is being shown off at one stage of the vertical slice, and we still get to brag with the fact that we have an actually playable game.
Narrative Commentary
Here I speak about some details included in the narrative. More specifically I talk about how mechanics that we did not have time to implement are demonstrated within the cutscenes.
​
Video Source: Wild Wild Animals Slack Channel
Creator: Olivia Gregory
Weekly Breakdown Comparison
It is clear from the image below that the first draft of the first breakdown was very clean looking in terms of how smooth I expected things to go. To be fair to myself there were a lot of unpredictable things that forced change. From the addition of a new team member to COVID-19. I therefore believe that the accuracy of my breakdown is not as important. Especially since this is the first games project I worked on, seeing how and why the breakdown morphed over time will help me in the future make more educated decisions for the weekly breakdowns of future projects. A document including all weekly breakdowns is available in the Work Structure Section.
To see a direct comparison of the first and last weekly breakdown, click the button below.
​
ERROR BOOKLET
Learning from mistakes
I have created an error booklet which includes all of the things that went wrong in terms of running the production of this Vertical slice. I will use this for future reference in case similar issues occur. I will be able to tackle these issues more effectively.
​
Click the button below to read about the issues and what I did to solve them.
OVERALL...
To wrap it up, I believe that our project went really well. As James told us, the project was one of the most ambitious projects that the course has seen throughout all three years. I am impressed and happy about how good the result looks. Yes of course there are areas for improvement but what we focused on ended up awesome. In the end it is a vertical slice and the whole point of it is to see what things look like and decide what further action needs to be taken to make this a marketable product. Although the communication of the group was sometimes inefficient, and there were some arguments what matters is the result and I am happy with it. The team disputes were a challenge for me as a leader and I learned a lot but I'm repeating myself for the third time already. One thing that I think we could have had a menu for or some form of elaboration is how the game works. Controls and all that. Other than that I would say cleaning up the UI a bit but that would be getting into the nitty gritty which isn't necessary for a vertical slice.
I learned a lot from this project and hopefully that is evident from this website.