Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

As a Web/UI dev rapidly expanding into more wide-open generalist territory, the more I learn about how its done in other languages, the more I love JS for architectural and basic messaging/event-driven concerns. For the record I am most certainly not a full-blown game-dev (although I did once write for a major gaming mag which is like saying I pretended to be friends with game devs on TV, although you guys were always my favorite folks to talk to).

Anyway, since it's fairly easy to bind C and C++ to JavaScript via Node (or perhaps more specifically V8), how reasonable would it be to assume you could write a decent 3D engine that exposed outcomes of things like collision calculations as events to the JS with the intention of getting the dynamic first-class-function party language benefits (assuming you see such things as benefits - I do) to higher level architecture and AI logic concerns without a crippling loss in performance?

Node, as I understand it, basically exposes a C event loop to JavaScript handled by V8. The JS is single-threaded, meaning any attempt to do anything calculation/IO-intensive with the JS would be foolish, but you get the advantage of not really having to sweat threads, queuing etc... since you're ideally never trying to muck with the same data at the same time. Most code would of course be heavily event/callback driven. All the file I/O concerns and other processor intensive stuff is basically C or C++ under the hood telling you when its done. Not to mention handling UI concerns directly out of the JavaScript via a webkit layer slapped on top of everything.

I'd be delighted to hear why you love/hate the idea but the core question is: is it feasible and why/not? And no, I seriously doubt my own ability to do this all by myself, although plugging an existing 3D engine in might not be outside of the realm of possibility but I'd still be learning a lot of new stuff to make that happen I'm sure.

share|improve this question
    
It's quite reasonable. Games have been heavily using scripting languages with far less efficiency than modern JS runtimes for decades. –  Sean Middleditch Jul 18 '13 at 1:54
    
While no one has mentioned it, there are three votes to close this question as a "which tech to use" question. I can see it going that way, so you may want to edit it to be a little less about which tech to use and a little more about how to do the things you want with your chosen tech. –  Byte56 Jul 18 '13 at 5:59
    
I guess I could edit the title since they're probably not reading the question. –  Erik Reppen Jul 24 '13 at 2:29

1 Answer 1

up vote 3 down vote accepted

Yes, it's quite possible. In essence, this would just be extensive scripting, and scripting is very common in game development. You can do whatever you can in JS, and use C/C++ for the stuff you can't get to behave with JS.

I wouldn't bother with Node.js and go straight for V8, which is not that hard to integrate. V8 has recently added isolates, which make it possible to run multiple threads on a single context, but you'll probably be fine with a single JS thread, resource loading and such can be handled by threaded native code.

Depending on how much you script, there'll be some tricky issues, even on the PC which has a relative abundance of memory. On mobile, these issues would be greatly amplified. But I'm mostly thinking about garbage collection related issues here, which affect Java and C# games all the same.

My preferred approach to scripting is to only use it for descriptive stuff, that doesn't cause any such issues. I use JS or Lua to describe worlds, UIs, dialogs and all that, run the scripts once to get the data into memory and then operate on that data from native code. My suggestion would be to start with something like that, and see how far you want to take the scripting.

share|improve this answer
    
Thank you for a thoughtful answer. I'd prefer the single thread as it keeps you focused on a clean separation of roles. In JS you do tend to think about memory (or you should if you don't), even though you never have your hands directly on it. Strangely I find I have more in common with C and C++ devs than Java/C# devs. It's two different flavors of more rope to hang yourself with but man, when you have that much rope... –  Erik Reppen Jul 20 '13 at 0:36

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.