What happened to Michael? Postmortem

Posted by (twitter: @BubsyPoochies)
December 18th, 2016 11:10 am

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!

004

 

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!

002

 

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.

objects

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.

diagrama

 

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.

003

 

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: , , ,


2 Responses to “What happened to Michael? Postmortem”

  1. wujood says:

    Since you had a problem with the combination of writing and coding, what would you change next time? I am asking because when you say you code a framework first, then you are giving away a lot of time. And what will the text writer do in that time? if they write the texts in a document, then it takes a lot of time to put that stuff into the framework afterwards

    • BubsyPoochies says:

      That’s a great question… it’s a complicated matter for sure, but sometimes it takes time to save time. I mean, waiting for the framework for be prepared in an efficient way may save a lot of time afterwards.

      Before writing the whole story, maybe it’s a good idea to set up an scheme or outline, stating dependencies between objects, rooms, characters etc. That will take a good amount of time, but will set a solid base to when it comes to developing dialogues and, probably, enough time will have passed in order for the programmer to have completed his part. I guess that’s why planning( / pre-production is so important, much so if the time is scarce.

      Of course, there’s a lot to improve (after all, it’s just our first adventure style game) 😉

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]