Defining the goals in a scrolling HTML5 shoot ’em up

Allow me to think out loud for a moment. I’m trying to figure out the best approach for Rebel Rescue.
The elements to the game that I know I want to keep are

  • constant stream of lasers
  • one directional scrolling landscape
  • rescue the rebel pilots

The elements to the game that I think I want are

  • maintain the decaying energy bar
  • rescue a set minimum amount of pilots per stage

The problem I’m having is that it has no real direction.
So I’m trying to figure some kind of a formula for defining the core challenge in an arcade shooter.
Perhaps I’m looking for something that isn’t there. I don’t know. But it’s a useful exercise in stretching the brain cells in an afternoon !

In the earliest days of arcade shoot ’em ups the goals of the game were quite simple: shoot and don’t get shot.
But in the games that immediately followed Space Invaders and Galaxians we saw a secondary goal added.

Scramble

Scramble

In the case of Defender this goal was to prevent the humans becoming mutants.
In the case of Galaga this goal was to improve your firepower.
In the case of Scramble this goal was to manage your fuel.
So on and so forth.

The first Galactians game had a simple Space Invaders style premise – shoot and don’t get shot.
With Galactians 2 I added the ability to improve your ship’s firepower as well as including more things to avoid.
With Rebel Rescue I’m torn. I know that I want the game to be about shooting stuff and I know that I also want to have the goal of rescuing the pilots. But I really cannot decide where the fun is.
Rescuing your fallen comrades ought to be satisfying and a real challenge but it’s not. Not at the moment anyway.
And I’m very conscious of just littering the screen with crap to prevent you from getting down to the surface to collect the pilot. I want it to be more entertaining than that.

Defender saw pilots kidnapped by aliens before being turned in to rabid mutants. I’m not sure I want that because I have to make a decision regarding the controls.
Just now I have one-directional action because I don’t like the idea of swiping to change direction.
So when the rebel pilot appears on screen the player gets about 3 seconds to do something about it. It’s fairly pointless having the pilot kidnapped since it’d be off screen left before the player had time to react.
So I very much want the pilot rescue aspect of the game to be more of a bonus. But then how do you define the goal of the level ? What do I want the player to achieve to get off the level (or Stage if you prefer) ?

One idea that I had was to provide a finish line. Quite simply a marker in the snow that signalled the end of the level.
At this point the game tots up the number of rebels rescued and provides a points bonus. Bonus points are awarded for the amount of fuel that the player has left in the speeder.

But then I’m not sure that there’s enough in there for the player to want to push himself in the next level.
“Oh right, so I just do it all again do I but this time aim for a bigger bonus ?”
It just won’t work for this sort of game.

So there’s a fine line here to be drawn.
For every challenge I want to present to the player I have to think carefully about what the most that I could do to derail the player’s plans for achieving it are vs what the most entertaining way to prevent the player from achieving his goal is.
There’s a balance to be struck.

In Defender the player was given a window of opportunity to rescue the human and the method of rescuing was to blast the alien to bits. The player then had to collect the human and set him down safely. When achieved this was hugely satisfying.

In Scramble the player was given a small window of opportunity to destroy the fuel depot before it disappeared stage left. More fuel depots would come along but there were only so many that you could miss.
In Galaga you were given a small window of opportunity to jump inside the alien tractor beam. You then of course had to go and shoot it to recover your fighter and boost your firepower.

Falcon Patrol

Falcon Patrol

In the excellent 8bit game Falcon Patrol (another side scrolling shooter) you were charged with taking down a set number of planes whilst managing your fuel and Air to Air Missiles.
This game was quite hard and like Defender a bi-directional affair. To replenish your fighter you would land on the landing pad. The aircraft in the game employed VTOL a la the Harrier “jump jet” so landing was a simple case of lining up your fighter with the landing pad.

Perhaps then I should employ the idea of the speeder flying between rebel outposts. I could include a radar to show just how close the speeder is to the base. When the speeder arrives at the base it lands and the rescued rebels are counted up and a bonus awarded.

This would give the player a welcome period of down time to prepare for the next level when I throw a bit more at him.
This has some mileage.
I’m still not convinced that the player will be encouraged to progress with such repetition but the important thing is I have something to try.

So back to the code to see what I can conjur up. I will probably spend the next 3 days just playing the game to see how excited I am for it.

Thanks for listening ;)

New HTML5 game in development – Rebel Rescue

One of the great things about shelving game projects is that you get to pick up on a fairly advanced development when you’ve cleared your head of the previous project.
When I made Galactians 2 I tried a few new things and generally speaking I’m thrilled with the results. So as I always do I gave myself a week or two to wind down from it before I look for my next project.

I have 3 games on the shelf just now. A Defender-like Star Wars themed game, a pseudo 3D mutant shooter and an Atari Stealth-like flying/shooting game.

It’s the Star Wars game that I’ve picked up to complete.

Rebel Rescue screen shot

I made a similar desktop game about 2 years ago called Hoth Strike. I absolutely loved making that game. The graphics were a great challenge as were many aspects of the game mechanics. As a complete Defender nerd it was a huge thrill to create something that was essentially a big nod to it.

When I completed the game I was so thrilled with it that I sent an email to Eugene Jarvis (the creator of Defender) to get his feedback. I got a simple response, “that’s a pretty hard game”. I felt completely satisfied with that response since anyone who has ever played Defender properly with all those controls will know just how damned hard Eugene’s original game was. It was nightmarish yet utterly absorbing at the same time.

For my latest mobile take on the theme, Rebel Rescue, I decided to respect the platform a little. Mobile devices are not the same as arcade machines. The controls and interface are completely different.
Creating a game with complex controls on a mobile device is pretty much a sure fire way of guaranteeing nobody comes back to play your game.
So I changed the theme of the game from rapid multi-directional blasting to simple one directional collect and avoid. The lasers auto-fire so adversaries can be dispatched as you’d expect. But the crux of the game is in collecting (rescuing) your fallen comrades.

This is my first landscape oriented game so I’m keen to see how my control system is accepted or otherwise by the mobile gaming community. I generally set myself a basic rule of making sure that the game is playable with just one hand. The thumb ought to be enough to control player movement and everything else is a case of colliding and avoiding.

The game is about 70% complete just now and I hope to finish it before the end of the month.

Designing arcade games – a quick guide

So I was thinking about designing arcade games over a coffee earlier …

Game design is often seen as a very exact science. If you learn some “rules” you’ll suddenly be a game designer. I’ve heard and read all sorts.

“As gamers we strive for patterns and repetition.”
“As gamers our primary focus is on ‘tidying’ the screen.”
“Games should be about challenge and reward.”
“Games are at their best when they teach us something.”

The list goes on.

You know what, each is probably true but sometimes I think those in the business ( i.e. selling books ) of game design can be a little too pretentious. Such a high-brow attitude to making games can be quite a dull thing to have to pore over so I’ve knocked up what I call ( well I do now ) my short bullet list to establishing the core to an arcade game.

Here you go. See what you make of it.

  • Create a cool central idea. e.g. blast stuff to hell
  • Create a cool avatar for the player to control and protect
    • Make sure the avatar appears:
      • fun to watch
      • alive !
      • vulnerable within the game’s environment
  • Give the avatar an obvious primary action e.g. shoot, jump etc
    • Feel the action. Don’t just let a bullet lazily drift up the screen. THRASH it up the screen and let whatever is in its way know about it ! Don’t just let your avatar jump lazily up and lazily down – change the pace. Walk,BA-BOING, down again. Bend ze knees. Let the avatar look alive.
  • Create a fun control mechanism for your player’s avatar
    • Understand the target platform’s limitations – auto-firing of bullets is always an option on mobile devices
    • Play with the numbers
      • Don’t just settle for a basic jump or bullet shot. Explore the fun in a super high jump or a screen full of bullets. If it’s more fun stick with it and build your game around it.
    • Feel the fun
      • On touch screen explore the ability to “swipe” or even control the avatar with just one hand for the ultimate in casual gaming
      • On keyboards select the best key for the maximum amount of reward in player feedback. ( Is the space-bar really the best “action” key for your game ? )
  • Give your avatar something to pitch its abilities against
    • Action > Reaction > Consequence e.g. Shoot, Destroy, watch for the bonuses
      ( Mario does it best. Jump, bonk, bonus )
    • Start easy and allow the player to learn the limitations and boundaries within the game and his avatar. e.g. Small swipe = small hop, BIG swipe = BIG jump, don’t touch the edges of the road etc.
  • Consider everything to be rewardable
    • e.g. bonus items, points, the firing of a bigger laser, the ability to jump higher and farther
  • Consider everything to be a challenge, no matter how easy or difficult you perceive it to be. Note: controlling your avatar should never be a challenge
    • Scale your challenges in line with the abilities of your player’s avatar

Beyond this you are firmly in to the realms of staging and level design. I think the underlying theme for what I’m trying to convey is that the first time you implement a feature isn’t always the best way to present it. Play with it. If you’ve built your game efficiently you’ll probably have the ability to just play with numbers. Change the gravity setting from 1.0 to 0.8. See how stuff responds. So on and so forth.

As a rule I build my games to be very simple to operate. I generally imagine that all players have access to the basic arcade stick and single action button ( fire button ). In most cases however the action button is replaced by either an on-screen action trigger ( e.g. the jump pad in Danger Ranger ) or automation ( e.g. the lasers in Galactians 2 ) such that the player is left with the relatively simple exercise of controlling their on-screen avatar.

Consequently many of my game’s challenges involve player collision at their core. Either in the form of dodging on-coming enemies or collecting moving bonuses in order to better overcome on-coming enemies.

If I had to write any kind of strict rules down I’d probably opt for “everything has a score value”, “when you think it’s the most fun it could probably be, just play it a bit more”, “make dying / loss of life / turn / whatever you want to call it a visual treat and for god’s sake restart the action promptly” – watching people play arcade games I often see a tremendous amount of people abandon the game when they lose a life, “imagine the guy playing your game has just 2 coins in his pocket and he spent one of them on your game”.

Above all of course. Have fun. If it isn’t working out shelve it and go and try a different idea.

The beautiful Atari colour palette

Atari screenshot

From the first time I made a JavaScript game (Castle Adventure 2005) I always wanted to capture the colour range that captured my imagination as a boy playing Atari 800XL games. I adored the graphic style in some of these games and loved the way that the developers played with the colours.
Some techniques stick in my mind since they were both very pleasing on the eye and also quite inspirational.
In Ballblazer (above) I loved the way that the designers added the simple glow of the horizon. You might think it doesn’t add much but there’s something about it that just gives you the sense that the game grid goes on for a long way in to the void.

Atari screenshot

Similarly with Stealth (above) you see your goal in the distance – the tall tower – set against what looks like a glowing sunset. At a time when 3D wasn’t working on home computers developers understood that with a bit of imagination (both on the part of the designer and the gamer) you could create a tremendous sense of depth and distance.

Atari screenshot

Encounter (above) was a personal favourite. Such a simple concept – shoot the saucer, avoid the bullets – executed beautifully and with the smoothness that few other games were achieving at the time. The colour palette really added to the sense of fun and adventure. You started on a green planet then moved to desert, snow etc. Wonderful stuff.

Elektraglide (above) was, and is, possibly the hardest game I ever played. Its unforgivingly nightmarish obstacles that infuriated you beyond belief (especially as the stunning music was reaching its climax) were only acceptable because the visuals in the game were so stunning. I remember saving my pocket money for about a month to buy this one and also remember the first time I booted it up. Just fantastic. I particularly loved the snowy levels which again played with the inspirational colour scheme of whites, blues and the pale glow of orange / yellow.

Atari screenshot

Last but by no means least Attack of the Mutant Camels (above) took it all a step further by animating the floor. I always loved the thick gradient style of the sky and indeed borrowed it for the title screen to my own Castle Adventure.

Castle Adventure

Even today when I start out visualising a new game I always take a look at the colour scheme of those early Atari 8bit games. They allow me to become a little nostalgic (itself a great source of inspiration) but also realistic in terms of which colours work well together in an arcade gaming sense.
I am (as I think you can probably tell) loving delving back in time to play these superb games.

 

The pain of fixing canvas dimensions across all devices

In an ideal world I would develop all of my games at a fixed resolution. That resolution just now would be something like 320 x 460. Largely because according to my analytics data from Google the majority of people playing the games do so on an Apple device such as iPhone or iPod Touch.

Of course the problem here is that for every 10 Apple players there is going to be at least 1 Android player equipped with an HTC Desire or possibly a Galaxy Tablet or… the list is endless.

Fixing the canvas size is also great for knowing where items can initialise on screen. You are able to set an accurate scale to your games, you know just how big the sprites are and just how much freedom of movement they can have.
With more fluid dimensions you run in to the territory of working with relative positioning – which is no bad thing and certainly not a difficult thing to work with if you are able to consider it from the outset.

A quick glance at my analytics title sends a shiver down my spine:

48,552 visits used 730 screen resolutions + operating systems

730 different screen resolutions !

So I delve a little deeper to see just what has been viewing these games.

320×480 iPhone
320×480 iPod
768×1024 iPad
320×401 Android
320×480 Android
320×452 Android
320×396 iPod
320×396 iPhone
319×50 Android
320×341 Android
240×320 Android
320×399 Android
320×345 Android
800×480 Android
480×320 Android
480×241 Android
320×240 Android
320×488 Android
267×309 Android
427×235 Android
480×800 Android
1280×1024 Windows
533×239 Android

So at this point I start to wonder about a few things. What exactly are my options ?

  1. Just fix the canvas width and height to the available width and height of the browser window
  2. Ignore it and continue to force dimensions to 320 x 460
  3. Take the window dimensions and try to calculate some kind of a scalable dimension based on height / width ratio
  4. Take the window dimensions and offer canvas dimensions based on a number of presets. e.g. 320 x 460, 480, 690, 640 x 920 – possibly centering the content with CSS

Considering each of these options of course introduces other questions.
For starters at the point when you grab the window dimensions how has the player got the handset held ? Landscape or Portrait ?

For example, if the screen dimensions come back as 640 x 480 is that just because the handset is on its side ? Or is it a desktop resolution.
We can of course check window.orientation for this.
Generally a value of 0 (zero) indicates a default orientation of portrait.
90 and -90 indicate the alternative orientation of landscape.
However, I notice that the Samsung Galaxy Tablet 10.1 sets its default to 0 in a landscape orientation. Very useful indeed. Not.

If, in the case of option 4, I decide to continue fixing dimensions do I need to offer multiple sized sprite sets to avoid sprite scaling ? Most probably. Scaling is a performance dog just now and can yield unwanted visual effects.

So how do you solve a problem like this ?
What exactly can you do to give the player a good full screen experience AND ensure that you are catering for all devices ?
Does anyone have their own experiences / solutions that they might wish to share ?

I ask this question deliberately since I have coded a number of solutions, none that I am truly happy with. Please let me know your thoughts. If comments close (after 7 days to restrict spammers) please mail me. You can find the address in the about page. I will publish your comments if you so wish.

 

New game Danger Ranger and a few lessons from a past master

In the past couple of months I’ve started and stopped a couple of games. The reason was quite simple in both cases – I just didn’t have the vision for the completed game. This is vital for me. I have to be able to see in my mind how the game will look and play right from the outset in order for me to pursue it.

Area51 is a game I’ve always wanted to make. I loved the graphics and love the theme but for some reason I’ve just not warmed to it.
Distant Orbit is another one. I enjoyed the challenge of creating the animated landscape but even with that and the arcing starfighter swooping across the screen I couldn’t quite see the end product.
So I shelved them both.

Screenshot

Instead I’ve started work on a game that I’m currently calling Danger Ranger (after the excellent game of the same name by Ken Kalish almost 30 years ago which was a Dragon32 hit and something I played to death).
The premise is simple – you use a jump pad to leap around the screen collecting stars whilst trying to avoid the 3 bad guys. There are platforms to walk along and as with any platform game it’s largely about timing.
In something of a departure for me there is no shooting !
(The original Danger Ranger had lasers and I’ve fought hard with the idea but ultimately resisted the urge. I wanted this to be a game about leaping around, collecting and avoiding.)

So far I have 8 stages that are built using random art content. I quite like that. As the game nears completion I hope to add another random factor. In fact I urge anybody looking to make cool arcade games to read this interview with Ken Kalish. It really helped me to think about tightening up game content and adding relevant challenges.

In particular this paragraph in response to the question “What is the history behind the creation of some of your games?“:

[“Starship Chameleon”] was my first foray into designing arcade gameplay. After the basic concept was put in, I discovered that it was too easy, too much like shooting fish in a barrel. So I took the path of adding more objects and making them faster. That helped a little, but it wasn’t nearly good enough. The gameplay wasn’t totally absorbing, it didn’t make you step outside of your conscious mind and put you into that zone, in the way that a good arcade game could.
So I would sit there, playing game after game, waiting for the insight that would make it work. Finally, I thought of using the change of color as a way to add complexity. The on-screen movement was two dimensional, and changing color added another needed dimension. That seemed to make the whole thing work. It now required enough parts of your attention and your co-ordination ability and your decision-making, with narrow focus to avoid collisions while also requiring wide focus to be always setting up for what you would do after the immediate threat or opportunity was over.
It also had, at least for me, acquired something that’s essential: when I was done playing a game, I immediately wanted to go and try again because I felt I could do better the next time. A good game always has you right on the edge where you feel that you were just at the limit of your ability the last time out, and you just know you can push that limit the next time. You have that instinctive recognition that if you can just get into that part of yourself where you react immediately and perfectly, while your conscious mind is mostly an observer, that you can go on forever.
Of course, you never achieve perfection, except maybe for some fleeting moments here and there. But that’s enough to make you want to go back into that little world again and again. The actual shapes on the screen and the premise of the game are just a cover story.
At that point, the next thing to do is to insert a wild card. You make up an object that’s worth a lot of bonus points, in order to strike up the players ‘greed’ and make him step out of the proven pattern that he’s developed after practice. So, the player hopefully takes the risky move to go after the high value item. Then he either pays the price and gets destroyed on screen, or else he narrowly escapes by instinctively using his ability to the utmost, dodging, twisting, turning and blasting until he can get back to his normal pattern.
Or, he might have refused to take the bait of the high-risk high-profit opportunity, and curse himself immediately after for not having tried. In any event, the designer and the player both win because the game engaged the player fully and in a way that’s innately very rewarding.
Finally, you add the explosions and the sound to complete the effects of the game. Then the scoring goes in. Scoring is not a trivial thing, since the way you set values on things influences what the player will be going after and that also affects gameplay.

Brilliant.
I hope to have my take on Danger Ranger finished in the next week or two.

%d bloggers like this: