Category Archives: Artificial Intelligence

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


Hoth Strike – AI modifications

The latest upload of Hoth Strike contains some AI changes. I had wanted to present a game where the player deals with varying alien behaviour. Up until last night much of the behaviour was predictable and samey so I decided to revisit it.

probe_0_1The probe is essentially the probe from the movie. I loved the dangly leg thing that was going on in that so it made sense to base it closer to the ground. I set the threshold to be about 3 probe heights from the base of the canvas. Better still I wanted it whizzing around like a probe on a mission. i.e. sniffing out rebel pilots. So I set a couple of new properties .floatdir, .upthresh, .downthresh.

Each of these new properties controls which way the probe is floating by way of a modification to the alienmove() function. The code sniffs for the sprite class and if it’s “probe” performs the modification. A floatdir of 0 sends the probe floating up and a floatdir of 4 sends the probe downwards. Better still I modified the speed of the probe and set it off at pace as it changed direction finally slowing down to almost a stand still before it flicks back the other way. The result is satisfying and from a player’s perspective a wee bit trickier to hit with the lasers. I’m happy with it since it ought to be close to the ground and now it is.

pod_0_1 I also modified the pods (the pink energy balls) and had them track the player a bit more by way of a simple modification based on tileDirection. They appear to linger a bit more now rather than just zip off as they did before.

mutant_0_1Finally I addressed the mutant. Defender’s mutants were horrible wobbly things that were a complete swine to hit. I wanted something similar so I modified the alienmove() function once again for spriteclass “mutant” and simply wobbled the sprite in a random direction by a random small amount.

I also added a special effect in the form of spawnSnow() which as you might gather spawns a snow flake. I perform this every time the probe or the player is in close proximity to the ground. The effect being that such close proximity would probably throw some snow up in the air. It’s particularly satisfying as you swing the speeder around !

Just now I have an issue with waves not ending properly. You could wipe out the bad guys and have rescued all the rebels but the wave would not terminate. It’s a checksum issue and something I’m looking at.

You can play the latest game here:

Fine tuning the action in Hoth Strike – a question of balance

There’s not much left to do on Hoth Strike before I draw a line under it and move on to my next game. But something that has been playing on my mind just lately is the question of balancing the action. I’m not a fan of implementing skill levels in games since they bring with them their own problems with level playing fields. I want everyone to experience the same game and to work it out such that they become competent and confident at it. That said I can’t just hurl stuff around the screen and expect players to accept it. I desperately need to consider balance.

A decision that I took early on was that I wanted to emulate Defender as much as possible. I prefer to set a stage and repeat it ever so slightly bumping the player’s requirements with each “wave” as opposed to say designing muliple levels. I’m very much an arcade gamer and not somebody who wants to sit down and devise a multitude of tricks and traps. At least not at the moment. Just now I’d much rather have the player see the limits of the game and work out how to “survive” within a static arena.

So I set out to design a few aliens and have them behave differently to one another. Some drift like jellyfish, others hunt for the good guys whilst some hunt the player or bounce annoyingly around the screen. Most spit laser bombs at the player (I even went to the trouble of plotting the player’s position relative to the alien and have them fire their laser bombs in a relevant direction!) and all will kill on impact. I wanted to have the player spend most of their time zapping the bad guys and probably spending most of their time in flight. But then I realised the player cared for nothing. They didn’t much care that the aliens were just drifting around since he had no goals. Hence the design goal of rescuing the rebel pilots. Instantly this new dynamic prompted the “mutant” alien idea. Lifted straight from Defender and DropZone the player had to stop the landers from capturing the good guys before they mutated in to the awful “chasers” that made those games so difficult. The player was now potentially all over the screen to complete the wave.

It still pains me that my original intention of having AT-ATs in motion had to be scrapped through my own failings at animation. The dynamic of speeding across the landscape taking pot shots at the walkers would have been stunning. But just now it’s not to be.

So to the point of this post.
In my games I try to design on a point – counter point basis. That is, where the point is to collect an item I make it the sole objective of a game object to frustrate the player when he’s trying to collect that item. In Invaders I threw bonus items down the screen and upped the alien bombing rate in an attempt to thwart the player’s attempts at powering up. With Hoth Strike I wanted to be a bit more intelligent with it. Where the player has to collect a rebel pilot I create an alien whose sole purpose is to look for rebels and destroy them ! Where the player has to carry a rebel pilot to safety I make sure that there’s enough on the screen to bring him down.

It’s that last bit I’m bothered about.

Simply littering the screen with obstacles isn’t very good game design in my opinion. I want to inject personality in to the probes such that they hound the player based on the things that the player can achieve.
The player can swing his speeder left and right, for example, so why not have an alien that tracks the player perfectly thus reducing the advantage of being able to swing the speeder around.

Now that the game objects are in place I will be fine tuning the game in terms of it’s execution.
If anyone has any ideas they’d like to share / offer then please do drop me a line.
This is the fun bit ;)

Super Copter update – jet fighters and bombs

I have been putting some effort in to refining the Super Copter game code and playing with the concept of spawning jet fighters way off screen. The simple reason for this is that they can then attack the player from right to left. I handle all jet sprite movement in a single function and randomly modify the altitude of the fighters with a random “bob”. This is reasonably satisfying although I’m convinced that diving jets would be a whole lot more satisfying.

Something that I wanted to implement was “smart” bombing. I wanted the jets to target the player with their bombs sensibly based on their position in relation to the player. Here is a verbose look at the code I currently use:

if (oPlayer.y < o.y) // Player above
if ((o.y – oPlayer.y) < 100)
o.x > oPlayer.x ? oAlienBomb[a].direction = 6
: oAlienBomb[a].direction = 2;
oAlienBomb[a].speed = nGroundSpeed + rnd(2) + 2;
} else {
o.x > oPlayer.x ? oAlienBomb[a].direction = 5 + rnd(2)
: oAlienBomb[a].direction = rnd(3) – 1;
oAlienBomb[a].speed = nGroundSpeed + rnd(2);
} else { // Player below
if ((o.y – oPlayer.y) < 100)
o.x > oPlayer.x ? oAlienBomb[a].direction = 6
: oAlienBomb[a].direction = 2;
oAlienBomb[a].speed = nGroundSpeed + rnd(2) + 2;
} else {
o.x > oPlayer.x ? oAlienBomb[a].direction = 3 + rnd(2)
: oAlienBomb[a].direction = rnd(2) + 2;
oAlienBomb[a].speed = nGroundSpeed + rnd(2);

Hopefully you can see what I’m trying to achieve. Directions run clockwise from 0 (North) through to 7 (North West). I only implement 8 core directions and modify them as required.

I’m going to document this “smart” stuff in more detail at some point since I think it really makes the difference between a game experience and a game challenge.

Some object theory and a little sprite improvisation

With Invaders I was pretty much following the natural course of events during some research in to classic DHTML sprite manipulation. I had looked in to HTML5 and the much talked about Canvas element and it’s many benefits but I wasn’t happy that I’d explored JavaScript enough to pursue it.

I started at the start and created a base “class” that all sprites in the game would be instantiated from. Literally everything that moved in the game would have its properties set in line with this one object definition. It started to get messy since it made no sense, for example, for the player’s ship to have an attribute harmPlayer. By the end of the game I had got quite sick of examining attributes for sprites that just didn’t need them.

With the next game I am going to deliberately split out the object definitions and it was this that got me thinking about the types of sprite that I will present.

There will always be a player object. The character, ship, car or object that is under direct control of the player. In many respects this is a unique element of the game since it is potentially the only object that doesn’t carry aggression. With Invaders I was sure to set an aggression level for each sprite which was aimed toward the player object. Most other actions that the sprite could perform centred around this attribute.

But I needed to take a step back from this. I needed to look at the necessary actions that the game must take to make it all happen. I simply boiled it down to this:

  • Move
  • Animate
  • Collide
  • Die
  • Fire

With Invaders I had two functions handling movement. The first function was also bound to the animation function. You can see this between levels where the second method is employed whilst the aliens form the pack. There is no animation on the on-screen sprites !

The new game will completely separate Movement from Animation and handle it independently in the game loop. Collision will also be handled on the game loop as in Invaders. Death frames are handled within Animate but it is a unique state in its own right none the less. Firing of missiles is actually a trigger the object handling is a separate consideration.

Further breaking down the model I will consider a number of sprite types (which I’m careful not to call classes since JavaScript doesn’t employ that concept).

  • Alien
  • Player
  • Missile
  • Tile
  • Effect

Taking in to account the earlier problem of sharing attributes I will now be able to assign specific attributes to the sprite based on its role within the game.
For example, missiles are only concerned with movement, possibly animation and being tested for collision. They are not concerned with the triggers of launching missiles. Similarly the alien is concerned with all aspects and is by far the most complicated sprite since it will naturally employ intelligence of some kind. Alien movement can be a complicated and expensive affair. Coupled with collision detection and animation based on circumstances the alien is complex. The player controls his own sprite so much of the complications of intelligence and behaviour are removed.

Towards the end of Invaders I dabbled with the concept of spawning. This proved useful for generating such things as explosions and puffs of smoke. I also used it for the green gunk that the Beholder dropped on dying.

I used what I called a bucket approach for this. I defined an infinite bucket array that would handle each sprite. When something was spawned I dropped another sprite in to the bucket. The game loop handled every sprite object in the bucket and at the end of the level (or on player death) I emptied the bucket and reset the array index to 0. It worked beautifully and I ran several hundred spawned objects at once without any impact.

In a future entry I will post up some object definitions based on what I’ve written here and some basic code for handling the game’s sprites.

Alien bomb management

A decision that I took very early on in the development of Invaders from Mars was to contol rather strictly the number of alien bombs that were on the screen at any one time. I’d figured (largely from playing Do Don Pachi and other manic shooters) that this was key to the difficulty of the game. I’ve since found that there’s a fair bit more to controlling a game’s difficulty but the design decision stuck none the less.

The logic for an alien firing is quite simple. Each alien has an aggression setting. If a randomly generated number between zero and the alien’s aggression falls between a set threshold then the alien will become interested in firing. Previously I’d left it at that and randomised the direction (3, 4 or 5 – SE, S or SW) and speed. The result was unsatisfactory since the player had nothing to rely on. No pattern ! I’d found that playing other arcade games revealed that the player responds best to aliens firing in bursts but hadn’t really wanted to go down that route since I imagined it was a pain to implement.
So as a simple workaround I opted to only have one alien type (Squid) firing in random directions. All others would fire south all of the time. It made for a more comfortable game in that the player could predict the alien’s behaviour 90% of the time but ultimately fell flat for the same reason.

Alien bomb burst

Alien bomb burst

When I load the game first time in I build “pots” of bombs for each level. Essentially I define a set amount of bombs that will be at the alien’s disposal for each level that increases in size throughout the game. For example, level 1 (pot 1) will contain a maximum of 5 available bombs. As bombs are spawned they dip in to the bomb pot. When a bomb reaches screen edge it is “killed” and becomes available again. For level 1 therefore you will only ever find a maximum of 5 bombs on screen at once. This proved to be a useful way of controlling difficulty.
Towards the later levels the screen could become full with 60 bombs which when firing in all random directions provides (I think) a sloppy experience for the player.

It was time to implement aliens firing in bursts.

To my surprise it was extremely simple. I set a flag to on or off to indicate whether the alien was in firing mode and then counted down through a preset number to zero. On each count the alien would attempt to launch a bomb by dipping in to the pot. The result was perfect. Aliens would fire up to 5 consecutive bombs in the same direction. On the later levels (where it matters most) the screen would soon become a kaleidescope of alien bombs. This was just the result I was after and provides a far more satisfactory game experience.

The more I play Invaders the more I realise that I am edging closer to the “no brain” style of gaming that Don Pachi, Esp RaDe et al all present. It really is possible to almost switch your brain in to neutral and just move between patterns erasing the screen of aliens in delightful waves of lasers whilst avoiding the shapes.

A worthwhile and significant development.

Giving the enemy an identity and setting player expectations

I’ve very much come to the conclusions that the key to turning a series of well met challenges in to something that is fun lies with meeting the player’s expectations. In order to do this we of course need to set those expectations.

With Invaders from Mars I decided to set expectations by identifying each alien by its own trait. Some just hurl bombs whilst others dive when shot and others actually launch laser bolts. All the aliens move in a uniform pattern and none fly around the screen in a series of parabolic curves a la Galaga and Galaxians. This is a deliberate move that in part has got plenty to do with the fact that I have no idea how to plot those curves. Besides, it just doesn’t seem necessary to create a good game.

As I’ve written previously I’m a big believer in presenting a bonus and immediately presenting an obstacle to aquiring it. Most of the game is executed in this style with the ultimate bonus being the high score in the top corner of the screen.
To expand on this I balanced the game’s levels and placed what I considered to be the trickier opponents in the later levels.

When the level loads and the screen fills with aliens the player gets a glimpse of the task ahead. Initially I thought it was just a cool prelude to the action but I’ve since realised that there is a level of excitement that builds as the aliens move in to position. In one sense the player is looking at an organised structure that he knows he will bring crashing down, and in another sense the player is looking for familiarity. If, for example, he sees the Beholder move in to position he instantly knows that they take a shot at the expense of some acid coming his way. A whole line of them is going to be more problematic than a vertical stripe. Similarly the Drones that tend to sit atop the level pack will fire a laser when agitated. They also fire the lasers at some pace. If therefore any Drones fall in to position lower down the pack the player knows that he has little time to respond.
The pack formation may only take a second or two but in that time I’m successfully setting player expectation. Once the level kicks in it’s up to the player to destroy them all. I’m convinced that there is a good deal of satisfaction to be had by knowing just how the pack will perform as it takes shape and a far greater satisfaction in destroying the pack in a patterned way.

I’ve seen it written before that patterns hold some clues to the secrets of fun in games. Perhaps I’ve never acknowledged it before due to not actually having first hand experience of it.

Player missiles and basic alien behaviour

I put some effort in to game structuring and refining the game stats to provide a smoother and more satisfying experience. This includes allowing the player to shoot as many lasers as their finger tapping will allow.
Note: Movement is with arrow keys (L and R) and lasers are Z or SPACE.
You can see the latest test (#4) by clicking the tech area link over on the right. (

The game’s structure follows a simple 3 step process. That is, we are always in 1 of 3 possible scenarios (Attract Mode, Ready Mode or Game Mode). Attract mode is essentially the front end with all menu options and fancy pre-defined sequences to attract the player. Ready mode is the short time that the player has to prepare for action and Game mode is obviously the game itself, or the back end.

In addition to structure I attempted to spice up the alien behaviour. Again I used a simple parameter that goes along with the other instantiation parameters and defines the alien’s tendency towards aggression. (i.e. how likely is it to drop a bomb)

I also took a look at basic movement and decided to add a ‘think’ flag. Currently each alien will whizz around the screen in their default direction until they have exceeded their think time. At this point they consider changing direction. If their tendency is towards moving around a lot then they will change direction other wise they just stay on the same path. I quite like the randomness of this but for the final game I can’t manage any player expectation like this. I will have to bite the bullet and look at patterns and formation.