In summary: Why create a game when you can design and implement a new programming language?
Corollary: Why create a game when you can implement cool new engine tech?
Game Programming Patterns – Bytecode
51–60 of 73 posts
Re: Game Programming Patterns – Bytecode
#52If 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/
[2] http://www.inolen.com/articles/compiling-quake-3-virtual-mac...
Re: Game Programming Patterns – Bytecode
#53In summary: Why create a game when you can design and implement a new programming language?
Corollary: Why create a game when you can implement cool new engine tech?
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.
Re: Game Programming Patterns – Bytecode
#54Earlier quoted context omitted.
it is not always about whether you can at all. Sometimes it's about power budget- That is, battery drain, etc. Run your lua engine and you have less budget for particle effects. Run all the things and your game drains the battery in 10 minutes. It's perfectly legitimate to not care. Writing a from scratch bytecode vm is a fairly extreme last resort solution. But on the other hand, the bytecode VM, appropriately scope…
The power delta between AngelScript or Lua and your own interpreter is gonna be pretty small, though. It's a cost you pay once (in a modern implementation) to interpret into...a bytecode VM. And you totally might be a wizard beyond my ken here, but I strongly doubt it'll be easier to implement a bytecode VM of your own than calling, like, five functions. =) I'm not denying that there are cases where such a thing is v…
You're probably right and it's totally irrelevant in this day and age with cheap memory and cpu power.
I can't help but remember fondly on the idea of the bytecodeVM that "Out of this World" used to draw vector graphics, and think "That. is. neat".
or the power and flexibility the SCUMM vm afforded story writers.
It's fetishistic and unrealistic I suppose, to think it would be cool to do some amazing game on some extremely primitive slow low power cheap machine that anyone could buy for like $10. The whole fantasy usually ends when you realise that the cost of displays is well beyond the cost any actual computer hardware you may consider.
Re: Game Programming Patterns – Bytecode
#55Earlier quoted context omitted.
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 e…
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…
> 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.
Re: Game Programming Patterns – Bytecode
#56Earlier quoted context omitted.
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…
> 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…
>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...
>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
Re: Game Programming Patterns – Bytecode
#57Earlier quoted context omitted.
> 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…
>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…
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.
Re: Game Programming Patterns – Bytecode
#58I'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.
Re: Game Programming Patterns – Bytecode
#59Earlier quoted context omitted.
Corollary: Why create a game when you can implement cool new engine tech?
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…
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.
Re: Game Programming Patterns – Bytecode
#60I 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.
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-...
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...