In what situation would "just embed python/lua/js/etc." not be the appropriate solution to this problem?
(I should know, I've certainly killed enough projects by doing it.)
'''In what situation would "just use linux/freebsd/etc." not be the appropriate solution to this problem?'''?
And if it doesn't, it's not going to be improved by rolling your own.
What we did do was write a tiny little bytecode VM as described in the chapter. The level editor I wrote[1] let designers author behavior using a little UI. It then compiled that to bytecode.
It worked like a charm if I may say so. Unlike a full-featured language VM, we didn't have to deal with strings, parsing, garbage collection, or any of that stuff at runtime, which would have been untenable on a DS.
(That said, no-GC AngelScript uses under a megabyte of RAM on ARM; before I switched to libgdx and decided that I could do without supporting the Galaxy Nexus I'd spent a lot of time examining it. It certainly might be tight on the DS, but on any modern system, I think you're probably cool.)
It's hard to sandbox python or lua and block I/O and all system calls. 1 mistake and player computers are compromised.
Even with JS in browser you can't just eval(), you need sandboxing like https://code.google.com/p/google-caja/ or https://github.com/jterrace/js.js/ (200 times slower than js).
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.
Don't forget low-end mobile devices.
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.
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.
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.
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
Also, yeah, maybe I'm overshooting the average programmer.
I sorta doubt there are many games targeting these devices (and, more particularly, the people who still use these devices in 2014) in the first place, but even fewer which are pushing their headroom so hard that, if they decide they need what amounts to a scripting language, they can't fit one in off-the-rack.
My market research has shown that when you get below those specs you start getting into dumbphone/J2ME platforms, where you have other constraining factors.
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 scoped, could end up being easier than embedding lua. That is, if what you're doing is only barely more than loading and using data- not even quite crossing the boundary into turing completeness.
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.
Oh hey, I think you just described asm.js