What went wrong.

Well, for one, I can’t get that damn Mario theme out of my head! Too much Mario for one weekend.

What wouldn’t you do, to save the kingdom you love?

Seriously though: physics, collision detection, and scope. I decided right from the start that this would be the jam where I implement physics and collision from scratch, and then regret it for weeks. And guess what happened?

I don’t really understand why, but my physics, with all those vectors and gravity, just wouldn’t give me the “marioness” I sought for. Tinker and fiddle as I might with those forces… The jump arcs,  acceleration, and movement speed just were not coming together. I felt like I was trying to plug holes on a sinking ship.

In Super Plumber Brothers, Mario lands with a heavy thud, sticks to the sides of blocks, and sometimes is inexplicably sucked into the earth. These are the problems that crept out of my collision engine. I took the approach of using four or more “collision pixels” on the corners and sides of mario’s sprite, and then to push Mario away any time they became embedded in something. Every day of the Jam I had to spend at least 4 precious hours tweaking and pleading just to get through the day!

Has this ever happened to you?

Scope! These last two problems lead to a third. On day one, in the first three hours, I insisted on controlling scope. Our original concept took place over nine levels, had many NPCs and cutscenes, and included more metroidvania style power ups. I lobbied for prioritization and reduced scope, and everyone agreed on a scaled down jam version. The problem? We stuck to that scaled down scope.

At the end of the first day, we had a pretty unplayable platformer with a ton of content designed to play well with the features we had hoped for. No one really took the time to actually play the game at that point, and as a result we ended up sticking with our now o’er lofty goals. I fell that if we had taken the time to play the game for even just half-an-hour we would have realized that we needed to scale way down to finish with something nice. Maybe this is just behind-sight, though! Maybe @clangmuir would played it and said, “dude, this platforming is terrible!” and I would have promised the moon tomorrow and just kept pressing on. The past is the past, but the take-away is clear.

The lesson

There are some things I will do differently next time. The physics engine and collision detection is part of it, for sure: I’ve thought about whether I should try to program games a little more like I program web apps; that is, by importing a ton of libraries to do my bidding. On the other hand, exploring coding is valuable and certainly more true to the spirit of the dare. “Programmare aude”, I believe they say. So that’s not the lesson.

No, the real lesson for me is that “limiting the scope” is not good enough. You need more fine grained control than any one “scope” can give you. You need the scope, for sure, and you need to limit it at the start of the project. You also need to make a game that is fun. Next time I’ll dream up a crazy game and then ask myself, “What am I making?” Is it a zelda-like? Then before I work on what makes my game special I need to at least have a playable zelda-like that is fun.

If at the end of day one, you sit down and play your fledgling platformer, and you realize that the physics isn’t fun and you keep getting sucked into the floor… Then you need to spend day two making it fun! To just soldier on thinking the bells and whistles will shine brightly enough to blind a gamer is madness! Don’t make a plan and stick to it. A road map will only get you so far in inclement weather. Instead, dream a lovely dream and then set the most fundamental goal. Don’t set the next goal until everyone agrees you reached the first one. If you run out of time, you will still release a fun, well designed game. This way you will find tao.

This way you may find tao.