Modding:Tutorial/Designing AI - Revision history

Epyon at 12:29, 11 August 2025

2025-08-11T12:29:48Z

Game Hunter: added more to Single-minded AI

2011-11-22T15:36:26Z

added more to Single-minded AI

Game Hunter: /* Rule 1 */ derp wrong word

2011-11-22T14:46:42Z

‎Rule 1: derp wrong word

Game Hunter: incomplete tag given

2011-11-07T15:19:19Z

incomplete tag given

Game Hunter: /* Single-minded AI */ quick fix

2011-10-17T15:08:31Z

‎Single-minded AI: quick fix

Game Hunter: small fixes, added some of "Single-minded AI"

2011-10-17T15:05:31Z

small fixes, added some of "Single-minded AI"

Show changes

Game Hunter: /* being:fire() */ forgot a parameter

2011-10-17T13:29:24Z

‎being:fire(): forgot a parameter

Game Hunter: blargh syntax

2011-10-16T03:11:27Z

blargh syntax

Game Hunter: /* being:path_find() */ small inaccuracy

2011-10-14T18:24:10Z

‎being:path_find(): small inaccuracy

Game Hunter: /* Default Actions */ quick syntax fixes

2011-10-14T18:16:13Z

‎Default Actions: quick syntax fixes

@@ Line 1: / Line 1: @@
 {{incomplete}}
-Before the more recent versions of DoomRL, all beings other than the player used a single algorithm for AI, or artificial intelligence, that directed how the being should act under certain circumstances. Although this default AI is modifiable to some extent through a few being flags, the extent to which beings acted remained roughly the same. When it became clear that this default AI could be outwitted with clever tactics, the AI object was added into the game (sometimes known as "lua AI"), allowing for complete customizability as to what a being does given any circumstances. Most beings, as of v0.9.9.4, call a particular AI object that governs their actions, and are thus more difficult to fight when playing the game (which is a good thing).
+Before the more recent versions of DRL, all beings other than the player used a single algorithm for AI, or artificial intelligence, that directed how the being should act under certain circumstances. Although this default AI is modifiable to some extent through a few being flags, the extent to which beings acted remained roughly the same. When it became clear that this default AI could be outwitted with clever tactics, the AI object was added into the game (sometimes known as "lua AI"), allowing for complete customizability as to what a being does given any circumstances. Most beings, as of v0.9.9.4, call a particular AI object that governs their actions, and are thus more difficult to fight when playing the game (which is a good thing).
 This tutorial goes through the basics of creating AI objects and what you can do with them. The AI object class is very flexible in that the basic structure is extremely simple, allowing you to add almost anything that the game allows from within its API. Unsurprisingly, designing your own artificial intelligence can be an extremely challenging task, depending on what exactly you want the AI to be capable of. Basic structuring techniques will be explained, as well as general guidelines when writing the code that your AI will consist of.
@@ Line 165: / Line 165: @@
 ==Default Actions==
-There are a number of being methods that will automatically cause the being to lower its energy. Many of them are critical in developing an AI for DoomRL, and you would do well to memorize them:
+There are a number of being methods that will automatically cause the being to lower its energy. Many of them are critical in developing an AI for DRL, and you would do well to memorize them:
 ===being:direct_seek()===

@@ Line 192: / Line 192: @@
 end
-if break occured, end turn
+if break occurred, end turn
 *sign(x) is +1 for positive x and -1 for negative x
@@ Line 346: / Line 346: @@
 This new state is functionally identical to the four-state case but is easily half its size in terms of lines of code. Finding ways to cut down on the magnitude of a script can greatly improve the ability to debug it, as well as allowing others to read and understand it. Since states can become very complicated, it is important to organize them as cleanly as possible.

@@ Line 59: / Line 59: @@
 *The third, setting ''scount'' to 4000, is functionally identical to the first, except that it can be used immediately after default actions in order to make ''scount'' decrease by a very specific value. Suppose you wanted a being to be able to equip things immediately: using this method you can reset the scount value (to 5001) in order for the process to have taken no virtually no time at all. (Technically you could compare ''scount'' before and after actions taken, but this is a much simpler method.) Thus, a being with an action modified by this method will act "independent" with respect to its default action speed.
-You will almost always use the "typical" modifier, but don't forget about the other two. (In particular, "global" and "independant" modifiers become important when you have several beings using the same AI and want to coordinate their actions very precisely.)
+You will almost always use the "constant" modifier, but don't forget about the other two. (In particular, "global" and "independant" modifiers become important when you have several beings using the same AI and want to coordinate their actions very precisely.)
 ===Rule 2===

← Older revision		Revision as of 15:19, 7 November 2011
Line 1:		Line 1:
		+	{{incomplete}}
	Before the more recent versions of DoomRL, all beings other than the player used a single algorithm for AI, or artificial intelligence, that directed how the being should act under certain circumstances. Although this default AI is modifiable to some extent through a few being flags, the extent to which beings acted remained roughly the same. When it became clear that this default AI could be outwitted with clever tactics, the AI object was added into the game (sometimes known as "lua AI"), allowing for complete customizability as to what a being does given any circumstances. Most beings, as of v0.9.9.4, call a particular AI object that governs their actions, and are thus more difficult to fight when playing the game (which is a good thing).		Before the more recent versions of DoomRL, all beings other than the player used a single algorithm for AI, or artificial intelligence, that directed how the being should act under certain circumstances. Although this default AI is modifiable to some extent through a few being flags, the extent to which beings acted remained roughly the same. When it became clear that this default AI could be outwitted with clever tactics, the AI object was added into the game (sometimes known as "lua AI"), allowing for complete customizability as to what a being does given any circumstances. Most beings, as of v0.9.9.4, call a particular AI object that governs their actions, and are thus more difficult to fight when playing the game (which is a good thing).

@@ Line 261: / Line 261: @@
 A single-minded AI never needs to make an intelligent decision between two choices. Simply put, it follows only action-based algorithms: if there are changes that do not stem from actions, they are automatic or constant. Such AI are the easiest to create and implement, as their movements are always obvious when observed. There are two ways to implement a single-minded AI: create only single state that performs the actions, or divide each type of action into its own state and cycle through them. Most of the time a single state is all that is necessary, though there can be cases in which having separate states is a more logical procedure.
-We will now return to our example AI from before, which involved commanded a being with the AI either walk up or stop whenever walking would cause it to hit a solid object. It is a sufficient AI but is certainly lacking in mobility: after all, the game will eventually run out of coordinates if it can only move in a single direction. Let us expand on the design by allowing it to move in any orthogonal direction (up, down, left, or right), depending on what direction it is currently walking and what is in the way.
+We will now return to our example AI from before, which involved either walking up or stopping whenever walking would cause it to hit a solid object. It is a sufficient AI but is certainly lacking in mobility: after all, the game will eventually run out of coordinates if it can only move in a single direction. Let us expand on the design by allowing it to move in any orthogonal direction (up, down, left, or right), depending on what direction it is currently walking and what is in the way.
 We should begin by setting up the AI such that it can walk in all of the directions specified. Since each direction can be considered a separate action, you may be tempted to create a state for each one, like so:

@@ Line 220: / Line 220: @@
 ===being:fire()===
-'''being:fire'''(''coord'') commands ''being'' fire its ranged weapon, aiming at ''coord''. If the weapon cannot be fired (e.g., out of ammo), then the being's energy does not decrease.
+'''being:fire'''(''coord'',''weapon'') commands ''being'' fire its ''weapon'', aiming at ''coord''. If ''weapon'' cannot be fired (e.g., out of ammo), then the being's energy does not decrease.
-As there is no return value to determine whether or not the being's attack was successful, you may want to set up exceptions in the event that the weapon cannot fire.
+As there is no return value to determine whether or not the being's attack was successful, you may want to set up exceptions in the event that ''weapon'' cannot fire.
 ===being:reload()===

@@ Line 108: / Line 108: @@
 *'''Infinite''' states have obvious flaws that will cause a being to return an infinite loop error. AI objects with infinite states should always be fixed. However, infinite states can be used as a debugging tool: since infinite loops can easily be traced to a particular condition, they are a useful way to find a problem with the AI.
 *'''Finite''' states will always either change to another state or cause the being's turn to end, regardless of the being's circumstances. Ideally, all states should be finite.
-*'''Indefinite'' states, while not explicitly finite, will only cause infinite loop errors in unlikely circumstances. Sometimes it is feasible to fix these "indefinite conditions", sometimes not: these can be used in modules but care should be taken to avoid circumstances in which the error may manifest. (The simplest way to prevent an infinite loop is to simply set a limit on how much a loop can repeat itself, either with a loop counter or a finite iterator.) The most common indefinite states involve properties that are not explicitly defined in the AI, but belong to beings that use the AI.
+*'''Indefinite''' states, while not explicitly finite, will only cause infinite loop errors in unlikely circumstances. Sometimes it is feasible to fix these "indefinite conditions", sometimes not: these can be used in modules but care should be taken to avoid circumstances in which the error may manifest. (The simplest way to prevent an infinite loop is to simply set a limit on how much a loop can repeat itself, either with a loop counter or a finite iterator.) The most common indefinite states involve properties that are not explicitly defined in the AI, but belong to beings that use the AI.
 States that satisfy rule 3 are considered finite, and when every state of an AI object is finite, the object itself is considered finite as well.

@@ Line 203: / Line 203: @@
 The return for this method determines whether or not a path was successfully found. Even if a complete path was not created, there will still be a path that '''being:path_find()''' established for ''being'', and can be used as a way to begin its approach to ''coord''.
-'''being:path_find()''' does not actually move the being: use '''being:path_next()''' in order to initiate the movement attempt.
+'''being:path_find()''' does not actually move the being, nor does it decrease energy: use '''being:path_next()''' in order to initiate the movement attempt.
 Generally speaking, it is not good practice to recalculate a pathing algorithm on every action, tempting as that may be. Naturally, the shuffling of enemies and opening/closing doors can affect whether or not the path is a correct one, but it is better to consider these exceptions as the time to call '''being:path_find()''', rather than doing so all the time.

@@ Line 159: / Line 159: @@
 ===being:direct_seek()===
-'''being:direct_seek'''(''coord'')) causes ''being'' to take a step toward ''coord'' following the most direct path possible. The direct pathing used here is the same as the game's default AI, and its algorithm can be roughly described by the following:
+'''being:direct_seek'''(''coord'')) commands ''being'' to take a step toward ''coord'' following the most direct path possible. The direct pathing used here is the same as the game's default AI, and its algorithm can be roughly described by the following:
 <source lang="text">
@@ Line 196: / Line 196: @@
 **'''3''' indicates that the being was stopped by another being
-Specifically, when the movement process is interrupted '''being:direct_seek()''' searches for CF_BLOCKMOVE. If it is not found on the blocking coordinate, '''3''' is returned; if CF_BLOCKMOVE is found but CF_OPENABLE is also found (which is used for doors), '''2''' is returned; in other cases when CF_BLOCKMOVE is found, '''1''' is returned.
+Specifically, when the movement process is interrupted, '''being:direct_seek()''' searches for CF_BLOCKMOVE. If it is not found on the blocking coordinate, '''3''' is returned; if CF_BLOCKMOVE is found but CF_OPENABLE is also found (which is used for doors), '''2''' is returned; in other cases when CF_BLOCKMOVE is found, '''1''' is returned.
 ===being:path_find()===
@@ Line 208: / Line 208: @@
 ===being:path_next()===
-'''being:path_next()''' moves ''being'' to a coordinate as specified by '''being:path_find()'''. To think of this process abstractly, consider that whenever '''being:path_next()''' is executed, an array of steps is called: the first step is then used as the coordinate into which the being moves, and is removed from the array. Thus, calling the method each time moves the being to each coordinate, until the array is entirely removed and the being has reached the supposed target position.
+'''being:path_next()''' command ''being'' to move to a coordinate as specified by '''being:path_find()'''. To think of this process abstractly, consider that whenever '''being:path_next()''' is executed, an array of steps is called: the first step is then used as the coordinate into which the being moves, and is removed from the array. Thus, calling the method each time moves the being to each coordinate, until the array is entirely removed and the being has reached the supposed target position.
 '''being:path_next()''' carries the same return values as '''being:direct_seek()''', and exceptions can be handled in the same manner.
@@ Line 232: / Line 232: @@
 '''being:wear'''(''slot'') commands ''being'' to equip an item that exists in position ''slot'' of its inventory. (For instance, to equip the first item in the inventory, ''slot'' should be set to 1.) If the item in position ''slot'' cannot be equipped, or if the being cannot equip items, the being's energy does not decrease.
-'''being:wear'''(''item'') commands ''being' to equip ''item'' from its inventory. ''being'' will always equip ''item'' from the lowest slot in its inventory. If ''item'' does not exist in the being's inventory, or if ''being'' cannot equip items, the being's energy does not decrease.
+'''being:wear'''(''item'') commands ''being'' to equip ''item'' from its inventory. ''being'' will always equip ''item'' from the lowest slot in its inventory. If ''item'' does not exist in the being's inventory, or if ''being'' cannot equip items, the being's energy does not decrease.
 The output returns true if the being equipped an item and false otherwise.