Last November, I couldn’t join GameBoy Jam 2. However, I was in love with the idea I had, so I kept developing it. Now, that idea has a name, Caste Break, and I’m releasing an alpha version for you guys to play, YAY!

Caste Break is a fairly simple tower defense. The main feature is that you won’t build towers, per se, but instead you’ll train your units by mixing the tribes you have available. You create a unit by choosing its type (attack or support) and then its starting tribe. When you upgrade, you choose in which tribe that unit will be trained. Depending on the combinations you make, the unit may change or simply increase its stats. This alpha version reaches only the second level training and there’s 8 fully playable levels, but I’m planning to create something around 20. I’m also wanting to add a new unit type on the final version.

I kept some of the limitations of the Game Boy, such as color palette and sound quality, but the real hardware would never be able to run the game as it is today. It can be played with mouse, mouse+keyboard, keyboard only or joystick (on browsers that supports the GamePad API) and it is also touch friendly (although the buttons can be a bit tiny some times). Ah, and it’s developed with cocos2d-html5!

You can play it on Game Jolt.
If you prefer, here’s a direct link, more suited if you’re on mobile platforms.

For those interested, here’s some information I thought that would be cool to share with the fellow gamedevs.

Entity-Component System

I learned about that approach on a tutorial. I kept reading about and decided to try it, as it seemed to ease the creation of the type of game I wanted to make. Dude, it made a huge difference! I’m not saying that it’s the best way and everyone should follow it, far from that, but it makes so easy to extend and increment features that I can’t think of a better approach. After you get out of the Object-Oriented mindset, it just feels natural for game programming. Honestly, I’m not 100% happy with the final code structure of the game, mainly by my own fault, but I’ll keep improving on the next games I make 🙂

Workflow

With this game I learned the importance of automating tasks.

When balancing the game, it started to get really fucking tedious to replay the levels for every little change. So, I built a simple system to play the game automatically (placing the units on the tiles I previously specified), along with speeding up everything. That way, I could simulate a play session through the 8 levels in a minute, which otherwise would take me about 40 minutes. This also offered me more safety when changing the units, because I could easily see if the modifications would break the game.

Also, there are some tools I’m using to simplify and speed up the general development workflow:

• Google spreadsheets and JSON export (to manage units and enemies data)
• Closure Compiler (the cocos2d-html5 template already contains a “build” file for that)
• Audio sprite creation with a Node.js package and some shell script magic

Part of my process can still be improved, like pulling the data from the spreadsheets automatically during a build process instead of pasting it on the code, but, as I’m working alone, that would be too much trouble for not much advantage. What I’m currently considering is using TexturePacker, instead of Zwoptex, mainly for the command line utilities. Recreating the spritesheets one time is fast, but when you’re iterating a character design a hundred times, it gets boring and time consuming.

Sound

Currently, the sound engine present on cocos2d-html5 doesn’t work very well on mobile platforms, so I used Howler. I found an integration on GitHub, but I ended up creating my own. If there’s someone interested, I can share the code. There’s still some bugs here and there, but it’s pretty much usable. The big bonus is the possibility of using audio sprites (one file with many sound effects/songs), considerably reducing the number of requests made to the server when loading the game.

For sounds effects, bfxr was my friend, as always, but for the musics, I experimented a lot. I tried many obscure apps and tools until I finally got my perfect setup: abundant-music.com, a great tool that procedurally generate songs with no hard work from your part, and GSXCC, a precious little software that takes MIDI files and generates 8bit-like songs. If you’re a Javascript dev and also an abundant-music.com user, I created a snippet that may be very useful for you.

UI, oh why you

One of the greatest challenges I faced when developing Caste Break was the in-game UI. 160×144, for a tower defense, is a very cruel resolution. If you play it, you’ll know what I mean, but, to put it shortly, there’s too much information for little screen space. Since I made the bottom bar, I started thinking about increasing the resolution, but I decided to wait and see what people think about it.

Final words (or “Please, finish this post!”)

While creating the graphics, I was tempted to switch to a bigger palette so I could differentiate the units more easily, but I was stubborn and kept the decision of using only 4 colors. What do you guys think? Would the game benefit from a more diverse palette?

There’s still some game balance to be made (specially on the support units), so I would really appreciate if you leave some comments, here or on Game Jolt or on wherever you prefer, about what you like and dislike about Caste Break.

See ya!