Amiga Isometric Devlog #7

20 November 2024

After a break to make a Christmas game for Amiga Addict, do Amiga Belfast, and have a very /very/ busy November IRL, I'm back on my isometric adventure with some serious yak-shaving.

NICE OS FRIENDLY OS

The first task was to make the game more OS-compatible, as savegame functionality will be very necessary and, while it's absolutely possible to support floppy save/load with non-OS code, it gives me the ick (as I heard the kids say). I'd rather do it the AmigaOS way. The game already used AmigaOS for display initialisation, file loading and memory allocation, but took over the machine afterwards and I'm never comfortable returning to the OS from that state. I replaced the hardware banging interrupt and input code with max priority OS interrupt and input handlers that block the rest of the call chains as these can be cleanly added and removed as required when it's time to access the disk or other OS functions. Some other details were allocating the blitter and audio channels to make sure we have control of those but can hand them back too.

SCRIPTING

Next, scripting. Previously, I had some rooms in place but I wasn't happy with the way the interaction implementation. It was thrown together as I was making the rooms and was quite hardcoded in places, and I knew I would need something more flexible before proceeding much further with content. Making the next room needed a different interaction and I didn't want to hardcode anything else. In October, a chance encounter with a tool to show how Cadaver (Amiga) was put together sent me down a scripting language rabbit hole. I wasn't sure if I needed a full language, and indeed I settled on a simple custom language with only a few instructions to test and manipulate world-state flags ("wsflags") and entity variables.

Entities have a number of events that can be triggered and execute scripts to affect their state and the world state.

SpawnCondition     test if entity should spawn based on wsflag(s) state
OnSpawn                         when the entity spawns
OnTouchStart                    when player starts touching entity
OnTouchEnd                      when player stops touching entity
OnWorldStateChange              when a wsflag has changed

'wscondition' describes a logically AND-ed sequence of wsflag(s). For example, '!GATE_LOCKED,SWITCH_PRESSED' will evaluate true only if the 'GATE_LOCKED' flag is clear and the 'SWITCH_PRESSED' flag is set.

The script language, used for all events except 'SpawnCondition', is as follows:

set  []           set wsflag
set  []    set entity variable

clr ]                  clear wsflag or entity variable

ifws               conditional block based on wsflag(s) state
endif

nop                             do nothing ... i don't know why this exists

stop                            end script

=> [IMG: Scripting in Tiled] | [IMG: Scripting in Tiled] | [IMG: Compiler Core]

The scripts are entered in object properties in Tiled, and compiled to bytecode during the build process. It was too simple a language to justify using a parser generator, so I wrote a very simple compiler in 250 lines of Python. The runtime interpreter is a similar number of lines of C, with a sprinkling of assembler to make sure it executes quickly.

Having the scripting engine in place allowed me to very quickly put the following interaction sequence together.

• The player crosses the first room over the moving platforms
• The "jump ability" item in the second room is touched. Its OnTouchStart script sets the ABILITY_JUMP world-state flag.
• The "jump ability" item unspawns because its SpawnCondition is !ABILITY_JUMP
• The player returns to the first room. The small platforms don't spawn because of SpawnCondition !ABILITY_JUMP; the large platform spawns because of SpawnCondition ABILITY_JUMP.

=> [VID: Scripting in Action]

I also converted all the previous interactions to the scripting system, and reorganised the entities in Tiled to a more structured, almost entity-component, design. Not in that order, now that I mention it.

Hopefully, now all these yaks are bald, I'm in a better position to add many more rooms without worrying about having to rework them all later!

Related Links

=> Amiga Isometric Devlog #6 | Amiga Game Scripting Languages

=> Amiga Belfast | Santatron 2024

Tags

=> amiga
=> devlog
=> gamedev
=> isometric
=> retro