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

Post a comment or leave a trackback: Trackback URL.


  • Cody  On November 9, 2010 at 2:43 pm

    I agree with your sentiments about enemy AI. Gauntlet got it right. As long as the pace is good and lots of enemies are lining up to be killed, the fun factor can be there.

    In rare occurrences, the enemies did find alternative routes to you; as they huddled up against corners, it would create a cluster that would occasionally spill over.

    Since you’re talking about player health, you might want to consider enemy health as well. Gauntlet had a balance of going in guns blazing vs. luring out enemies in small groups. To prevent either from being exploited, enemies had some health to stop the gun blazers (they’d swarm you before you could kill them all) and regenerating monster boxes to stop the luring strategist (they’d regenerate about as fast as you were luring them in some cases with enough monster boxes). Plus, the fact that your health went down on it’s own pressured you into not taking all the time in the world.

    Gauntlet had a surprisingly delicate balance to encourage both types of game play. It even threw you for a loop by punishing wild button mashing by making food destroyable.

    Anyway, food for thought. ;-)

  • markw1970  On November 9, 2010 at 2:53 pm

    Yeah, I saw that spilling over effect. I think I can get that effect without too much effort. Just now I’ve had to suppress the diagonal movement to get something close to the desired effect.
    I also implemented a spawning point for the monsters. But I need to test it since I have problems with monsters spawning in on top of other monsters and getting stuck thanks to the monstersCollision() function. I added this to stop monsters overlapping against the walls but now it’s working against me.
    The spawning point is actually a sprite object so I can test its co-ordinates before respawning the monster.

    Destroying health potions / food is next on my list ;-)
    Much of the problem is that I shyed away from using a scrolling viewpoint. I have to create a game where Gauntlet’s action can be played within a static arena.

    Such a fun game to research.

  • Hemebond  On November 10, 2010 at 1:20 am

    Gauntlet 2 mobs would actually try to get around obstacles; at least on the Amstrad. For example if you were directly north of a mob with a block in between, the mob would move north until it hit the block then, when it wasn’t getting any close, would make a short journey east or west to see if there was a way further north.

    • markw1970  On November 10, 2010 at 10:57 am

      Thanks for the comments Hemebond. I will take a look.
      Emulating Gauntlet 2’s monster behaviour might just require a bit more brain power than I have available just now ;-)
      Certainly an interesting exercise though.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: