We have been reading all the comments you guys have left about “What Happened to Michael” and we thought you could be interested on how the development went so, we’ve made a postmortem!
What Went Right
The game
This is true in regular game development and even more when making a game for a Ludum Dare. The fact that you have to ship a game, that can be somewhat played from beginning to end is something that must not be overlooked. That’s the most important thing!
We always try to have a minimum shippable game as soon as possible and then add layers to it to make it better. Sometimes we get the core of the game right super quick and sometimes we have to deal with more problems than expected and the core game takes longer to be done. But this is an adventure game! Our first ever point&click adventure game! And we were close to not having a complete game to ship. But we focused on that and we did it!
The vision
Also worth mentioning is the fact that we shipped the game we envisioned on Saturday morning. More often than not, the projects we want to make end up not being possible. Maybe because the scale is too big, maybe because it’s not technically possible, or because the game is just not fun. Not to mention when each team member has a different vision in their heads. What does that mean? It means you lose effort and time instead of just getting all the effort in one single product.
We were all aligned to make this vision a reality and all components of the game were made to complement each other. The end result is a very cohesive game, and a game that looks like a “3 days of effort” game, because all the things we produced made it’s way to the final game.
Splitting programming tasks
Having two programmers in the team is a blessing when the work needed to make the game can be split, so each programmer can work independently.
This game had a big core gameplay task that, if assigned to just one programmer, would leave the other programmer with little amount of work until some assets were ready to be added to the game. We didn’t want idle people but sometimes it is better to leave just a single person dealing with a big task. When we realised this, we think it payed of. Save the core gameplay! Save “the game”!
The other programmer had to wait a bit for art and sound assets to be done, but alas he got a lot of work to do on texts aesthetics, abduction effects, and little details that add quality to the game!
Trust
When building something as a team, trust in your fellow team members is a must. This way everyone can concentrate on their work and know for sure that, whatever other members of the team are making will be great.
For those things we were in doubt, we knew we could ask for help to others and get good feedback when needed!
What Went Wrong
Communication, tasks and time management
One of the big problems when making a game for a game jam is usually we all want to start doing our work, and forget about everything else, because there’s a lot of work and little time! But we must do some team work before that. Ensure we’re aligned in our vision, make a bit of pre production work so we design the game, the software and assets in a way that help us get the job done as quickly as possible, and make a little planning of the tasks and time we’ve got ahead.
This is usually not super easy to do because designers, programmers and artist all speak different languages (not literally). We’ve done together as a team several Ludum Dares, always at Undercoders’ offices. However this time it was different. One of the designers, and producer (that’s me ^^/) was in a different city that weekend, and the remaining three were at a new location. The university facilities were the designer and artist of the game was, at the same time, organizing a Ludum Dare onsite and helping his pupils. And this place had a fixed schedule and was open only from 9 a.m. to 8 p.m.! That made things a bit more challenging than usual!
What this meant is we were not able to clearly identify a design for the dialogs that would help programmers implementing it and vice versa. Also it took time to decide on getting just one programmer on the core gameplay to try and save the core, and set the programming tasks not related to the core.
Scale
Having played classic and modern adventure games we thought our one room game was so small that we could just write the dialogs on a Google Docs doc with a few notes on dependencies and there would be no problems. Also we chose a way of programming the whole thing that made adding or fixing texts a bit difficult but… it’s a small adventure, there won’t be that much text right? Wrong.
We underestimated the scale and work needed to make even the smallest adventure game and we payed the price. As we added more text, we started realising how confusing it all started to become. We had to cut the number of objects down to just those that made the story advance and we had one programmer exclusively adding all the text, fighting the mess it all had become.
31 objects to interact with were planned
A bit late though, remembering a post on Ron Gilbert’s blog, we transformed the document into a tree of dependencies.
Lack of iterations
As mentioned before, we like building the minimum shippable game we can and then add extra stuff in order of importance. This time, the minimum shippable game was done a few hours away of the deadline and we were all tired (here in Europe, Ludum Dare ends at 3 a.m.).
So even though we could play the game from beginning to end, there were some important features to add. Features that were designed since the very first morning, but that we didn’t have time to add.
The game was not supposed to show as clickable objects those you cannot interact with at a given time in the game. But they were there! And there was no time to fix that so we had to add that sentence everybody hates now: “Not Now”. Otherwise the game would look broken and players would stop playing.
We wanted to have text we’ve read before marked and be able to skip the texts. We had time to add the ability to skip text… but unfortunately very close to the deadline we found an important bug related to that feature and we had to remove it entirely.
And so on…
Bugs reporting
This one is a classic. You feel the deadline approaching, test the game and start reporting bugs skipping all the right procedures to report bugs (say Trello, bugzilla…) and instead report them through Slack or just talking directly to the programmer. Which causes some fixes that were feasible (like changing the unreadable blue text color) to get lost, like tears in the rain.
Conclusions
I cannot overstate enough how important Pre Production is. We got right some things on pre production, like aligning all minds on the same vision, but we did not on how to make it easy for the programming and the writing to come together nicely.
Making a good pre production saves a lot of time while in production. Never forget that! 😉
Tags: adventure, LD37, Point'n'click, postmortem
