Difference between revisions of "Prog Section 1"
From Immwiki
m (fixing formatting --Telelion) |
|||
(One intermediate revision by one other user not shown) | |||
Line 1: | Line 1: | ||
− | + | =Prog Structure and Practice= | |
− | + | ||
− | Firstly, there are three classes of entities in the game which can have progs: Mobiles, | + | <i>"It's just a puzzle box."</i> |
− | + | -- Kirstie, Hellraiser | |
− | + | ||
− | + | : Firstly, there are three classes of entities in the game which can have progs: Mobiles, | |
− | + | : Objects, and Rooms. Broadly speaking, the syntax used on each of these prog types is the | |
− | + | : same. Respectively, these are referred to as mobprogs, objprogs, or room progs. Over time, | |
− | + | : the prog system has been rationalized so that the syntax for mpcommands and if checks is | |
+ | : the same across the type of entity. "Mobprog" is therefore often used to refer to the general | ||
+ | : class of all prog types, and this is the usage which will be employed in this document. Every | ||
+ | : prog has the following structure: | ||
[prog_trigger] [modifier] [argument] | [prog_trigger] [modifier] [argument] | ||
Line 17: | Line 19: | ||
} | } | ||
− | + | : It isn’t immediately obvious by what we mean by all these terms, so let’s try to clarify them: | |
− | + | <b>prog_trigger</b> | |
− | + | : The prog_trigger reflects a central fact about progs: All progs are, in fact, a set of actions | |
− | + | : which occur in response to a triggering event. What a trigger really says is, "Execute the | |
− | + | : commands that are in my body when conditions matching my trigger are met". | |
− | + | : To take a concrete example, consider the following prog_trigger: | |
− | + | : Greet_prog: | |
− | + | : Syntax: greet_prog <Percentage value from 1-100> | |
− | + | : A greet_prog triggers whenever a pc enters the room with the object/room/mob. The chance that | |
− | + | : the greet prog triggers is equal to the percentage value given as an argument. | |
− | + | : Ex: | |
− | + | : greet_prog 50 | |
− | + | : say Hello there! | |
− | + | : So, this mob has a 50% chance any time a pc enters the room of triggering the prog, at which | |
− | + | : point the pc will see the mob saying "Hello there!" | |
− | + | : Another example of a prog trigger which does not have a percentage argument is the speech_prog. | |
− | + | : Syntax: speech_prog [p] [argument] | |
− | + | : Speech_prog triggers if [argument] is said aloud in the same room as mobile or object. The "p" | |
− | + | : determines whether or not the match must be exact or simply a substring match. If no argument is | |
− | + | : specified, the speech_prog will trigger on any speech at all. | |
− | + | : Ex: | |
− | + | : speech_prog p Hello | |
− | + | : say Hi there! | |
− | + | : Now, a mobile with this program would respond whenever someone said "hello" to the mob. | |
− | + | <b>The Prog Body:</b> | |
− | + | : The body of the prog is where the ‘meat’ of the prog resides. Broadly speaking, you will find | |
− | + | : two types of things within the body: | |
− | + | : Commands | |
− | + | : Control Structures | |
− | + | ==(i) Commands== | |
− | + | : Commands are actions that the mob can perform. As a general rule, mobiles can perform any | |
− | + | : action a player can that does not involve the use of a skill or spell. [They can do these | |
− | + | : as well, but it requires a special other thing to be done first.] | |
− | + | : In addition to these normal commands, there are a suite of prog-specific commands. These | |
− | + | : commands are designed to allow progs to duplicate imm commands, player skills or spells, or to | |
− | + | : just generally do interesting things. To take a concrete example, consider the following prog | |
− | + | : specific command: | |
− | + | : mpgoto: | |
− | + | : Syntax: mpgoto <vnum> | |
− | + | : When executed from within a mob prog, mpgoto causes the mobile in question to goto the room | |
− | + | : with vnum specified. Taking the examples we’ve seen, we can construct a very simple prog: | |
− | + | : greet_prog 100 | |
− | + | : say Oh no, people! | |
− | + | : mpgoto 5000 | |
− | + | : In the above prog, "greet_prog" is the prog trigger, and the say and the mpgoto are examples | |
− | + | : of commands. This prog basically says, "Whenever someone enters the same room as this mob, | |
− | + | : have it say "Oh no, people!", then have the mob goto room 5000". | |
− | + | : This is a very basic prog, but might be used on a mischievous imp or forest spirit. [And a | |
− | + | : cunning player would go to room 5000, and ambush the imp there!] There are many, many different | |
− | + | : mpcommands, so we’ll detail those in their own chapter. | |
− | + | ==(ii) Control Structures== | |
− | + | : Normally, commands in the body of a prog are executed in linear order. I.e., if we have a prog: | |
− | + | : prog_trigger | |
− | + | : command 1 | |
− | + | : command 2 | |
− | + | : command 3 | |
− | + | : When the prog triggers, it will execute command 1, then command 2, then command 3, and so on, line | |
− | + | : by line, from top to bottom. | |
− | + | : Control structures allow us to control the natural order of prog execution. Structures exist to | |
− | + | : allow for logical branching, multiple conditionals, looping, subroutines, and numerous other | |
− | + | : functions. To take a concrete example, consider the "loop" statement: | |
− | + | : Loop: | |
− | + | : Syntax: loop <lower number> to <higher number> | |
− | + | : [Body of loop] | |
− | + | : endloop | |
− | + | : The loop structure, like its name implies, will loop through the body of the loop, executing the | |
− | + | : lines within for every iteration of the loop. So, consider the following prog: | |
− | + | : greet_prog 100 | |
− | + | : loop 1 to 3 | |
− | + | : say Hey Hey! | |
− | + | : endloop | |
− | + | : This prog will trigger when someone enters the room. It will then hit the loop, so it will | |
− | + | : execute its contents three times. So, if I enter a room with a mob who had this prog, I will | |
− | + | : see: | |
− | + | : Mob says, ‘Hey Hey!’ [this is when the loop is on 1] | |
− | + | : Mob says, ‘Hey Hey!’ [this is when the loop is on 2] | |
− | + | : Mob says, ‘Hey Hey!’ [this is when the loop is on 3] | |
− | + | : Later, we’ll give control structures their own chapter. But for right now, the important thing | |
− | + | : is to realize is that the default behavior for a prog is to execute its commands in order, and | |
− | + | : control structures exist to change the order in which commands are executed. | |
− | + | [[category:Leviticus]] | |
− | [[ | + |
Latest revision as of 00:22, 9 May 2011
Prog Structure and Practice
"It's just a puzzle box." -- Kirstie, Hellraiser
- Firstly, there are three classes of entities in the game which can have progs: Mobiles,
- Objects, and Rooms. Broadly speaking, the syntax used on each of these prog types is the
- same. Respectively, these are referred to as mobprogs, objprogs, or room progs. Over time,
- the prog system has been rationalized so that the syntax for mpcommands and if checks is
- the same across the type of entity. "Mobprog" is therefore often used to refer to the general
- class of all prog types, and this is the usage which will be employed in this document. Every
- prog has the following structure:
[prog_trigger] [modifier] [argument] Body of Prog: { (Control structures) (Commands) }
- It isn’t immediately obvious by what we mean by all these terms, so let’s try to clarify them:
prog_trigger
- The prog_trigger reflects a central fact about progs: All progs are, in fact, a set of actions
- which occur in response to a triggering event. What a trigger really says is, "Execute the
- commands that are in my body when conditions matching my trigger are met".
- To take a concrete example, consider the following prog_trigger:
- Greet_prog:
- Syntax: greet_prog <Percentage value from 1-100>
- A greet_prog triggers whenever a pc enters the room with the object/room/mob. The chance that
- the greet prog triggers is equal to the percentage value given as an argument.
- Ex:
- greet_prog 50
- say Hello there!
- So, this mob has a 50% chance any time a pc enters the room of triggering the prog, at which
- point the pc will see the mob saying "Hello there!"
- Another example of a prog trigger which does not have a percentage argument is the speech_prog.
- Syntax: speech_prog [p] [argument]
- Speech_prog triggers if [argument] is said aloud in the same room as mobile or object. The "p"
- determines whether or not the match must be exact or simply a substring match. If no argument is
- specified, the speech_prog will trigger on any speech at all.
- Ex:
- speech_prog p Hello
- say Hi there!
- Now, a mobile with this program would respond whenever someone said "hello" to the mob.
The Prog Body:
- The body of the prog is where the ‘meat’ of the prog resides. Broadly speaking, you will find
- two types of things within the body:
- Commands
- Control Structures
(i) Commands
- Commands are actions that the mob can perform. As a general rule, mobiles can perform any
- action a player can that does not involve the use of a skill or spell. [They can do these
- as well, but it requires a special other thing to be done first.]
- In addition to these normal commands, there are a suite of prog-specific commands. These
- commands are designed to allow progs to duplicate imm commands, player skills or spells, or to
- just generally do interesting things. To take a concrete example, consider the following prog
- specific command:
- mpgoto:
- Syntax: mpgoto <vnum>
- When executed from within a mob prog, mpgoto causes the mobile in question to goto the room
- with vnum specified. Taking the examples we’ve seen, we can construct a very simple prog:
- greet_prog 100
- say Oh no, people!
- mpgoto 5000
- In the above prog, "greet_prog" is the prog trigger, and the say and the mpgoto are examples
- of commands. This prog basically says, "Whenever someone enters the same room as this mob,
- have it say "Oh no, people!", then have the mob goto room 5000".
- This is a very basic prog, but might be used on a mischievous imp or forest spirit. [And a
- cunning player would go to room 5000, and ambush the imp there!] There are many, many different
- mpcommands, so we’ll detail those in their own chapter.
(ii) Control Structures
- Normally, commands in the body of a prog are executed in linear order. I.e., if we have a prog:
- prog_trigger
- command 1
- command 2
- command 3
- When the prog triggers, it will execute command 1, then command 2, then command 3, and so on, line
- by line, from top to bottom.
- Control structures allow us to control the natural order of prog execution. Structures exist to
- allow for logical branching, multiple conditionals, looping, subroutines, and numerous other
- functions. To take a concrete example, consider the "loop" statement:
- Loop:
- Syntax: loop <lower number> to <higher number>
- [Body of loop]
- endloop
- The loop structure, like its name implies, will loop through the body of the loop, executing the
- lines within for every iteration of the loop. So, consider the following prog:
- greet_prog 100
- loop 1 to 3
- say Hey Hey!
- endloop
- This prog will trigger when someone enters the room. It will then hit the loop, so it will
- execute its contents three times. So, if I enter a room with a mob who had this prog, I will
- see:
- Mob says, ‘Hey Hey!’ [this is when the loop is on 1]
- Mob says, ‘Hey Hey!’ [this is when the loop is on 2]
- Mob says, ‘Hey Hey!’ [this is when the loop is on 3]
- Later, we’ll give control structures their own chapter. But for right now, the important thing
- is to realize is that the default behavior for a prog is to execute its commands in order, and
- control structures exist to change the order in which commands are executed.