Tooth decay: Postmortem

Almost recovered from the rush of the weekend, this is the post-mortem of Tooth Decay, my entry for the 38th Ludum Dare. As always, I participated in the compo mode, and as always, I had a lot of fun.

mainscreen.png

Play it here!

Background

As usual, I tried to brainstorm some ideas with the final theme selection. This time I couldn’t spend long doing this but still managed to fill some pages of my notebook with ideas.

brainstorm_themes.png Eventually the theme was announced. I wasn’t particularly excited with it: I felt it might lead to a relatively narrow range of mechanics and/or settings (I’m guilty of this myself :D). However, there’s always an interesting idea you can come up (or any kind of idea, really), and if there’s anything sure is that people will surprise you with their own, so in the end it’s fine. I kept brainstorming for a while, now focusing only on the final theme. One set of contradicting concepts I would have liked to explore was how communications and technology have managed to vastly expand a relatively small world (a tribe in prehistory, or a small town not so long ago…), but at the same time they have contributed to shrink it sometimes, reducing it to isolated bubbles of like-minded people. I wasn’t able to come up with interesting mechanics for either of the two, so I went for something more conventional.

brainstorm_smallworld.png More ideas for “a small world”

By that time, one of my wisdom teeth started to hurt “BIGLY” -and has continued to do so without fault. That reminded me of an episode of one of my favourite cartoons when I was a kid, Once Upon a Time...Life (Fun Fact: if I hadn’t discovered video games I would have probably studied to become a doctor because of it). The episode in particular was about a bacterial colony excavating a cavity on a tooth.

hqdefault.png My streptococci are way cuter

The setting was perfect, and an obvious game mechanic immediately joined: drilling. Because of the time and constraints I went for something relatively simple and fun, and I remembered Mr Driller, a game by Namco where you...well, drill. I decided to use the same concept, and incorporate some base building mechanics (which unfortunately didn’t make it onto the game in the end), a la Steamworld Dig or a Flash game I found while looking for references: Motherload.

sketch.png I had a solid idea, and it wasn’t even noon! I immediately opened FlashDevelop, created a new Haxeflixel project and started prototyping.

What went well

  • Clear vision.
  • Main mechanics working relatively early.
  • Modular design. Thanks to this compromising was easy and at the same time there’s a lot of room to expand it in different ways while staying loyal to the vision.
  • *Cluster-finding algorithm. * To detect groups of tiles of the same type that can be drilled in one go and drop to the ground I used a two pass labelling algorithm, as depicted here and here. It was surprisingly easy to implement, and it worked like a charm (or almost, I think I’ve spotted an occasional bug).
  • Haxeflixel debugging console. This time I took a bit of time to research how to the in-game watch window and the command console quite a bit and I have to say it is quite powerful and helpful.

What went wrong

  • Art bottleneck. I spent more time than I should have coming up with an art style (pixel art? vector? what about “none of them”!?) and a decent set of concept references for the in-game screen and the overworld. I also added some animations to the main character, and even if it doesn’t have too many frames I’m still super slow at doing that. promo_concept.png Some early concepts. I think I liked the colour palette better then.

  • *Collision resolution + Camera management woes. * I had to fight a bit with Haxeflixel, first to sort out some glitches handling player-tile collisions, and then to get my two cameras (one for the HUD, one for the board) to render properly. I could have probably been able to work with a single camera setup, but as the map had an X-offset and applying it to the whole scene isn’t trivial I’ve found that using a camera works fine...once you manage to set them up correctly. I lost a good couple of hours with this.

  • Dropped working-ish feature. On Saturday night, right after I implemented the clustering algorithm, I quickly hacked tile shaking and dropping once a tile’s cluster becomes disconnected from the ground. It was working, but drove performance to the ground and it was quite late at night, so I decided to. In hindsight this was probably a good decision, but I would have liked to see it in the submitted entry.

  • No resource management / upgrade system, or "pain threshold" What can I say here...good old lack of time.
  • No time for sounds. Same T_T

Lessons learned

  • Keep a stock of Nolotil pills available on my cabinet for emergencies. Paracetamol just doesn’t cut it T_T
  • Improve the art pipeline! Practice, practice, practice.
  • Start exploring alternatives to Haxeflixel. It is simple and powerful, but from time to time I keep finding some issues with relatively straightforward features that have me fighting against it more than they help me save time. To tell the truth, most engines and frameworks have their own peculiarities, so in the end you're bound to bump against something that works in a different way than you expected.
  • Defined the task list for a post-compo version! new_plan.PNG