I'm currently un-dusting an old adventure game engine I had last worked on back in 2019. The engine itself doesn't use an interpreter (there's no special script compiler producing bytecode) but instead compiles into Go code and then into native binaries from there. Technically there would therefore be no need for opcodes since, unlike many earlier adventure engines, there's no special interpreter/virtual machine.
I still question the wisdom of those earlier designs (Lucas Arts' SCUMM and Infocom's Z-Machine come to mind) that all implemented opcodes for common engine behavior.
My engine uses two parts. The engine itself and a small over-the-wire protocol that enables developers to implement GUIs in whatever language they want as long as it can connect via TCP. Currently, that protocol just sends the player input (it's a text adventure, although for later implementations I want to add mouse support) right back to the "backend" in clear text. However, there's also other actions aside of { "input" : "" }.
Aside of making things harder to disassemble (but also harder to debug) and enabling the development of custom script languages that differ from my reference implementation, would there be any benefit to replacing things like "input", "launch" or "quit" with opcodes like 0xBA, 0xBB, etc (perhaps also obfuscating the input values), etc?
Inside the engine itself I use public structs like this to define items, locations and characters.
Would I gain anything by replacing this human readable format with opcodes or is that very idea archaic?
type Item struct {
Article string `json:"article"`
Name string `json:"name"`
Description string `json:"description"`
Verbs ItemVerbs `json:"-"`
Synonyms []string `json:"synonyms"`
Moveable bool `json:"moveable"`
Carryable bool `json:"carryable"`
Attributes []string `json:"attributes"`
Fixture bool `json:"fixture,omitempty"`
}
Aucun commentaire:
Enregistrer un commentaire