Tap Runner [update]

Development for Tap Runner continues to progress at a decent rate.

The overall framework and game progression is in place, the game is playable and is starting to look half-decent.

Pro-tip: don't step on landmines.

Originally, I had intended to use a bright colour scheme and super-low res graphics but after some experimentation, a more moody med-res look has emerged. The gameplay has expanded a little too, allowing the player to have more control over the running man character. There will also be some sort of bonus level where the player has to outrun a bear and control switches from jumping to Tekken-like screen tapping to run fast enough to escape.

The largest remaining challenge is to make the game more fun and increase its longevity. Right now, it's the same thing over and over getting a little harder with each increasing level. New obstacles need adding and maybe platforms of some sort - the scope of what's feasible is quite large.

Tap Runner

I have spent a little while undertaking some R&D in regards to procedural level generation for Kingdom - as a result, I have elected to do another side project for the time being. Kingdom is turning into a larger and more daunting project than I'd anticipated.

A nifty looking game by the name of Dino Run caught my eye a few months ago. I've not played it so far but it's ingeniously simple and appeals to my love of retro / pixel games. The plot appears to centre on the extinction of the dinosaurs and you control a running dino as he tries to outrun various calamities trying to overtake him.

This simplicity fits nicely with where I'm at in what I want to develop at the moment. Simple is good. Achievable goals are a necessity.

He just keeps on running

I've spent a few hours today putting together a small prototype of a one-tap type game. In this instance you're guiding a little man through a randomly generated world jumping over obstacles as they appear. That, in itself, is obviously going to have limited appeal so I'll be developing various ideas over the coming days, finding ways to expand the game to be more fun and interesting to play. It should be a fun project.

Not anticipating a long development cycle for this one - a few weeks at most provided my motivation stays buoyant.

Building an Engine

Christmas is here again and I've got 12 days to focus on my next Android project.

Various ideas have been floating around my mind for the past few months and I've yet to decide the theme overall theme - either another Sci-fi game or swords and sorcery type stuff.

What I do know is that it'll be another Roguelike, based on the Pixel Station code but advanced in some ways.

Cardinal Quest 2 has been a big influence on my process this time. I like its atmosphere and particularly the way the map is revealed while you play. CQ2 also has some very nice random level generation going on - something I'll be getting deeper into soon.

Initially I'll be adapting the Pixel Station code to run at a different resolution then developing further the map/level code so the player discovers the layout as their character sees it.

Other than that, I'll be using a more linear approach to the levels. Pixel Station allowed freedom of movement around the levels but they were pre-made rooms - with random level generation, re-visiting rooms may not be feasible. Although I want the game to be as sandboxy as possible, that doesn't always add to the gaming experience.

I'm not sure how far I'll get this holiday but I'm planning to spend longer than usual on this game and get it just right.

Meteor Crisis OUT NOW on Android

Meteor Crisis is now available for Android devices via Google Play.

Meteor Crisis - Pre-release Footage

Meteor Crisis - First footage

Missile Blitz

It's been a few months since I've done any serious development so as before, I've elected to make a simple game at first just to ease my brain back into the coding groove.

A long, long time ago a game by the name of Missile Command could be found lurking in your local arcade. It used a giant trackball and fire buttons as it's control mechanism. On reflection, that's quite a tricky way of moving a cursor around quickly and accurately. Nowadays, we're all used to touchscreens and though I'm hardly an advocate for touchscreens, I feel they're the perfect input device for a Missile Command type game.

Mockup of Missile Blitz

Obviously there are a few games of this type floating around the Play Store already but the ones I've tried haven't been great. They're generally too slow and have weird, out-of-place graphics and sound. So I think I can do better in terms of creating a much more fun game to play.

In terms of timescale, I'm not rushing headlong into this as before and risk exhaustion. Nonetheless, I don't imagine spending more than a month on this.. and then I can get back to developing Kingdom.

Missile Blitz is the codename for this project and will most likely just end up staying there and becoming the actual name for it. 

Kingdom

OneSevenOne (that'd be me then) has begun early work on a new game codenamed Kingdom. I'm currently unsure of the ultimate direction this game will take. The initial idea is to produce a game engine based on simple calculations in order to mimic a convincing working 'world' environment.

Other possible elements include building and reshaping the land, researching new tools, machines etc., nurturing the population and so on. I want an original game with new ideas, not a rehash of something that's been done before. This general idea has been floating around my head since the late 90's so is long overdue to be put into production!

Pixel Station is currently unavailable on the Play Store due some crash issues introduced with Android version 5. Once fixed, the game will be published and available for free download once more.

Pixel Station OUT NOW

Pixel Station is now available for Android devices via Google Play.

Getting ready for Alpha

Having had some extra time recently to commit to Pixel Station, I'm nearly ready to release the first Alpha.

I've created an open testing community so anyone can join in and have a go. Hopefully this will be manageable and encourage more people to offer feedback.

Pixel Station is orders of magnitude more complex than Simples so I'll be putting it through it's paces in a more rigorous way.

OneSevenOne Android Testing Community

Android users are invited to join the testing community page linked above. Further instructions are on the main page

Pixel Station: play-through of pre-alpha build

Pixel Station - first footage

A very early version of the gameplay in Pixel Station. A lot of development still to come but this gives a good idea of what the game is like.

Pixel Station is a science fiction turned based game with some Roguelike elements.

I've yet to find a good way of capturing the Android audio so this sounds a bit like a 70's kung-fu movie at times.

Complex 1

Pixel Station continues to progress well. I've spent a good few hours today coding and adding new graphics and sound effects.

There's still a long list of things to do but the game is starting to take shape with a host of functionality up and running now.

Collision detection is always fiddly but as of this evening, it's working well. I used Bresenham's line algorithm to check line-of-sight when shooting and will also use this to determine if an enemy can see the player. Fortunately, someone posted a Java implementation of the algorithm and it was a simple cut & paste effort which worked first time.

Inventory management is nearly complete - this has also turned out to be be an involved task, partly due to Java still being something of a second language for me.

A simple storyline is still floating around in my head so I'm developing the game to fit around that. Or rather, the storyline has evolved from the direction in which the game has been headed, with the various limitations of me and what makes a good game.

I'm hoping for an early summer release, which gives me about three months to get everything done and polished. At this point, that seems like ample time but experience tells me these things don't often turn out quite as I'd imagined.

Pixel Station

Having laid work on Simples to rest, I've begun work on a new project. Originally project SG7, Pixel Station is a  2D space adventure of sorts. It contains elements from various genres but would most likely be compared to "Roguelikes".

I've drawn inspiration from a number of games, old and new:

• Pixel Dungeon
• Dungeonmans
• Corporation (Amiga)
• Hired Guns (Amiga)
• Rebelstar (8-bit)

And likely more than that.

Things are at an early stage at the moment. I've only spent a couple of days on graphics and code so far. I expect development to take considerably longer than with Simples. The scope and depth of the game is much greater so everything is going to take more work.

So far I've added frameworks for drawing a 2D level, moving a player around and colliding with walls etc., the beginnings of enemy handling and some of the on-screen-display stuff. It feels like more than that but that's it so far.

I've settled for 16x16 tiles at 160x240 resolution - so quite chunky looking, even on a phone screen. Any less and the detail becomes too, any higher and I'm just using up more memory - my artistic skill doesn't warrant anything even approaching HD.

Not so Simples

My adventure into Android game development is well into it's release phase. I've been learning loads of stuff about the process and wanted to get a few points down, mainly for reference in the future.

Firstly, the actual development process was a doddle. After a few false starts, I found a good framework that I could jump straight into using. As with most systems, simply setting up the screen and such is fiddly and esoteric so having a pre-made "shell" is advantageous.

The first major hurdle was implementing ad-banners. Perhaps ironically, this really makes the game a bit worse but is a way of being able to still offer the game for free. I'm inclined to use a different model for my next project - perhaps a free demo level then a paid-for pro version containing the bulk of the game. The Silent Age did this really well, offering a substantial playing experience for free but leaving the plot open for more episodes if you wanted to pay a modest fee and continue.

The release process was fairly straight forward, though did involve a bit of waiting - there is a gap of several hours from you updating to the game actually appearing on Google Play.

The largest new area for me, was promotion. I've no experience of getting in people's faces to try and persuade the to do something. I don't like it and find the whole area foggy and full of dead-ends. Most websites that pertain to be willing to help ended up trying to sell me something instead. I don't have any sort of marketing budget this time but will likely need to consider this carefully next time when I have a good product to sell. There is also a waiting game to be played here, sites don't pick up your submission right away so it may be days or weeks before you see results.

Understanding statistics. All week I've been checking my Google Play Developer Console and wondering why my downloads have been static. It appeared no one whatsoever was downloading the game. I thought this improbable but disappointing nonetheless as I've shared the game in a number of places. However, this morning, the stats have all jumped so it seems they may be updated weekly rather than live or nearly live. This is a pain as it's hard to gauge what prompted the bulk of the downloads.

I'm winding down work on Simples now as I've learned as much as I reasonably can from the process of developing it.

One other thing - "Simples" is not a good name for an app. There are thousands of titles with the word "simple" in the name so it gets lost in a sea of similarly named titles.

It's been a brilliant three weeks and I'm pleased to have learned so much in that time. I feel in good standing to continue and develop my next project.

Simples

Simples is out on general release. I've got one or two things to improve but felt the game was good enough and stable for release.

BETA

After a pleasingly short amount of time, Simples is ready for beta testing!

Although I've played the game a lot myself, it needs other people to try it on different devices to make sure it's all working as it should. This is also useful for seeing what people think of the game and if the difficulty levels are about right. I've always been rubbish at my own games so tend to make them quite hard (from my point of view).

If you'd like to join in with the beta testing, you can. Google have a recommended procedure for managing test versions and testers themselves. You'll need an Android device and access to it's associated Google account.

First of all, send me a request to join this Google+ Community: OneSevenOne BETA Testers

Once you have access, follow the link within the community page to access the beta through Google's Play Store.

What would be most helpful at this point:

• Whether the game runs properly on your device
• Which device you're using
• Which version of Android you have

You can give your feedback via the community page, Facebook or email.

That's all there is to it. Simples!

Class Wars

After a few days, Simple Game is well underway. I've been tackling some programming challenges and met with some working results.

First off was writing some collision detection to keep a marble inside a given path. This was more tricky than I first thought, with the marble getting stuck and so on - usual collision detection type bugs. It's working in a basic fashion now - following the correct path, not getting stuck etc.

Today, I spent a while on some particle effects. Specifically, creating an explosion effect by dicing up a sprite into a load of pieces. Previously I'd only ever used little square or lines to create the effect of something exploding. As my sprites are mostly simple squares at the moment, you don't get the best result but it does work as intended. Functionality needs expanding to be more flexible and allow for multiple explosions.

Code-wise, I'm still somewhat baffled by how exactly to use classes "on the fly". Right now, I've created everything at the started and am managing classes with "alive" booleans and so on. Maybe that's the best way to do it, maybe not. It certainly works OK.

I don't yet have a sense of how Java's garbage collection works and when exactly my classes are destroyed. I'm not sure if I'm creating classes over and over, taking up more and more memory. This will need to be looked at sooner rather than later else I'll go a long way down the wrong road, writing sketchy code.

This evening, Simple Game is playable, in a sense. You can't really win or lose yet but you have some control over what happens and the game's rudimentary automation seems to work smoothly.

Side Quest

I've decided to take a break from my main project to undertake something simpler.

The goal of this is to gain a good understanding of the Android development process from beginning to end. As things were, it was starting to look like development was stretching further and further into the future - I was continually getting new ideas that needed looking at and adding to the game design.

So now I'm building a very simple game and will work through the process of beta testing, monetising and publishing. Hopefully by the summer I should have a published title under my belt.

The "simple game" after 1 days work

My design approach for "simple game" is to not really have a design and let the game evolve in a more natural way. I'm not one for having good ideas out of the blue and work much better by looking at something and seeing how it could be developed.

The simple game will involve guiding a marble through a series of square by creating a path somehow. The different colours will influence how you're able to create that path.

Right now, all the app does is generate a random grid of squares and the player can create a path by tapping the squares.

It's not anything you could call a game yet but this is part of my process and how I generate ideas in my own mind.

Vive La Resolution

Being back at my 'normal' job this week has left me little time to sit down and do much coding. So, instead I've been experimenting with graphical styles, trying to settle on a suitable format for me game.

Initially I'd decided on retro style graphics with areas constructed from 8x8 blocks - that seemed sensible as drawing is not my greatest talent. Having tried a few things with 8x8, it seemed that 16x16 might be more suitable. 8x8, though quick to produce gives very little detail.

Now though, I'm even considering 32x32.

[...some time passes...]

After a week off from normal job and playing around with a few more graphical ideas, I've settled on the 16x16 format. It seems my own drawing isn't detailed enough to warrant 32x32. I'll be using multiple 16x16 blocks to create larger shapes to reduce the overall feeling of being blocky.

Another thing I've decided is to have the game divided into levels, like floors in a building connected by stairs and/or an elevator. Each floor will be themed so you'll have an maintenance level, medical level, etc. depending on what the story needs. Each level will have it's own items suitable for the theme of that level. Say you might pick up a nail gun in a maintenance bay somewhere.

Example of a 32x32 block level

16x16 blocks

Visual Inspiration

As a lifelong sci-fi fan, it's no surprise I draw much inspiration from that genre. Thinking about it, most of the games I've made in the past have had some sort of sci-fi theme.

Every time before, I've sat down with a single idea and began drawing graphics, sampling sound effects and ploughed into coding the game. And this time has been no exception.

For SG7 I'm taking visual cues from many sources, mostly sci-fi movies and old 8-bit space-based games. Although it's unlikely my finished result will be particularly atmospheric in comparison to some of the stills below, it's helpful to have a direction to go in with visual design.

The set design in Solaris (2002) is pretty close to the atmosphere I'm trying to recreate. Lots of grey panels, blue-tinted lights and screens illuminated with blue displays. It gives a sterile, claustrophobic feel that works well in the movie but may not translate to a low-res two-dimensional scene so well. Nonetheless, it provides useful inspiration for level layout and specific scenery elements.

The set design for the USCSS Prometheus has similar elements to that in Solaris, but with more displays and lights. Even with that, the atmosphere is gloomy and foreboding - something that I may want to incorporate to a degree in SG7. However, the game needs to be accessible. Players will be pulling out there phones to play on the train, on a break, down the pub.. anywhere, so it needs to work in the short as well as long term.

Fog of War

Getting a bit ahead of myself today but wanted to try out a few graphical ideas. A lot of adventure and Roguelike games use some sort of fog of war, that is, you can only see what your character would be able to see, rather than the whole game map.

Simple fog-of-war implementation

At first I was against this idea. Playing Lords of Chaos back in the 80s, I found the feature claustrophobic and restricting. Over the years, it has become more appealing as game makers have learned to better implement the idea.

There are a few ways you can apply fog of war to a game; here, I've used by far the simplest method by overlaying a static vignette on the whole screen. This is not particularly realistic and I don't believe adds very much to the game.

Later on, I'll be getting into line-of-sight code and ways of shadowing off areas not visible to the player. Some games have scenery in three stages: unseen, seen, and currently being seen. I like that model and will likely implement it myself, again, later on. There are more fundamental things to wrestle with before then.

I'm Your Density

It's nice when a hunch turns out to be right. Yesterday, I was baffled by my bitmaps being cropped to one corner and suspected something to do with pixel densities.

After reading much stuff on Stack Overflow and finding a very helpful video on YouTube, I discovered some useful information about how to properly support Android displays. As there are thousands of different devices with many screen sizes and resolutions, Android simplifies this by categorizing devices into 'buckets' labelled medium, high, extra-high definition etc.

Life's a medium density maze

I'd been using actual pixel sizes on an extra-high def. (XHDPI) screen which doesn't work correctly. The baseline is medium density where a physical pixel equates to a device independent pixel, or 'dip'. A dip on my XHDPI Nexus 4 is 2x2 pixels which explains why all my graphics were being chopped into quarters yesterday.

This evening, I've got part of my test map (yes, Pacman) displaying correctly, without any artifacts and learned that I'll need to make multiple copies of all my graphics in order to support the various buckets. This is frankly a bit of a bind but it's handy to know early on that I'll need to be doing this.

For now I can just work at XHDPI, produce my graphics for that level and make resized versions later when testing on different devices.

Cropped

So it's been a few weeks since I sat down to seriously do some Android programming. I'd never done Java before but have a previous life as a 'C' programmer. Upon first looking at Java, the code seemed pretty familiar and I optimistically felt making the change would be relatively trouble-free.

That's not quite been the case but with some perseverance, I've started making some progress. It's been an awfully long time since I did some coding, longer still since I had to learn anything new.

In the mid 90s, I taught myself 68000 assembler for the Amiga and learned how to use the various custom chips on that system. Being young and at college at the time, it took a couple of years before I produced anything decent. Two years seems an awfully long time now so I'm more focused in order to produce something useful sooner.

Back then I had two books - Amiga Machine Language and the Amiga Hardware Reference Manual. Now I've got, it seems, the entirety of human knowledge available to me via the internet. And that's been quite a problem - there's much dross, opinion and discussion about every possible topic so it's hard to weed out useful information and answers to my questions.

Still, I'm happy to report modest progress in the few short hours I've been developing for Android.

The world doesn't need another block game

Doesn't look like much, I know. Java on Android is a bit fiddly to set up so just getting a blank screen to draw on was a faff.

So far, all my test app does is load some resources - a couple of PNG images and a WAV sound file. The squares are the beginnings of a 2D level and the man is, well, just a man at the moment. He responds to touch input and moves to wherever you touch the screen.

Tonight, I have two outstanding issues, both with the map drawing. The squares are being cropped to the top left quartile and for some reason the map is being displayed sideways. I've had to set the tile size to 200% the actual size to get them to display correctly. More fiddling is needed - I suspect something to do with pixel density at this point but to be honest, I have only the smallest idea what I'm doing.