One major problem with me trying my hand at writing games, even simple grid based puzzle games, is that ultimately one needs some artwork. I will state now that I am not artistically inclined. Download Flip! </subtleplug> and you can see that plainly. I doodle as much as the next man when I’m in a meeting at work, but like most engineers this seems limited to constructing expanding geometric shapes and patterns that mimic a structure (seriously, what’s with that, I swear I’ve seen others do this as well. Must be part of our wiring). So how did I tackle the artwork and animation for Flip!?* Well, essentially I cheated.
Everything starts with the design. It’s pretty much unavoidable and I had to revisit it a few times as things evolved and I realised I had made everything too small (note to other libgdx developers – I love the ability to easily test my app on a desktop deployment rather than an emulator or phone, but you forget sometimes that you are working on a bigger screen). The design just needs to be a simple sketch with a vague idea of dimensions / distribution / layout to make it easier to support varied devices.I was then left with three groups of graphical elements to tackle: backgrounds, the UI elements and the animations for the tiles. The background was simple. Once I’d written off the idea to have variable backgrounds, I tore out some notepaper from one of my pads and threw it in the scanner. Job done.
For the UI elements, other than the ripped up notepaper background of the in-game menus, I wanted to get the look to be both uniform (it’s a grid based game after all) and have simple solid colours. With my lack of experience, I didn’t want to invest too much time in anything but “simple” for this very basic game. I found the best way to achieve my goals was to use Inkscape. I’ve used Inkscape a bit before for illustrating things at uni so was fairly familiar with the interface. Because it uses SVG, I didn’t have to worry about neat curves with a pen, I could just draw to my hearts content then work it out in the exports later. I could then change the size of images easily without losing any definition. Once everything was created, into a texture atlas it went and all was good.
The tiles were a tougher prospect. If I can’t draw, I certainly can’t animate. For this I turned to trusty old Blender. In fact, I had originally turned to Blender because I was going to render the tiles as 3D and animate them using rotations in OpenGL ES. Luckily, it was equally suited to 2D animation. By sticking an orthographic camera over a rotating tile model I could capture all the frames and then bung them back into a texture atas to manage the animation. Using comic effects with the materials got me the simplistic look I was aiming for while retaining the 3D looks of the animation (IMHO).
To create my texture atlases in each case, I used an excellent app called TexturePacker Pro. This produced both an atlas and a file used to address the locations used for each image loaded into the atlas. This can then be loaded directly into libgdx using the TextureAtlasclass.
* note to self. Stop ending sentences with the word Flip! or at least change the name to not self-punctuate.