Forgotten Astronauts team at DigiPen Institute of Technology
Team members:
Spencer Peterson - PRODUCER and PROGRAMMER
Brady Menendez - PROGRAMMER
Shiv Bhatnagar - PROGRAMMER
Jesse Vanselow - PROGRAMMER
Zach Dolph - AUDIO PROGRAMMER
Christien Ayson - AUDIO LEAD
Hugo Anquier - LEAD DESIGNER and UX/UR DESIGNER
Garrett Canlas - SYSTEMS DESIGNER and UI/UX DESIGNER
William Harline - CREATIVE DIRECTOR and TECHNICAL DESIGNER
We all came into this project very excited for multiple reasons. Part of that excitement was because we were working in Unreal instead of a custom engine. We felt it would open up a lot more avenues. Designers could get to work on the level design and game mechanics immediately. There were no huge technical problems in the underlying engine to get working before we could start on the project. Unreal is also one of the main standards for an industry level game engine. We were excited to learn how to use it and add it to our skill sets.
The idea for the project started during the summer, but changed when we fleshed out the team more at the start of the Fall semester. When we added in 4 more people in the Spring semester, some aspects of the game changed again, mostly to fit within the scope of the project and also to add in the unique skill sets of the new team members.
Over the course of the two semesters, we learned a lot about Unreal and about working together. We also learned a lot more about the game design process and why certain problems can arise in larger projects. Many things we did well. Some other things went poorly. Nothing catastrophic occurred however, which is a testament to how well we all worked together to resolve the issues that did come up.
In this post mortem, we will go over what went right, what went wrong, some things we could have done to prevent issues, and lastly, some cool things we all learned as a result of working on this project.
What went right
First of all, the game is really fun. There’s a lot of potential in the idea we chose, and we think we tapped into it really well. It really shows off the amount of work we all poured into the project. It took a while to get to that point though. In the beginning, we had several prototyped mechanics. We settled on the rail grinding as the main mechanic with a grapple hook and explosion as sub-mechanics. A short time later, we also had a time bubble mechanic as well. The combination of these created a really interesting space that the player had a lot of freedom in. However, the number of tools we were giving the player was too much compared to the amount of time they had to learn and use them. The time bubble in particular didn’t fit well with the rail grinding mechanic and would have taken too much development time to make it work. So we cut down to just the rail grinding, the grapple hook, and simple shooting. Choosing the grapple hook as the sub-mechanic was hard. Some team members felt it wasn’t as fun as the other mechanics. It was the one that best fit our space though, and making it the only sub-mechanic gave us the motivation to make it fun.
We never had a crunch period. It is now the week of submission, and no one is panicking trying to finish a crucial feature or level. We scoped the project really well for our team size. When we had problems, we accurately rescoped to what we could handle. A lot of ideas, some that were implemented quite far, had to get cut, but the end product is so much better because of it. We also were all proactive in solving problems as they came up and taking care of our tasks.
We were made aware of critical problems quickly thanks to an automated build bot that ran every night. The bot would build the project and upload the results of it to both our Google Drive and to our Slack. When a build failed, the bot would parse out the errors and post those errors to Slack. Because this bot ran at 6 am each day, we knew what had to be fixed the moment we woke up. Problems were usually fixed within the day. Partially in thanks to this, all but one of our milestone submissions went really smoothly. The one that did not was the one submission we had before the build bot was active.
Lastly, we all worked well as a team. There were no personal issues. Any arguments or issues we had with each other were resolved within the day.
What went wrong, and how we resolved it
The largest problem this project had was vision. It was repeated to us several times during the Fall semester and a few times during the beginning of the Spring semester: we didn’t have a clear vision of what the end product would be. We thought we did, but instead we had a vague, excited idea of what we wanted. We were having too much fun playing with our various mechanics and fitting them into the game. At the beginning of the Spring semester, we had a pile of mush. It was fun mush, but it was still mush. This was made worse when we gained 4 new team members. Their vague ideas of what the game was added into the mush we already had. That was when we realized we were in trouble. Right after milestone 5, the first milestone of the Spring semester, we had a lengthy meeting about all the aspects of the game in order to create a Game Design Document. We defined the design pillars, the vision, and what the end product would be, and we wrote it all down in an easy to see location. This meeting lasted several hours, but it got everyone back on track.
The next major problem is one that has plagued us more so during the Spring semester than the Fall semester. We had several communication problems. We didn’t know how much progress another team member was making with their tasks. Miscommunication on Slack was also a problem. Part of the reason for this was a lack of daily meetings after Spencer got his new job and we were forced to put Brady in as the new producer. Several team members would also show up really late to lab times. This lack of in person communication made telling each other about our progress difficult. Many of the miscommunication problems could have also been resolved by having more in person meetings since a lot of context and emotion is lost when using text-based communication on Slack.
The last problem we had was with Perforce. There were two main problems we had. The first was when the Perforce server for the school went down for several days. Fortunately we had backups of our project and we were able to continue working on the smaller tasks we had. The second issue was our own fault. Some files got checked into Perforce that shouldn’t have been. This effectively shut down our access to the project until we fixed it. We did fix it within the day, but it took several hours to do so. There are two reasons it took so long to fix. The first is that we were all used to SVN and its terminology. Perforce’s terminology is really confusing in comparison. It also is not consistent with the terms it uses. The prime example of this is when attempting to revert a block of changes. Perforce has a “base”, “target”, and “source” when looking at file changes. In other places the terms “base”, “theirs”, and “mine” are used. Both sets of terms are used when attempting to revert multiple changelists. The second reason, and part of why we didn’t understand Perforce’s terminology as well, is because a lot of check out and submission of files is handled through Unreal’s editor. It makes things really nice but allows team members to be ignorant of how Perforce works if they don’t have to interact with external files often. Had we been using SVN, we could have resolved the source control issues almost immediately.
What we could have done better
This section is about what things we could have done if we had known better earlier in the project, or had remembered to do but never did.
The most obvious to all of us was to write the Game Design Document sooner. None of us had such a major problem with vision in the past, so it didn’t occur to us that having a written document detailing the game would be so necessary with a team project like this. Because we had this problem, now understand how industry problems with vision can occur. So many issues can arise when project leadership changes, new members join the team, and changes with the project specifications change. We learned recently that some of Anthem’s issues arose because of a lack of vision. Having our own problem with this was a little eye opening for why large studios can have this problem.
We had completely forgotten about doing code reviews. Had we regularly done code reviews, many bugs and refactoring issues could have been resolved early on. As some examples, an early level blueprint was set up in a way that couldn’t support checkpoints. Using events and breaking it up would have been a lot smarter, and easier to edit. The initial code for the rails was some of the most ugly blueprints we had created. It was a very complex system and was also one of the earliest blueprints we had created. Had this been reviewed by more members of the team, it could have been much nicer and avoided the huge refactoring it had at the beginning of the Spring semester.
Cool things we learned
This project was the first time we had to really use event based programming. Unreal really pushes to use its events, and it is so much more powerful when we do. It was really eye opening into how powerful this method of programming was. As long as we could get a reference to an object, multiple objects could react to an event that another object sent out. This was really important for both the rails and the grapple in order to get a smooth detach from the rail when the grapple was fired while riding the rail. However, we also learned that debugging events can be difficult since it’s hard to know while debugging all of the objects that are receiving a certain event.
As many troubles as it gave us, we now know Perforce’s terminology. We also appreciate the system showing us who has what checked out. This helped us know immediately who was working on what, and who to talk to about certain pieces of the project. This was a huge benefit with Perforce over SVN since many of Unreal’s files can’t be merged if multiple people worked on the same file.
These next few points are some cool things individual team members learned. Our audio programmer, Zach, learned a lot about wwise and Unreal integration. He had to compile data patches between the two and learned a lot of tools with both that he’ll be able to use later. William learned how to compile a C++ Unreal project from the command line, and generate wwise soundbanks from the command line as well. He also learned how to have a python script parse through the Unreal log and upload things to a shared Google Drive that anyone could access. Garrett got a lot of practice with UI research and documentation that he’ll be able to turn into a workable skill.
This is a small sample of the many things we learned in the project. The ones that were explained here are the highlights that stood out to us. We all accomplished our goal of learning how to use Unreal engine and feel that we could confidently use the engine in another project.
Conclusion
Building “Rail Runner” was difficult. It required a lot of work from all of us. But we can say that we all enjoyed the project and we all learned a lot from it, both from where we went wrong, and from where we went right. It has helped show us industry level problems and it introduced us to industry level tools that we can use later. We are very happy with our work and are proud with what we accomplished.