Is the game still planned to be written in C#? It was the last time I remember reading about the subject, so I assume there's an extant codebase in that language. While cross-linking is not much of an issue and it's certainly possible to mix and match a lot of things, it makes sense to maintain a clear division between pieces written in one language vs. another, so that you can know without looking what some chunk is written in by what it does. Ferexample (say) the alien races' AI could be in Python while the graphics and physics are in C++, or what have you. I often claim Rule Number One of game programming is Always Make Sense (I have several rules, all of them interchangeably Rule Number One -- that's one of them).
Opinions vary and it's you guys' project, not mine, of course, but For What It's Worth™, I wouldn't attempt anything but C++ for at least the game engine. C++ lets you hammer on the machine as hard as you want without imposing hidden overheads, or at least many of them, and it lets you be as elegant as you want with object-oriented tricks while still being able to be shoved out of the way when you want to brute-force something. Sometimes, it Makes Sense to grab the address of something and start doing pointer arithmetic, and it'll happily let you get away with it. You can look at a simple section of C++ code and get a pretty good idea of what it'll translate to in assembly and how many clock cycles it'll take to run; when dealing with entities as small and numerous as pixels, shaving the nanoseconds will add up quickly. To go even farther, there are still occasions when it comes time to drop down into actual assembly (though they are ever smaller and farther between); unless you like fiddling with stack frames, you can just let the compiler deal with all the stuff, throw in the #asm keyword, then step back up into C++ when you're done and let the compiler pop your stuff and handle the return. I don't know of another language that's worthwhile for this sort of thing that'll let you do that (there may well be some, but nothing I'm familiar with).
(Ferinstance, the landscape surface in this image:
2.4 MB 1680x1050 .pngis 2049x2049 vertices times four bytes per vertex, so what you see is a shade over 16 MB. There's a source buffer, a destination buffer, and a transposition buffer for over 48 MB total. Using pointer arithmetic, it's generated, scaled, clipped, transposed, and gets a 3-pass render in about 2200 ms, far faster than what 2-dimensional array notation yields with the same compiler settings. I hate being second-guessed by the compiler. The ~4000 ms time given in the caption was for an older computer, 2200 ms is on a core 2 2.6 GHz machine.)
With the flexibility and power of C++ comes the ability to screw up so spectacularly that people will put up billboards around the resulting crater. It will blithely let you get yourself in trouble to a degree unmatched by almost any other language. It's kind of like driving a Ferrari or something; sure, you'll cross the finish line way ahead of the people in Hyundais, if you don't turn yourself into a red mist because you weren't paying attention. A big project like a game can be really tricky to keep in line if you're the slightest bit careless, and that's one of the biggest arguments people have against C++. The bottom line is that the people who write the thing have to live with it, and ya gotta go with what you know. However, there's a reason why C++ libraries are always the first (and often the only) ones available for any game platform. That's been true since the original Playstation and it remains that way, and it's not simply inertia on the part of those in charge. In the last 18 years, I've never worked on a game that wasn't primarily C++ (or straight C, before C++ got popular and widely supported). Given the changing nature and loose hierarchy of a project that survives on volunteer effort such as this one, I'd caution against even somewhat esoteric dialects like Objective C because you could wake up one morning with nobody who knows how to deal with some of the code. It made sense for Quake 2, but it doesn't here.
Oh yeah -- Rule Number Two says that Rule Number One takes precedence over all other rules. Rule Number Three says you should comment the crap out of your code (someday, the poor stupid sumbich trying to figure out what your code does may just be
you), and Rule Number Four claims you need to null your pointers after you free them, not before. Rule Number Five tells us not to test if something == TRUE, test for !(FALSE) instead. You can go on as long as you want with things like these as long as you
Always
Make
Sense™.
Um, lastly, I can't promise anything, but I'm between gigs at the moment and I'd love to see what you've got. (I've got Visual Studio Professional 2005 and the 2010 beta -- what do you build with?) I'm not going to tell anybody what to do or anything (this not my dojo), but I could make a stab at pointing out any obvious holes and it might be fun to pound out a chunk or two if it'd help at all. I've started looking for work and when I find it I'll have to bail out suddenly so I can't make any kind of meaningful commitment, but this could be an insanely cool game if you can pull it off and with a little luck I might be able to not screw up too badly if I can't actually accomplish anything. Should I post in the programmer applications thread even though I can't claim to be applying, given that I could be hired too soon to contribute anything real? Like I said, I'm a C++ head so if you decide to take a different direction I'd be of decidedly limited usefulness. Thanx, and let me know -
