Final Week & Postmortem – Noah

The project’s done. This week was spent putting everything together. Fixing bugs and making sure everything works to the best of our ability.

For the final sprint, I worked on implementing player health, the respawn mechanic, and several bugfixes.

Player health was in the build for a while, but issues with colliders kept keeping health from properly updating. Tom and I fixed the problems, and the player health UI now updates to reflect the player health variable. I also worked on implementing the respawn mechanic. After one player dies, the camera will adjust its player following code to only follow the remaining player. When the second player dies, the game will fade to black with a game over message before reloading the level.

I also worked on bugfixes. Most of my involvement with bugfixes was helping the other programmers when issues arose. We worked hard through the week to look over our code.

The bugs I personally fixed were related to the sister’s animation, her shield, and the brother’s slingshot. All of the sister’s animations looped, so when she aimed upwards, she continued to look up over and over. She now only looks up once. I also repositioned her shield to be drawn closer to her body, and to be taller. Now, enemy bullets won’t sneak past her shield before she can pull it up. The brother’s sling shot fired in odd positions depending on the direction you were aiming at. I cleaned up the code so that the slingshot firepoint would stay consistent.

The good of this week was that we were able to push hard into building a vertical slice of the game.

The bad is that we didn’t have the time to polish and bug test as much as we’d like to.

Post Mortem

This was a interesting project to work on. I enjoyed working with this team: everyone had a strong work ethic and our project management kept us on task.

The programming team was able to learn source control quickly, which greatly helped our ability to save and share code.

Unfortunately, we didn’t much time to work on this project. We worked on this game as part of an introductory course, so many of us were learning our development programs and tools as we were going through the weeks. If we had a few more weeks of development, we would have more work time in which we all understood how to solve our tasks.

We also overscoped. Even for a simple sidescroller, we had too many features, which cut into polishing the core mechanics. In the future, we should focus on the minimum viable product before exploring other ideas.


Last Week and Post Mortem – Chris

This week was most definitely crunch time – the last push before our “finalized” game. As far as art is concerned, the environment was still too short, and so Syd and I worked together to make tons of extending, seamless assets. After all, we didn’t want the environment to be repetitive. Syd made a ton of environment tiles, and while I also made a couple seamless sand tiles, most of what I did was sprite sheets full of environment decorations and place-able assets, such as anchors, rocks, seaweed, etc. Shout out to John also for becoming a level designer and arranging it all.

Positive: I learned a lot about seamless assets, sprite sheets, and new ways of importing into unity.

Negative: I have never tried to make art at such high speeds, and it was incredibly stressful. Crunch time is not fun.


Post Mortem:

I think that so far at Drexel, this is the most “industry” experience I’ve had so far. Never before have I worked on a project like this with such a large group, and that alone was new. Usually when working on games, I’m doing a bit of everything rather than having a specific role in a department, so that was interesting. Communication definitely was important. I was also really surprised by the scope of our game, and how large it ended up being. I remember thinking that the other group in our class, Orcs in Love, had a dangerous scope. Ours ended up being huge, but also manageable, and only manageable through extreme task management and staying up at inordinate hours of the night.

I suppose in terms of skill, I learned a lot about specifically making assets for games. Sprite sheets, importing, making vector art for rigging, simplifying character designs, color theory to direct the players eye – making something at this scale in such a short amount of time forced me to learn a lot on the fly, and even though it was stressful, it was fun. The positive to this was really just going through the whole process, the ups and the downs. It was cool to see and help a concept we were all excited about become a playable product. The negative though, was the stress, especially around crunch time,  but now at least I know to avoid it.

Postmortem — Erin

What a term it has been.


From project pitches to idea selection to the chaos of executing a project of this scope in six weeks to trying to get eight Drexel students in the same room at the same time, I’ve certainly learned plenty. This project has been, I think, a combination of two cliches: drinking from a firehose and trial by fire.


Positives: Well, I learned a lot. One of the best aspects of this project was being able to give my programming muscles a workout since they haven’t had all that much attention since I left my train job. Plus, trying to keep just myself organized was a wild ride from start to finish — project management did what they could but making sure subteams were coordinated and even minor things like getting everyone on source control or getting people in the same room proved to be huge challenges. It was a rough go for the first couple weeks and still wasn’t totally smoothed out by the end, but this was one of those experiences where one comes out the other end with a ton of experience under one’s belt.

This whole project was an exercise in Murphy’s Law. I learned that I can survive on three hours of sleep and that Monster is only semi-effective for keeping me up after a certain number of hours. I drank a lot of coffee. So I suppose the best thing was learning how to prioritize. When everything breaks, one has to learn what to work on and what to let go. Rinse and repeat.


Negatives: EVERYTHING IS ON FIRE. Seriously, though, with everyone having to wear multiple hats and many people learning new software and skills for the first time, this project was far too much to take on in the time frame we had. Many things broke and we only had time to fix so many; we were forced to start a hierarchy of importance for features. Some things we wanted got left out, and we were forced to skip over some pieces in favor of others, and there are definitely some broken things in our build.

Also, the times we had with what were seemingly huge problems that turned out to be tiny, and vice versa, were extremely frustrating.

But mostly, our struggles involved getting everyone’s work to fit together as it should (Noah spent many sleepless nights fixing code issues that could have been avoided if we got everyone on source control earlier). We faced challenges in just the sheer volume of work that needed to be done: 5 enemies, one boss, two characters, powerups, player health, and a level that would last as long as we wanted our slice to just proved to be a massive amount of work. We all put in late nights and/or long days to get the game to its current state.

And so I reiterate: what is sleep.


Final Thoughts: I’m writing this postmortem at 2:30 in the morning because I’m still up making fixes and additions to the final build which we’ll be presenting this afternoon. Even if the final product isn’t ideal, I’m darned proud of our progress and everything we learned as a team. These people were good to work with and I am happy to say I’m going into the rest of my education and my career with this experience in my pockets.

Looking back and to the future.

Looking back at this project I have come to the realization that time management and management of the team members is the most important thing. Initially everything was great. We were all so excited to create a game with our own narrative spin. The first thing that went right was the fact that we are agreed on one game and we all allocated ourselves to tasks we felt we would be able to accomplish.

So First good thing was -Diplomacy.

The second great thing to happen was source control. Erin and Noah introduced me to source tree (a program I didn’t know existed), it allows for pushes/pulls of any files. Pushing puts your own files in a repository. While pulling, grabs your teammates “push”. This made getting everything together way easier than I had previously imagined possible.

Second good thing -Source Control.

Here is where things get messy. Management was a serious and critical problem I felt throughout this entire development cycle. That’s all I’m going to say. The amount of resources we had to work with was poor and the team management didn’t help. I have learned from watching that if I eventually want to lead my own studio, task completion must be iron-clad and things need to be addressed from the beginning. If something needs to get done, do not give them a option, get it done. We should not be dancing around features with 3 weeks left.

First bad thing – Poor Resources/Management

Second thing that destroyed many of us was time. I do not feel that with my workload on top of this class that creating a fleshed out game is even possible. We did not have the time or knowledge to get to where we wanted. While I’m very happy with my team and what we have accomplished. This was just too much. Some people working on one day finishing a task only to here that something is missing because someone wasn’t working yet. When you go to test everything breaks and you spend the rest of the waking hours bleeding your eyes out. I personally felt this when I had to recreate our level. I can only imagine what Noah felt like the past 5 weeks. Since, he held to main build for the entire project.

Second bad thing – Time (not enough)

So after that semi-rant, a couple of lessons I have taken from this is one. Rule with an iron fist or your employees may procrastinate/complete tasks leisurely. Leading to a worm hole of problems and sleep deprivation. But more importantly, make sure that if you set a release date for your game that it is actually possibly to attain. Give your team adequate time to make your game/vision possible.

In the end this was our first time creating a game, for some, first time touching unity, first time leading, first time animating, and first time programming for a game.

-John Harvey