Staying true to the golden days of the videogame arcade in modern mobile gaming

If you were a kid in the late 1970s and early 1980s you’ll no doubt remember the wonderyears of the videogame arcades. The thrills of the new technology that provided hours of fun for us young gamer geeks was mesmerising.

These were the Star Wars years. Science fiction had finally become mainstream and was in the mind of every kid. To be able to visit the arcades and drop a coin to blast everything to hell was the ultimate thrill. We were all Luke Skywalker and Han Solo.

But what was it about those days, the games and their magic that endures and why have we built our business around maintaining the ethos of those early, pioneering days in gaming?

Nostalgia?

This isn’t nostalgia. That’s important. Nostalgia is a fine thing but for us it’s much, much more than that.

Sure there’s a buzz in reliving and recreating the game thrills of our youth. There’s always an inevitable thrill in regressing as you get older. But the key thing here is that there are aspects to ‘retro’ gaming that are entirely relevant to the modern mobile gamer. Not least the ability to be able to pick up a game, have a ‘go’, succeed or fail and then put the game down in the knowledge that next time you pick it up the same challenges will be presented to you without the added blag of being repeatedly sold to.

Better yet you can be sure to test yourself against your (and your friends) past achievements via such mechanics as a high score table or achievements matrix.

It is indeed a decidedly retro thing. There’s a charm to it that has been somewhat eroded over generations of advancing technology. The limitations of a colour palette and small screen resolution forced some ingenious design decisions and pushed the artist in particular, into creating some wonderful effects.

Retro for us is Defender but it’s also Out Run or even Doom. Retro for you may be more relatively recent titles such as Grand Theft Auto 3. It matters not. The point is that there was a charm in the ingenuity of designing within limitations be they graphical or processor.

Mobile devices are phenomenally powerful in terms of their graphical capability and raw horsepower, but they come with their own challenges for designers in terms of their physical size and limited control options. This, for us, is hugely attractive as designers and artists.

We want to try and map aspects of the classic arcade game experience onto modern mobile gaming.

Annoyances

The modern game scene is driven by the desire to sell once and sell again actually within the game experience. We don’t much like this trend. Not necessarily because it wasn’t prevalent in the ‘golden days’ (you can be sure that if it was possible back then it would have been done) but because it’s a distraction from the thrill of the game.

Monetising your games is important from a business sense but ramming it down your audience’s throat is ugly and unattractive. If there’s one thing that annoys us as gamers it’s sitting down to enjoy a game only to be presented with a full screen advert and a tiny (X) to close and progress. For us it then becomes less about you the gamer and more about ‘we’ the business trying to earn a buck.

If there’s another thing that annoys us it’s not being able to get into a game without the tiresome ‘this is how you play the game’. You’ve seen it before, you click PLAY and then you have 5 minutes of a greyed screen with highlighted pointers for how you actually play the damned thing.

Then, if all of that isn’t bad enough, you’re playing your game in the company of a 1/5th screen height persistent advert.

It’s ugly, intrusive and not at all what we want as gamers. As gamers we want to play. Pure and simple. We have our game and we want to play it and use our own intelligence and intuition to get us through.

Identifying these things was key to establishing our plan, or promise, if you like.

Our promise

So our ethos, our promise to the gamer, is that you will pay once for the game (£0.99, for example) and then play without any interference as many times as you like.

In the first two weeks of release we’ll likely offer the game free of charge. Following that initial free period we’ll charge a small fee for the game. We’re not Sega or Namco so won’t be asking for the usual £10.99 to recoup the enormous associated costs of development and marketing.

Staying true to the arcade ethos

True arcade games should not be so complicated as to require lengthy tutorial stages.

Many mobile games are of course fairly complex and warrant a tutorial of some kind. But even then it’s not as though you’re paying to play each time and have somebody breathing down your neck waiting for you to finish. Just wade in and figure it out! I personally often think that tutorials in games are a waste of dev effort and more a product of the heavy-handed marketing department who’ve seen such things in the competition.

“They do it so we should do it!”

It’s nonsense.

Most arcade games had an ‘attract mode’. It was a cut away from the title screen that offered a brief look at the game in action. Attract mode was designed to pull you in and have you spend your hard earned 10p. The cartoonist in me often imagines rows of agitated and excited arcade cabinets beeping, flashing and bouncing to get your attention :)

In many respects the iOS App Store is like a videogame arcade. You’re generally looking for a game to spend your gamer budget on (take a chance on). If the game is free to download there’s no risk, you’re not taking much of a chance!

Screenshots and ratings go a long way to attracting you. Ratings is not too dissimilar to word of mouth. If there was enough positive buzz about a game you’d hear it either amongst your friends or in passing whilst you wander the arcade. If there’s plenty of people stood around the cabinet you can be sure there’s something attractive on offer.

Similarly, if a game has merit you’d read about it on social media, gaming websites or hear about it amongst your gamer peers.

Sifting through the negative feedback and filtering out the ‘it crashes on my phone’ comments should leave you with enough information to persuade your purchase.

Marketing your games is vital and something for a future post. But for now let’s assume you can generate a healthy enough audience for your game on the app stores.

Attract mode translates into the preview video. Gamers are keen to see the game in motion before they commit. Both the iOS and Google stores offer a video preview. This is our opportunity to attract gamers based on the actual game. Flashy, over produced videos that show little or nothing of the game fail here in an instant. Rule 1: show the game in action! Show the promise to the gamer.

Genres and development challenge

We tend toward shoot em ups. It’s just our thing. We loved them all from Space Invaders and Defender through to Raiden, Outzone and Ikaruga. But we’re by no means limited to that genre. The key for us is in the visual style that we can achieve. The graphical potential of a game is a huge draw for us. If we can see a sizeable challenge in the code and art the project will often gain enough momentum to move into development.

The best projects are built on top of a number of key challenges.

From the developer’s perspective it may boil down to the tools that need to be created to build game specific levels. Our current project, Akari, started out as a scrolling shooter that quickly evolved into something that required staging and good level design. Our in-house level editor Neo was adapted to construct such challenges.

The artists and developers work closely to translate design goals into game features.

The time between developments is fun. We enjoy pulling together game concepts, graphical ideas and any other ideas for making a cool mobile game experience. But we never lose sight of our ‘promise’ – that our games will be all about instant accessibility and fast-paced thrills.

We also want to provide a consistent and level playing field. This is why we reject in-app purchases. Mechanics like that immediately offer an uneven playing field.

Social media

Embracing social media is almost essential in succeeding in modern mobile gaming. Testing yourself against your friends and then sharing those achievements on Facebook, Twitter et al is an increasingly important aspect to the game experience.

We’re keen to explore this without intrusion and are looking to integrate Apple’s Game Center and Google’s Play Games in all future games, for example.

It was always a thrill back in the day to visit the arcade and stand in front of your favourite game to see if your score was still top of the tree. Heaven forbid you should be displaced. Nothing would motivate you more than to see somebody else’s 3 character moniker sitting proud above you.

It was actually pretty frustrating to see an unfamiliar moniker sitting immediately above you. We’re convinced that challenges between friends is the way forward. We all want to brag our achievements to those buddies we know we can communicate with.

Conclusion

Modern mobile gaming is hugely enjoyable. The games are staggeringly attractive and full of style. Despite game companies insisting that mobile games are much more than ‘casual’ we feel that actually this is exactly what they are.

To that end, for us, the best games offer instant action and a great challenge with the ability to replay to your heart’s content without ever being pulled away from the game experience.

The golden years of arcade gaming perfected the art of offering such experiences which makes classic arcade gaming entirely relevant to the modern mobile gamer.

 

Defining alien attack formations in a retro shoot em up

In our last game, Thundergun, we adopted a purely randomised approach to generating the levels. That is, the alien formations were predefined prior to the game loading but their formations for completely random.

For our next game, Akari: Battlestar (working title), we’re looking to plan the action with far more precision.

Our inspiration for this game is from the early 1990’s and games like Raiden.

Raiden was a tough game. Very tough. Our game will hopefully be a little more forgiving in the style of what were once referred to as manic shootersDo Don Pachi epitomised this style in which you pitched your fighter against hordes of formation-based adversaries who sprayed bombs (with some elegance) around the screen. Under normal circumstances avoiding the bombs would be nigh on impossible. But this genre used much tighter collision detection; often using just a single pixel in the centre of the player’s ship for collision reference.

We’ve already adopted a similar approach.

But it’s the fighter formations we’re keen to establish up front by way of an in-house level design system. The placement of aliens, cannons, collectables, mini bosses, tanks; you name it, will be handled by this system. Each entity will have all attributes defined and the resulting output stored in a JSON format to be read by the game.

The attack formations for Thundergun were based largely on Capcom’s 1943.

Fighters swooped in, curled around and then flew off. If you took the entire formation down you were presented with a bonus item.

For Akari we want to have a lot more variation.

Fighters will adopt one of several attack formations.
e.g.

  • Drift down from the top of the screen, pause, fire, drift off to the side
  • Drift in from the side, fire bursts, drift off to the side
  • (Tanks) trundle in from the side and follow a set path
  • Squadron formations from the bottom of the screen that fly off screen and return in slow formation

For Thundergun we introduced the concept of a game progress ticker. In code this was defined as part of the global namespace g{} and referred to as g.progress

g.progress bumps with every tick of the game’s main loop. This is consistent and in tune with everything else that the game loop handles (movement, animation, collision etc) so it’s a good base for defining the introduction of alien formations.

As g.progress counts its way through to several thousands for each level it passes what we refer to as waypoints. As each waypoint is triggered a new randomly but predefined alien formation is spawned.

The difference with Akari is that there will be no randomisation. Everything will be delivered from a level data file.

At set intervals in Thundergun the action was interspersed with a mini boss; a larger fighter that drifted into view and bullied the player. Formations continued to spawn around it.

For Akari we’ll suppress the formations and halt the bumping of g.progress while the mini boss action plays out.

With the mechanics for the mini boss developed we have pretty much 90% of the code written to handle a proper end-of-level boss. The main difference will be in defining the scale of the boss and any sub-elements such as wing-mounted cannons.

Level structuring isn’t a new thing for us. We’ve employed it for our platform games and the C64 style shooter Crossfire.

Hopefully we can get a demo up and running in the near future. Exciting times in arcade game development!

Some (more) thoughts on a football game

It’s World Cup year. As a football lover I love the world cup finals. This year we are in Brazil, the home of traditionally the most exciting team in the world. Brazil are generally the neutrals favourites and have, in years gone by, come to epitomise a free flowing style of football that is both easy on the eye and extremely effective at opening up the opposition’s defence.

I’ve thought about making a football game before but have never really settled on a design that suits the nature of the touchscreens that I target.

Lately I’ve been thinking about a game in which the player controls an attacking player with the sole goal of dodging oncoming defenders.
For as long as he has his finger on the screen the player is controlling the movement of the player. It’s all about timing. When an approaching defender looks as though he is about to slide in the player must lift his finger off the screen. This triggers a jump from his on-screen attacker.
If the jump is well timed the play continues until the attacker reaches the edge of the box.

Now it’s about position. As the player steps on to the edge of the 18 yard box the game automatically shoots. But it’s not over yet, the player just has the keeper to beat. To maintain the momentum I don’t want to completely stop the action for the player to place his shot. Instead I’m going to give him as long as he has earned!
For each well timed jump to avoid the defenders the player earns valuable time. Also, to distract the player in to changing direction during his run toward goal I will drop bonuses on to the pitch. The more the player collects the longer he has to aim his shot at the goal.

After each attack it’s the turn of the opposition to attack. But I’m not interested in displaying that. For that I’ll roll a dice and present whether or not they scored to the player. I want to get right back in to the attacking phase so that the player is primarily concerned with scoring goals.

I think I could probably take this design forward in to an initial concept with some crude graphics.

Adding dynamic tweet functionality to HTML5 games

My current focus is with the PlayStar Arcade. I’m keen to push it as a platform for playing my HTML5 games. A lot of work has been carried out “under the bonnet” as we say in the UK and now I’m in to the slightly more entertaining areas of adding bells and whistles.

Something I was always keen to pursue was the ability for players to share their scores via social media. Twitter was my first port of call.
Thanks to their Tweet button script placing a button inside the game was a fairly simple exercise.
The flow that I wanted would see the player complete the game and reach the “GAMEOVER” status. At this point I would present the <div> containing the Twitter code.
The player would then be prompted to share their score and tap the Twitter “Tweet” button. All I had to do at this point was switch the text inside of the code that Twitter gave me with my own text. This replaced text would be what appears in the dialogue box for the player to tweet.

tweet score from html5 game

But there was a problem.

The attribute that I need to change to achieve this is the data-text attribute of the <a> tag in the Twitter script. But dynamically changing this attribute proves useless. 

When the Twitter script executes it converts the <a> tag in to a <div>. Any subsequent calls that I make to amend the tag fail.

I appreciate that this is largely theory so rather than post my own code solutions I’m going to link a site that covers it neatly with code examples.

http://tumblr.christophercamps.com/post/4072517874/dynamic-tweet-button-text-using-jquery

This guy had the exact same problem and solved it beautifully. 
I now have the ability to let the player complete a game, rack up a score and then share it with the world courtesy of Twitter. Facebook is next.

The importance of quickly proving a game concept with JavaScript

I have what I’m sure is probably considered a primitive style of coding JavaScript. It’s never really evolved in to anything that a purist would adopt over the years. To be frank it doesn’t concern me. What’s most important to me is that I understand my code and more importantly perhaps; it works.

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.

HTML5 arcade game screenshot

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

Balancing the action and using a classic for inspiration

Designing HTML5 arcade games with JavaScript has become something of a theraputic exercise. The combined thrills of pixelling, coding and designing the various elements of the action are proving to be quite useful in the stressful run up to Christmas.
Yet despite this I now find myself in that unavoidable “crunch” mode on two projects. I also set a target to finish these two projects by the new year.

A laugh at it now but I shelved my first project as it approached completion to pursue a fresh project. It was of course a diversion. I was deliberately avoiding the pain of that final 10% that takes an agonising amount of time to complete. Now I have doubled the pain!

It’s not all bad.
The discipline of developing arcade games has evolved and tightened over the years to become almost formulaic. This in itself isn’t always a good thing but it can be useful to have a blueprint for design when it comes to balancing, testing and code fixing.

For the most part at this stage I find that the raw code is cut and I’m largely playing with numbers. I play the games A LOT and talk to myself as I’m running through them – always making notes. Here’s such a conversation :)

There’s just not enough to challenge me here. The player character moves too quickly to be threatened by the bad guys. The bad guys need to target the player more. There’s too much room to move. The player isn’t developing any skills in his movement and bullet / entity dodging!

I kid you not. This was a recent note I took.
The beauty of all of this is that everything in the game is defined by numerics. The player’s movement is defined as a speed parameter that allows his co-ordinates to increment each tick. Similarly the other objects in the game perform against the same calculations. In the driving / shooting game (which I currently call Road Rage) the room in which the player has for movement is defined by the road object’s width and height. I applied a .nextthink attribute to the road container which ticks down every game tick. At zero I make another decision on how to scale and move the road.
With this method I can shrink or expand the road with ease after an elapsed amount of time. As a result of my testing and observations above I could see that the road needed to narrow more frequently. The player’s car going “offroad” results in a lot of damage and consequently Game Over so a shrinking road is a real challenge to the player.

HTML5 arcade game

As you can see in the screenshot the road is divided up in to slices. Each “slice” is an object that contains parameters for the ground texture, the road, the road’s verge and the lines that run down the middle.
The only artwork on display per slice is the ground and verge. The other two elements are solid colour blocks.

The tree decorations that overlay the ground are sprite objects and behave in a default sprite behaviour. i.e. emerge off screen, run the length and disappear without any collision detection.

Developing the shifting road wasn’t really much of a challenge. You could almost imagine the process as a series of around a dozen rectangular cards placed in order. By altering the x position of each road object as it is spawned off the top of the canvas (and subsequently allowing the object to increment its co-ordinate) you can create a satisfactory rippling effect that simulates the shifting road. The road width (the solid colour area) is known and therefore I can plot x co-ordinates for the overlayed verges.
Similarly any sprite object that sits on the road can be tested to see whether it has over-run the verge in which case I apply damage to it. Too much damage and it is destroyed. The impact on the random military vehicles in the game is a key part of the appeal as the player’s gleaming red sports car (modelled on a Ferrari 458!) can bump them off the road with a few well timed swerves in the right direction :)

For a long time in the early days of development I was playing the game and struggling to find a core mechanic for it. That vital element of the game that forms the player’s goal or goals. I knew that arming a sports car with rockets and allowing it to shunt other vehicles off the road would be fun, but as always I wanted an intensity to the action that meant there would be a ton of rockets and bombs on the screen. This can cause design problems in terms of setting a challenge since firing a huge amount of rockets and lasers only works if the stuff you’re aiming at is destroyed! It’s no good if the targets just bounce around a bit and are unaffected by your gunfire.

So I dabbled with all sorts of mechanics including collecting valuable items and avoiding oil slicks. They just didn’t work. The thrill of the game is in its pace and causing the car to spin or forcing the player to swerve and collect items just didn’t add up to very much fun. It needed to be a high octane experience with shooting, dodging, turboing and explosions set against an underlying need for speed.

So I fired up Out Run for a little inspiration. A wonderful game from the 1980s in which you drive a car at speed across an undulating terrain whilst avoiding other road users. The game is divided in to stages such that when you cross a checkpoint you are rewarded with a little more time to play.
This did it for me. It was obvious. A game in which you drive a car has to be a challenge of beating the clock.

I could still get away with blasting the bad guys I just needed to ensure that the core goal was to complete each stage in a set amount of time. Adding a timer was simple. I set it to 30 seconds initially and ticked down every second. At zero the car exploded and the game was over.

So the next question was how do I speed the car up and slow it down without having specific controls overlaid on the touchscreen.
This was a no-brainer. I implemented a turbo accumulator. The destruction of cars and military vehicles spawned turbo collectables that bounced around the screen. By collecting several of these the player built up their turbo bar sufficiently to engage a short (10 second) turbo mode in which the car’s speed doubled. The faster the car the quicker the player zoomed through each stage. So there was plenty of incentive for the player to destroy the other vehicles and go collecting the turbo shards.

But this wasn’t enough of a challenge. I wanted to add an element of dodging to the game so I stuck with the idea of the other vehicles launching missiles at the player. One hit and the car was destroyed! Unlike off-road damage or bumping the other cars, missile damage didn’t reduce the player’s “health”. It just wiped them out.

So I’m now confident that I have the game that I was after. As I play it now it’s pretty close to the original design and with the injection of the pulsating soundtrack and over-the-top sound effects I think it’s easily the best arcade game I’ve made to date.

I look forward to sharing it within the PlayStar Arcade shortly.

Building your own mobile web gaming portal – the games

I think that it probably goes without saying  that your games are your primary asset. They are the key to the success of your portal. Treating your games as such is a pretty good step toward achieving your goal of becoming a reasonably sized independent arcade.

It doesn’t take an astro-physicist to calculate that you stand a greater chance of repeat plays in your arcade if you have something worthwhile to offer.

Making sure you have enough quality in your games to keep a player engaged, challenged, entertained and ultimately rewarded enough to come back for more is of course a challenge in itself.
I have 15 games available. Some work well. Generally the older style shooting games. Some don’t work so well. For those that don’t work so well I am analysing the performance statistics to see if there’s anything I can do to improve the experience.

I think it’s probably worth exploring the world of mobile gaming in general and not just focusing on the burgeoning mobile web market. With a little investigation of the mobile gaming world at large we can probably get a good feel for what gamers will want and expect from a gaming portal.

Here’s a few key points.

Design with replayability in mind

Something that the arcade game designers of yesteryear proved to be very good at was designing enough to challenge and entertain the gamer whilst leaving enough behind to warrant another “go”.

This is of course linked to the need for a very visible and realistic target. In the arcades this target was ultimately a high score and the bragging rights that accompany having your name or initials flashing the brightest in the high score table.
But a good arcade game was split in to smaller more bite-sized chunks.

Scramble

Scramble arcade game

Consider Scramble. A tricky game and one that took most gamers a good amount of coins to master. The premise was simple: shoot, dodge, swoop and navigate your way through a deep scrolling maze. The game would throw more and more at you until your were hit or collided with a rock or a wall. It was intense and hugely challenging.

The ultimate goal was to take that top score. This was, in the early 1980s, very much a cultural thing. Gamers in those days would spend play times in school bragging about their scores. Although perhaps that has become less of a draw to modern gamers it is still very relevant to pitch your skills against your buddies.

Yet despite all of this I do believe that as gamers we invest an incredible amount on a personal level when we play. To that end I love the idea of designing stages within a game that must be conquered. On a personal level the gamer must go just one step beyond where they were in the previous “go”. Once this is achieved their attention turns back to the score.

“Right I beat that little challenge now what score do I get as a reward?”

So with that in mind I always try and design games that break down in to stages and also offer a wide range of points values for accomplishments therein.

In a later post I’ll go in to some detail of how I get data in and out of the games and in to a database.

Offering a niche

When I first set out to make mobile web games I knew that I wanted to make arcade games. Specifically the style of game that I grew up playing. They still to this day hold the most appeal.
As a result every game that I have in my arcade is an old-school style arcade game.

Just to ram the point home I even called the portal the PlayStar Arcade. I want gamers to identify with the portal as a source of arcade games. In my next post I’ll talk in some depth about the importance of branding your site.

So when a gamer comes to my arcade to play an arcade game they know roughly what they’re about to experience. The action is brief, repetetive and very much a throw back to the games of 25 years ago. This may not always be a good thing but I think on balance the decision to aim for this niche was a good one. I am engaging a certain type of player and my audience figures and play stats appear to show an increasing audience with a greater willingness to replay.

Something’s working!

I’m always reading about the importance of variety in a game designer’s portfolio. This is probably sound advice but it must be in line with your goals. It isn’t my goal to become a freelancing game designer. I just want to manage and administer my own niche arcade. I applaud those who are able to adapt to changes in the market and stay one step ahead. But it’s not for me. I guess you have to decide what is right for you and what your goals for your portal and your design ambitions are.

Rewards, rewards, rewards

This is a short and sweet one. Make the gamer feel good about playing your game. Reward everything that she does both visually and audibly (where possible). Don’t just display a “well done”. Shower the screen with tiny stars and let the little on-screen character do a little dance. Your gamers will remember it and come craving that feel-good experience in the future.

Screenshots, blurb, action and a challenge

This is a big one. I’m willing to bet that the primary reason for somebody clicking to play your game when it’s sat amongst a sea of games is the screenshot that is used to advertise it. In fact whether it’s a screenshot or an icon make damn sure that what you’re showing is the game’s key selling point.

If your game is a driving game don’t just show a stock image of a steering wheel with the name of your game over it. Show an in-game shot (or an adapted version of it) of a vehicle on the road in an interesting setting.

This of course links back to how you design your games. Designing with a screenshot in mind is no bad thing. When you construct your games try to visualise how it’s going to look sat alongside all of the other games in your arcade.

Those old enough to remember the glory days of arcade gaming will remember the artwork on the cabinets. The image of electro-invaders on the side of the Space Invaders cabinet or the bright yellow Pac-Man set against the largely blue hue of the maze that was in the masthead; both instantly identifiable and designed to pull the gamer in.

Similarly think about how you “talk” to the gamer. You want him to click and play. Give him something to fire his imagination. Calling a game Shoot the bridges is possibly not going to inspire a young boy’s imagination in the same way that River Raid does.

River raider

River Raider HTML5 arcade game

In my own game River Raider I wrote a small introductory paragraph which read:

Fly fast and low and blast everything to pieces. Your mission: destroy ALL bridges along the mighty river and neutralise the enemy threat. But watch your fuel and steer clear of the rocks. If you’re good there’s rank and glory to play for.

I worked hard to try and capture a young boy’s imagination and give him some motivation to jump in and play. I’d hoped that with just a few words somebody might pick up that gauntlet and take up the challenge of destroying bridges and blasting “everything to pieces”.
It also serves as a neat way to present at a glance what the player can expect when they press the start button.

So that’s it. A few starters based upon my own experiences designing games and attracting gamers in to play them.
In future posts I’ll go in to a little more detail about branding your portal and acquiring traffic. I’ll also discuss the tricky problem of converting casual visitors in to loyal gamers.

Tweaking games for a better challenge

I’ve been playing around with a few of my older games lately. Galactians 2 in particular has spent a good amount of time on the ramps.

598x158

Swoop, dodge, blast, bounce and splat

When I wrote it a year or so ago I was keen to just upgrade the graphics from the previous incarnation, Galactians, and boost the player ship’s laser power. My design document for the game was (as usual) a single sentence that roughly read “swoop, dodge, blast, bounce and splat”

To that end it came out pretty close to the design :)

It was a game that I’d enjoyed making and had tested to death before I unleashed it upon the portals. But I guess there was always an element of “am I making it too easy by giving the player so many laser power-ups?”
I still think I was. But the amount of fun that could be had wiping the screen clear of swooping aliens in under 3 seconds was just too irresistable to ignore.

3 second attack waves?

I’d played with the concept of short waves of attack with HyperGunner. It worked quite well in that game so I was keen to repeat it.

4I played Galactians 2 a lot this last week and of course my ability to rack up the high scores increased. Before very long I was in to the millions and the average game length was probably around 10 minutes.
It was only when I stopped to look at that number 10 that it occurred to me that it might just be a bit too long and a bit too easy. Should I be thinking about reducing the average game time?

My Google Analytic stats show me that the average amount of time on a game page is around 3 minutes. This isn’t exactly scientific. It only takes a handful of players to stay on the page for 10 minutes whilst the other lord-knows-how-many-thousand duck in and out within seconds to skew the figures. But that aside I stuck with the notion of 3 minutes per game. It seemed like a reasonable amount of time to be playing and quite possibly the optimum amount of time to trigger that all important I must have another go and do better.

So where next?

The frankly ridiculous jelly bomb

Well I didn’t want to mess with the core mechanics of the game.
I liked how the aliens peeled off the formation and swooped to attack. I also liked how later levels would see a non-destructable guided missile and the frankly ridiculous “jelly bomb”. It also seemed to work that on later levels just as the player was becoming comfortable with the repetition of blasting and splatting some aliens would target the player with their bombs rather than simply dropping them.

It was when I focused on the bombing habits of the alien bugs that I realised something fairly crucial to the game’s challenge / reward dynamic. The distance between the hovering alien formation and the player’s tank was fairly large. Around 200 pixels from the base of the lowest alien to the turret of the player’s tank.

Within that space the aliens would shift left and right whilst diving often in a sharp angle. On the shallower dives the player was pretty vulnerable. But on the steeper dive curves the player had a lot of time to react.
So I tweaked the game to shunt the player up by 48 pixels (I always work in 8’s with sizing in these games. No idea why?) and reduce the severity of the alien dive curves.

More challenging and more fun

The result was incredible. The challenge presented by reducing the player’s available response time was enormous. Better still it actually felt like the kind of arcade game that I grew up playing. I was thrilled.

My high scores were halved, as was my play time. Rarely did I score 1 million and rarely did I reach 4 minutes per game. But nothing was lost. In fact quite the opposite. The game was more challenging and consequently more fun.

The concept of reducing reaction times is now high in my mind as I shift my focus to some of the other games.
In particular Jumpin’ Jasper, which is nearly complete, is prime for applying this “rule” to.

There is of course another benefit to shrinking the play area in this way. The game suddenley opens up to a wider audience of Samsung Galaxy Y and iPhone 4 users. In fact my player sessions have more than doubled as a result.

An extremely worthwhile exercise.

The concept of Greed in game design

A concept that always intrigues me in game design is the concept of Greed. That powerful force that is strong enough to pull you away from your chosen path in the game to try and achieve something. You’re effectively taking a chance. You don’t need to pursue this extra “thing” to complete the game or even the level but the rewards for being successful are just too great to ignore.

capcom 1942

In shoot ’em ups we see it in the pursuit of power boosts to your guns / lasers. Classically in 1942 (above) you were presented with a formation of red planes. If you knocked them all out you were presented with a power-up.
I employed something similar in Crossfire. You didn’t need to hunt this special power down but you just knew that having that extra firepower would be a) more fun and b) pretty handy for completing the level.

With Jumpin’ Jasper I have a similar concept. When a bonus balloon drifts across the screen the player can leap in to it to burst it and take the rewards. Similarly when the Squirrel bounces on top of a monster the monster’s subsequent demise spawns a bonus item. Currently bonuses are purely a points boost. Hardly a real driving force for the player. So I’d like to create a mini-challenge by having a sequence of bonus items to collect. They appear ghosted out at the top of the screen – a strawberry, some cherries and probably a banana (yellow works well against the game’s backdrop) , an apple and an orange. Red, purple, yellow, green and orange respectively all work well against the game’s bluish backdrop.

As the player collects each item of fruit they populate the empty slots at the top of the screen and a special bonus is awarded when all are collected. Quite what yet I don’t know but it will hopefully be enough to see the player divert from his current path to try his luck with the bonus balloon as it drifts in to view. Or possibly take on the monsters to achieve the same result. Of course the random nature of the bonus items’ spawning means that the player could well go to all that trouble to spawn a bonus item that they’ve already collected.

I had initially wanted to run a story through the game and have certain side elements unlocked with progress. This could have been a neat way to involve the bonus items but on reflection I’d rather wait. My next game (which will use the same code framework) will probably lend itself to that approach more since it will be more of a science fiction affair.

A little side project and some thoughts on touch control in an HTML5 platform game

Screenshot

Screenshot from Bouncy

Spent a little time on a side project this last few days. It’s a pretty simple platform game that involves guiding a hedgehog / porcupine type animal around the screen collecting valuable items and avoiding the bad guys.

When I first came up with the control system I had intended for the game to not involve platforms at all. It seemed to be a lot of fun just hurling the spikey creature in to the air and have him pop balloons. But the more I developed the touch control the more it seemed to make sense that the player could jump and walk with ease.

I’ve never wanted to overlay touch controls on to a game. I really don’t like them. So for this game I’m using touchMove() to guide the character around and touchEnd() to initiate playerJump().

The theory is quite simple. When I initiate TouchStart() I set a time with a straight forward function to return the number of milliseconds since some moment in 1970. (I think!)


function time()
{
var d = new Date();
return d.getTime();
};

I store this value in something like m.player.firstTouch.
Then when touchEnd() fires I do the same and store it in m.player.lastTouch.
A simple test to see whether lastTouch is significantly higher than firstTouch tells me whether or not the player has tapped the screen or tried to move the character.

With a bit of fine tuning I’ve also managed to make the character’s movement pretty smooth and of course relative to the player’s first touch on the touchscreen.

The effect is nice. If there’s one thing I’ve learned making these simple arcade games it’s that if your controls are a mess the game will have no appeal whatsoever. According to my Analytics I enjoy a high percentage of repeat plays. I see this as a target to maintain.

I don’t have a title for this game just yet so I call it Bouncy :)
It’s very much a work in progress with still a fair amount of place holder art. But it’s moving along nicely and has given me a valuable distraction from my work on Kyle Comet’s first adventure in space ! As with Kyle my intention is to develop game characters that I can expand on and potentially brand for future adventures.

You can check my dev page for notes and updates on the game’s progress.