top of page
Search

CAGD - 370 Mobile Game Postmortem

Liam O'Hare

In my 370 class we were given a group project to make a small mobile game. My team included three members: me, the level designer, Pablo, the programmer, and Colin, the lead. Here is a postmortem post covering the process of making the game, what went wrong, what went right, and what I will do in the future for similar projects.


What went right


Firstly I am super excited to say our team managed our scope excellently. There was never a moment in our development where we felt overwhelmed or had to cut out necessary pieces of our game. Every one of our needs were accomplished, along with the majority of our wants and dreams. The only large card we ended up cutting was a player movement mechanic that we found didn't fit our playstyle through playtest.


This leads to the next strength of our team, we took playtests very seriously. After our first mistake in our kinetic prototype we quickly learned to honor the playtest and perform them frequently. I was adamant on this and my team respected my opinion when it came to my feedback. I will admit, I had the most to say about our game's gameplay, but thanks to my teams listening as well as flexibility we all were able to come together to produce a product that was fun and replayable.


Finally, as stated before, our team communicated phenomenally. We all listened to each others concerns, frequently met and made every team meeting, and would talk in between and discuss our game's progress. This doesn't increase work load as much, but it goes a long way to help make sure everyone is on the same page. My team lead was consistent with assigning cards and checking in with teammates and definitely helped me stay on track. My teammates were also very dependable, when I had work that was too overwhelming teammates would either help explain or take work off my plate in exchange for other cards. This was huge for me and helped me feel like I was frequently helpful.


What went wrong


The main issue with development on my end was the cards I was getting. As a level designer it took lots of time before I ended up receiving relevant work. This meant I had to handle some of the early pieces of the game, which ended up leaking in my backlog later in development. While this wasn't impossible, my programming wasn't as well done as Pablo's, who was our assigned programmer. This meant I ended up making a few enemies for the game that weren't properly set up for late development and implementation. This added for some rough spots in development and slowed our team down. This didn't only affect my pace of working but hurt the rest of my team as I would have to ask for help frequently. I wish this didn't occur in the first place, and I hope to be more vocal and insistent on me staying in my role for the future. Had I been the programmer for this project I would have read up and done more standard practice for these cards, but I had prepared for a level design position which hurt the work I had to fill in for early stages. This was my fault and hope to avoid this in the future.


Additionally in the future it is important for me to expect lots of iteration on my levels. It is hard to build newer, more difficult levels when mechanics change down the line. What kept happening was changes would be necessary in my backlog and stop me from finishing new levels, and this would happen repeatedly as we changed core mechanics throughout the development. It would have been smarter to make the middle and last levels first, and to continue refining them, and leave the tutorial level for much later in development. The tutorial level likely could be one of the last things I build next time as it was hard to gauge the difficulty players could manage until many playtests were carried out.


Another issue was me overestimating the challenge players could handle without frustration. I am a player who enjoys small quirks in game controls, so I embraced lots of advanced movement and skill gaps. I overestimated what players were okay with learning and putting time into. It's hard to adjust my sense of fun to another players but it was a learning experience to adjust my views to the playtest population and our target audience.


The future


I plan to continue focusing on playtesting as well as paying attention to my target audience. I also need to implement a pipeline that doesn't output levels in chronological order. This will allow me to understand how the game is played before teaching the player through tutorials and early levels. Finally I want to communicate more with my team and look for more work related to my role rather than hurting the team by taking jobs that I can't manage. Of course I can also learn more about scripting to better help my teammates in the future.

Recent Posts

See All

MADT Blog 10

The open letter asking for a pause on AI neural network development is in my opinion necessary. This pause on development is good,...

MADT Blog 9

The Internet of Things is a developing technology which uses many devices in conjunction as well as the internet to manage the existing...

Comments


bottom of page