Space Quest demake (Interactive fiction engine)

I’ve made an interactive fiction demake of Sierra’s graphical adventure game, Space Quest. It currently only features the first few rooms but demonstrates how the interactive fiction engine works.

IF.ino.hex (39.8 KB)

I developed a simple scripting language to make it easy to write IF games and it is designed to work in constrained memory environments like the Arduboy. Text is also compressed using a basic compression system that compresses string data to about 60-70% of their original size.

For the Space Quest demo:
Game logic: 979 bytes
String table: 4522 bytes
MicroIF engine: 8989 bytes
Total sketch size: 14490 bytes
Only used 50% of available flash so lots of space left!

Expand for an example of what the scripting language looks like
# An example script
# Everything on the line after a # is a comment
# All white space is ignored but can be used to make code easier to read

# Variables are single bit flags that can either be true or false
flag doorIsLocked is true

# Items are things that can be collected and stored in the player's inventory to use later
item key
	# The title and description attributes defines how the item is displayed in the inventory
	title "key"
	description "A shiny, copper coloured key."
	# This event is called when the item can otherwise not be used
	on use
		say "There is nowhere to use the key here."
# Rooms are places where the player can visit. The first room defined is the starting room
room kitchen
	title "The kitchen"
	# Attributes can have conditionals associated with them
	description when doorIsLocked
		"You are in the kitchen. It looks quite messy. The only door out of here is locked!"
	description when not doorIsLocked
		"You are in the kitchen. It looks quite messy. A door to the east is open."
	# Options are displayed to the player to choose from
	option "fridge"
		say "Nothing inside the fridge except a broken ketchup bottle."
	# Options can have conditionals
	option "east" when doorIsLocked
		say "The door is blocking your path."
	option "east" when not doorIsLocked
		go diningRoom
	# Conditionals can be based on item possession
	option "cupboard" when not have key
		say "Looking inside the cupboard you find a key."
		give key
	option "cupboard" when have key
		say "Nothing else in the cupboard worth taking."
	# Events for handling item usage
	on use key when doorIsLocked
		say "You unlock the door."
		unset doorIsLocked
	on use key when not doorIsLocked
		say "The door is already unlocked"

room diningRoom
	title "The dining room"
	description "A long table with chairs. The kitchen is to the west."
	# You can assign events for entering a room
	on enter
		say "You just walked into the dining room!"
	option "west"
		go kitchen

The engine has been written in a way to distinctly separate the compiler, VM and front end so can be easily ported to other platforms. The way the game data is accessed is also abstracted so it would be very easy to store it on a flash chip for example.

More details on the engine and the source code available on GitHub:

Still to do:

  • Save, restore and restart games
  • Score

Nice. This is one of my favorite adventure games :heart_eyes:

1 Like

OMG… So we need to work on ZORK now !:smiley:


Drat, someone beat me to it.

I was working on something like this a while back, though it was more of a Visual Novel engine.
I got the bytecode and main engine working but never developed it further because I got sidetracked.

I’ll leave it here in case anyone wants to resurrect it or compare notes:

1 Like

Oh my goodness gracious. You’ve done it again and done what would nearly otherwise seem impossible!

I can only imagine the amount of content one could have in a game using the external memory!

1 Like

yes, it’s a great news, i have difficulty to imagine how you could do a complete game like that on the actual Arduboy and yes it’s a case of game where external memory seems the only solution. If you succefully find a system to make it on an Arduboy without extension, you’re a Wizard. :slight_smile: Great job for the engine and the first rooms.

1 Like

Looks like your VM / byte code design is a lot more complex than what I ended up with. Understandable if you were aiming to do more complex behaviour (images, sound etc). If you take a look at mine its very minimalist (e.g. not even a stack)

Assuming that the size of the engine doesn’t change, the space available for the game data is 19,683 bytes of which 5,501 is currently used in the demo. This is about 28% so there is quite a bit of space left but would be difficult to fit the whole game.

Of course adding save game support will increase the size of the engine. There might be other savings that can be made though.

The whole game would easily fit with some external memory for sure! Perhaps even a graphical version more akin the original but that is another story :slight_smile:


I hadn’t really noticed that yours didn’t have image support.

I based quite a few of my instructions off Mother 3’s bytecode because it’s a very text-oriented RPG with precise text timing for maximum effect, with a little bit of inspiration from VNDS (which is a really poorly written VN engine, but the only one I’ve seen source code for).

Also me being me, I’m not very good at settling for minimal,
so I had to add at least some basic integer arithmetic capability. :P

This is one of the problems I had.

I was waiting for the FX chip to be developed enough to be able to stream instructions from the FX chip instead of the Arduboy’s progmem.

The added bonus would be that you could use a single program to play multiple games because all the game data would be on the FX chip.


Basically the program would be just the engine and the games would be loaded from the chip. Sounds like a plan to me.


I was previously also working on another simple Javascript-like language with an 8-bit VM a while ago but it quickly became very complex! I might still add very basic integer arithmetic for tracking score or game values. e.g. in Space Quest you have a certain amount of money. Also, the ship you are on in the opening section of the game should explode after a certain amount of time but this isn’t implemented yet.

Sierra’s AGI engine (which Space Quest was built with) allocates 256 bit flags and 256 byte variables for the game. Quite a lot can be done with such a limited amount of memory!

It wouldn’t be too difficult to add other features such as images and sound, but as mentioned becomes a problem with storage space.

If you are interested in what the byte code looks like, the compiler adds comments to the output (which was really useful for debugging the VM)

Generated from this script:

1 Like

Oddly enough I was planning to have up to 256 ‘saved’ global variables and up to 256 ‘unsaved’ local variables (as an alternative to just the stack - because shuffling the stack around can be awkard).
The default settings had just 32 for both, but it could be increased.

Yeah, that’s part of the reason I stopped development.
I gave the player the option to have 255 backgrounds and 255 images (and had I got round to it, 255 sounds),
but the progmem limitations would have meant it would end up being a lot less than that.

It looks a lot more declarative than the bytecode for the engine I was working on.

In my case because I hadn’t got round to writing the compiler yet I just wrote a set of macros to look like assembly instructions,
so the bytecode is quite readable:

The definitions for the macros can be seen here,
and there’s a corresponding header that undefines them all to prevent ‘macro poisoning’.

I probably would have found a way to do it without macros,
but generating an array at compile time with templates is somewhat tricky.
(Even moreso when you don’t have the C++ standard library available.)

Also, note my run-in with Arduino’s DEC macro.
People say it doesn’t happen, but truly there are times when macros collide, which is one of the reasons usually I avoid using them.

1 Like

Macro collision is a myth.

This was popular on Twitter so thought it might be worth sharing here too:


Doooooooo it, complete sentance.

it’s amazing and cool. Could be great exploited on the fx and it’s aditionnal storage capacities

1 Like

Yes this would to some degree be elementary to do with the FX hardware.

1 Like