Taxi No Roman (Ludum Dare 36 Post-Mortem)

Posted by
August 31st, 2016 5:03 am





What have we learnt?

Coming back to Ludum Dare again (after skipping Ludum Dare 35) with the classic team setup with my best friend and artist, Isaac, made me realise how far we’ve came from 4 years ago when we’ve released our first embarrassingly incomplete game.

We’ve massively improved our games development skills when we started our university.  We have learnt not just technical-wise, but design-wise as well.  This game is the result of having the technical “know-how” culminated through GameMaker: Studio over the course of 5 years alongside with the game design knowledge that we’ve gathered over the years.

We have proven ourselves, that it’s okay to fail as long as we learn and improve to become better, and we’ve certainly did.  This is our best game we’ve made thus far.  BUT WE WON’T STOP IMPROVING!




This game has proven that what we’ve learnt thus far are on track, and that we’re not being misled into doing the wrong things.  We placed our best game design knowledge to test in this game.

This started with the game design itself.


The game design

The best gameplay always stem from the best idea first.  If your initial ideas are bad, there is a high possibility that your game may not do well (although you can always improve its premise).

We started out by dumping all of our ideas at the start of the jam in a Google Drive Doc.  We didn’t have any interesting lead until Isaac wrote down “Chariot racing”.

I said to myself, chariot racing is pretty generic, and other people may have taken it anyway.

But one instant idea came along (and I’m not pretty sure why and how), what if it’s Crazy Taxi’s gameplay WITH chariots?? :O

Min Jeat, who sat by my side, also thought that was a good idea as well.  And thus we began working towards that idea.


The best gameplay always stem from the best idea first.


I chose the top-down view for various reasons:

  • It’s easier to make top-down view gameplay in GameMaker: Studio.
  • I’ve seen racing games made with a top-down view format and they’re pretty good as 2D games.
  • We have been experienced in making top-down view games, so this one was familiar to us.
  • It’s much more fun with physics!

I’ve also taken a few dynamic camera inspirations from GTA1/GTA2.  Plus, I’ve just recently learnt about how to make dynamic screen resolution (that tries to maintain pixel perfect in the world), camera movement and camera zooming.




We kept the simplicity of Crazy Taxi and went with it, developing only the most essential features first and then enhances it afterwards.  We’ve spent the most time on the actual gameplay itself and we’ve totally ignored the main menu, pause menu, and etc.

We’ve only planned to make the cutscene in order to bring the player in to realisation of what’s going on.  I simply gave the order to Isaac about the story which was plainly, “make a cutscene about a taxi driver watching TV then suddenly he was sucked back in time”. It was like this because in my opinion, great gameplay > story.


Great gameplay > story.


The game was intentionally made to be goofy to suit the game’s theme.  It’s supposed to be a light-hearted game which we don’t need any emotional rush 5 minutes into the game.

I’ve also decided that we’re going to attach the cart behind the horse, make player controls the horse, and let the physics affect the cart.  Physics in a fast-paced casual game is always fun :)




We’ve put the gameplay emphasis into:

  • The horse carriage movement – it must be responsive and fun to control.
  • Smoke particles – it creates a sense of motion and movement, and it’s effect is incredible!
  • Dynamic camera movement and zooming – having a static camera that just follows player around is quite boring and dull.
  • The picking up and dropping off passengers – we have to make sure that they work correctly and as intended.
  • Directional arrow pointing to the direction of the dropoff zone – it’s not fun if you don’t know where the target is.
  • Game performance.

And we only emphasized on these later on:

  • The countdown time.
  • The end game.
  • The fair system.
  • The background music.
  • Random pedestrians.
  • GUI.
  • Cutscene.




The main reason why we have lesser emphasis on these is because if the actual gameplay itself is not fun, all of these just does not add any value to the fun at all.

We chose 2 minutes because most Ludum Dare participants have no patience for long, dull, and boring gameplay that isn’t attractive at all, and since they have to vote on a huge number of games as soon as possible, they will throw the game away as soon as they ran out of juice.  2 minutes is the most perfect balance between fun and time conservation, plus you can casually play it anytime (even during lecture class)!


2 minutes of good gameplay is better than 20 minutes of bad gameplay.


Last but not least, we have placed a large emphasis on the performance of the game as well.  We spent the last day optimising the game to make sure that at least most of the low end modern laptops should be able to run the game smoothly.  Playing a fast-paced game with a ton of lag isn’t fun at all.

As a matter of fact, we’ve gone from a 20fps gameplay on a Pentium with 720M laptop to a 60fps performance.  HUGE IMPROVEMENTS!




Take it casually!

We didn’t panic this time during our development.  We took our time when the theme was announced to decide on the idea.  I was in the middle of class while Isaac was at home thinking of ideas.  We spoke via Facebook to develop our ideas.

Once we had our idea, Isaac just took his time to draw the cart and even spent some time to draw sketches so that we would know what we’re making.  When I managed to get home, it had already been about 3 hours since the theme was announced.  I have decided to take a nap as well for 4 hours so that I would feel fresh enough to program while Isaac kept on with the art.  So that means, we are 7 hours into the jam with no programming.

Only then I started to program.  Isaac took his naps later on as well.  We didn’t over-stress ourselves in this Ludum Dare jam whereas last time we would binge our development time.  It felt better and we were able to adapt to changes.  I had college on the 3rd day as well so we casually finished our game on the 2nd day and spent the whole 3rd day on optimization, bug-fixing and polish.  In the end we’ve submitted our game 9 hours before the due time.  We even had enough sleep throughout the Ludum Dare jam!

A lesson to take away: Take your sleep and nap.  You will work better and be more productive, rather than binge development time and risk getting stuck, demotivated and making poor decisions.




What went well?

I would say all of the gameplay emphasis that we’ve put on went absolutely well, except for the dynamic camera, which went half-well.  I would admit, it’s not a technical issue, but more of a poor design choice.

The particles effect went way better than I’ve expected.  I was expecting it to look really bad!

The fun element, yes.  The fun element that we’ve focused on for this game went absolutely well.  Everyone commenting on our game says it’s fun too!  Compare it with our previous game, we’ve not received a single complaint that says its not fun!

The physics – that went well too.  It looks realistic, it looks arcade-y, and it certainly looks really fun to play and control.

The GUI – It’s functional, it’s useful, and conveys all of the important stuff.  That’s what mattered.

The Graphics – No one complained about how bad the graphics were.  Isaac was a terrible artist to be honest.  At least he’s not that terrible now.  (JK)




What did not went well?

The camera zooming/panning effect.  Everyone says its too intense and nauseating, which we have taken note of.  We will tone down the camera effect next time we make something like this 😉

The music.  I’ll admit, I’m not good in music composing, but no one else in my team can compose so I have to try.  I’ve made it less loud and obnoxious to prevent headaches when listening to it and opted for a more “functional” music.  Functional as in, well, at least there is a music to keep things from being boring, right?  To be fair, I didn’t liked the music as much as I have imagined it to be.

There are only 5 dropoff points, and it gets repetitive the more you replay the game.  It doesn’t help that we have a small map as well.  The reason why we kept the map small is because we don’t want to overshoot our schedule, and instead focus on the most intense 2 minutes gameplay as possible.





This is the most fun Ludum Dare jam that we’ve ever done, and we’ve certainly made one of our most successful game thus far.  We will be coming back to join Ludum Dare again, maybe not the next Ludum Dare, but certainly in any future Ludum Dares 😉




Again, here’s our link:

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]