GameDev, Uncategorized

js13kGames 2015 – (late) post mortem

After taking 12th place in js13kGames 2014 with Rescue Copter I set myself the goal of making it to the Top 10 next year. And you know what? I made it!

(TL;DR for the lazy ones at the bottom)

Almost four months after announcing the results of js13kGames 2015 I’ve finally got myself together to write a post mortem for my latest game – Captain Reverso. I’m not saying I’ve been celebrating my 7th place the entire time, but hey, let the man have his moment… ^_^

I must admit that the theme – Reversed – wasn’t my favorite and it took me a while to come up with an idea. Back in my school days, I really enjoyed playing those Flash-based car parking games. Most of them had terrible physics, but that didn’t stop me from playing for long hours. It was the same time when the “18 Wheels of Steel” series was born. I immediately felt in love with all those games, especially with their semi-trailer truck mechanics. Delivering a cargo was pretty cool, but parking a semi-truck with a trailer attached to it was a really challenging task and I enjoyed this part the most. From the combination of these two things Captain Reverso was born.

In this post I’d like to summarize the whole process of making this game and point out some of the things I found important.

What went right

Organization and Planning

This time I decided to take my process to the next level. I needed a tool to organize my development tasks, keep a small wiki and store the code. The obvious choice would’ve been Github, but it lacked private repositories in the Free plan.

Then I remembered Bitbucket, and boy, this was a game changer!  Free account, private Git repository, customizable issue tracker, wiki pages and all that in a single place. With the UI and functionality similar to other Atlassian’s products it felt like home!

However, there where thow things I really missed – customizable filters and some sort of a kanban board view. I solved the first problem with a pretty neat Chrome extension called Bitbucket Filters. The second problem could’ve been solved with Bitbucket Cards but I didn’t use that after finding out there’s a limit of cards that can be loaded…

Bitbucket's issue tracker
Bitbucket’s issue tracker

Anyway, thanks to the issue tracker I knew where I am and how much work there’s left. I was also sure that I won’t forget about that bug I found few minutes ago.

Having the ability to assign priorities to tasks, I was able to mark some of the features as lower priority and drop them when running out of time and/or available memory.

Dividing the process into typical steps – design, prototype, first-playable, alpha, code-freeze, beta and release – I was able to prepare a pretty accurate schedule for a whole month of development and I tried to follow it working almost every evening for a couple of hours.

Once I got to the beta phase I focused myself on bug fixing and there was no way I could introduce any new feature. Such an approach really paid of – I finished my game three days before the deadline!

Visual Level Editor

While designing the game, I decided there will be a pre-defined set of maps to complete. This meant I needed a tool to create and export those levels to a format understandable by the game. At first I thought about Tiled, but it wasn’t flexible enough. So two afternoons later, I had this simple visual level editor based on some jQuery UI components:

Now I was able to create a map, export it and test it in the game – everything with just a few clicks!

Playtests

It’s a shame to admit by my previous entry – Rescue Copter – wasn’t playtested mush. Yes, I gave it several hours of testing, but my main concern was looking for bugs. The thing I missed back then was checking if the game is fun to play at all.

This time however, I thought I’ll start sharing the game with some of my friends as early as possible and collecting their feedback. This resulted in several improvements in the game, including two different control styles, modified level layouts and nerfed difficulty.

What went wrong

Planning

Even though the planning turned out pretty well, it wasn’t ideal. I have overestimated some of the features and development phases, planned way to many features for the available time and memory. As a result I ended up removing tons of graphics that took me several evenings to create and dropping some cool features I really wanted to see in the final product.

And the biggest feature I had to drop was…

3D Buildings

Early in the prototyping phase I came up with an idea of adding a pseudo 3D buildings that would improve the visuals of the game. It was meant to be something similar to the first GTA.

Preparing a simple prototype (above) didn’t take me long, but the real problem started when I tried to compose an actual level containing those 3D objects. I couldn’t find a simple yet pretty way of placing buildings next to each other. Also, I wanted to be able to place obstacles rotated by 45 degrees and rendering walls in this case would require some crazy transformations (we’re talking about plain Canvas2D and orthographic projection) and it didn’t guarantee the output will look good.

So I ended up wasting at least 4 days playing with that concept and finally dropping it. I think I should’ve made that decision earlier and save that time on polishing the levels.

Oh, and that obstacle rotation every 45 degrees? It’s gone too…

Playtests

Again, something that came out as a huge improvement compared to my previous entry, could’ve been executed better. More time spent on playtests and a wider group of testers would probably reveal several problems with the game, difficulty being the biggest one I guess…

Lessons learned a.k.a. TL;DR

  • Get yourself some tools to organize your code and development process
  • Use those damn tools!
  • Have a schedule and stick to it
  • Don’t have a right dev tool? Make one
  • Don’t be afraid of dropping a feature, even tough you really love it
  • Playtest a lot and do it early

Summary

I bet most of my observations is well known to game developers, I heard some of them before too. Despite that I still wanted to share them hoping some of you would find them helpful.

This year’s Last year’s js13kGames was another success. With exactly 160 entries it emerges as one of the biggest gamedev compos these days. The quality of entries is rising each year and I’m pretty sure that judges had a hard time picking the best ones. With that in mind, I’m really glad to be one of those, ending up in the Top 10.

On this occasion I’d like to congratulate all the participants, especially to the winners of each category, judges and organizers. I hope we’re gonna see each other again during js13kGames 2016!

by Greg

4 Comments »

4 thoughts on “js13kGames 2015 – (late) post mortem”

  • Nice article, it was interesting to see your process.

    First thing, I’m also using Bitbucket for private / research projects and it’s working pretty well.

    “(…) I focused myself on bug fixing and there was no way I could introduce any new feature (…)” – totally agree, couldn’t agree more on how important that kind of approach is.

    The thing with tools sometimes could be a tough call. It all depends on usage, and estimation on how much time tool will take and if it’s worth the effort. In this case I think editor was relatively cheap, because all the rendering logic can be reused from the game source. But sometimes people do helper tools, that turn out to take much more time compared to what was saved by using it.

    Once again, congratz – that was really well executed project!

    • Thanks for the comment Marco!

      “The thing with tools sometimes could be a tough call. It all depends on usage, and estimation on how much time tool will take and if it’s worth the effort. In this case I think editor was relatively cheap, because all the rendering logic can be reused from the game source. But sometimes people do helper tools, that turn out to take much more time compared to what was saved by using it.”

      That’s true. In my case it was totally worth those two evenings. My point is that you shouldn’t be afraid of creating one yourself, especially when it can save you some time in the long run.

  • Don’t be afraid of dropping a feature, even tough you really love it

    Probably that’s the hardest part.

    Played your game until frustration level got too high and then just a bit more 😉

Leave a Reply to Greg Cancel reply

Your email address will not be published. Required fields are marked *