Introduction
After me and the collaborative games design group where done with the first and second part of the collab games design course, we moved onto our final segment of a three part course. This segment is the game collab post mortem assignment log where we reflect on the whole experience of finishing the game and the pitch also analysing what went right, what went wrong and what we have learned for future projects to undertake.
Reflection
Design
Prototype
When creating the Taxi Game prototype, I focussed on the technical features of the game and making sure they work. I used a video tutorial that teaches me how to create car driving physics for my player. Following the tutorial, I successfully understood the coding and created it using the video as a guidance.
As it is an arcade game, I wanted the prototype to look simple so I gave it basic shapes and colours to show this arcade style. I can understand others saying that it looks boring and plain but it supposed to be a prototype and isn’t meant to have complicated visuals.
The design of the game also needed to include a scoring system and I used a separate video to help me. Overall, with the functionality being put into the prototype, it really presented the aim of the game pretty well and I believed that I did good in creating a solid game loop.
What I could improve on this prototype is to add more content like the enemies I planed to have or giving it better visuals. But as a prototype I kept it simple.
Main Game
As for the design of the main game I was tasked to create props that you would see in a museum and a Sumerian level. In my opinion I believed that I got the museum props spot on with all the decorations, exhibits and extra props that can be used many times to fill out the empty space. Mainly due to experience of going to museums helped a lot.
But for the Sumerian level, I believe that I couldn’t do the same because as much as online resources can give me some understanding, of the props that can be seen in that level, since I had no experience of the Sumerian culture, my knowledge of creating props are limited with only the research I’ve done.
Art
Studio Logo
When making the studio logo for NeonByte Games, I wanted the main colours to be green and black to fit with the whole 0s and 1s binary code theme. Also, I chose a piranha to fit with the Byte name as it is a play on words for bite.
However, I could see why this logo may look boring, bland and unfinished because I only picked two different colours making the logo look incredibly monotone. It may look unfinished because there’s not much to look at (being a green piranha and some numbers with a black background).
The lessons I have learned when making the logo is to spend more time in thinking about the logo and practice creating logos that are more interesting to look at by adding more depth or colour for a games studio.
Prototype
When creating the Taxi prototype, I solely focused on the functionality of the game and did not think about the looks.
I did provide some looks to the protype by giving the taxi player a yellow colour, the setting is grey, the people who get’s pickup and dropped are green capsule shape and the drop of point is a diamond with the cyan colour.
The fact that I only provided the proto type with shapes and colours may hinder others from choosing the prototype given as it would look very boring as they would like to visually experience the game be seeing it play out.
I will take what I’ve learned and make sure that my prototypes looks slightly better than boring shapes and colours.
Main Game
When it comes to the art style, we as a collective group, wanted to create a game that has similar artistic styles as The Escapist 2 game. As a prop artist for the team, I believe that I have done a great job in providing my team with the props they need to make the levels of the game and integrate core game mechanics within certain props.
As a team, we all decided that we should stick with a 64 by 64 bit resolution for props to fit with the 64 by 64 bit style for the game.
However, when doing the artworks for the props of the game, there were some feedback from the another person in my group saying that the style in how I created my props for the game is different to the style of how the character artwork was done. I created my props with a black outline and the character artworks doesn’t. This resulted in a game with two different art styles.
Art style I used for the props
Art style used for the Character
So as you can see the art styles are different. I believed that what I did was an artistic choice I made to separate the props with the background. But others may see it as not being cohesive at all can look unfinished. Leaning that this was a possibility, I plan to take this feedback of sticking to the same art style and use it for future projects when I join in groups to make more games.
Teamwork
Pitch
When collaborating as a group of four, we discussed notes with each other, recorded our individual progress of those notes, each of us created our own game prototypes for a collective pitch that decides what one game we want to push forward for our main game.
Overall, we successfully collaborated as a group to create three prototypes and pitch them to our examiners. As a team we have successfully followed the criteria in making three prototypes and created a power point of our collective findings which leads to our final game decision.
When building the power point I believed that I did well in providing a prototype and adding information in my entire section of the power point being inspirations, ethical values and principles.
However in some cases, our teamwork wasn’t always great. The assignment given to us told us to create three prototypes and pitch them using a power point. As a collective group we ended up making four prototypes and did not have time to practice the pitch as a group and by our selves.
I insisted to stick with making three game prototypes so we don’t tire ourselves out and make space for practising the pitch. But the entire team thought it would be better to do some extra work (that probably won’t effect our grades) mainly due to having four people in our group. I believe this decision is one of the main reasons why we didn’t do as well in the pitch.
Learning from that, I must learn how to be more persuasive and understand different ways to influence a teams decision making by providing more evidence to my claims, make my claims sound more logical and ask for feedback for my claims and requests.
In terms of the pitch it self, I believed that I practised well before the pitch started. It made my talks fluent and straight to the point. But I did feel what I wrote (about my section of the power point where I talk about my game prototype) was too much and pushed back the other prototype games that we pitched.
Noticing this flaw, made me realise that I need to shorten my content in future collab game assignments and only talk about the important parts. Side parts and other boring topics aren’t good to add in a collaborative power point.
Main Game
When it comes to the main game being the thief game, we have successfully worked together, communicated adequately with each other, put a lot of time and effort into the main game and successfully created a game with a functional game loop and working mechanics.
Overall, we did a great job in creating the main game with it’s style, mechanics, narrative, goals and features. The end result is pretty good and it has a nice flow.
I believed that I provided my team with more than enough props for the game. Also any prop the coder asks me to create, I create it with no trouble at all. In terms of creativity, I am great at it and use creative software like photoshop so much that making 4 props is a 10 minuet job max.
However, we had difficulties with teamwork and communication within our group. After we finished the first part of our three part assignment, that being the prototype pitch, we had the easter break before we started the second part of the assignment which is to work together to make the game, document it, have video gameplay of it and either have a working link from itch.io or a functional downloadable version of the game.
During the easter break, me and rest of the team found out that one our members (who is our second coder) outright abandoned us with no warning. Making us a group of three. The team as a four included two creative artists two coders. With that unfortunate change, our new team consisted of two creative artists and one coder.
This made the game making process significantly harder and the quality of the outcome will change drastically (negatively without a doubt). This also causes a problem that forces our only coder hold twice the weight of making a functional game and puts more pressure on him to get things done.
When we saw in the Discord that one of our teammates left we were uncertain if he left indefinitely or he may come back at a later date. It wasn’t till weeks later we learned that has indeed left for good.
I as a person and a teammate, I felt that this was a fault on his behalf on why the game turned out the way it is and I did feel frustrated, confused and quite annoyed that this happened. I did tell my self and had others tell me there could be a million good reasons to why he left and I mustn’t look at them the wrong way.
At some parts of the course, communication was definitely lost resulting in outcomes of the project being completely different. Me (the prop designer) and our second creative artist (being the level designer) have both explicitly said to our coder that we wanted to create a prop that is designated to be the item the player steals in the first level of the game. That being the museum level. I created a prop that resembles The Rosetta Stone exhibit and the creative artists wants that to be the main object the player steals.
The coder unfortunately disregarded and completely ignored this request by using a prop that I made, that isn’t even meant to be an exhibit but a mere statue for the player to hide behind. This in particular upset me because our creative choices where ignored and for me, I spent so much time on the props I made and most of them don’t get used especially the centre piece that is The Rosetta Stone.
Most of these annoying and outright frustrating problems I don’t have control over but the only thing to learn from all this is to improve my communication with the team and now that I have experienced such unfortunate events during this course like the fourth member leaving us, I know how to overcome them emotionally and move on.
Gameplay
Prototype
When working on my prototype, I wanted to create an arcade style taxi driving game where you pick up passengers and drop them off at the drop off point. I focussed heavily on the functionality of the game and perfecting the mechanics so the art style is very basic.
I have successfully created a game loop where the player controls a taxi with real-life driving physics (with the help of a YouTube video tutorial), a pick up and drop off mechanic where the player picks up civilians and drop them off at the drop off point and a score system (with the help of another YouTube video).
There are a few gameplay mechanics I have not implemented that can make the gameplay even better, like a timer, a win screen and a loosing screen, a bigger map and enemies that can hinder your progress. Also, since it is prototype, I do not need to spend so much time on it and the gameplay should be basic and simple and doesn’t have to be perfect.
Main Game
For the main game, we wanted to create a thief game. Where the player needs to steal a certain object in each level and progress. The player needs to get through the level containing puzzles to solve and guards to avoid.
Gameplay wise, It’s pretty sophisticated with multiple puzzles, a nice level, actual guard ai, interactable objects, a few tasks to complete, a start, an end and a goal. As a game made by a group three, it’s pretty solid for what we where trying to achieve.
The props, characters and level design for the game are implemented well but in some areas of the level, I do see some tiny mishaps within the implementation of those props. Those include poorly cut out props and unrefined areas of the map that makes part of the game look very ugly.
I believe that the reason why this happened is because the person who is coding and implementing the props I made, never asked me for feedback when viewing the game (maybe the coder assumed that the way he implements some of the props in the map are fine to his eyes). The only thing to learn from this mistake is to communicate more, ask to see the work in progress of the game and ask for more updates on the progression of the game. This may help in providing feedback on time if there is any.
Testing
Prototype
When testing the prototype myself, there where some movement issues and tweaks I needed to fix. Those include the taxi player slide on the road like ice so I needed to make the player go to a slow stop when they remove there fingers of the keyboard another tweak is to optimise the speed of the player movement to make it move just like an average car or taxi (having it too fast makes in uncontrollable but making it too slow would feel draggy.
A way I fixed the movement is by following the YouTube tutorial I found where it provide guidance on how to make real life driving physics in a 2D top down game. This video helped me to learn about coding in Unity and understand why certain mechanics may not work as I hoped and I overcame those issues by understanding how certain coding works.
I shown others my prototype and they have also tested it. They told me that the prototype is good and there is a fair amount of game mechanics that work well together. They also stated that as a prototype, it is really well made and the style is basic but good for a first build.
I believe that the mechanics included (driving, pick up people/ drop off people and a score system) worked so well and I have successfully created a great game loop for a prototype.
Main Game
When testing the main game, I noticed that our game is pretty good in functionality, style, artwork, level, narrative and game loop. The overall final game works great (being made by three people) in some cases.
The positive part of the testing phase was that most of the mechanics worked pretty well, and the controls are easy to learn. Also the guards having their own ai can teach the player how to sneak by the guards.
Ever since our fourth member left, the quality of our games have dropped significantly and it is expected that the fewer people to work on a game the lower quality the game will be.
So judging the game, based on the dev count we did a pretty good job at making the game as a collective group of three. There where a few negatives when testing the game. Those include a mishap with the camera in the second level of the game (the camera being too uncomfortably close to the character compared to the first level). Another issue we faced was when we tested the game, it was nearly submitting time.
The lessons to learn from those mistakes is to have more communication and inform the coder that he is not being present enough in the lab sessions we where given (being present means he can show the game version to us at an earlier time so we as creative artists can give feedback) and learn to time manage more properly so the testing phase isn’t as late as it was.
Time Keeping
Prototype
When it comes to time keeping within the prototype making part of the project, I believed that I did a great job. It went smoothly like I hoped and I’m pretty proud of my self in that part of the course.
I successfully made a decent prototype of a game that has a good game loop, working game mechanics and a pleasant art style with good time to spare for practising the pitch and adding my parts of the course to the overall collective power point for the team.
In terms of learning something about this part of the course (when it comes to time keeping), I need to focus on replicating what I did for the prototype (preparing, completing and focusing on getting the prototype right and have time for the other parts of the pitch) because It worked for me and I wish to use this skill for future projects.
Pitch
When it comes to time keeping within the pitch part of the project, I believed that I had plenty of time in practising before the pitch starts. The pitch went fine. There were some good parts of the pitch like me having practised the pitch, resulted in me presenting it better.
However, there were some negative things that happened during the pitch part of my course. Those negatives include me spending too much time talking about my part of the pitch and leaving others little time to speak and we did not practice the pitch together as a group instead practiced by our selves resulting in the group not doing great when presenting the power point.
The few things to learn from this is to write less information when doing courses like these and communicate to others that when doing the pitch, we should practise together not just alone.
Main Game
When It comes to time keeping for the main game, we did a decent job in completing the main game and kept with the deadline for that part of the course. I believe that we, as a collective group, have done amazing in time keeping for the note making, prop making, level making and slightly on progression.
There where some cases of poor time keeping where the game is about to be finished and the deadline gets closer and we haven’t even tested the game yet. This is due to a lack of communication which made us test the game late. I did feel that for the last moment of the game production assignment was a rush due to our only coder being responsible for giving us (creative artists the working file for the game and the working video walk though.
A way I could improve and learn from that is to have better communication skills by asking to test the game early. The fact that our coder gave us the game late a good reason why we tested the game late.
Conclusion
In conclusion, I enjoyed working in this course and have learned a lot when taking part of a collaborative games project. I have a better understanding on the production part (making the prototype and proving props for the team), I know that I need to improve my communicational skills (due to the issues we faced), I have become more emotionally stronger when things go wrong or they don’t turn out well (with the fourth member leaving us and communication has been missed resulting in poor design choices). I plan to learn and get better for future courses and projects
References
Coco Code (2021) Points counter, HIGH SCORE and display UI in your game – Score points Unity tutorial. YouTube. Available online: https://youtu.be/YUcvy9PHeXs?si=CMLaqgMyGK-Ff4-L [Accessed 19 May 2024].
Pretty Fly Games (2021) How to create a 2D Arcade Style Top Down Car Controller in Unity tutorial Part 1. YouTube. Available online: https://youtu.be/DVHcOS1E5OQ?si=l6S04keePrNq6ErU [Accessed 19 May 2024].
