This week in gamedev #7

This week has flown by, and my day job has been quite draining, but today is Thursday and that means gamedev update!

Released my ZX Spectrum 48k beeper engine

That could explain why this week I have been a bit low, because working on this little project was kind of intense, and when one of those ends, it always leaves some emptiness.

The project lives in beeper engine for the ZX Spectrum 48K, in GitHub.

Although it is ready to use, there are some things that I may probably add later on:

• More ASM versions of the player. Currently I provide the primary source for he SDCC assembler, that is not the most common syntax. I hope other people using it will contribute other versions.
• Currently the player doesn’t preserve the border color (and there’s a FIXME for that). I may or may not use that, but I guess it is something that is missing for general use.

Everything else is in place and working, to the extent that I have tested it, of course. I’m mostly concerned about the editor having bugs, but I will fix those when they are reported.

Investigating a scripting solution

Although most of my games are very data driven, I have never implemented scripting for any of them. We are talking 8-bit games here, so is not about making the games extensible, but to save memory by using very high level functions in a very dense virtual machine (the script would be more like bytecode).

Looking at existing art that is open source, Na_th_an (from Mojon Twins fame), has implemented scripting on his MK1 NES engine, with a compiler written in BASIC –I love it–.

This solution is very close to the data driven approach I’ve used for example in Rescuing Orc and Dawn of Kernel, were all the data is entered using tiled, and then packed into binary by a Python script.

In Dawn of Kernel for example, there’s a “text” event that, when present, it will display a message from Kernel –the enemy IA–. That saves space and makes game design easier, but there’s no game logic on that data, and that’s something the scripting engine should support.

In reality I should start a project, and then look to implement a simple scripting engine if I need it. Ah, if only things were that simple!

Anyway, I’ve always been into programming languages –specially compilers and interpreters–. Together with operating system design, those topics were my main interest back in Uni. Fortunately I gave up with the operating system part, but every now and then I have the itch to implement a programming language. From silly toy languages to a 6502 VM for 8-bit AVR, so getting myself to write such an engine can be dangerous for my free time!

For now I’ve looking to some interesting resources:

• Build your own Lisp
• Crafting interpreters (I have read Game Programming Patterns by Robert Nystrom as well, and is great)
• Micro parser combinators (in C)

The idea would be around the following points:

• A high level language to access and manipulate game state.
• A compiler to translate that language to bytecode.
• Execute the bytecode in a tight VM, written in the target platform (likely to be Z80).
• Integrate the VM in the game loop.

I’m not sure if is worth moving all the entity information I usually encode in the map data into this language, because the way it works now is very optimal and I really like using tiled to place the entities in the map –it makes game design nicer–. Perhaps this is about including labels on the script and refer to those labels in the map data, so a part of the script is run as an entity. That could allow supporting game logic easily, keeping the benefit of both approaches.

Hopefully I’ll start a project soon and we will see if any of this makes any sense!