Category Archives: Level design

HyperGunner – level / wave design theory

HyperGunner is turning in to something to be proud of. I’m very excited to be developing it just now and am thoroughly enjoying assembling different game elements – scoring multipliers, power-ups, hyperspace bonus phase etc.

hypergunner title graphic

HyperGunner titlescreen graphic

What I’m most thrilled about is the pace of the action.
When I first started assembling the game code based off the previous game – Wizard Wars – I fell firmly in to the trap of thinking it should be just another formulaic shooter a la Galaxians. As much as I loved that game in my youth I knew that it needed something more.
A brief foray in to manic shooters taught me a great deal about maintaining pace in a shooter and increasing the perception of pace through some visual trickery.
I employed as much as I could in HyperGunner.

 

I guess the biggest success in terms of game design was the concept of waves within waves.

Initially I created a screen full of about 32 aliens all jiggling across the screen and essentially lining up to be shot.
It was dull. I knew I needed something more and that something was to have the aliens move much more freely. Rather than simply being cannon fodder they needed to be cannon fodder with a bit of movement.
So I stripped the alien count down to 8 and implemented movement patterns.
Depending on which stage of the wave you are in you will see the aliens move in a certain pattern.

Naturally each wave was over very quickly since with just 8 shots you could dispatch the lot !

HyperGunner in-game action

HyperGunner in-game action

So I looked in to having layered waves. That is, waves within waves.
On the first level you have 3 waves of aliens to clear before you officially complete the stage. Or level. Depending on which terminology you prefer.
On later levels you can have up to 25 waves of aliens to clear.
Each wave to be cleared is represented by a small flag icon in the lower part of the screen. This visual indication is vital to show the player what he must achieve.

 

I implemented 4 movement patterns for the aliens and it plays very well. But again it needed something more.
So I looked in to having a wave that is quite different. For this I looked at an old Atari game Threshold. This game had swooping bird-like aliens falling down the screen and I loved the way that it broke up the standard flow of the game. It was quite simple to implement even though the calculation for adjusting the x co-ordinate took some playing with. I’m still not totally happy with the movement of the swooping aliens (they tend to fall in to line too easily) but there’s enough in there for a challenge. For now.

 

HyperGunner in-game action

HyperGunner in-game action - older version

So with the core challenge figured out I set to looking at the bigger picture. After all, it’s fine blasting through countless waves of aliens but it’s important (I think) to focus on greater goals.
I was obsessed with the idea of hyperspace. So much so that I wanted to encourage the player to aim for hyperspace. I also wanted to have the visual effect of hyperspace with the stretched stars falling down the screen at high speed.

So I implemented an energy bar that is boosted with the collection of stars.
Bright gold stars fall down the screen when aliens are shot. Essentially the aliens release them. The more stars that the player collects the larger the energy bar. When the energy bar reaches right across the screen the player enters hyperdrive !

Hyperdrive is both a visual diversion and also an opportunity to score double points for each alien hit.
It currently lasts for about 10 seconds. I also went to the trouble of affording the player 5 lasers per button press as opposed to the normal in-game maximum of 3. The effect (I think) is stunning.
The rewards to the challenge of collecting so many stars without losing a life are great on both levels – visual and interaction.

By the time the hyperdrive phase is complete the player could have easily scored an additional 10,000 points.

I will discuss the game elements in detail a bit more once the game is complete. I have quite a bit more to do before I can call it complete. But for now it is, I think, a hugely thrilling game to play.

My organic design document

I don’t know how interesting this is for people but it struck me as interesting just how many game developers (inparticular those that make very casual games, such as myself) write design documents.

I had a quick look around the web last night for fellow casual game designers and stumbled upon some interesting discussions.

Design notes for Wizard Wars and Invaders from Mars

Apologies for the poor quality. I took it rather hastily with my BlackBerry. Not a great camera.

I guess where there’s more than one person working on a project it makes a lot of sense to have a document full of ideas. But for me there’s no real requirement. I just use one of those rather neat little Moleskine pads and scribble down my ideas on the fly :-)
It will probably bite me on the backside one day that I don’t invest time upfront planning my games but so far it’s served me well.

I just love idly scribbling down thoughts and cartoon sketches for my characters.

I’m working on a mobile version of Invaders from Mars just now hence the little sprite sketches that you see in the picture. The Wizard sketch is my sole wizard design for your little guy in Wizard Wars :-) Merlin style of course.

I hope to have something to show for Invaders pretty soon.

Brief analysis of Atari’s Gauntlet – Monster Movement

I am focusing my efforts on the behaviour of the monsters in my Gauntlet-esque game.
I want the player to be able to move freely shooting anything that comes at him. Similarly I want the monsters to move convincingly around the level effectively trying to sniff out the player.

I decided to take another closer look at Gauntlet courtesy of YouTube.

What struck me was how unintelligent the monsters actually are. In my mind the ghosts and wizards had walked around the walls to seek out the player. What actually happens is that they line up against the wall in a big huddle waiting for a clear shot at the player.
In essence they are happy to correct one co-ordinate at a time. That is: where the PlayerX co-ord is less than the MonsterX they will run to correct the difference. If a wall stands in their way they continue to correct the X co-ord but simply bump up against the wall.
Where the Y co-ord is different the monster will simply slide up and down the wall in an attempt to correct that co-ordinate as well.

What doesn’t happen is the monster intelligently looking for another route. At least I didn’t see that kind of behaviour.

This is hugely encouraging since my own game code would take an enormous hit if I had to implement paths.

Sprite movement

Sprites "hunting" the player - but not intelligently

It all boils down to what is acceptable to the gamer as a challenge. I am convinced that if I can get close to Gauntlet’s style of play I will have enough of a gaming challenge. I literally do want the monsters to line up and be shot. I want them to fall in to position such that I can hurl magic at them. I will have to address the one strike and your out element of the game just now. Perhaps re-employing the health status as before (and of course as Atari do it themselves).

A rethink on the level design / goals of “Castle Adventure 2”

I took a time-out to explore some game design ideas.

To start with I needed to write down what I had come up with so far with my game. I then mapped that on top of what I originally set out to create.
The results were interesting.

So far I have created the following game mechanics:

Each level is populated with monsters to be avoided and items to be collected. Collecting certain items reveals an exit to the level entering which ends the stage and prepares a new one.
The monsters can be dispatched by magic powerballs which are collected at various points around the level. One shot to kill one monster.
The crux of each stage is avoidance and collection.

My original design idea was to have a free roaming fantasy arcade experience where the lead character was free to shoot hordes of monsters. In the style of one of my favourite games as a kid – Atari’s Gauntlet.
I wanted the action to be quite frenetic in that it was to be a case of “player is chased through the level by seemingly endless monsters” until he finds a key and escapes.

Quite what went wrong during the “build” process I don’t know but I seem to have lost focus.

With Invaders from Mars and Hoth Strike I kept my design document (a single sentence scribbled on a post-it note) in view at all times. I hadn’t done it this time.
Losing focus is a killer.

So I took the time to re-address the design and try to steer the whole thing back on to the tracks.

For the most part it’s not a huge change to have the player firing at will and dashing around avoiding monsters. I did afterall force the restriction on the number of player missiles and monsters on screen deliberately at some point to slow the action down and change the direction of the game.
So I unlocked it all and let the player run and gun as previously intended.

To counter the fact that the player could wipe out the monsters with ease I set them to respawn. Previously the monsters respawned to their original starting point in the level. I changed this to have them respawn at a Magical Swirling Energy Source. All respawning monsters come through that portal. In the level designer I can set this point.
In the game the energy source is visible as a rotating sprite.

Magic in game

Magical swirling energy source - the monster spawner !

This gave me another dynamic and a useful goal. I already had the collection of the strange brown artifacts as the key to exiting the level. So I used the collection of all gold coins as a means of destroying the energy source.
No energy source = no respawing monsters !

I kept the magic balls for the player to collect and just had them granting the player a short burst of rapid fire. It lasts around 10 seconds.

The last thing I tweaked was the ability for the monsters to literally hunt the player down. I figured that a monster that had been shot would be pretty pissed off so I gave them the ability to sniff out the player. It currently doesn’t work so well on diagonals so will need to rethink that. But when the monsters actually hone in on the player it can get pretty scary trying to outrun them. Especially as the monsters are set to have x3 speed on respawn.

The key to the monster chasing player scenario is as much about level design as it is AI.

As the fourth version of this game takes shape I hope to have many more monsters on the screen at once. I am going to try a level without so many walls and see how it fares.

Play the latest version here: www.wilfscorner.co.uk/sandpit/4/castle.php

Building levels and refining the game experience

At some point the thrill of solving game design issues will give way to that final slog of packing the whole thing up in to a playable game. Such things as title screens, game over presentations and handling certain gamey elements. I also need to consider what happens after level x (where x = the final level). I’d like to present something nice to the player as a reward for his efforts in my ever-more-complex dungeons.

But for now it’s all about puzzles, rewards and designing cool scenarios and monsters.

As I’ve blogged previously I’m a huge fan of creating enough of a stable codebase to be able to play with graphics. I’m an artist first and foremost. In the not so recent past I worked as a game artist. It’s what I really enjoy the most. Being able to construct these game worlds and actually realise them is a huge thrill.

One of the things that I’ve been toying with is the regeneration of level entities following playerdeath().
In the past I’ve always respawned every gem, powerup, key, bonus etc after the player character has died. It’s just an easier way to handle things. But with this game I’ve decided to leave the level in the state it was in immediately prior to playerdeath().

So when the player dies and respawns back in to the level all the previously collected items do not reappear. Much like PacMan where the eaten dots stay eaten.

There are a couple of exceptions to the rule; keys and magicballs. Keys because you may have collected the key and died before reaching a door (doors remain open after playerdeath). Magicballs because they are designed to respawn mid-game anyway.

I think the result is much more satisfying and less daunting for the player.

An old school friend of mine (Gary Webster) has been busy with his own bit of nostalgia creating Commodore 64 style game music. As kids we marvelled at the work of Rob Hubbard and Martin Gallway. Back then the UK spawned the best of game talent (IMO of course) so it’s a great thrill to be able to actually honour something so personal from our childhood.
Webbo goes by the name TheLastWaltz and his work can be found on SoundCloud.

Whilst I’m figuring our the Audio element of HTML5 I implore you to give his work a listen whilst playing the game.

A great example of C64 style music can be found here: http://soundcloud.com/thelastwaltz/game-tune-2

The latest version of my game can be found here: http://www.wilfscorner.co.uk/sandpit/3/castle.php

Note: if you have problems viewing the game at the first time of asking hit F5. I need to figure out the problems and start pre-caching content.