Difference between revisions of "Prog Section 1"

From Immwiki
Jump to: navigation, search
 
m (fixing formatting --Telelion)
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
= Prog Structure and Practice =
+
=Prog Structure and Practice=
<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,
+
  <i>"It's just a puzzle box."</i>
Objects, and Rooms. Broadly speaking, the syntax used on each of these prog types is the
+
  -- Kirstie, Hellraiser
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  
+
: Firstly, there are three classes of entities in the game which can have progs: Mobiles,
the same across the type of entity. "Mobprog" is therefore often used to refer to the general
+
: Objects, and Rooms. Broadly speaking, the syntax used on each of these prog types is the
class of all prog types, and this is the usage which will be employed in this document. Every
+
: same. Respectively, these are referred to as mobprogs, objprogs, or room progs. Over time,
prog has the following structure:
+
: 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:
+
: It isn’t immediately obvious by what we mean by all these terms, so let’s try to clarify them:
  
<b>prog_trigger</b>
+
<b>prog_trigger</b>
  The prog_trigger reflects a central fact about progs: All progs are, in fact, a set of actions
+
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  
+
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".  
+
commands that are in my body when conditions matching my trigger are met".  
  
  To take a concrete example, consider the following prog_trigger:
+
To take a concrete example, consider the following prog_trigger:
  
    Greet_prog:
+
:    Greet_prog:
    Syntax: greet_prog <Percentage value from 1-100>
+
:    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  
+
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.  
+
the greet prog triggers is equal to the percentage value given as an argument.  
  
    Ex:
+
:    Ex:
    greet_prog 50
+
:    greet_prog 50
    say Hello there!
+
:    say Hello there!
  
  So, this mob has a 50% chance any time a pc enters the room of triggering the prog, at which
+
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!"
+
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.
+
Another example of a prog trigger which does not have a percentage argument is the speech_prog.
  
  Syntax: speech_prog [p] [argument]
+
Syntax: speech_prog [p] [argument]
  
  Speech_prog triggers if [argument] is said aloud in the same room as mobile or object. The "p"  
+
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  
+
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.
+
specified, the speech_prog will trigger on any speech at all.
  
    Ex:  
+
:    Ex:  
    speech_prog p Hello
+
:    speech_prog p Hello
    say Hi there!
+
:    say Hi there!
  
  Now, a mobile with this program would respond whenever someone said "hello" to the mob.  
+
Now, a mobile with this program would respond whenever someone said "hello" to the mob.  
  
  
<b>The Prog Body:</b>
+
<b>The Prog Body:</b>
  The body of the prog is where the ‘meat’ of the prog resides. Broadly speaking, you will find
+
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:
+
two types of things within the body:
  
    Commands
+
:    Commands
    Control Structures
+
:    Control Structures
  
  <b>(i) Commands:</b>
+
==(i) Commands==
  
  Commands are actions that the mob can perform. As a general rule, mobiles can perform any  
+
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
+
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.]
+
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  
+
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  
+
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
+
just generally do interesting things. To take a concrete example, consider the following prog
  specific command:
+
specific command:
  
    mpgoto:
+
:    mpgoto:
    Syntax: mpgoto <vnum>
+
:    Syntax: mpgoto <vnum>
  
  When executed from within a mob prog, mpgoto causes the mobile in question to goto the room
+
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:
+
with vnum specified. Taking the examples we’ve seen, we can construct a very simple prog:
  
    greet_prog 100
+
:    greet_prog 100
    say Oh no, people!
+
:    say Oh no, people!
    mpgoto 5000
+
:    mpgoto 5000
  
  In the above prog, "greet_prog" is the prog trigger, and the say and the mpgoto are examples  
+
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,  
+
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".  
+
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  
+
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
+
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.  
+
mpcommands, so we’ll detail those in their own chapter.  
  
  <b>(ii) Control structures:</b>
+
==(ii) Control Structures==
  
  Normally, commands in the body of a prog are executed in linear order. I.e., if we have a prog:
+
Normally, commands in the body of a prog are executed in linear order. I.e., if we have a prog:
  
    prog_trigger
+
:    prog_trigger
    command 1
+
:    command 1
    command 2
+
:    command 2
    command 3
+
:    command 3
  
  When the prog triggers, it will execute command 1, then command 2, then command 3, and so on, line
+
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.  
+
by line, from top to bottom.  
  
  Control structures allow us to control the natural order of prog execution. Structures exist to  
+
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  
+
allow for logical branching, multiple conditionals, looping, subroutines, and numerous other  
  functions. To take a concrete example, consider the "loop" statement:
+
functions. To take a concrete example, consider the "loop" statement:
  
    Loop:
+
:    Loop:
    Syntax: loop <lower number> to <higher number>
+
:    Syntax: loop <lower number> to <higher number>
    [Body of loop]
+
:    [Body of loop]
    endloop
+
:    endloop
  
  The loop structure, like its name implies, will loop through the body of the loop, executing the  
+
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:
+
lines within for every iteration of the loop. So, consider the following prog:
  
    greet_prog 100
+
:    greet_prog 100
    loop 1 to 3
+
:    loop 1 to 3
    say Hey Hey!
+
:    say Hey Hey!
    endloop
+
:    endloop
  
  This prog will trigger when someone enters the room. It will then hit the loop, so it will  
+
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  
+
execute its contents three times. So, if I enter a room with a mob who had this prog, I will  
  see:
+
see:
  
    Mob says, ‘Hey Hey!’ [this is when the loop is on 1]
+
:    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 2]
    Mob says, ‘Hey Hey!’ [this is when the loop is on 3]
+
:    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
+
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  
+
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.
+
control structures exist to change the order in which commands are executed.
  
----
+
[[category:Leviticus]]
[[Prog Section 0]] | [[Prog Section 2]] | [http://http://www.ender.com/~jolinn/avendarbible/wiki.pl?Leviticus Leviticus -- Builder Resources Page]
+

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.