Kevin Carlos – Personal Postmortem

Things that went right:

I had never really worked on such a large project within Unreal Engine 4, nor with blueprint visual scripting so much. As we had used Unreal Engine 4, a new software not taught in classes, we had to teach ourselves much of it, and I am not extremely comfortable within the environment, a major plus since it is a more standard industry engine than Unity.

In terms of general programming knowledge and skills, this project has really pushed me to become a better programmer. There were many times where things would break, or I would have to figure out a pretty advanced mathematical formula to handle some kind of movement. Because of situations like those, I feel like I’ve been pushed to think much more creatively, and have become a much better problem solver as a result.

Lastly, I feel like I have learned much more about more standard programming practices within a group. In many of the project I’ve been in before, either I was the only programmer, or I was an artist on a team. I never really had to deal with multiple programmers and artists all working on one project together. While we could have had more organization, I think that we divided our work quite well, made proper use of our source control, and kept the code commented and at least partially organized.

Things that went wrong:

This entire project is a case study of students overreaching and going out of scope. While I believe what we had originally was in scope, a local couch co-op multiplayer game with simple game game modes such as capture the flag, I feel as though a combination of us being pushed to make a more unique game, faculty feedback, and our own over confidence led to us adding more and more during the fall term, until it had all become so integral to our game when we realized it was too much.

The primary cause for nearly all of our bugs was the decision to use networking. While we had some experience in networking before, we had no where near enough to make a project of this size and scope, especially since Unreal Engine 4 lacks the amount of documentation that something like Unity has. The use of networking literally tripled our workload as programmers when we wanted to add something new, as it would have to work on the server, client, and then in between the two, and quadrupled the time we would have to spend bug fixing. This led to much more time being invested in trying to fix things that were partially broken solely due to networking.

Lastly, several terms this year were also filled with many production classes I was taking to fulfill my minor requirements. Taking classes like Character I and II, Experimental and Serious games, and Compositing while in Senior Project was a terrible move for me, dividing up my time preventing me from working as much as I wanted on this project.

Lessons I’ll take from this project…

Organization is key. We weren’t as organized as we needed to be and we suffered for it.

Don’t overreach. Even if people don’t think your game is unique enough, I think having a less unique game that is more complete is more important.

Be more open to change. We were stuck for several weeks, and didn’t want to pivot because we thought we were too far in. If we had pivoted in say winter, I think we would’ve been able to reduce the scope of this game enough to have a much better end product.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s