Game scripting
Structure of the game script engine
using the example of L7 script engine
SAM style, 2015
Back in the early 2000s, when I played
"Star Legacy"on my Scorpio, I
hopelessly stuck, opening a niche in the cave
islands. I was probably just not paying attention─
I'm lazy and missed the hint about the code, but
I had to go into the shadow debugger to
overcome this place. There I discovered for─
clear feature - at least that moderate one─
one hundred in the game was made in the form of an interpre─
tator of a certain bytecode, which contained
describes the menu and actions when selecting an item─
comrade...
Then I was interested in it, but not more─
Also, I wasn’t writing games at that time.
However, then I started using exactly that
peepedreception at "Star Heritage"
- mostly Anime Story and Nocturne
were interpreters of bytecode scripts─
Comrade Then I moved in the other direction and
began to develop other scripts where there were
animations are described. Similar ones are used in
all parts of Viking Quest and partly in
Karlos.
At the beginning of 2014 I wrote a small
tile engine supporting 7 layers
graphics - each with its own set of tiles,
with/without mask, with optional use
colors. The working title became 7LT (7
Layers of Tiles). It was originally created
for another game, but the idea quickly died out, and
the engine remains. Now it's time to volume─
edit everything that came before - scripts
game logic, animation scripts and news─
line tile engine. It's a bunch of code
received the name L7 script engine.
Game logic script interpreter
is a handler for something
a set of commands represented by 1-2 bytes with
parameters. Some teams change support─
structures generated by the engine, others give away
commands for the animation part of the engine, third
are intended for branching and transitions along
any conditions. Because the engine was filling up
to play a quest/jRPG, then a set
his commands and structures are appropriate.
Structures are grouped into tables, the engine
the addresses of these tables are transmitted.
The engine currently supports
the following structures:
- NPC (non-player characters).These elements─
cops have sprites, animations, you can use them
talk, give them something.
- Active elements.These are essentially the same
NPCs, but they can be influenced if
they allow it.
- Items.Can be located either on the
mouth, or in the hero’s bag.
- Doors.Activated when the hero kills─
he is afraid to step on them, and they carry him to
another place on the map.
- Zones.Activated when the hero is on them
is coming. Unlike doors, action
could be anything.
- Magic.Used in battles, consumes
MP. Action for use - any.
- Potions.Have quantity and duration
actions. The action itself is any. Essentially
potions is a list of effects imposed on the hero─
effects during the battle.
- Equipment.Currently - 4 slots
(armor, shield, sword, amulet), up to 8 names─
tion in everyone. Armor and shield absorb damage,
the sword inflicts it, the amulet gives the task─
washed effect.
- Crafting table. From 2 items you can
create a third one.
- Table "talk" - with whom + address
script.
- Table "give" - what, to whom + address
script.
- Table "use" - what + address
script.
Many teams interact with these
structures. For example, they set NPC animation,
wait for it to end, move them to another─
certain places, turn zones and doors on and off,
add or remove magic, potions, equipment─
zhenie... There are commands that operate on hardwired
into the engine with 256 bits and 256 variables -
this goes back to Anime Story, only there
these arrays were smaller.
The command block is responsible for branching -
the condition and address where the script goes is determined
jumps if the condition is met.
But first things first:
First of all, I’ll note that I don’t want to particularly
get involved with the Wanderers engine - I’ll tell you in
in general terms so that the idea is clear. But when─
measures will come from there.
-working with flags and variables.
Commands such as install─
turn/reset/invert bits and set
binary operations on bits - OR,AND,XOR.
In addition, operations on variables take─
flashing values 0..255 - set changes─
new, increment, decrement, addition and you─
reading withnumber or other variable.
All this is necessary to take into account events and conditions in
transition commands.
-branching and transitions.
This group contains teams based on:
anyone condition branching fulfillment
script. The parameters specify the condition itself
and the address to which the transition will be made.
Conditions can be very different. Standa─
dial - if the bit is set/reset,
if the variable is greater/less/equal to a number
or another variable if a random number
more/less than some value. Except
this, you can come up with more specific
conditions - if the character has a certain─
item/magic/potion/equipment.
-control of music and sound effects─
tami.
There are few commands here - on/off play─
playing music, starting a track, playing sound─
ka.
-service commands.
Here are the auxiliary commands, which─
some do not directly affect structures
data. Such as - pause at a given task─
new number of interruptions; scan key─
aura and execute the one assigned to the key
script when it is pressed; make a call
script or call code.
-structure management.
This group includes teams that interact─
dealing with data structures -activated─
activate/deactivate zones/doors, add/
remove a hero's item/potion/magic/equipment─
tion. Plus control of visible elements -
set the NPC/element animation/sprite, re─
place it somewhere...Animation and so on─
An animator is engaged in moving them on the screen
in the engine, this all happens in parallel with
execution of the game script.
-dialog windows and menus.
Essentially there is only one command - start working
with menu. Set the position and size of the window
menu, list of items and assigned to it
addresses to which the transition will be made to
case of selecting an item. Any printable character
causes the engine to open a dialog box,
if it is not already open, and start withdrawing
line.
-table actions.
These are table scanners that indicate 1-2
id and transition address. For example, action
"speak" has one parameter - person id─
pressure that stands in front of the hero. If at
while scanning the table this id was encountered,
the script assigned to it is called.
From these elementary actions you can co─
take a simple quest. I’ll give you a bite as an example─
ki from the Wanderers script. All these strangers─
myt* are macros that create a mixture of db and
dw - the bytecode itself for interpretation.
tSetMap 255 ;draw screen,
;on which the hero is located
;(255 - special number)
gsLoop tHalt ;HALT. The animator is called
;screen is updated
tKeyScan mKeyTab; scan
;keyboard
tJump gsLoop ;return to
;label gsLoop
mKeyTab dw 0x01fd,gsDown ; A
dw 0x01fb,gsUp ; Q
dw 0x017f,gsMenu ; Space - menu
dw OxOChdf,gsEquip; I - equipment
...
db 0
gsDown tNpcAni 0,cOOdn ;set NPC 0
;(hero) animation described
;at cOOdn (this is a step down)
gsdOO tWaitNPC 0 ;wait until
;NPC 0 animation will end
tZoneScan gsdOO;scan
;zone table;
;if the zone is activated,
;execute zone script,
;then return to the gsdOO address
tEnd ;end. This part was
;called as a subroutine,
;so it acts like
;RET to the calling script
gsUp tNpcAni 0,cOOup ;set NPC 0
;(hero) animation described
;at cOOup (this is a step up)
tJump gsdOO;jump to gsdOO label
gsEquip tSelectEquip ;this is "volumetric"
;the team in charge
;the engine itself -
;working with the equipment menu
tEnd ;RET
gsMenu tMenu 255,255,0,0,dMainMenu ;this
;Displays the action menu.;On dMainMenu lies
;description of menu items -
;what to show, what they are called,
;what scripts
;call when selected
tEnd ;RET after execution
;script of one of the items
Now let's turn our attention to the animator.
Thanks to this part, we no longer have a screen─
chen. The animator scans the tables every INT
NPCs and active elements. If they meet
those with active animation, animator
undertakes the execution of a script describing
sprite behavior. These scripts are very similar
with those described above, but have their own specifics,
because sharpened only for gra manipulation─
fika. Of the general teams - ne─
move the sprite to the specified location, mix─
Tilt the sprite relative to the current position
and, perhaps, that’s all :) There are specific comas─
nds and even branches - check the current ones
sprite coordinates, check the possibility
take a step in a certain direction
(it’s better not to walk through walls), etc. Herself
the sequence of frames is specified by the structure─
tours of the form,
Having met one, the animator updates the sprite
element and pauses for it forvalue> INTs.
Here's an example of the animation. In Wanderers it's
pilgrim at the great tree, stroke it sometimes─
showing off his beard. Also,a* is a poppy─
dew:
ani13 DBW 30,npc13a ;30 INT's, sprite
;npc13a
aIfRndLess 200,ani13 ;if
;RND(255)<200, go to ani13.
;This determines "sometimes".
DBW 20,npc13b;20 INT, npc13b sprite
DBW 20,npc13c;20 INT, npc13c sprite
;These 2 sprites just put my hand in my beard
aJump ani13 ;go to address ani13
;(animation looped)
macro"DBW p1,p2" is "DB p1; DW p2". I
I often use it in a variety of places.
So, to create at least some kind of screen─
it is important to determine the type of engine for yourself
a few things:
- withwhat structures will have to work─
t;
- how these structures can be changed;
- what basic actions do you need?
perform;
When all this will be painted on the second hand─
mage, you will get some kind of meta-language for the game.
If you use it correctly, you can create─
give a real masterpiece.
(Attached is a complete list of commands and
defines.)
Share your thoughts about the article