-CHAMBER- postmortem

2014-12-08 12.44.31 pm

Play and rate here!

TLDR; Didn’t know what I was doing. Rescued it in the last 8 hours. Get sleep.

The initial brainstorming for this game started over sushi. Once I saw the theme, I started to think of ways to create a level dynamically as the player was playing. Tetris blocks were the first thing I thought of, but I really didn’t have any ideas beyond that.

I had 2 considerations:

  1. The game must be HTML5 / Javascript.
  2. The game would have an atari aesthetic.

Design:

FallingBlocks

This was my entire design document. The original idea was to have the blocks fall very slowly and have them being destroyed as they hit the spikes at the bottom. I wanted to keep the design of the game as simple as possible because I have bitten off more than I could chew during several game jams before.

I figured with an atari look I could keep the art requirements to a minimum and make the game look more polished without a whole lot of effort.

Tech:

I was determined to make this game run in a browser. I found a list of HTML5 game engines at http://html5gameengine.com/ and quickly went though the docs of the highest rated ones. It looked like Phaser did everything I needed it to and had built in arcade physics. I’m not a huge fan of Javascript development, but I am a huge fan of Photonstorm’s flash tools (http://www.photonstorm.com/) so I went with my gut.

I used Webstorm as an editor/development environment https://www.jetbrains.com/webstorm/.

I used http://www.bfxr.net/ for sound and Photoshop for the art.

What went right:

  • Phaser was very easy to get up and running.

It literally took about 10 minutes to get something drawing on the screen. I was shocked at how complete this library is and how little configuration it took to get up and running. The documentation is great, and copy/pasting from examples got everything running while I was learning the library.

  • Javascript was much better suited for rapid prototyping than I expected.

This saved me at the last minute. I see why people actually like Javascript development for prototyping now. I was able to add properties to just about anything, The block matching was a last minute addition, and being able to just add a color property to the physics body ‘willy nilly’ was pretty awesome! I still hate Javascript.

  • Webstorm made things a lot easier.

I was able to catch errors quickly and find my properties easily. Having some code completion was very nice, and made development go a lot smoother.

  • Limited scope

I forced myself throughout to keep a super limited scope, because I had anticipated that the game would change direction. I kept the design requirements to an absolute minimum, and purposely didn’t ‘design’ anything outside of a limited premise. I over scoped during pervious Jams and ended up with half playable big concept games rather than fully playable limited games.

  • Change in focus.

A forced change in focus near the end of development was for the better. Once I figured out the original concept wasn’t going to work as I expected the simpler, easier to implement idea ended up being a lot more fun.

  • Plenty of sleep .

I usually make it my mission to not sleep during Jams. But I’m getting way too old for that now :). I stayed up until 3am or so, but didn’t do the 48 hours straight. Waking up with fresh eyes in the morning kept me sane, and I think I had more productive time than just powering though. I did go though about 4 pots of coffee.

What went wrong:

  • Phaser’s arcade physics didn’t do what I expected.

Phaser is awesomely complete, and has several physics engines built in. The idea was to create Tetris blocks out of a base single block sprite, and then add a bunch of physics bodies to a single sprite.

2014-12-08 01.39.16 pm

This didn’t go as expected at all, and I spent the entire first day just trying to attach multiple physics bodies to a single sprite. After some research, I switched physics solutions, but that was about a day wasted just watching my bricks fall and shatter on the ground. I almost made the game about this.

At this point, I didn’t have any game to speak of. Just sprites on a screen and things falling.

  • Phaser’s P2 physics didn’t do what I expected.

I changed to P2 physics, and about 5 hours into the second day I got multiple physics bodies attached to a sprite. It looked like this though:

2014-12-08 01.46.29 pm

The physics bodies were offset by a random(?) amount, which took way too long to troubleshoot. I never did figure out exactly what was causing the problem, but I think it’s because I was adding children to a sprite and physics bodies at the same time (which may have caused the sprite to recenter each time). I don’t know why the solution I hacked out worked, but it does so I just left it alone and moved to the next problem.

I wanted the blocks to fall slower than the player, but still have acceleration due to gravity. P2 allows you to change the damping per body, but when the player jumped on a brick it pushed the brick down, so I couldn’t use it as a platform to jump on.

At this point, it was fun to just push around the physics blocks, so rather than try to solve the problem with making the blocks fall slow I just decided to make the game about pushing the blocks around.

The game was now: match colors. In this case, it was nice to be using Javascript because I just added a color property to the physics body (without modifying any framework code) and compared matching colors on collision. This took about 10 minutes to get working, and gave the game an instant goal.

2014-12-06 07.28.09 pm
  • I had absolutely no idea what I was doing.

This was my first HTML5 game, not to mention my first game in Phaser. I’ve worked on plenty of enterprise javascript applications, and their convoluted frameworks and project design to keep everything as modular as possible. This wasn’t that.

All of the game code is in one VERY LONG 900 line file with absolutely no closures, namespacing, or any easy way to find anything.

To control timing events, I just used a window.setInterval and window.setTimeout. This caused hilarious bugs at the end of the game because several events were all firing at once.

Add to that no prior knowledge of Phaser and it was a wonder it even ran at all. I’m glad I stuck with my guns and did this in Javascript in the end, but in the future I’m going to stick with tools I know.

  • Got stuck too long on minor bugs.

I had planed to do some animation on the main character. Or some character design at all. But several seemingly minor bugs kept me busy most of the last day. Text didn’t update: 2 hours wasted. Mispelled property on an object: 2 hours wasted. Physics materials not being applied correctly: 2 hours wasted. All this added up to major time spent troubleshooting things I ended up simplifying or removing entirely anyway.

It also kept me from the things that mattered, like actually setting a win and lose condition for the game.

  • Game cleanup.

This ALWAYS get me. I always lose a lot of time ending the running game state and starting a new game. I didn’t want to refresh an iframe or something hacky between levels so I spent a lot of time trying to clear out all of the sprites and physics bodies, quit the updates and go back to the title screen.

I did this during the last 2 hours. Next time, I get the game in and out of it’s main loop and clean everything up first, and maintain it as I’m working.

  • Crap, I forgot sound!

About 45 minutes left, and I realize I’m missing sound. Luckily Phaser had an easy way to playback sound, so the code was trivial. Searching were to actually trigger the sounds was the hardest part. I quickly used BFXR to put together some sounds, mashing generate as quick as I could until I got something that sounded ok.

I’m a big fan of the death sound effect, but it’s just really luck I was able to find something as quick as I did.

Lessons Learned:

  • Don’t be afraid to change directions.

This is always something I’m terrified of. I tend to get stuck in iterative cycles where I change major mechanics over and over until I get something that ‘sticks’. This is my design process and I’m trying to get away from it in larger games and larger projects. I second guess myself too much.

I am aware of that, and in a Jam environment I feel like to tend to overcorrect in the opposite direction. I pound on a single concept until I beat it into submission but I end up with a game that isn’t very fun.

This time, out of sheer necessity I changed direction at the last minute. I think it’s because I didn’t have time to think about it, or try to talk myself into or out of design decisions it ended up working. I could have just gotten lucky too. But I think the moral of the story is to not over analyze the design and course corrections are OK during jams.

  • If something doesn’t work, move on.

In this case, I’m thinking specifically about tech. I don’t want to get too bogged down in technical problems during Jams. The updating score? If it wasn’t there would I have missed it? Probably not. It wasn’t worth 2 hours of my time when I could have been polishing something else.

  • Game Jams are a bad time to learn new tools.

it’s a great time and a horrible time. If I hadn’t finished the game it would have been ok. I had nothing on the line. But it’s probably more stressful than it was worth to try and learn a new toolchain. I did this one year during GGJ (learning Gamemaker), and I didn’t learn my lesson then either.

I’m confident I could have made this game in half the time with Flash or Unity, but then I wouldn’t have learned Phaser. So I’m torn.

  • Don’t drink beer while programming.

Beer isn’t the best beverage to consume while Jamming. Although to beer’s credit, it probably encouraged me to get more sleep.

  • SLEEP HELPS!

I lose HOURS of productive time by not sleeping during Game Jams. At the end, hours actually felt like hours instead of the usual ‘OMG where has the time gone’ feeling I get at the end of ‘not sleeping’ jams. Everything just went so much smoother. I know it’s all cool to power though 48 hours, but I think it worked out for the better. I’m also not sick on Monday (like I usually am).

That’s it!

This was a bit longer than I intended it to be, and I’m not sure how insightful it is – but it was good for me at least to think about how to approach this for next time. I had fun! Hope you enjoy the game!

Source: ludumdare.com archive

Found a bug?
Tell us on Discord