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.