Skipping Feb OGAM

I’m skipping the February OGAM due to a house move and illness. Luckily I have a design in mind and it’s one I want to work on a bit longer term so I expect to release something, just not to the deadline!


Resolution v0.1.0

I’ve been busy with a house move for the last week so I’m releasing where I last left Resolution. It has a way to go before it’s a proper game, but it’s got the basic mechanics in there. I’ll call that a tick in the box for my January OGAM entry.

Left and right control the character, up and down vary the target speed for running. The max speed you can run at depends on both your energy and current weight. Either of these are affected by how long you run for and what you eat (energy bolts or food).

It’s obviously missing some major features, which I’ll add over time when I can:
– Scoring and failure state. I imagined that coming off the end of the treadmill would be failure. Wah wah wah wahhhh. The longer you’re on, the higher your score counter goes. Or pickups. I dunno.
– Game state handling to let you start at your leisure, pause, and handle the end game states.
– Better balancing of pickups. At the moment they’re randomly spawned across treadmills, increasing in rate as you avoid them, decreasing if you hit them. It also needs to distinguish between good pickups (energy) and bad (food).
– More treadmills. I’ve implemented variable speed treadmills, so these can be added to make it a challenge to move around the whole scene. This could then be tied into a risk/reward system for collectibles.
– Tuning. It needs it. Much of it.
– Sound? Who listens to things anyway?


Resolution: First Demo

I’ve managed to find a few hours to play with both Unity and the wonderful (in my unskilled hands anyway) Pyxel Edit so have made a start on my January OGAM entry for Resolution. Non playable at the moment, just demoing animations, variable speed treadmills, working HUD meters and spawning of random pickups. Looks fun doesn’t it! No? Fine … see if I care.


One Game A Month

I already know 2015 is going to be a busy year. I should have a new house to play in, with all the associated DIY and building work that will come with it. Work isn’t going to get any easier so will either kill me or drive me into a change of jobs, neither of which option is going to result in me being rested and having an abundance of free time. I’m already signed up for at least one comic con for which I’ll need to get my cosplay sorted. I’ve also got quite a few weddings and stags coming up this year. All that doesn’t leave a lot of time to focus on realising my pages of scribbled notes and game ideas, so there’s only one thing for it: I need to set myself an unattainable target! One Game A Month seems like the perfect target to follow. Someone else can manage the tracking and goal settings, and I can sit back and fail to hit any of the deadlines!
Seriously though, it’s a good framework to get myself to put some effort into working on some game development. Every month there’s a new theme to work to, which should help me to branch out or inspire some new challenges. Even if I do the minimum for a given month – create a tech demo or follow a game tutorial that fits the theme – it’ll help improve my game dev skills. I will make one prediction now – September is going to be mega-busy so I expect to be missing that deadline!
The first theme word for 2015 is “Resolution”. I’ve got an idea in mind for a small mini-game about weight loss so let the games(dev) begin!


The Problem with Motion and Touch Controls

The recent announcement by Microsoft that they will be selling the Xbox One without the bundled Kinect has sparked mixed reactions from critics and developers.  From my perspective, Microsoft seem to be accepting something that I’ve been thinking about for a while – the problems with waggle and touch controls for gaming (which I’ll collectively refer to as “waveprod” from here on).

I should point out at this juncture that I think both motion tracking technology and modern capacitive touch screens are amazing advancements in consumer tech.  I attended a lecture by Professor Chris Bishop a couple of years ago on the science behind Kinect and it’s truly fascinating stuff.  The thing is, a lot of his own enthusiasm for the product seemed to come from applications outside of gaming, such as helping doctors control interfaces in sterile environments.

I’m also not trying to say that these types of interface have no place in the gaming world.  There have been some excellent applications of the technologies thus far, and I’ll touch on how some of these implementations overcome the issues with waveprod.  Unfortunately there are also some oft repeated mistakes made with waveprod implementations in games, quite often as a result of lazy porting of an aspect of game design to mobile platforms.  I’m going to touch on two different sides of the waveprod problem – the connection to the game, and the connection to the player. … 


libgdx 0.9.2

At the moment I’m playing around with some different frameworks for game development, but I’m almost certain that (for Android anyway) I’ll keep returning to libgdx.  Love the way it’s designed and the ability to easily throw my game into a desktop version for quick testing is the major strength.

The 0.9.2 update has made me even more likely to stay with libgdx after reading this:

Fancy schmancy AssetManager. I haven’t talked about it yet on here but will do so sometime next week, telling you how to use it. It’s incredibly powerful and allows for asynchronous loading of assets. See
AssetManagerTest for a taste of what it is capable of.

Now I can ditch the crappy one I wrote for Flip! …


Creating Artwork for Developers

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.

Inkscape Export Settings (Ctrl+Shift+E)

Inkscape Export Settings

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).


Lights, Camera, Action: Note the animation timeline along the bottom

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.

Texture Atlas Pro

Texture Atlas Pro

* note to self.  Stop ending sentences with the word Flip! or at least change the name to not self-punctuate.


Flip! LITE v2.0

I’ve pushed out an updated version of Flip! to the market.  It contains a few bug fixes, an updated libgdx backend and 12 new levels featuring a new tile type.  This “cascade” tile will cause adjacent tiles to flip when it is flipped.

One of the fixes was to make sure the game rendered properly on the Motorola Xoom.  I don’t know if this was unique to that tablet, but for some reason it couldn’t load a texture atlas larger than 2048*2048.  Seems rather crap to me, but there you go.

So far it’s not had massive takeup, but as I’ve repeatedly stated, that wasn’t the aim of the exercise and I haven’t put any effort into spreading word of its existence.  When I get around to committing some of my other designs to code  I will put a bit more time into these things.


Fighting the Inner Perfectionist (or Knowing When to Set Limits)

When I was writing Flip! I started with grand schemes.  I wanted to make the engine completely flexible so I could support all sorts of form factors, screen rotation, system power, etc.  I also wanted to be able to define all sorts of characteristics of each level – changing backgrounds, sounds, colours, look & feel and so on.

As I wrote the app, I began to realise just how daft this was.  For something being created with such limited visible complexity and for a very small target audience, I was spending far too much time adding in the potential for these features that wouldn’t be noticed unless one actually dug into the source code!  I’ve always maintained that one of the best games in existence is still Tetris on the original GameBoy (you know, the green and black screen one).  The gameplay (and of course the music) was spot on.  It didn’t need massive complexity and it didn’t need startling visuals.  It was then, and remains now, a complete win.

With games on Android there are still some things that are worth putting the extra effort into supporting.  We all hear the claims of hardware fragmentation problems, and this hits home more than ever when designing a layout for different screen sizes and aspect ratios.  For Flip! I took the approach of having the layout work itself out from the screen size by saying, for example, I want to make sure at least 4/5 of the screen is devoted to the game area itself and then working around that.  I’ve tested on a few different devices that tend to fall into three main aspect ratios and it seems to work well as an approach.

I’ve kept the artwork fairly simple. I’m not an artist so don’t actually have anything to offer by adding all sorts of variable backgrounds.  For the tiles I cut myself back to just a couple of different colour options (Black/White and Red/Blue) whereas originally I had wanted each level to define the RGB values of the two colours used.  I don’t think this is a great loss to the game, but saved me a hell of a lot of effort.

All of these changes came as part of a (necessary) re-write and I’m much happier with the underlying code as a result.  It’s cleaner and easier to maintain, while still leaving me very happy with the end result.  I’ll be taking a lot of these lessons into the next app I write.

The moral of this post is this: don’t think that limiting your ambition is a bad thing.  It’s very easy to be over-ambitious and this has the potential to leave you in a state where you’ll never actually finish anything!  It’s a lesson I was taught many years ago by the chap supervising my thesis, and I have to apologise to him that it’s taken me this damn long to learn it!


Flip! LITE v1.0 Published to Market

Well, I’ve finally uploaded my first app to the Android Market.  It’s called Flip! LITE and it’s a simple puzzle game of the sort you’ll see appearing in many other games over the years.  The goal is to flip all tiles over to be the same colour in as few moves as possible.  Hitting a tile will cause the tiles next to it to flip as well.  The app was built using libgdx and what could be mustered from my free time.  It’s probably not quite what I had pictured for the first release, but I’ve had to balance out time available vs getting something completed.   I did want to have more puzzles in the first release, but these can come in an update soon enough when I have a chance to create them.

Anyhow, give it a go and let me know any feedback.  I know it’s not original, and it’s nothing amazing, but that was never my goal with this first app.  I’ve achieved what I wanted to do: I’ve gotten myself back into a bit of development, I’ve learned a lot about the Android platform and gotten something published.  There’s only up from here 🙂

So what’s next?  Well, I’ll be reporting on the progress of the app in the market on this blog.  I’ll also be working on the next update (some new levels and some better graphic asset management).  I wouldn’t expect a rapid turnaround on this release as the next few weeks are looking pretty busy for me even for the times I’m allowed to get away from work.  I also have a few blog posts lined up to cover things I’ve learned throughout the development process and a couple of new app ideas to start on.