log in | register | forums
Show:
Go:
Forums
Username:

Password:

User accounts
Register new account
Forgot password
Forum stats
List of members
Search the forums

Advanced search
Recent discussions
- WROCC March 2024 meeting o... Hughes and Peter Richmond (News:1)
- Rougol March 2024 meeting on monday with Bernard Boase (News:)
- Drag'n'Drop 13i2 edition reviewed (News:)
- South-West Show 2024 talks (News:4)
- February 2024 News Summary (News:1)
- Next developer fireside chat (News:)
- DDE31d released (News:)
- South-West Show 2024 Report (News:)
- South-West Show 2024 in pictures (News:)
- Big NVMe news for the RISC OS at the South-West Show (News:)
Related articles
- Bob and Trev: Resurrection: Just in time
- Combat
- Visibility and pathfinding
- The level generator
- Static game data
- How to fit a roguelike in 32k
- Bob and Trev: Resurrection
- Wakefield 2003 - the preview
- Newsround
- Arculator updated to add A4 emulation and more podule support
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
 
View on Mastodon
@www.iconbar.com@rss-parrot.net
Site Search
 
Article archives
The Icon Bar: News and features: Monster AI
 

Monster AI

Posted by Jeffrey Lee on 00:00, 16/3/2007 | , , , , , , , ,
 
Previously, on Bob and Trev: Resurrection...
Next time I'll be talking about monster AI. I'm not going to be creating an Einstein, but I will be able to talk about a few of the basic features I'm hoping to implement.
But before I talk about monster AI, I might as well take the time out to talk about the time system that the game will use. Also, I don't have much other material for this article.
 

Time

Just like with the combat system, I haven't really looked at roguelike time systems before. Obviously I know what the outcome is - some monsters move more often than the player, and others move less - but I don't know the exact mechanic or formulae behind it.
 
For Bob and Trev: Resurrection, the choice of time keeping system was fairly simple. The game would have a global 'turn counter', and the speed attribute of the monsters and player would determine how often they move. A proper roguelike time system would likely give each monster an internal timer, which counts down how many ticks are left until the monster can next move; this would allow certain actions to take more time to complete (or recover from) than others. But with memory an issue, I decided to go for an approach that only relies on the global clock:
 
IF (time MOD speed)=0 THEN move
 
Simple in design, and on the surface quite effective. However it won't correctly handle cases where the speed of a monster changes (i.e. a monster which slows down may get its next turn a lot sooner than it should), and depending on the scale of the time and speed values, a small change in speed may have a dramatic effect on how fast a monster moves (i.e. changing speed from 2 to 1 will cause a monster to move twice as fast).

Goal-based AI

Goal-based AI is a simple and effective method to make nasties in computer games more interesting. Each AI has a set of goals it can choose between (such as attacking the player or running away). The AI will stick with its current goal until such a time that it completes it, or deems another goal to have a higher priority. For Bob and Trev: Resurrection, I'm aiming to include four basic goals:

  • Attack the player
  • Run away from the player
  • Collect items
  • Wander aimlessly
For most monsters, the initial state will be "wandering aimlessly." But on seeing or being attacked by the player, the monster will switch to one of the other states - most probably the attack state. While in the attack state it will seek to get closer to the player, either (a) until it's within weapons range, or (b) until it's in an optimal fighting position. (b) is more complex, as it would include calculations such as trying to find a space where the monster can attack the player but the player cannot attack the monster.
 
If the player succeeds in damaging the monster to a certain threshold, or the player is significantly more powerful than the monster, the monster may opt to run away. There are many possibilities for a "run away" algorithm, but not all of them are simple enough to be suitable for BASIC running on a 32k BBC.
 
Similarly, there are many possibilities for a "collect items" goal. A monster could examine its surroundings and seek out the item it will find most helpful - such as weapons or armour. In reality I may not have the time to implement this fully, so a simple "move to nearest item and collect it" approach may be taken.

Game over, man

The competition is nearly at an end, which can only mean one thing - tomorrow's article will be the conclusion, and will (hopefully!) feature a copy of the game to download.
 

Log in to comment on this article

The Icon Bar: News and features: Monster AI