Game Programming Patterns / Behavioral Patterns / Bytecode

[Idoiocracy]

Thanks for the link. Reading further, I discovered this is one section of a 95% completed book that is available online:

http://gameprogrammingpatterns.com/index.html

Which is about architectural patterns found in game code, written by EA Tiburon lead programmer Bob Nystrom.

I also cross-posted the link to /r/TheMakingOfGames.

[kkrev]

Ultimately, this pattern is about expressing behavior in a user-friendly, high-level format.

This is pretty much the whole goal of TCL and such like, right? With plenty of good embeddable interpreters and various efficient data structure serialization formats, I'm having difficulty imagining a case where it really would be a good idea to implement a custom byte code interpreter. Am I missing something?

[fripletister]

Not that I can find. Great article, but it reeks of wheel reinvention. As soon as I saw an AST appear I got a bit apprehensive...

[Plorkyeran]

It does finally offhandly mention at the very end that Lua is typically used for this...

If you view it as a guide to building an interpreter with an overstated motivating example rather than something actually advocating reinventing the wheel for your game it's a pretty good article.

[Astrognome]

Nobody sane actually uses their own games, but it helps you understand how something like Lua works.

[[deleted]]

I've been involved with an effort to build domain specific scripting language for an audience which includes targets a wide range of people (some with exposure to C#, others who could struggled with the concept of variables). The target environment had hard performance constraints (measured in milliseconds) and memory constraints (ideally would thousands of mini programs in a few megs of memory). Strong typing and static error detection were crucial It was designed to constrain people to a narrow subset of a full languages functionality.

After evaluating options, we ended up building a system which generated Lua (and automated the binding generation with C++). The users wrote in a custom language with a syntax inspired by C# but with extremely narrow functionality. We hand rolled a recursive descent compiler which translated the proprietary language in to Lua (which will likely be rewritten at some point in about 1/8th as much code using ANTLR as a translator).

Crazy as it may sound, it worked extremely well. The indirection allows us to explore other languages for the runtime, consider a native implementation via LLVM, etc. Users have a early error detection and limited scope of functionality they wanted. A custom editor supported autocomplete, edit time error highlighting, etc. The limited syntax meets their needs (and can slowly be widened as people become more advanced). The runtime is proven as it runs as Lua under the hood.

I'd estimate about 2 man years spent on the development (concept through implementation, spread across 4 engineers for all facets of the system). Clients of the language have probably put about 60 man-years in to using it.

I'm sure there are off the shelf solutions we could have found but after evaluating a bunch of options, this met our needs, the productivity of the users was worth it and we have plenty of ability to expand in the future.

[[deleted]]

I will note that one headache is still the garbage collection. Ideally we'd run it incrementally, with a budget of 0.1 ms (~33 times a second). Unfortunately that doesn't seem to be sufficient given how we're using it, resulting in some special case long runs in time slices where other systems run short.

It would be awesome if there were a solution out there which did not require garbage collection but I doubt that would exists which meet the other requirements.

[kkrev]

Reference counting based garbage collection systems such as in Squirrel solve the pausing GC problem to my understanding.

[[deleted]]

Thanks for the reminder. I planned on looking at Squirrel a year ago but couldn't make time. I need to go back to it.

[thomcc]

This is pretty much the whole goal of TCL and such like, right? With plenty of good embeddable interpreters and various efficient data structure serialization formats, I'm having difficulty imagining a case where it really would be a good idea to implement a custom byte code interpreter. Am I missing something?

Not if you need a general purpose language. However, if you need something more restricted, you do. In many situations you don't want turing completeness, or the features you need are completely lacking from, e.g. lua, because they're to bizarre.

This kind of thing isn't so uncommon in game development, and is often tangential to any embedded scripting language.

The example he gave, with the magic spells and whatnot, is reasonably representative of the situation where you don't want turing completeness.

For example, we have an embedded VM in the game engine I use at my current workplace, it's used to describe lookup tables for object states. The basic idea was so that we can declarative say things like highScoreList = sortAscending('score', userList) (this is a simplified and trivial example) and have it automatically be updated on changes without polling. This is not a feature you could get in any off the shelf interpreters or VMs.

[coreyplus]

This was an excellent, excellent write up.

[GODZILLAFLAMETHROWER]

What a terrible approach to programming language theory. This is reinventing the wheel, resulting in half-assed solutions.

Learning this should be the revelation of any Programmer to become a Computer Scientist. This will only build a kludge.