Tools Help Make The Game But Are Not The Game

I haven’t posted since before the holidays and, well, it’s almost February so I thought I’d do a post to talk about two things, where we are and a small missive on tools.

Where we are is still at demo complete. We have a complete version of the demo that is relatively bug free and that we’ve been showing people while we continue our fundraising and ramp up to doing a Kickstarter campaign in order to fund the final push to finish the game. However, Dan and I spoke when we both got back from the holidays and a couple of things were bugging us, both things we’d noticed and some comments we’d received. So… we’ve been doing a little tweaking, making the jump feel more “video game-y” and the controls feel more responsive. None of it has been revolutionary. Rather, it’s entirely evolutionary. But it’s all for the better, as I’m sure you’ll agree when you see the videos we plan to release with our Kickstarter campaign.

And with that… let’s talk about tools.

Tools have been something that’s been on my mind since we demoed our game back in November. I spoke a tiny bit about the tools we used and realized that I kept coming back to one tool in particular that I mentioned had it’s “pluses and minuses.”

This tool was LevelHelper.

LevelHelper is the graphical level layout tool we’ve been using developed by a Bogdan Vladu. It’s part of a suite of tools that is/used to be called SpriteHelper & LevelHelper. SpriteHelper was the sprite sheet tool that imported individual sprites, turned them into grouped sheets, and allowed us to draw physical bodies over them with some properties that could then be easily imported into a physics engine like Box2d or Chipmunk, Box2d in our case.

LevelHelper then took advantage of a file format created for SpriteHelper to import these sprites and allow them to be easily laid out into a level in a graphical drag-and-drop way. Thus, if you had a sprite that was a floor and had a physical body drawn on it and lined these up to one another on the screen, when it was processed by the physics engine, a floor would now have been placed.

Pretty cool, right?

Actually, it is. For one very important reason: BKLYN Bit Labs is a tiny, tiny company with very limited resources. Unlike AAA titles and studios, we don’t have a team entirely devoted to creating toolsets for us and couldn’t afford to set one up even if we wanted to. So we have to use the best tools that we can find. And LevelHelper is pretty good, as far as that goes.

But it does have its problems. Just a few of them:
A display of nodes in LevelHelper.

  • The level file size is huge – Our demo level, just a single two minutes of playable game time is 2.6MB. This means it’s slow to load since it’s an uncompressed .plist file with white spaces that has to be parsed with every load but it also means our final game (with the planned twenty levels) could conceivably be 52MB just in level descriptor files, not including any of the artwork. This could be fixed by compressing the level and/or using a different file format, one that’s not as wordy as the Apple .plist one.
  • The way it handles sprites and batch nodes is very rigid – If you look at the image to the right, you’ll see the way it sets up nodes. Batch nodes are nodes in which every sprite on them is from the same sprite sheet and it’s drawn in a single OpenGL call. They’re great and totally necessary. Unfortunately, LevelHelper only allows one batch node per sprite sheet. This may not sound like a problem but what if you want to use a sprite (or series of sprites) where the batch node is z-indexed into the background also in the foreground? You can individually tell each sprite to self-render (which is bad if you want to use a lot of them as each is a draw call) but you can’t place them in a second batch node z-indexed to the foreground. And, before you ask, there is no technical reason why this can’t be done in OpenGL or Cocos2d-x wise. It’s just a limitation of the tool.
  • Some of the features it offers are good in theory but too limited – In LevelHelper you can draw bezier paths and animate objects along those paths, which sounds awesome. But, unless these things are background objects, it’ll never be used in a final product. Smashers that move statically up and down just look boring. Enemies who walk lines need to have AI written anyway to know when to stop and attack. Perhaps the only case where this might be used are elevators and moving platforms. Other than that, the amount of work saved is very little. This could be improved by applying an easing setting to the path movement but it’s not there yet.

That’s just a short list of a much longer one I have.

The point here, really though, is that the tools are not the game. Tools help make the game, but just because you may use the same tools someone else did, you will probably wind up with something radically different and here’s why: SpriteHelper, LevelHelper, Cocos2d-x, and Box2d are where the game’s development begins. After that, it’s up to you.

SpriteHelper and LevelHelper package your art into useable sprite sheets and place them on the screen. Cocos2d-x saves you from having to make your own OpenGL rendering pipeline and add a few nice utilities. Box2d is a great 2D physics engine but, unless you’re Angry Birds, games really aren’t about perfect 2D physics.

In developing 1-Bit Trip, I’ve had to construct and modify an entirely new platformer control scheme. I’ve changed the way a hero jumps up (though I still use the physics engine to handle how he falls). And I use Box2d more as a collision detection engine than for the physics simulations its supposed to provide. None of this occurred to me when Dan and I set out to create this game.

So… would I use the same tools over again if I were to start over? I know I was hard on LevelHelper but, yeah, probably. As long as I didn’t go with something radically different like Unity, I probably would because they’re the best I’ve seen so far. Mostly, I’d just have totally different expectations of what I’d get from them a second time around.