| I've actually done a fair amount of thinking (and even a little implementation) on this topic so I'll share my thoughts. I've come to the conclusion that my ideal 'game programming' language would actually be 3 different languages that are tightly coupled. It would consist of the following: - A low level language, similar to c/c++/d - A scripting language that is tightly coupled with the low level language. - A scripting preprocessor that's run as a preprocessor for the low level language (effectively replacing templates and the C preprocessor) Low Level Language: Games need to be fast, that's why they're written in C or C++. At the end of the day, when you're trying to squeeze those extra cycles out of your console, you need to be able to have precise control over how your data structures are arranged in memory, how things get copied around, what data is preloaded into the cache, etc. It's okay for this language to be garbage collected, but the programmer needs to have full control over the garbage collector, ideally the garbage collector is of a variety that doesn't require stop-the-world collection. You'd probably also want manual memory management to be an option. Scripting Language: In game development, having a low-cost for iteration is also extremely important. If it takes your game designers 20 minutes to tweak something simple, the end product is likely not going to be very good. This is where scripting languages come in, you load all your resources (textures, models, etc) and then you iterate on the game logic without having to load everything from scratch. Loading can actually eat a very large portion of your development time if you don't have hot-reload or your game logic doesn't exist in script. By tightly integrated I mean make the two languages intimately aware of each other's details. They each need to know how the other is storing data, it needs to be _simple_ (as in just a keyword simple) to call into and out of one from the other. This way the way they communicate can be fast, and a lot of the process can be automated by the compiler so you don't have to do it by hand. A cool thing here would be having the ability to compile the scripting language to assembly or the low level language when it's time to lock things down for ship. Scripting Preprocessor: Embedding scripting languages into lower level languages can be a bit of a pain. In C++, you have a code generator do it, you use templates, or you do it by hand. Templates are way too complicated for what they accomplish (code gen), the preprocessor is usually used in the same way (code gen). If you're not using these two methods to generate code you've probably written a code generator in an external scripting language that's parsing your C/C++ (yuck) and spitting out C/C++. What we need is a preprocessor that is actually a scripting language in its own right. The scripting preprocessor gets run before the low level compiler, and just spits out code in the low level language. You have to jump through hoops to 'loop' or 'if' with templates, it's about time we gave ourselves a fully featured language to do our meta-programming in. |
Strangely, IMO, I find most of my fellow gamedevs are not PLgeeks.