Jump to content
IGNORED

"Bad guy" AI for games


rdefabri

Recommended Posts

I was playing Raymaze 2000 and I noticed some interesting AI for the "bad guys".  That had me thinking - how do you build in that AI in a game?


Of course, it depends on the type of game, some have far easier models.  I'm just curious how you build the logic, and what that might look like - not so much the code, but the logic and how it works.

Link to comment
Share on other sites

A lot of it from back in the day was pretty primitive.

These days game AI is a lot more complex but we're talking multi GB games on PC and console there.  Homebrewed legacy system games we still have those old limitations of lack of memory, slow CPUs and limited instruction sets.

 

There's plenty of articles describing AI these days like pathfinding etc.  There's some technical descriptions of arcade Pacman to be had - each ghost has it's own behaviours that can be taken advantage of and it's worth reading up on.

  • Like 2
Link to comment
Share on other sites

24 minutes ago, Rybags said:

A lot of it from back in the day was pretty primitive.

These days game AI is a lot more complex but we're talking multi GB games on PC and console there.  Homebrewed legacy system games we still have those old limitations of lack of memory, slow CPUs and limited instruction sets.

 

There's plenty of articles describing AI these days like pathfinding etc.  There's some technical descriptions of arcade Pacman to be had - each ghost has it's own behaviours that can be taken advantage of and it's worth reading up on.

I'll have to check out some articles - the concepts other than basics are new to me, but it's definitely something worth knowing.  As I think through creating some games of my own (should I ever get there), this always looms as an unknown for me, particularly for something where the "bad guys" chase or follow you.

Link to comment
Share on other sites

A lot of the "old days" programmers just made it up as they went along.  Hobbyist programmers BITD didn't have research or articles to look at.  There's a lot to be said about just getting some stuff onscreen and moving, then just playing around with the code to see what works.  Fun and educational, IMO...  🤪

  • Like 2
Link to comment
Share on other sites

1 minute ago, glurk said:

A lot of the "old days" programmers just made it up as they went along.  Hobbyist programmers BITD didn't have research or articles to look at.  There's a lot to be said about just getting some stuff onscreen and moving, then just playing around with the code to see what works.  Fun and educational, IMO...  🤪

Funny enough, I was thinking decision trees, but then felt maybe not so efficient.  In doing some research here, I stumbled across a comment from another person about using decision trees - so I guess my brain is functioning somewhat properly! :D

Link to comment
Share on other sites

15 hours ago, rdefabri said:

I was playing Raymaze 2000 and I noticed some interesting AI for the "bad guys".  That had me thinking - how do you build in that AI in a game?

You could try to look for some kind of source code, or disassemble the original Z80 roms (from the arcade version), or maybe look at the 6502 NES version (not the exact same game, but maybe the enemies have similar behaviors).

What I did was to look at a couple of youtube longplay videos and also played the original game in Mame, until I have an idea of the algorithms behind those behaviors.

Sure, is not that simple with the more complex behaviors, but I wanted them to be good enough, not perfect.

In fact I remember seen some videos where an enemy did something that I could not explain with my final models, but at that point it could even be a bug in the original code :D, so 99% was good enough for me.

In the end you cannot really do it perfect without looking at the original code.

 

After you have the basic behaviors in a nice list of steps and conditions you can start thinking about algorithms.
This is going to be easier if you have experience with those.
But for ""AI"" so simple as this, probably this list of steps is already your algorithm.
Then implementing this in your chosen language will depend on how much experience you have with it.
There is no shortcut for all this, you just start with simple things and move to the complex ones.. baby steps as they say (and time and patience).

 

As an example, one of the behaviors for the first enemy is that it tries to rotate toward the player's "perpendicular" direction, every time that it gets to an intersection in the maze.

 

Then if the enemy is moving up, and gets to an intersection or a front collision, the final code look more like this:

 

    .proc BehaviorUpFollowTarget

 

    // if there is a CounterClockwise exit and (playerX < enemyX) rotate CCW
    // if there is a Clockwise exit and (playerX >= enemyX) rotate CW
    // if there is no front collision continue front
    // else turn CW, CCW or back..

 

And there is equivalent code for when the enemy is moving right, left or down.

 

  • Like 2
Link to comment
Share on other sites

I like to think of ai as living agents where each one first has to know "where it is", then motivation, something where it needs to go, and in the and different ways how to move... Most of the time decision about next action is easy, unless it's complex game like RTS or similar. Many times it's enough to decide if it needs to move up/down/left/right and just do that once, repeat...

 

Pacman that was mentioned for example had those kinds of "period of random wandering..." replaced after some time "chase the player". It's just a flag at start of certain ghost routine. After you pass that decision it's all about doing h/v movement as needed.


You'll need counters, timers, path finding, sometimes even acceleration, speed, position, gravity etc... Then comes collision detection, bounding boxes etc... Fun times ahead :)

 

  • Like 2
Link to comment
Share on other sites

  • 1 year later...

If you have predefined levels or even a maze that doesn't change at all like in PacMan, you can pre-compute an all points shortest paths graph and maybe even store it in a reasonable amount of space,

 

https://www.geeksforgeeks.org/floyd-warshall-algorithm-dp-16/

 

If you're trying to compute it on the fly with a randomly generated playfield, well, good luck with that in 8-bit lol

 

FBEscape2.thumb.png.d0bf5cd2d18167c16cd982aabbd0bd39.png

 

You can try getting around the horrible time complexity with Dijkstra or A*, but the auxiliary memory requirements kill you

 

FBEscape.bas

  • Like 1
Link to comment
Share on other sites

FBEscape is still very much a work in progress. I just got the time to calculate the all points shortest paths down to only about three days, a vast improvement from over a week 😄 

Screenshot_20240825-125229.thumb.png.d7e72a9351f544febd10225cd0eec665.png

Maybe I should give Dijkstra or A* a try after all

Edited by yetanothertroll
Include a screenshot
  • Haha 1
Link to comment
Share on other sites

To quote Bewesoft, commenting on his early development of the Multi Dash game for FLOP magazine issue 44

"Why are the little green men so terribly stupid despite 2kB of code??!!?!?"

 

 

Edited by baktra
Link to comment
Share on other sites

On 8/25/2024 at 11:47 PM, baktra said:

To quote Bewesoft, commenting on his early development of the Multi Dash game for FLOP magazine issue 44

"Why are the little green men so terribly stupid despite 2kB of code??!!?!?"

 

 

Mine needed 6KB of code, or at least a 6KB .XEX, 13^4 bytes of RAM for the paths, and up to 3-4 days per level to compute the all points shortest paths, but a valid if not optimal path to get to the player might be computed much sooner, maybe even in as little as 14 1/2 hours 😄 though 153*256*256 jiffies seems to be more typical,

 

This is kind of sort of playable as a game, if you hold down the joystick trigger to enable the robots to compute moves the stupid way if a real path hasn't been found yet. The code is a complete mess written in Fast Basic

 

FBEscape4.thumb.png.da16550fa594bb68beff980433f33ec3.png

FBEscape.xex FBEscape.rom FBEscape.bas

Link to comment
Share on other sites

On 8/25/2024 at 9:49 PM, yetanothertroll said:

Maybe I should give Dijkstra or A* a try after all

Yes you should :)

I've done it in 90s on c64, still have single buggy version of source code I've managed to rescue from an old tape... It was written in profi assembler on c128, looks horrible but I remember it working nicely :)
It worked on char screen 40x25 and the main idea was not to calculate a* the entire way each frame. Just do it step by step for each agent, repeat as much cpu time there is. Agents moved kinda slowly but it turned out to be just the right speed for the game (kind of simple rts dune clone). While the player moved cursor with joystick from one part of the screen to the other, the couple agents (trucks and tanks) moved 2-3 chars (positions) so it all felt really good for a slow strategic game where most stuff happened slowly.

Here's an example video where I move the cursor down, click on a unit, move cursor on other position and click fire and it moves :)

I know, I know, it's not Dune or C&C but I was really proud of this back in '92 :)

 

  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...