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.
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.
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.
> 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.
>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:
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.
