An introduction to designing mobile arcade games

Before I start to present some thumbnail views of potential mobile game designs I just want to recap a few thoughts on the control system and a rough structure for the design of each game.

So much in designing games for mobile (be it an app or a mobile web game) is dictated by the control system. The lack of buttons to press is both a blessing and a hinderance. Far too often with console games I’m left put off and baffled by the spaghetti-fingered controls so I find the relative immaturity of the touch screen interface refreshing.
But of course the moment you want your mobile on-screen character to walk, run, jump and shoot you have an issue.
As I’ve blogged many times before I never overlay a joystick and buttons.

I have several games that sit on my developer’s shelf just now that never made it beyond concept phase. In many cases this is due to continuing to scratch my head about the controls. Automating certain actions is the obvious way forward (player movment, auto-firing weapons…) and balancing this with giving the player something to control that relies on developing a skill is where the mobile game designer spends a good deal of his time.

Generally speaking I centre my games around a single “gimmick”. Something a bit quirky such as the pseudo-3D effect in Distant Orbit or the scrolling trench in Crossfire. For me it goes hand in hand with the formation of the central challenge.
Recently in Super Jet Boy I hit on the idea of controlling a character with thrust alone. As a boy I’d played Dropzone to death and wanted to emulate the way the spaceman rotates on the x-axis. This formed the core of the game for me.

Dropzone screenshot

Dropzone

In my design documents I always start with a small section called Gimmick :-)
I then expand on this to identify and develop the core challenge and any sub-challenges. The one thing that (if I got the design right) is never a challenge is the control itself.

So with my designs I will initially try to present a rough genre, style, visual style and high concept. I will then expand to explore what it is I want the player to actually achieve in the game and of course identify what it is that stands in his way. From this I expect a bunch of challenges to fall out and this is where the game starts to come to life. Exploring where the real fun of the game can be found should be fairly organic.

All questions welcome and of course if you have your own thoughts on mine or your own designs feel free to share them.

Talking about HTML5 games and cool game designs

I love sketching out game ideas. The thrill of designing a spaceship or game character and trying to figure out what monsters and challenges lie ahead has never left me.

photoshop worksheet

Designing sprites for the HTML5 game Galactians2

Right back when I was a young teenager in the early 1980s I got a buzz out of watching a TV show or film and dreaming of how the events therein might translate in to an arcade game.

To this day I keep a sketchbook in the car or an iPad mini at my side should I have inspiration. The one thing I don’t do (which I really should) is share my thoughts on here. So all of that is going to change. In an attempt to breathe some life in to my much neglected blog I intend to spill my design thoughts on to here a bit more frequently. There will of course be an obvious bias toward mobile web gaming and the technologies of HTML5 / JavaScript. But generally I just want to get back in to the habit of talking about games and cool designs.

Some more thoughts on an HTML5 mobile adventure game

I’m determined to make an HTML5 adventure game so here goes with some more thoughts on the potential design of such a game.

The games that work best for me are the ones that are instantly accesible. Load assets (acceptable delay) > splash screen (acceptable and expected delay as long as it’s short) > title screen / menu > straight in to the action.
I employ this with all my games and simply offer a link on more recent titles to study a “how to play” screen.
For my adventure game I want to offer something similar that allows the player to simply pick up from where they left off with just a tap of the menu.

The game itself I would want to centre around the pursuit of experience (XP) and therefore higher levels.
Combat would be a huge feature in the game as would the collection of loot. All fairly standard for an adventure game so far.

Where I want the game to stand out is in its “randomness”.
I enjoy crafting structure to arcade games such that the player’s expectations for what he will see in each level are always met. Consistency is key in games where the player is chasing a high score.
But with my adventure game I want the experience to persist across multiple game sessions with the player finding himself in a new location / situation every time he comes to play.
In some circumstances that situation may be a confrontation and the player’s options will be FIGHT or ATTEMPT TO FLEE.
In other circumstances the situation may be designed to progress the story, say an in-game character attempts to talk or barter with you. The player’s options in such a scenario are varied.

In any scenario I would aim to present two buttons on the screen at any one time – the player’s actions being limited to simple A, B decisions.

Example 1 – interaction

The Inn-Keeper wants to talk with you.
[ TALK ] [ IGNORE ]
TALK selected.

The Inn-Keeper tells you a story about the fabled treasures buried within the dark castle’s dungeons and guarded by the spirits of the King’s fallen soldiers. -more-
[ CONTINUE ] [ STOP ]

Example 2 – confrontation

A GRUE stands before you and demands that you surrender your weapons and gold.
[ FIGHT ] [ FLEE ]
FIGHT selected.
The combat screen appears and the player must fight the GRUE to the death.
All adversaries drop loot.

I call each of these scenarios STAGES.
Stitching each stage together in a way that captures the player’s imagination and moves the story along is vital to the game’s success.
After each stage I would save out to localStorage all of the game’s data. Asking the player to save progress seems terribly out-dated to me.

Clearly this sort of a game experience works best when the player has limited time available to play.
Pick up the phone, launch the game, complete a stage, close the phone. Next time the player comes to play he finds himself that bit further on.
Indeed changing the location is very important to allow the player to feel that he is progressing through an adventure story.

What I haven’t completely thought out is how to present these stages when the player has perhaps half an hour to kill.
Although half an hour is an extraordinary amount of time to play a mobile web game it must be considered.
My initial thoughts are to use a map and have the player attempt to move between locations to unravel the story.
Another variation on that theme would see the player progressing through a randomly generated map with towns, villages, citadels and places of interest all popping up at loosly defined intervals to give the impression of a realistic world.

In a town or village the options system would change. The player would be in a safe zone so there would be no need for combat decisions.
In a “place of interest” the player would have a different challenge. Perhaps a stealth mission where the player controls his character around a maze whilst trying to avoid monsters.
If successful the player is rewarded with treasure.
In places of interest there would always be the threat of combat regardless of the underlying challenge to the player.

Another slightly more radical idea I have had is to make the game completely open-ended. No fixed goals. Simply let the player explore the world and discover new things whilst advancing his XP and level.

Still very much at the “brain-storming” stage but I’m getting closer to actually laying some code down and fleshing out the game.
I have that many concepts on the shelf just now it’s ridiculous. Hopefully one of these will see the light of day soon!

Some thoughts on player interaction with HTML5 mobile games

I currently have a number of small side projects which are for all intents and purposes simple design tests. My current focus is with establishing new, reliable and aesthetically satisfying ways to have the player interact with the game.

Basic control – Touch, slide and first-touch free movement

Initially with Wizard Wars I stuck to the basics and the game centered around tapping the screen to direct the wizard.

Subsequent games have seen simple slide left and right controls implemented to steer cars and star ships.

More recent games have seen me register the first touch and allow free movement in all directions. I like this approach and generally find it to be the most satisfying to play. Games like Crossfire (my homage to the C64’s shoot ’em up heyday) and Desert Rescue really benefit from this style.
So for the most part all of my games exclusively feature one of those three methods of controlling the on-screen character.

The only time I veered from this simplicity was with Dungeon Adventure. With hindsight I’d perhaps concede it didn’t work out so well and the control system took a lot out of what was a potentially enjoyable game.

Feedback and limitations

With mobile game development – HTML5 or otherwise – it’s vital that the game’s design is wrapped around the limitations of the touch screen control. I have never implemented on-screen buttons and don’t have any plans to. It just doesn’t work for me. The whole point of pressing buttons to affect the action is in the touch > tactile response > on-screen action dynamic.
For example the process of a ships laser firing in response to a button being pressed is empty without that central bit – the tactile response to the player.

Feedback in games is important to me, as is the management of player expectation. In many cases it makes a lot of sense to automate basic actions. e.g. your on-screen character automatically runs and you simply tap the screen to have him jump.

With Danger Ranger I desperately wanted a platform game experience. To achieve this I placed a jump pad at the base of the screen. As the player’s on-screen character walked in to the jump pad he was thrust high in to the air. The player’s only control was in sliding their finger left and right to control the character’s movement.

So there are several genres that can be achieved even with the limitations of a touch screen. We just need to consider these limitations and design the game around them.

Classically of course ports of great arcade games have failed to deliver since they were designed for different interfaces. Defender springs to mind. A proper spaghetti control system if ever there was one. Not a great game to try and play on a sheet of glass.

Fusing a couple of ideas together

So moving forward with some new design ideas I’d like to try and fuse some of these touch styles together.

Initially I considered Bomb Jack as a project.
I’d always loved the game in the arcades and figured it was colourful and lively enough to translate in to a good casual / mobile game. Better still it could quite easily be shoe-horned in to my Danger Ranger code base.
The issue of course was in the control of “Jack” (I assume that’s his name).

Bomb Jack arcade screenshot

Bomb Jack (Arcade version)

So what is Bomb Jack ?
Well essentially you play the game by directing Jack around the screen with the joystick. and hitting a button to have him jump in the air. He only jumps when he’s on solid ground be it the base of the screen or one of the floating platforms.

This makes things quite easy in that I will always know when he’s NOT flying or falling. So if the guy is on terra firma any tap above him on the screen could be an instruction to launch him skyward.

Of course whilst he’s in flight the side swiping controls still work to control him albeit at a slower rate.
For this to work there would have to be a threshold set around the character since the simple act of tapping the screen with the intention of moving him left or right is also going to fire touchStart().

Jump vs movement

   A         B  <-- Any touch here results in a jump
  ------------- <-- Slide control threshold
                <-- Any touch in this region moves Jack left and right
        J       <-- Jack's position
  ============= <-- Solid ground

Hopefully the crude illustration above makes some sense.
J is relative to Jack’s position and the dashed line above him marks the uppermost region for touch events that result in his walking left and right.

Tapping in the A or B region will send Jack skyward to the left or the right respectively. In reality I would aim Jack to the point that the touch was registered to give greater granularity of movement.

Whilst Jack is in flight the illustration isn’t relevant and any touch on the screen will drift him left or right until he finds solid ground.

Pure theory right now but so far I’m happy with it. In fact if it works I’d be happy to consider more complex platform games.

Crossfire – an HTML5 vertical shoot ’em up – development update

Just a quick update as work on Crossfire (previously Stargun) is moving at pace just now.

I’m very keen to use the project as an exercise in broadening the featureset of my game framework.
Currently I’m focusing on creating the kind of vertical shoot ’em up that was popular around the late 80’s and early 90’s. The sort of game that you might have played on an Atari ST or Commodore Amiga. I didn’t personally own either machine as this was a period in my life when I didn’t do much with computers – parties, playing in a rock band and girls were far more important :) – so this is very much an exercise in researching the games of the day via YouTube & VGMuseum, buying a few old magazines and firing up emulators.

It’s a huge amount of fun and the results are proving to be very exciting.
I’m still using a 2 pixel brush as a hang over from the previous game. I rather like the pixellated style of the artwork that is produced and may continue the theme through a few more games. Drawing with a bigger brush in Photoshop is a lot of fun !
I guess the irony is that the artists of the day were probably desperate to work with greater palettes and increased resolutions. They would probably look in horror at how I adoringly craft these retro-inspired spaceships and effects :)

Crossfire fighter graphic

So the features of the game are pretty established.
The in-game level editor / structure allows me to define a JSON map of the level and then iterate through based on a pre-defined delay. As the code ticks through the level row by row a new set of obstacles / bonuses / enemies / power-ups is spawned just off the top of the screen and moves slowly in to view and off down the screen.
Based on the sprite’s type and class it will then animate, glide, blink on and off, shift left and right, rotate, be destroyable or simply shoot at the player.  The combinations available to the level’s designer are huge !

I also took the decision to have the player’s fighter move instantly with the touch.
In River Raider I implemented a kind of drag effect. As you slid your finger across the screen the plane drifted in to position. A kind of drag effect. I think it worked for that game and gave you a little more to think about. But in Crossfire I wanted the movement to be instant.
It’s a mobile game so to enable this functionality and still be able to see the fighter sprite I register the first touch on the screen and move the fighter relative to subsequent touch co-ordinates. This really is the correct way to control your on-screen fighter / character. Too many times we see a virtual joypad and it really doesn’t work.

So currently I’m designing the enemy and toying with the idea of using a pre-rendered scrolling backdrop rather than just the trenchlines that I detailed in an earlier post. The game has a distinct feel and character which I think (hope) the retro shooter enthusiasts will enjoy.
It also has some cool sound effects courtesy of the Buzz JS Audio Library. Getting this to work across the board on mobile is flaky so ultimately I think the audio will be a desktop feature. But big things in mobile audio are on the horizon so watch this space.

Hoping to complete the game within a couple of weeks and push it to PlayStar (mobile only) shortly after. As always the game will be available for licencing on a non-exclusive basis.

Short (choppy) video for new HTML5 “Trench” arcade game

Following on from the previous post about creating a crude Star Wars style trench as viewed from above I thought I’d post a video of it in action.

I put some additional work in to throwing some aliens around and having the player’s ship move freely. I resisted the urge to have the ship tilt like a fighter plane as it banked. The game just doesn’t need it.

Additionally I threw in some bonus / power-up spawns which are triggered by predefined alien attack groups. In the final game these groups will become visibly noticeable.

The game is still a little way off completion but is growing in challenge and complexity by the day. Gotta love the older games :)

Converting Robotron in to an HTML5 mobile web game

I’m looking for inspiration for my next arcade game and somewhat predictably I turn to the games of 30 years ago.
Robotron was a stunning arcade game. In many respects a pure arcade game. It was a game that could only be played at a cabinet with two joysticks. The sound, the visuals, the player feedback.. awesome.

Robotron arcade game

Robotron

I like the idea of it a lot as an HTML5 phone game. But the controls. Something’s got to give with the controls.

Lazy coders that port these kind of games place two virtual joysticks on the screen and expect you to handle the lack of touch feedback like it’s second nature. The purists would of course argue that altering the game to suit the touch screen’s control is an act of pure heresy so the virtual control seems to be the only option.
But I’m intrigued by the potential for presenting a similar game where the game actually handles something – say, the movement !

Radical for sure.

The thing with these mobile games is that you really need to feel comfortable with the controls.
I always present the simplest of demands on the player where possible. e.g. swipe left and right to move the player. Rarely to I deviate from this.
The game’s code tends to handle such things as laser firing automatically. That way the player is concerned more with movement and the game is as much about avoidance as it is about blasting the enemy.

But with a Robotron style game the movement is quite free and the lasers are independent of the player’s movement. The 8 way lasers define the game.
Which bit to you hand over to the code ?

Perhaps it’s time to hand over the player movement to the game. Shift the player’s avatar horizontally across the screen and allow the player to touch the screen to direct his lasers.
I don’t know. It’s just thoughts right now.

I tend to try and strip the game back to its foundations and identify where exactly the fun is to be found. In a game like Robotron the fun is in being surrounded by a ton of things to blast to piece and therefore the fun is in blasting things to pieces. It’s almost like there’s an unwritten rule that sits within this game’s design that reads “if you’re gonna recreate this for God’s sake honour the blast-everything-to-pieces ethos that defines the game”.

I love Robotron enough to attempt to honour it. (I swear Eugene Jarvis knew how to make great games)

I also love the idea of grabbing a 2px square brush in Photoshop, editing my grid to be 2 pixel squares and coming up with some cool graphics.

Watch this space :)

46 per cent of all video game time comes from a mobile device

It is with huge interest that I read this statistic. For the last 2 months I have had my head buried on a project and haven’t really looked up very much to the wider mobile gaming world around me.
I had wondered just how much of a foothold mobile gaming has achieved lately so it’s hugely encouraging to see that almost 50 percent of games are played on a mobile device.
From the point of view of an open web game developer it’s surely significant since these devices will be HTML5 compatible. Quite whether the browsers are good enough and fully support all the features that we have been spoiled by on desktop is another matter, of course.

46 per cent of all video game time comes from a mobile device | Mobile content industry news | Mobile Entertainment.

PlayStar.mobi Free Mobile Arcade Games

It has for a long time been my intention to create my own mobile gaming portal.
I had been using the m. sub-domain from spacemonsters.co.uk (m.spacemonsters.co.uk) with some success but I really wanted to shift everything on to its own dedicated domain.
Furthermore I didn’t want the domain name to bear any resemblence to an HTML5 gaming resource since the technology really ought to become transparent.

So I now have great pleasure in presenting PlayStar.mobi. A dedicated mobile-only resource for free-to-play arcade games.

Just now it is a simple case of click to play the game but over time I hope to develop the site to include simple registration, high score tables, social functionality and achievements.
PlayStar will also be my project for testing integration with Facebook which as you may well know is on a huge drive to embrace mobile and HTML5 this year.

%d bloggers like this: