Keep Dreaming – Post Mortem

Introduction
This post is about the development process of the game Keep Dreaming, of which I was the lead programmer for. The struggles we’ve ran into and some of our working pipeline.

Concept
During the concept phase we wanted to create a game which contained both gameplay and narrative. Our assignment was to create a demo which would focus on only narrative and no gameplay elements. We as a group decided to ignore the no gameplay part of the assignments as none of us would enjoy creating a boring game.

With that in mind, we discussed the style of the game. When we all agreed upon a concept we all wrote down our own version of the concept in order to see if everyone was on the same page. It quickly turned out that not everyone had the same idea, so we discussed the concept more and repeated the process untill everyone in the team agreed upon the concept.

Our concept was to create a mystery dungeon style game in which the “level”, which we refer to as floor, would be procedurally generated. It would contain predefined rooms which we would use to script the narrative and progression. A room can contain enemies, items, npc’s and scripted events.

KD_prototype

To create and manage all these different things we wanted to create tools for the floor, tiles, consumables, equipment, room and dialog. This would allow a workflow where the designer can change parts of the game without having to interrupt anyone else by requesting things to be added.

editors

Planning
We made a planning for the entire project right from the beginning. This would allow us to see the scope of the project, what tasks still needs work and if we were going to have to cut out features or not. Right from the beginning we realised that we were overshooting what would be possible. For the programmers we were supposed to plan for 384 hours. Our estimate for everything we wanted to have in the game was around 700 hours. The same thing happened for the art side, but in less extreme numbers.

After learning about our issue we decided to cut out features before we even began on production. Our final estimate was still about 100 hours over the target, but we settled on that as some members were willing to work overtime to compensate. Looking back this was a bad idea to allow this to happen. This caused a long stressful first couple of weeks. Adding up to that we forgot to include the time it took to manage the team, and create the planning every day. So our estimate of 100 hours over target would increase even more as the project continued.

Teamwork
Simply put, the teamwork throughout the project was bad. Everyone was assigned a role at the start of the project, but this caused people to tunnelvision into their respective role and not care about the project as a whole. When asked for a specific detail, people would say that it’s not within their role and not help eachother find the answer.

Next to tunnelvision, there were personal clashes. Some team members are not compatible which eachother and were not capable of being professional enough to put that aside during working hours. This caused for a mostly negative atmosphere when everyone was sitting at the same place and trying to work.

The final result
Even though the entire process was sub optimal, we managed to create a fairly decent game considering we created our own engine in C++. Most of the systems were implemented, and we had a nice set of tools.

KD_Alpha