
Game Programming Patterns – Bytecode - beef3333
http://gameprogrammingpatterns.com/bytecode.html
======
namuol
In summary: Why create a game when you can design and implement a new
programming language?

~~~
daemin
Corollary: Why create a game when you can implement cool new engine tech?

~~~
krapp
Depends on what you can actually finish I suppose.

I have several game maker projects which are long dead and gone because I got
bogged down trying to write nifty engines and crap for them. In one case, I
spent probably weeks working on my own custom (and, to be fair, only barely
passable) physics engine for a game which can now be accomplished in a few
lines now that game maker studio comes with a physics engine.

I can only imagine how deep the rabbithole would go if I ever started to learn
game design in C++ or something (which, of course, I plan to) and then added
language design on top of that. Would probably be really fun though.

~~~
daemin
In line with the other commenter, I have spent many years tinkering with just
game engines in my spare time, and indeed it is a rabbit hole.

For that reason I think things like indie game jams (Global Game Jam & Ludum
dare) are a good idea because you will write crappy code, but you will
actually make a game.

------
SixSigma
[http://c2.com/cgi/wiki?GreenspunsTenthRuleOfProgramming](http://c2.com/cgi/wiki?GreenspunsTenthRuleOfProgramming)

"Any sufficiently complicated C or Fortran program contains an ad-hoc,
informally-specified, bug-ridden, slow implementation of half of CommonLisp"

~~~
yoodenvranx
Are there any good real-world examples for this?

~~~
tonyg
The browser.

~~~
pcwalton
Well, it's pretty formally specified now. (Also pretty fast.)

~~~
silentOpen
It's kinda sorta specified in English prose. I wouldn't call that _formal_ ,
though.

------
anon4
In what situation would "just embed python/lua/js/etc." not be the appropriate
solution to this problem?

~~~
ANTSANTS
You saw them a lot in old games (the kind likely to be written in assembly),
because not even C, let alone a general-purpose scripting language, was
acceptable for performance reasons for quite some time, yet there has always
been a need for greater abstraction and expressive power. Look at any Japanese
RPG of the 80s and 90s, for instance, and there's probably a simple bytecode
VM (or state machine, if you prefer) for scripts that move characters around
during story sequences, one for displaying text in menus and dialogs, and so
on. Look in an arcade shooter, and there's probably one for defining enemy
movement patterns, etc. Tiny bytecode DSLs not only boosted expressive power
for programmers, they also allowed non-programmers to script behavior. 6502
assembly might be out of reach for non-programmers, but `SETANIM PLAYER1
PLAYER_WALK_TICK; WAIT 20; SETANIM PLAYER1 PLAYER_WALK_TOCK; WAIT 20; LOOP;`
is not. If you only have to remember a few simple rules to get the behavior
you want, even learning to hand-assemble bytecode is not out of the question
for a dedicated professional.

Nowadays, you'd probably be better served by embedding a general-purpose
dynamic language in most of these scenarios, but hand-rolled bytecode can
still win in certain situations that _need_ high performance and/or low
latency. Imagine, for instance, one of those fancy "danmaku" shooters with
hundreds or even thousands of bullets on screen moving in intricate patterns.
You just might want a language more dynamically manipulable than C to script
the behavior of those bullets, but using a dynamic language that furiously
generates garbage and demands collection pauses for something that _must_
happen 60 frames per second on so many objects is probably going to cause
hitches eventually that _will_ get your player killed (in the game, at least).
You'll then be subject to a very harsh but valid criticism: "I played games
like this on my PlayStation back in the day with no slowdown, this guy must be
a crappy programmer if his 2D game stutters on my monster PC." Sure, it's
great that you don't need to break out the optimized assembly to do a Breakout
clone anymore, but at the same time, _you should feel bad_ if a 1Mhz 6502
provides a considerably more reliable experience than your game on a modern
x86.

A certain popular 2D shooter series made by an ex-Taito arcade game programmer
uses a bytecode DSL for its intricate bullet patterns for this reason. It was
probably an easier decision to make when the series started in the late 90s,
but today it lets the author be productive without adding wildly variable
latency into the mix that would kill the gameplay. People should not forget
that running smoothly even on poor hardware is a real feature. Even in 2014,
I'm sure there are plenty of people out there still using Pentium 4s and
Windows XP. If you make the only new games/apps/whatever that run well on
these computers, you have a captive audience.

At the same time, I think you could extract 99% of the performance benefits of
the bytecode approach if your language had a well-defined heapless, stackless
"tasklet/microthread" subset that centered around mutating existing objects
and making certain limited kinds of allocations (allocating from a memory pool
and manually "freeing" by marking the object as unused later). Knowing that a
piece of code will never generate garbage and that a garbage collection cycle
will never happen during its execution makes a huge difference.

~~~
munificent
> Even in 2014, I'm sure there are plenty of people out there still using
> Pentium 4s and Windows XP.

Don't forget low-end mobile devices.

~~~
x1024
Eh, angry birds runs on Lua. Your point was?

~~~
ANTSANTS
Angry Birds is not a terribly involved or demanding game, and the hard part,
2D physics simulation, is handled in C by the Box2D library anyway. It
requires no real-time control, you just aim the bird and watch the reaction.
You could half or quarter the framerate and add enormous interframe jitter and
the game would play exactly the same. If you tried to do the same thing with
an demanding twitch action game, it would quickly become unplayable.

~~~
eropple
Lua's been fast enough to do what you describe for years on gear much slower
than even bottom-end smartphones, but if that's too iffy for you, AngelScript
is a sub-megabyte runtime when run on Android via the NDK. It's historically
been performant enough for use on the PS2 (with its ballin' 300MHz MIPS CPU
and 32MB of RAM). It's statically typed, has a very well-defined garbage
collector you can pretty easily avoid ever invoking once, and as a simple
transform language generates very little (possibly even no? I don't remember)
heap allocations. It will also take literally ten minutes to set up for the
sort of use case we're talking about here. (If you want to bind a big honking
C++ library to it, then things get interesting, but we aren't talking about
that.)

You still write your perf-sensitive code in C++, of course. Just like if you
embed Lua. Because you _aren 't dumb_.

munificent hit on the one use case where this makes a ton of sense to me--when
you're a basically-embedded environment, he was talking about a platform with
four megabytes of RAM--but that hasn't been a serious use case in games on
popular platforms for a _while_ now. Which is why I'm confused why it's in a
book that seems to basically be for novices, at least without some "you should
rethink doing this unless" asterisks.

~~~
ANTSANTS
AngelScript seems relevant to my interests, I'll have to check it out.

I'm sure Lua is "good enough" for a lot of tasks in most games on most
hardware, I was just trying to hint at scenarios where the GC overhead could
be painful enough to warrant a custom approach.

>but that hasn't been a serious use case in games on popular platforms for a
while now.

The DS with its 4 megabytes of RAM was still a relevant platform not that long
ago. The 3DS doesn't have a whole lot of breathing room either; 128 megabytes
of RAM, who knows how much of which is available to the game and not reserved
for the OS.

>Which is why I'm confused why it's in a book that seems to basically be for
novices, at least without some "you should rethink doing this unless"
asterisks.

I haven't read too much of this book, but I got the impression that it was for
programmers of other disciplines that wanted the skinny on game development
practices, not for total novices. Somewhere between "Game Programming for
Teens" and "Game Engine Architecture." This chapter doesn't seem that out of
place to me.

~~~
eropple
_> 128 megabytes of RAM, who knows how much of which is available to the game
and not reserved for the OS_

The OS reserves 32MB for itself, which leaves you with a bigger working set
than a bottom-shelf Android phone. =) I get what you're saying, but I don't
think anybody's going back to the halcyon days of fewer megabytes than I've
got fingers.

 _> I got the impression that it was for programmers of other disciplines_

It felt like something I'd recommend to a CS student, tbh. Maybe that's just
me.

~~~
ANTSANTS
>The OS reserves 32MB for itself, which leaves you with a bigger working set
than a bottom-shelf Android phone. =) I get what you're saying, but I don't
think anybody's going back to the halcyon days of fewer megabytes than I've
got fingers.

Ok, 96 megabytes. When you set aside RAM for everything else in a 3D game (the
main binary, sound/mesh/texture caches, etc) there's not a whole lot of space
left for a scripting language's heap, especially when you consider that most
garbage collectors require that the heap be significantly larger than the
working set in order to achieve reasonable performance. Again, not saying Lua
wouldn't work just fine (any 3DS devs in the audience that would care to
comment?), just that it's by no means impossible to bump against that limit.
For comparison, here are the slides to a 2010 presentation that demonstrates
how devs were having real performance problems with (PUC-Rio, not Mike Pall)
Lua _on the 360 and PS3_ :

[http://www.slideshare.net/hughreynolds/optimizing-lua-for-
co...](http://www.slideshare.net/hughreynolds/optimizing-lua-for-consoles-
allen-murphy-microsoft)

>It felt like something I'd recommend to a CS student, tbh. Maybe that's just
me.

Well, I wouldn't be surprised if the average programmer is actually working
below the level of what we expect a CS student to know _/ me ducks_

~~~
eropple
I think--not sure, I haven't tried--that I'd be a lot less worried about that
RAM budget on that phone, actually. That phone almost certainly doesn't have
the GPU for a game rolling with nontrivial models/textures. Like, just as an
example, I don't think you're running even a downscaled, super-optimized,
everything-in-C++ version of the Angry Bots demo that comes with Unity (it's
on Google Play if you want to check it out) without stripping out actual
_functionality_ to the point where I think you sort of miss the point of the
game because I think the GPU would give up the ghost. So I feel like on this
low-end hardware you're basically talking about fairly lightweight 2D games
because it _can 't push better_, so I'm not sure I'd really worry about big
honkin' meshes or textures. Is that unfair? (My own libgdx game doesn't use
more than 60MB of textures at its peak, and I'm doing a lot more stuff in my
JRPG than I'd think almost anybody would _try_ to do on that sort of bottom-
of-the-barrel hardware.)

Also, yeah, maybe I'm overshooting the average programmer.

------
Marazan
I think a lot of people misunderstand what is being proposed here. He's not
saying to write a whole new language, he's saying to write a byte code
interpreter. You can implement one of those in about an hour.

~~~
namuol
Ah yes, I'm sure designers will just love to write their scripts in raw
bytecode.

This section is somewhat important:
[http://gameprogrammingpatterns.com/bytecode.html#how-is-
the-...](http://gameprogrammingpatterns.com/bytecode.html#how-is-the-bytecode-
generated)

While you're at it, you'll probably want to write some debugging tools since
your designers are bound to dream up some complicated scripts you never
imagined your system needing to handle...

~~~
Marazan
They will write them in FORTH and they will like it!

------
mambodog
If you're interested in this, check out Fabien Sanglard's code review of
Another World[1], which is one of the more notable VM based games, managing to
target a multitude of different platforms with some impressive vector graphics
for it's time.

Also very interesting is the Emscripten port of ioquake3, which includes a
custom compiler for Quake 3 VMs to Javascript.

[1]
[http://fabiensanglard.net/anotherWorld_code_review/](http://fabiensanglard.net/anotherWorld_code_review/)

[2] [http://www.inolen.com/articles/compiling-quake-3-virtual-
mac...](http://www.inolen.com/articles/compiling-quake-3-virtual-machines-to-
javascript/)

------
dylanrw
I've been keeping track of this book as it's developing and I must say, it's
an excellent, well thought out, high level primer.

~~~
munificent
Thank you! I'm almost done! Only one more chapter.

------
killertypo
Everything about this website makes me happy and I read it regularly.

------
coldcode
"Console manufacturers and app marketplace gatekeepers have stringent quality
requirements, and a single crash bug can prevent your game from shipping". Not
in my experience, usually when the hard ship date comes it goes out the door.

~~~
munificent
There's a bit of give and take, but when I was at EA, certification was
serious business. During beta when we had a final candidate build and the
console manufacturers were testing it, we basically sat there with our fingers
crossed hoping they didn't come back with an issue.

~~~
SixSigma
My friend scored his dream job "game tester" for Rockstar. The fun turned into
tests like "Run to edge of gameworld, fire 25 rockets, run back, swap rocket
gun for pistol, run to edge of gameworld, fire 25 shots, run back, repeat"

------
matt_heimer
Seems like he is reaching for an Entity-component-system -
[https://en.wikipedia.org/wiki/Entity_component_system](https://en.wikipedia.org/wiki/Entity_component_system)

~~~
munificent
I wrote a chapter on that too!

[http://gameprogrammingpatterns.com/component.html](http://gameprogrammingpatterns.com/component.html)

~~~
wtetzner
You might want to look at how people are approaching components now. Instead
of components containing logic, components only contain data.

You then have systems that operate on the components. This solves the problem
of needing components to interact with each other, since a system can look at
as many components as it wants.

[https://en.wikipedia.org/wiki/Entity_component_system](https://en.wikipedia.org/wiki/Entity_component_system)
[http://t-machine.org/index.php/2007/11/11/entity-systems-
are...](http://t-machine.org/index.php/2007/11/11/entity-systems-are-the-
future-of-mmog-development-part-2/) [http://piemaster.net/2011/07/entity-
component-artemis/](http://piemaster.net/2011/07/entity-component-artemis/)

~~~
munificent
Yeah, I'm aware of that approach too (all of those links are already gray for
me!), but I wrote the chapter before that became as popular as it seems to be
now.

I say seems to be because while ECS is clearly being talked about a lot, I'm
not sure how many shipped games are actually architected around it. The
blogosphere doesn't always accurately reflect reality.

I've looked at a few ECS implementations and many of the ones I saw had such
bizarre implementations that they more than nullified the performance benefits
of components.

I do see the advantage of systems that work on multiple components, but I
think some proponents are starting to cargo cult this model. That happens
frequently in games because you have so many amateurs that want to know the
"best" way to do things, and the constraints are challenging.

Hmm, this ended up sounding overly negative which I didn't intend. I think ECS
is interesting, but I'll be interested to see how it matures over time. Right
now it feels a bit like the OOP fads of the 90s to me. There's good ideas in
it, but any good idea can be taken too far.

------
beefsack
I'm patiently waiting to see if Rust can solve two of the three points in the
"when to use it" section without sacrificing significant performance.

------
SixSigma
Should have used Forth from the start

~~~
herokusaki
What is a good embeddable Forth for a game?

~~~
SixSigma
Not embeddable, from the start

~~~
herokusaki
Is this a viable suggestion, though? Correct me if I'm wrong but I imagine
that developing the entirety of your video game in Forth for anything but
desktop operating systems would mean writing your own tooling and API
bindings, if not your own Forth compiler.

~~~
SixSigma
It is pushing the the machine model to where it is most appropriate, on the
iron. No different from choosing Javascript because it is cross platform, just
someone has already done lots of the base work.

Forth has strengths and weaknesses, lack of wide use on modern platforms is
definitely a weakness. There is still plenty of Win waiting in there.

