Fighting games oftentimes implements specific character moves through scripts (e.g. Lua, JavaScript, or proprietary scripting languages), rather than hardcoding value and behavior into code. Implementing behavior via scripts brings the benefit of decoupling the underlying engine from the game’s contents.

As an example, many tittles made by Arc System Works shared the same (approximately) engine code, with character move sets and behavior developed in their proprietary scripting language, BBScript. If you are interested in this, some info can be found on the Dustloop Wiki page:

https://www.dustloop.com/w/User:Kjam/bbscript/starter[↗]

Fight750 State Script (F750 or FSS for short) is a scripting language I’ve recently developed, targeted at modelling state (or character moves) in fighting games. It is currently being used and tested on Super Smash Rhodes, a fan game of the popular mobile tower defense game Arknights.

Note that this post does not serve as the primary language specification or reference documentation for F750. The primary language guide and specification documentations can be found at the location below. Note that this guide is still work in progress.

https://app.notion.com/p/ku6/F750-State-Script-Bytecode-Specification-3e329cbe869580b9a941e9935c229cee[↗]

Fight750 State Script is an event-driven, general-purpose scripting language that targets primarily fighting games.

Some key features of F750 are:

• Extremely simplistic code syntax.
• Compiles to bytecode, then ran in a F750 Virtual Machine (VM) in the implementing game.
• Supports macros that are expanded at compile time.
• Supports forward declaration of external symbols (bindings and labels present in other modules at runtime).

F750 scripts are managed in the form of projects. A project is a collection of multiple F750 source code files, and is compiled into a singular bytecode module (.750b) file. Multiple modules can be loaded by the VM.

Let’s start with a short demo:

[Copy]plain
.data:
	const DebugMessage: "Hello, Fight750!", 0

_engine_on_state_begin:
	mov a64, #Libstd.EngCall.Debug.DebugPrint
	push DebugMessage
	engcall
	
	exit

In the above example, we define a label engine_on_state_begin, which invokes the Libstd.EngCall.Debug.DebugPrint engine call to display a message to the debug console. More specifically:

• We define a constant variable named DebugMessage with the content Hello, Figh750! plus a null byte (0x00) at the end.
• We define a label named engine_on_state_begin (the leading underscore is not part of its name), which refers to the address of the instruction immediately below it.
• We load the value of the engine parameter Libstd.EngCall.Debug.DebugPrint into the register a64.
• We push the address of DebugMessage onto the stack. The F750 VM uses a 64-bit architecture, meaning that all addresses and registers are 8 bytes (64 bits) wide.
• We invoke the engcall instruction, which looks at the value currently stored in a64, and invokes a particular functionality identified by that value.
• Finally, we invoke the exit instruction to notify our VM that execution has completed.

This article is incomplete. I’ve decided to publish it in its incomplete state to allow me to preview the contents. More content will be added as I finish this article, and this blog page will be updated.