86
edits
Difference between revisions of "AGI/Specifications/Overview"
Jump to navigation
Jump to search
m
no edit summary
(Wikifying. Adding missing bits from SGML) |
m |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 78: | Line 78: | ||
Example LOGIC code (from the AGI version of KQ4): | Example LOGIC code (from the AGI version of KQ4): | ||
< | <syntaxhighlight lang="C++"> | ||
animate.obj (smoke); | animate.obj (smoke); | ||
ignore.horizon (smoke); | ignore.horizon (smoke); | ||
| Line 89: | Line 89: | ||
cycle.time (smoke, work); | cycle.time (smoke, work); | ||
draw (smoke); | draw (smoke); | ||
</ | </syntaxhighlight> | ||
<span id="Debug"></span> | <span id="Debug"></span> | ||
| Line 96: | Line 96: | ||
Testers often need some way to achieve certain things quickly so that they can test a certain part of the game. Most AGI games still have the debug code that these testers used when the games were being developed. Of the thirteen AGI games mentioned above, there are only three which I haven't discovered the debug mode in. Most of the games activate their debug modes by pushing the <tt>ALT-D</tt> key combination. The other games used a magic phrase to enter the debug mode. | Testers often need some way to achieve certain things quickly so that they can test a certain part of the game. Most AGI games still have the debug code that these testers used when the games were being developed. Of the thirteen AGI games mentioned above, there are only three which I haven't discovered the debug mode in. Most of the games activate their debug modes by pushing the <tt>ALT-D</tt> key combination. The other games used a magic phrase to enter the debug mode. | ||
{| border="1" | {| border="1" cellspacing="0" cellpadding="5" | ||
|- | |- | ||
! Game | ! Game | ||
| Line 200: | Line 200: | ||
the background components. Nothing is ever given a priority of four | the background components. Nothing is ever given a priority of four | ||
except for the background parts of the picture itself. Values 0 to 3 | except for the background parts of the picture itself. Values 0 to 3 | ||
(represented by | (represented by colors black, blue, green, and cyan) are infact used | ||
for ''control lines'' drawn in the priority screen. | for ''control lines'' drawn in the priority screen. | ||
| Line 219: | Line 219: | ||
In most games, black and blue appear to be used for obstacle use which means that Ego can't walk past that line. This is the main use for control lines. Other uses include triggers which active an event. For example, control lines are used at the edge of water, or the edge of a cliff to tell the interpreter at what point it should execute its "drowning" or "falling" sequence of events. We can all remember the nasty trap that the hunter beast on Labion set for us in Space Quest II. This is activated when Ego walks past a green control line. | In most games, black and blue appear to be used for obstacle use which means that Ego can't walk past that line. This is the main use for control lines. Other uses include triggers which active an event. For example, control lines are used at the edge of water, or the edge of a cliff to tell the interpreter at what point it should execute its "drowning" or "falling" sequence of events. We can all remember the nasty trap that the hunter beast on Labion set for us in Space Quest II. This is activated when Ego walks past a green control line. | ||
The cyan control line will often be a whole filled area. A VIEW object such as a crocodile can be given the object.on.water command and then told to wander. The interpreter will only allow the crocodile to wander over the area that has a control | The cyan control line will often be a whole filled area. A VIEW object such as a crocodile can be given the object.on.water command and then told to wander. The interpreter will only allow the crocodile to wander over the area that has a control color of cyan. | ||