Ever since my first foray in to browser gaming I’ve stuck to my goal of creating the kind of games that I enjoyed in my youth. Generally speaking this means classic “pixelled” sprites and the control of an on-screen character / spaceship / vehicle of some kind. Ideally I’d also throw in bombs, lasers and explosions a plenty.
If I’m honest it’s also a pretty easy style of game to write.
I guess right now I’m wondering whether it’s right for me to continue to target this niche in retro gaming or whether I should move on a bit and challenge myself with a different genre.
There are benefits to maintaining a niche and also several drawbacks.
The benefits clearly come in the form of brand association and search relevance. The more I can focus on writing about a specific area of mobile gaming the more I improve my chances of being returned favourably in Google et al.
But sticking to a niche also narrows my opportunities in the wider field of attracting work. Whilst I’m always going to favour working on my own projects and my own designs I can’t disregard the fact that there is some value in being a coder for hire.
Arcade games, the classic ones (which I guess we now refer to as retro arcade games), offer some wonderful pointers for achieving an optimum in designing games for casual mobile play.
Arcade games almost by definition were games that you could play and access quickly and each “go” would last for little more than a few minutes. This is what your single coin gave you and if the experience was a good one you’d possibly sink another coin. If not you’d move on and find something else.
This has real parallels with today’s online games scene. Especially the mobile web gaming scene.
HTML5 game portals tend to target mobile devices. The good sites are clean and optimised for display on the smaller screens. As such they are pretty straight forward to navigate around and generally uncluttered. The same cannot be said for the desktop equivalents which in many cases are more of an excuse to litter the screen with advertising than offer any kind of a gaming experience.
My stats continue to show me that my games are popular. When somebody visits the site they generally play around 3.2 games per session before they disappear. 6% of visitors exit via an advert. I’m not actually sure whether those 6% have enjoyed their time on the site and played that average 3.2 games or whether they’re simply hacked off with the experience and were looking for a way out. I guess there’s every chance this is the case.
Regardless mobile arcade games and mobile game design (HTML5 game design) continue to challenge my brain cells. I’m always thinking of new elements to games that I scribble down for later reference and often draw upon them when I’m thinking of the finer details of a game’s execution.
I use SNES and Arcade emulators (ZSNES and MAME) on a regular basis to research gaming styles, challenges, reward systems and every other vital element of a good gaming experience.
MAME generally offers that throwback to the mind boggling and dazzling array of cabinets that beeped and zapped at me as I stalked the arcade for that perfect way to spend 5 minutes and 10 pence. I suppose it gets me in the mood :)
The SNES games on the other hand are showing me the visual style that I’m aiming for. Especially in my most recent game Jumpin’ Jasper which was every bit a SNES inspired game.
I’ve not set out to find any magic solution here it’s really just a Sunday morning blog update with a coffee and some thoughts.
I have to say that playing and designing retro-styled arcade games still thrills me. There’s a lot to be said for this.
I may be missing a trick or two by not becoming a more high profile game developer but maybe that’s not for me.
An old manager once said to me “Stick to what you know by all means but do it well. Do it very well. Be the best at what you do well and above all enjoy it.”
The benefits of knowing my own code and the intimate relationship that I have developed with it have time and again proven useful. Not least when I’m approached by clients and 3rd parties to implement their own code and / or extract data from the game. Simple modifications and tweaks are simpler because I know my code inside out and the upside to all of that is of course that such changes are quick. Or at least quicker than they would have been if I’d had to first figure out how the code works.
There’s another huge benefit to writing and understanding my own code which for me comes in to its own when I’m considering a new game. I often daydream about a game or take inspiration from the most random things. I’ve got sketch books full of ideas and documents on my computer full of code snippets and high concepts.
To try and explain I’ll briefly explain the process of developing one game.
Some time last year I was driving home after a long journey across country. Not too far from home I remember pulling off the motorway and as I approached the traffic lights on the slip road I watched the striped yellow lines on the road. As I slowed to stop I remember clearly thinking how cool it would be to create a game in which the player controls a jet fighter that flies low over a striped landscape. Inspired by the illusion of the lines cascading beneath the car I turned over in my mind how the code might look. It didn’t take much to figure it out and that game turned out to be Distant Orbit (pictured).
I could prove the concept quickly because I knew how to adapt my code base to implement the stripe objects that form the planet floor. Better yet I visualised the game loop and could understand how to scale the alien bugs as they emerged over the horizon. There was nothing overly complicated in it and using the same approach I could quickly implement the tower that forms the player’s primary target in the game. The thought processes in understanding scale rates and how to manipulate such events per game “tick” came to me pretty quickly and because I understood the underlying code that handles the drawing and moving / scaling of objects I knew pretty much how the code would look.
What’s valuable to me is being able to take a concept, process it in my mind (and therefore visualise it on screen) and then move quickly in to code. It’s only by being able to do this that I can quickly dismiss an idea or take it to the next step – design. I like to have one quirky feature per game: striped floors, scrolling terrain, 3D trench, starfield; and it’s generally this feature that I’m focusing on at the concept stage.
Much of this is always done using “defaults” for sprite art and defaults for audio. All objects have default behaviours as sprites in my code and adapting them to behave differently is 5 minutes work. At least to prove the concept. Fine-tuning can happen much later on as part of a balancing process.
So in short it’s crucial for me to be able to very quickly get in to coding. When I have a vision for something I spend a short amount of time poring over the approach that I’ll take and then it’s all about cutting code.
In future posts I’m going to break with my own tradition of not sharing my code. You can see for yourself just how ugly code can render some pretty cool looking arcade games :)
My larger Kyle Comet project is moving along nicely and today I’m enjoying spending a little time researching a couple of smaller side projects.
I have a real love for quirky Japanese arcade games that involve super simple challenges and pretty much demand that you drop another coin in to have just “one more go”.
I’ve taken to MAME to explore a few of these and am enjoying trundling through the likes of Bomberman, Bomb Jack and Diver Boy. Simple games with a clear and simple goal. Better still they have extremely simple controls. Generally it’s a case of move the guy and press a button for a single character action.
Naturally this kind of simplicity lends itself to simple touch screen gaming where user input is a little restricted.
I currently rather like the idea of a game where the player spends his time avoiding obstacles whilst leaping around collecting moving items. It’s a simple premise and ought to be a straight forward development. The appeal in the game will extend to its presentation and such things as a quirky soundtrack that bounces along in the background as the player’s character leaps about the screen.
Kyle is my primary focus but I’m a big fan of smaller diversions every once in a while.
Castle Quest renamed to Dungeon Adventure. Received an email from the creator of a browser based game with the same name. I wouldn’t normally have bothered but his game was quite established and by the looks of it he’s working on the game full time, so it seemed fair to me. Especially since my game wasn’t complete.
I actually rather like Dungeon Adventure plus I own the domain dungeonadventures.com so I have some tie to the name at least.
Some initial thoughts on a back story for Dungeon Adventure:
The castle has been overthrown, the King is dead and the dark warlord Azuran has taken to the throne. The kingdom is in turmoil.
As the King’s court fell to Azuran’s army of evil the good wizard Melligan hid deep in the castle dungeons for in amongst the catacombs and creepy crypts lie the ancient Spell Stars that hold the power to banish Azuran and his wretched horde for good.
You must guide Melligan around each dungeon collecting all of the powerful gem stones and avoiding the ghosts of long forgotten prisoners. Hold on to the glowing Dragon Orbs for periods of immunity from the undead and be sure to collect the key to the dungeon door. Only once you have that and all the gems can you escape…