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