Who feels sometimes like he (she) is using the wrong language?

General Discussions
#41

Many of the AAA titles use quite a lot, if not in bulk (ie most of the interesting stuff) in lua. Or least the few i have seen under the hood.

As for C++ portability. If for every platform I add to my supported list I have to a lot of work, then portability means something different to you and me. With that working definition, assembler is pretty portable too, in fact i have always seen C as syntax sugar to a assembler. The last line of DSPs we worked on we just used assembler anyway. I mean hell it even has a FFT instruction.

I am not trying to rag on C++ or C or anything else (right tools for the job). But adding another target to these is generally non trivial. And the whole “really good code its easy” doesn’t really sell. Hell look at how many apps still won’t work with x86_64. Its really not that much of a change, and we have had x86_64 for more than 6 years.

However one thing is now very true. A large amount of software these days spends more time in development, than in production, this is more true for games. I think languages that help with development (aka bounds checks, null pointer exceptions, GC etc) will become even more dominant in the future. Keep an eye on LLVM.

#42

Many of the AAA titles use quite a lot, if not in bulk (ie most of the interesting stuff) in lua.

Naaah… there are millions of lines of C/C++ code in the 3D engine, the physics engine, sound library, image/audio loaders, middleware and whatsnot.

Lua is often used for the high level game logic. E.g. in a first person shooter, you can create weapons on the Lua side. Which model, which sound files, which objects for projectiles, rate of fire, spread, zoom behavior, damage, splash, particle effects (declaration only), clip size, pickup size, max ammo, and things like that. You can also create menus, in-game menus, and the HUD this way. And all those things which would be usually in some kind of config file also end up in Lua scripts. No need to write a parser for that shit. FarCry did all of that stuff for example.

You can also script boss battles or mini games like that. E.g. press all those buttons within xx seconds and you see sequence A otherwise you see sequence B and die. (MDK2)

LuaJit is amazingly fast, by the way. (But I don’t really like the look and feel of the language.)

Edit: On a second thought… it all depends on your definition of “interesting”, I guess.

#43

My main Java usage is for very small tools, which it is also very handy for.

Back to the OP topic. I’d be tempted to write a small native framework in plain old C and either use embedded Lua or V8. The choice between Lua & V8 depending on a combination of personal preference and target needs: game logic, platform, libraries and tools. From a pure language standpoint there’s no strong reason to choose one over the other as they are both prototype based. Personally I’d go for V8. Like oNyx I’ve never liked the syntax of Lua and V8 has better performance and is rapidly evolving. Lua has the advantage of being older and it seems to have a strong community. So there are good arguments for either.

#44

Serverside I would stick with Java, client side something like C with Qt or C# with OpenGL sprinkled in.

#45

[…] V8 has better performance and is rapidly evolving.

LuaJit is bloody fast:

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=v8&lang2=luajit

I’d also go with V8 though.

#46

Sorry DzzD, I discovered Molehill Flash API thanks to you, I admit that Flash in 3D will be a real competitor. However, I disagree with your figures about Java penetration. Even in France it is not possible to pay your taxes on Internet without at least Java 1.5 and even Java 1.6 since last year…

#47

The downside of LuaJit (at least the last time I looked at it) is that it’s i32a only. Luckily it’s pretty small and armed (yuck! yuck!) with a minimal knowledge of ARM and asm banging out a port shouldn’t be too difficult.

C# doesn’t seem like a reasonable choice, esp for embedded devices. Not really convinced it would be a good idea for desktop either, for that matter. This isn’t a comment on C#, but on the VM choices.

Running Java on the server? Maybe. Assuming the game needs a server, the choice should boil down to performance needs vs. the desired for a unified client & server DSL.