Language... Games.

[trivia]

I'm thinking about learning more advanced scripting. Earlier I've worked with things like flash script (don't know it's name) and JASS(the language used in warcraft)
Mainly I'm thinking about games, but also other stuff.
My question is what language you recommend that I should try to learn? I'm thinking about C++, cause it seams both wide and good, but I don't know.
I'd like a language that you can both use for advanced stuff (Like real video games. Not because I will sit at home and scipt new games, but still), but also I want it to be easy to learn.
I'd like something that doesn't require programs that cost money.
Thanks for you advice.
/Trivia

[G_Morgan]

If you're interested in production quality games then the game engine practically must be done in C or C++. Few other languages can produce the high performance code necessary. Take a look at the fast InvrSqrt function used in Quake 3. It uses a pointer cast of a float to an integer before doing a right shift, negating it and adding a magic number before reconversion to a float. That number then forms a good initial guess in the newtonian sqrt approximation method. This is far quicker than standard or even platform built in options (by about a factor of 4) for finding invrsqrt.

Beyond3D - Origin of Quake3's Fast InvSqrt()

Not possible in any language that is type safe.

Having said that it is possible to build the engine in C or C++ and then use a higher level language for everything else. It's quite common for game engines to have a built it interpreter.

[trivia]

Thanks for your reply.
Ye, that's what I thought. Just wanted someone to confirm it. Spending time learning a useless language isn't really fun.
I can't say I understood much of what you just said, but anyway I wont really start at the Quake-level.
Anyway, can you link me to a nice beginners guide in c++? So that I can get started.

/trivia

[G_Morgan]

The stuff I mention above is just some low level hacking which most people would cringe at but is necessary for games development. If it's good enough for John Carmack it's good enough for me.

C++ Language Tutorial

That site covers most of the basics bar the STL.

Planet PDF - Thinking in C++

PlanetPDF has links to two free books on the language.

Naturally you'd then need to learn the API's of whatever game libraries you will be using (SDL and OGL are quite popular being easier to learn than some of the DX stuff).

[mahogny]

I would consider all options before C++. it is very inproductive compared to most newer alternatives and the lack of garbage collection can cause tons of nasty bugs.

speed is not always an issue. in fact, it is quite rarely an issue. you need it in really tight loops; the sqrt is a perfect example. yet, most likely you don't need to make an unsafe cast on every line in your program.

I recommend a statically typed compiled language with GC. there are plenty, and they are usually reasonable or as fast as C++. if you need even more speed at some critical spots then you can still mix with assembly (or the portable version, C)

[G_Morgan]

Adding GC to C++ is trivial. If you use a factory method pattern for any objects it is pretty unobtrusive as well.

A garbage collector for C and C++

OTOH generating tight code isn't trivial in any of the higher level languages, the interface to native code is usually massively inefficient. Also, what's unproductive about C++? You need to write header files but the fact I don't have to wrap functions in a superfluous class is worth every header file I've ever written. If you use some of the legacy C stuff then that's a PEBKAC problem rather than a C++ one. It is possible to write relatively clean C++ code. Other than Java it is the most popular language on the planet, those two stand out well ahead of the others.

If you want I have a package with the DLL, header files and the def file for the GC mentioned above, building it for Windows proves difficult. You will need to generate the import library for your compiler though (unless you are using MinGW, I have that import library). That's usually trivial though if you have a working def file.

Another alternative might be to look at a pre made game engine. Torque is freely available AFAIK. If you pick up '3D Game Programming All in One' it has a disc with the Torque engine on there and goes through developing a game for that engine. You don't need C or C++ for this because the engine is already made.

[WingedPanther]

mahogny, garbage collection doesn't always work, and should only be a backup to manual memory management. GC can also cause bugs.

Speed, especially for games, is frequently an issue, as it will limit how much can happen in the game.

Finally, C++ is just as portable as C.

[mahogny]

the only bug you can run into with GC is space leaks. these are fortunately very uncommon in eager languages (ie all the mainstream) and debuggers can find them, and patching them is trivial (so far I've only had one case of them).

GC is inherently incompatible with C++. it is very messy/impossible to get compositional properties of GC active in C++ since it requires that most of the code does GC, which is seldom the case. then it should be noted that a good GC implementation need compiler support. otherwise schemes like reference counting has to be used which fails in trivial cases.

C++ is ineffective because of the time it takes to debug and amount of code you have to write for trivial matters. the lack of first class functions and partial application is just the beginning (and please don't get started about Boost; it is a terrible hack).

C++ is almost as portable as C (in practice, the same). that wasn't my point - you don't use a low-level language when it isn't worth the effort. the speed requirements. and your concerns about speed are way beyond function. if 80% of the game time is spent in a few functions (almost always the case) then you optimize there and nowhere else, hence you might as well use a more productive language for all other functions that are less critical.

and no, wrapper code need not grow large. it is a matter of planning.

[G_Morgan]

If most of the code does GC is down to the programmer. Like I said, it's trivial to ensure that each class you create has a factory method basically executing 'return new (GC) Whatever()'.

If GC is inherently incompatible with C++ then someone wants to tell the C++ standards board before they add one for 2009.

Debugging is almost non-existent if you follow a test first methodology, same in all languages. Can't remember the last time I had any difficulty with debugging whether it is Python or C. It can't completely eliminate the debugger but it does eliminate 99% of it. Also a nice side effect is that your code ends up lightly coupled.

I agree with the fact that 80% of the game will be 20% of the code. That's why I suggested the game engine be written in C++. The rest of the game will be a huge selection of scripts and data that apply on top of the engine.

Out of interest, what do you suggest as a more productive language? Usually I find productivity is effected far more by things other than which language you are using, a good programmer will do more in ASM than an average one will in Lisp. First class functions and the other functional stuff does not generally see a lot of use in games programming. Fiddly pointer arithmetic is far more useful in this domain than things like closures and lambda's. Performance dominates.

[mahogny]

>If GC is inherently incompatible with C++ then someone wants to
>tell the C++ standards board before they add one for 2009.

the reason it is incompatible is that everyone is that there is no shared way of doing it. if the C++ board finally decides it then there is hope that GC actually will become useful. that said, it's hard/impossible for a GC to do a good without more analysis of the code which isn't currently done.

>Debugging is almost non-existent if you follow a test first

yes, the best way to remove bugs is to not add them in first place. nothing new. bugs are still unavoidable though. I guess here we can kick C/C++ in yet another way: there are no good interpreters and few statistical test tools, making unit testing more time consuming.

>The rest of the game will be a huge selection of scripts and data
>that apply on top of the engine.

...or some kind of embedded language, depending on how much scripting is needed/cost of making scripting language.

>Out of interest, what do you suggest as a more productive
>language? Usually I find productivity is effected far more by things

one language for each problem, or maybe even a mixture (some languages mix better than other though, this is a sad situation). I use mostly Java, C, C++ and Haskell, together special purpose languages like Erlang and Matlab. I hate all of them there is especially room for an eager imperative language that is guaranteed fast but doesn't give you cobol fingers.

>games programming. Fiddly pointer arithmetic is far more useful in
>this domain than things like closures and lambda's. Performance
>dominates.

lambdas and closures doesn't offer your language something you cannot already do with tons of interfaces and classes (or blatant replication of code). but it saves a lot of time and hence makes you more productive. pointers are rather more comparable to lazyness as a feature, but that on the other hand, has little use in games programming. luckily you don't need lazyness for higher order function etc (and indeed Java 7 will have something similar, and C# also has something like it)