Skip navigation

Monthly Archives: April 2014

The EAE day happened. We had the game running on two computers, and everytime I looked over someone was playing the game. We recieved a lot of great feedback, and people in general really liked our game! Its amazing how a 2 week prototype, which was not even pitched earlier, got more love and made it this far, than the one game that everyone thought would definitely be THE thesis game for our team. We had some problems, but it was nothing a couple of clicks couldn’t solve, and since we had two members always next to the game, people were able to play it as much as they wanted. I don’t know what else to say, other than that it was a successful day, and we have made a fun little game, which are going to continue working on over the summer and into next semester, when we have to submit it to IGF. Before I leave, here is a short gameplay video, and here is a pic of Roger failing at our game.

The game is done! For EAE day tomorrow at least. EAE Day is the last day of the semester, where all of us show our games to industry people, people from the Unviversity, and the general public. We recreated the hallway from the initial prototype, and a new stairway of spikes level for tomorrow. Last week was, in the words of Matt, crunch time, and it certainly felt so. I was up on multiple nights, putting stuff in, making sure stuff added y other people was working, and in general hoping nothing breaks. Not as fun as it sounds. But yeah, it was a great experience working on Unreal, and although we faced many problems and got stuck in many places, with the added disadvantage of limited documentation(the guys at Epic are still updating it continously), it was tough, but then who said grad school is easy? In the end, we have a product we are all proud of, and I’m really happy with my team. Say what you will, but these guys know how to get together and get stuff done.

Also, my experience being the lead was very different from the usual development experience. The rest of the team would look to me regarding engineering questions, I was the one who delegated the engineering tasks among the team. This involved knowing the strengths of each member, and giving them tasks that they would excel at. It was also my duty to make sure that the work was getting done, though I didn’t really need to do that because this team is just too amazing. If I had one complaint though, it would be that between Blueprints and short deadlines, I didn’t get a chance to write code. Currently the entire game works on Blueprints, but I know that all of the engineers would have loved to do it through code. Considering that Unreal uses C++ and not a scripting language, we were really looking forward to programming, but didn’t get the opportunity. But yeah, I know that as we continue development, we are going to dive head first into coding, so I don’t see this problem arising again! Well, wish me luck for tomorrow!

So we decided to work with Unreal Engine 4 for last two weeks, and then decide whether we are sticking with it or going back to Unity3D. I think the fact that we unanimously decided to go with Unreal says a lot about it. It has some amazing new features, two of which are really helpful for us. These are dynamic NavMeshes, and Blueprints. Since the game is all about sending out future versions of yourself, seeing how they die, and use that information to navigate through the level safely, we really needed a way for AI characters to be able to move around the level easily. Unity has NavMeshes, but they are static and need to be baked beforehand. The Unity build, instead of using those NavMeshes, used a systolic array system developed primarily by Skip. Unreal NavMeshes are created with a single click, and the AI can move anywhere on the NavMesh through a single function. The other great thing, Blueprints, is also amazing. It allows non-engineering members of the team to contribute greatly to the development. We’ve had Tony, James, and Brenton constantly working in Unreal, and making the life of us engineers easy. Tony and James have been prototyping various level ideas, and Brenton has been experimenting with what we can do in Unreal for our game. This way, the engineers have been able to focus on core tasks, which also resulted in a speedy development. Although the one problem we have faced is source control. While Unreal has support for SVN, it isn’t very good, or intuitive. We think that Perforce support would be much better, but we currently have licensing issues for Perforce so we are going ahead with SVN, at least for now. We spent the last two weeks setting up proper source control, and we also have the “Premonitions” moving around, almost like we want them too. Development is going on full speed!