Post-Mortem: Mini-Jon & Mini-Maple Game

A Quest To Simplicity

When we set out to work on Mini-Jon & Mini-Maple: The Labyrinth, we understood early on that it would be a challenge. The budget was low, our team was already busy on bigger projects and let’s be real: do you REALLY want to make games for young kids? Reasons to say “no” and move on were many but still, we didn’t hesitate long. Why?

The Context

When you’ve been working with a client for years, there’s a special connection that tends to form. Since we knew the client so well, we felt at ease and knew it would be easy to get our ideas across. They would understand the limitations of the budget and they would also trust us to do our thing so that we can make the game fun. This long history with the client was certainly a deciding factor.

It was also the 3rd game we were going to make with them and our previous 2 (we worked on “Turbo Aero” and “Destructovor”) had a very solid record. We reached the top of the charts with the previous titles! Radio-Canada has a vibrant kids section and being the developer behind the best game of the site, twice in a row, is certainly flattering. Why not try our luck for a 3rd time?

The Timeline

We had 1 year. Yep, a game that takes less than 1 month to create from start to finish had a timeline of about 1 year. It was refreshing to work in this context, where we usually have to deal with the exact opposite. That was critical to us because it meant we could mostly chose when we wanted to put time on the project, for instance using it as a buffer to fill up a slow work-week.

But even then, I remember around the beta that we had quite the crunch happening. We had put too many things on the same week and added a game jam on the same week-end on top of that… That amount of output that happened on that week was a sight to behold! And of course we crashed the week after. Clearly we’re getting too old for this…

A Balancing Act

Now that you understand the context better, let’s dive into the game itself. Here are the things we did NOT do:

• Unique animations for each characters
• Different levels
• Save game system

All in the name of saving a buck? Yes and no. Sure we would have done all of those if the budget would have been higher. But think about it: do these items truly make the game more fun? We argued that they have a low fun/dev-time ratio. Luckily the client agreed, so we were able to focus our energy on these items we deemed more impactful:

• Visual and audio feedbacks on everything
• Simple UI to navigate and understand
• Easy, responsive and reliable inputs

These items probably look easy and simple. And that’s great! If you look at the game and think “Anybody can do that!”, we did a great job. It’s when it’s done wrong and you think “Oh what just happened?” or “Did I do that?” that something went wrong. These 3 things are hard to get right and, when you put too much on the plate, the dev just can’t get all the way through with them and that’s when the end product suffers. I think we managed to get a really good balance here and, for that reason, we’re proud of the game. You can try it out right here by the way!

What Went Wrong

It’s not really a post-mortem unless we take a tough look in the mirror. We mentioned the scheduling issue previously which wasn’t great, but honestly we knew that we were making things hard on ourselves. It’s one thing when things derail and you overwork because you lost control of the project; it’s another when you’re excited about multiple opportunities and actually put many items at the same time on purpose on your schedule. We knew going into that week that it would be rough; it was planned as such. So I wouldn’t call the exactly a lesson learning opportunity.

One thing that truly went wrong was that the staff that ended up working on the project were not the ones we expected when we planned everything. For the first 2 projects, we had the same artist + coder combo doing both games. So we planned for the 3rd one with the same combo. But the new artist on the project didn’t have much pixel art experience, which made it much harder on them than they anticipated. Pixel art is hard guys! We clearly underestimated that one.

We could also have prevented the pixel art issue if we had planned a bit better around vacation time. The usual artist could have spent 1 or 2 hours with the other guy to show them the pipeline and everything would have been smooth sailing.

Then a new coder got in. Of course they reused the technology stack that was already in place, but that stack didn’t go through much trial yet and, of course, had some limitations that were discovered only late in the project. It required rewriting some fundamental code that had unexpected side-effects because of how the stack was used.

One way to counter that would have been to reserve a bit of time early on to test the fundamentals on the stack and not assume that it would all work out as it seems to work on the surface. You know, just play with it a little bit on random stuff and, once you got the hang of it, only then start working on the actual project.

Both of these problems ended up not being a critical hurdle, but are still worth noting here.

Conclusion

Overall, the project was a success. As always, we learned valuable lessons along the way. Every project and client is unique and through these varied experiences, we get better at our craft. The relationship we developed with Happy Camper Média was certainly a key element to the success and, as they know, we’re always open for another project!

---