It’s a fact that C++ has been the most successful and probably the most widely used programming language till date in the gaming industry. Even if you were to look at the software industry as a whole, a near countless software projects owe their existence to the language and probably many more will eventually be made using C++. Universities around the world still churn out thousands of CS grads with C++ knowledge and there will be no shortage of programmers who know C++, at least for some time to come. So why is C++ so popular? The reasons may be many (, I am sure there are other near infinite blogs which touch on this,) but at the end of the day it just boils down to the simple fact, “it gets the job done”! While it made good business sense to employ C++ (some years ago), it doesn’t make all that much sense when we consider scalability looking into the future. C++ in it’s current form is — well, simply inadequate. Most people will agree with me that C++ has probably outlived it’s time, and it was time the programming community as a whole moved away from the language. Easier said than done though, but the question to ask is, what real options do we have which provide radical new changes to the way C++ operates? Very few approaches I would say. Before you raise your hand and give out the name of <insert your favourite language here>, let’s look at some of the challenges facing future game development and/or rather future software development as a whole.
Lets first look at the C++ language itself. It’s well known that C++ has it’s faults. It’s not an easy language to learn and an even more difficult language to master (, compared to other languages). It takes a substantial amount of time and experience to understand the intricacies of the language and takes even more time and effort to fully grasp the quirks and subtleties involved in software creation using C++. Typically it takes quite a lot of time before an average programmer can become truly productive with C++. The learning curve for the language is high and not for the faint hearted. Besides this the language has increasing come under flak for allowing seemingly undefined behavior without complaining too much. The language does very little to deter flawed assumptions regarding some (very) basic constructs that contradict how things actually work. Even with proper planning, strict development cycles and stringent coding practises, software development using C++ is difficult. Memory management is a bane and can cause unexpected and unwarranted catastrophes which are known all too well in the industry.
There are a growing number of languages that address the shortcomings of C++. Be it Java, C#, Python or most new(er) languages, all try to fill in the gaps left out in C++. As a matter of fact most languages do a good job at it. However with all it’s faults, C++ still stands out as a viable game development choice. That’s because of 2 primary reasons; a) it has vastly more libraries, code dumps (, I am talking about game development only), engines, examples and everything really, that it simply wins over the argument right there. True many libraries have bindings to other languages, but most of them seem rather inadequate or poorly maintained. Besides there are a lot more examples on cutting edge technologies (,especially graphics) written in C++ than there are in all other languages put together. and b) It’s easier to get programmers for C++ than any other programming language, Java being the exception. Things are changing though and there are some concerted efforts being made to promote other languages and platforms (XNA, PyGame) as viable game development alternatives. However all those remain some distance away from challenging C++ for the number one position.
The above mentioned points in support of C++ are non trivial. They go a long way in weighing out the demerits of building a game using the language. So the question really is, do we really have any viable options beyond C++? The answer is somewhere in between a complete YES and a total NO. As we stand today the best scenario is probably building the core engine using C++ and then having a scripting system on top of it. Be it Lua, Squirrel, Python, or whatever. That way you can always find a middle ground between having to reuse existing code and at the same time allow rapid development and prototyping capabilities. Many engines/games take this route and there is little doubt that such a process proves to be advantageous in the game building process. There are already a lot of games out there that use scripting language for rapid prototyping and in some cases building large sections of the game. Having a scripting language on top of the engine core is clearly a step in the right direction.
Scripting languages solve but some of the problems. They do a part of the job and they do it pretty well. However, there are issues related to game development which require newer and more radical approaches. The challenge facing game development in the future is building an engine which can effectively and efficiently use parallel programming/computing techniques (Invasion of the multi-core machines). Current generation programming techniques fall short of addressing the issue effectively. More importantly most newer approaches to effectively address multi-core problem are just way too complicated to be implemented effectively in C++. Efforts are on to find radical new solutions (C++ STM), but thus far they look good only on paper and still seem too cryptic to be put in production use. The issue of effectively using multiple cores of a CPU will probably be the biggest challenge for the next generation engine designer. The more natural choice for addressing the multi-core and parallel programming issue is the the use of functional programming languages. Since functional programming approaches are typically side effects free, parallelizing functional programming code is easier than imperative programming. However mixing functional and imperative styles can be an equally daunting task. As my argument in the above paragraphs suggest, there will still be a lot of code in C++ that will need, someway, of interacting with any functional language that may be used.
It’s debatable if going “strictly functional” will solve all the challenges the future will throw at us. A more plausible scenario would be to have specific portions of the engine/game parallelized either by using a functional language or by having a subsystem level parallelism. This obviously would allow existing (C/C++) code to be reused, however there are still challenges to overcome even with such approaches. Sub-system parallelism means having each subsystem (physics, renderer, logic, AI, sound, network…) run in a separate thread/s. This however is a very optimistic approach since sub-systems tend to overlap and in some cases critically depend on each other. Such a system could be achived with existing code also, however I remain very skeptical whether such an approach will actually work on the ground. Another approach is to have job based parallelism. Divide your most CPU intensive tasks into jobs and then have a kernel system to marshal them based on priority. This is something similar to what an OS does and seems the best way to shoot for parallelism with existing mechanisms. This approach however requires you to split your design into a job based approach and that could prove challenging. Having a functional language as a script system (on top of a C/C++ based engine) is another idea to think about. I am not really sure how helpful this would be and can’t really comment on this (, since I myself haven’t tried such a radical approach, maybe I ought to give it a shot). But it seems very much possible to have a functional language as a scripting system, and could in theory be used to parallelize sections of the game/engine.
So it would seem C++ might just survive in the game engine of tomorrow, although in a less prominent form compared to it’s position today. It may happen that over the years C++ may eventually fade out, however it’s part can’t be total ruled out. Transition from C++ to any other language will be slow and may be tumultuous, with teams opting for a hybrid approach than just downright building existing functionality from scratch. As new technologies progress and CPUs with 100s of cores start being commonplace, we sould see the popularity of C++ waning and been replaced by some other (maybe functional) language. As time progresses C++ might well become increasingly irrelevant as more and more libraries get promoted to newer and more modern languages or newer more efficient ones take their place.