what will become the "industry standard"?
Author
im just curious. what will be the "industry standard", most widely used language for games, in about a decade or two? right now its c++, but it cant stay the most popular, right?im guessing c# or maybe java, but im no professional. state your opinions please.
It's impossible to predict. We can't even say what games will look like in 10 years: will it all be online, directly input into our brains, there will be no more games b/c the conquering aliens think games are bad...
Otherwise there's no inherent reason that C++ won't stay king. 99% of our codebase is C or C++ so that's a lot of inertia.
-me
Otherwise there's no inherent reason that C++ won't stay king. 99% of our codebase is C or C++ so that's a lot of inertia.
-me
My understanding is that C has a particular advantage that endears itself to console game developers; it's dead easy to write a compiler for. Hence when a new console is developed with a new fangled architecture a most likely first compiler for the platform (after pure assembly) will be C. C also has the advantage that you control when and where you allocate the memory, which is important for consoles.
Hence I think console development (with the exception of the Microsoft systems) will still have a low level language bias for quite some time.
Hence I think console development (with the exception of the Microsoft systems) will still have a low level language bias for quite some time.
Why are you asking this question? Are you trying to decide what language to learn?
If so, it doesn't really matter. All procedural languages work from the same set of concepts, the only difference is in implementation. After learning C++, I have been able to become competent at any other language I've needed to within a matter of days (mastery, on the other hand, takes time).
If you're asking just to see what we "think" will happen, I "think" the next step in languages will be a cross-platform evolution of C#, which in turn was an evolution of Java. Within 10 years, I "think" C++ will become somewhat dated for game development.
If so, it doesn't really matter. All procedural languages work from the same set of concepts, the only difference is in implementation. After learning C++, I have been able to become competent at any other language I've needed to within a matter of days (mastery, on the other hand, takes time).
If you're asking just to see what we "think" will happen, I "think" the next step in languages will be a cross-platform evolution of C#, which in turn was an evolution of Java. Within 10 years, I "think" C++ will become somewhat dated for game development.
I think functional programming will take over for multithreaded joy and we'll finally get most of the goobers out of computer science.
Then again, I am hilariously underequipped to predict future trends in the industry. Something about that tunnel vision.
Then again, I am hilariously underequipped to predict future trends in the industry. Something about that tunnel vision.
Whatever language is best tailored to console game development will become industry standard. So far there's nothing besides Assembly, C, and C++ that fulfills the ridiculous demands that game developers put on the language.
I use C# a lot in desktop development since I can get away with it, and I wish that I could professionally develop for consoles in it, but it just won't happen until console developers get that low-level control (memory, forced inlining, inline assembly, etc) they need to compete with other companies who will keep using C++.
XNA is exciting because it opens up that R&D phase where we find out how much we can push a modern console using a newer language without any low-level control (on the application side anyway. I guess you could optimize the hell out of your framework implementation).
I use C# a lot in desktop development since I can get away with it, and I wish that I could professionally develop for consoles in it, but it just won't happen until console developers get that low-level control (memory, forced inlining, inline assembly, etc) they need to compete with other companies who will keep using C++.
XNA is exciting because it opens up that R&D phase where we find out how much we can push a modern console using a newer language without any low-level control (on the application side anyway. I guess you could optimize the hell out of your framework implementation).
Quote:Original post by JBourrie
If you're asking just to see what we "think" will happen, I "think" the next step in languages will be a cross-platform evolution of C#, which in turn was an evolution of Java. Within 10 years, I "think" C++ will become somewhat dated for game development.
I think I agree with this. For the most part, all languages so far have been getting bested by other languages for whatever different purposes. C++ has taken a while, but I think it will happen sometime.
And yes, C# seems like the next step in the line for games, then something better will come. Languages look to me like they are getting higher level and taking work off of the developer, though sacrificing some speed in the process usually. For example, assembly is the fastest, the superman of speed, but you have to write a lot of code to actually get something done. Look at C, no classes, but still much less complex than assembly. C++ added classes, which made it easier to organize code into actual objects hence OOP. But with C/C++, we still have to maintain our own memory. Java and C# have come along, and by using garbage collection and other things, our life as programmers should be getting easier since we don't have to manage things as much as we used to. The sacrifice is of course speed. Now obviously, some will say the speed difference isn't much, which may be true. And C#/Java have their advantages. Also, computer hardware is progressing so much that the little speed differnce won't matter, but the speed of development will matter all the same, so languages like C# will probably replace C++ over time. Probably, something else will be invented and replace that too.
Whooh, sorry for the long lecture, maybe it will be useful to someone.
The prevailing attitude, on these forums and among many game programmers, is that C++ is here to stay for a long time to come. But I think all it will take is one AAA breakout hit whose developers proclaim, "we didn't use C++" or "we only used a tiny bit for performance" and the C++ era will be over.
Language goes hand-in-hand with other large-scale software design decisions. The idea of having a scripting language, distinct from the "core engine," is there because it's perceived as easier to do some things with a second language that has different properties - not because it's faster.
If you were to move things up another step, it might be, instead of moving over to a VM language like C# or Java, to put more of the engine into the scripting language; if you were using (for example) Python, one might start the engine, control the main loop, and describe game entities inside Python, using it as the host, while the heaviest number-crunching operations of collision, rendering, pathfinding, etc., are called into C code.
This may sound a little unfeasible, and on last-gen consoles with the available software technology of five years ago, it probably was. Python is approximately 22 times as slow as C, if you believe the Programming Shootout and take the benchmark mean. (in the worst test - recursion - it's 250 times as slow) However, great strides are being made in turning interpreted languages into self-hosting, compiling languages. For example, there are now not just one but many implementations of Scheme that compile to C. There is a version of Lua, LuaJIT, which improves the speed of Lua close(within 5-10x) to that of C# and Java. There is a VM, NekoVM, based on the idea of making language hosting an easier process with the help of a readable low-level syntax. And Python itself has a project, PyPy, which has just recently reached 1.0: it can compile a Python interpreter to C - or other languages - by running Python code; the end result is that Python will see huge optimizations in the next few years as PyPy improves.
Alternatively, one may look at how to better solve concurrency issues as we move into a multicore world. The popular trends in that area are twofold: functional programming, and multitasking languages. FP is well-known since it's been around at least since Lisp has been around. However, it doesn't seem to be a panacea, and especially not for games; games are based on changing state with every frame, whereas functional programming is based on immutable state. The end result is that you write code that looks unnatural and probably isn't optimal if you try to fit a whole game into a functional paradigm.
But multitasking languages look promising if they can get over some sticking points. The threading system used in C, and hence most places, is a blocking pre-emptive system; when Unix was designed, it was important for an operating system to share resources as equally as possible, so that processes don't run away with CPU time. Thus C threads are built to be useful for operating systems, by being focused on a "locking out the other threads" paradigm. But if you're making a game, you have no need to share in such a context, since you control the whole program - you want a more cooperative mode. But while there are many languages doing this under names like "tasklets" or "green threads," we lack for languages that use multiple cores in a cooperative context, since that is a much trickier problem than the most naive cooperative systems, which just go through a round-robin loop of code to execute. Erlang seems to be the front-runner for this; it is, in fact, being used by the MMO Vendetta Online.
Finally, the focus may shift away from AAA boundary-pushing titles if indies become prominent. In that case, all bets are off; it becomes mostly a matter of what people feel is easiest to learn and most flexible for their projects. But that probably won't be C++ either.
Language goes hand-in-hand with other large-scale software design decisions. The idea of having a scripting language, distinct from the "core engine," is there because it's perceived as easier to do some things with a second language that has different properties - not because it's faster.
If you were to move things up another step, it might be, instead of moving over to a VM language like C# or Java, to put more of the engine into the scripting language; if you were using (for example) Python, one might start the engine, control the main loop, and describe game entities inside Python, using it as the host, while the heaviest number-crunching operations of collision, rendering, pathfinding, etc., are called into C code.
This may sound a little unfeasible, and on last-gen consoles with the available software technology of five years ago, it probably was. Python is approximately 22 times as slow as C, if you believe the Programming Shootout and take the benchmark mean. (in the worst test - recursion - it's 250 times as slow) However, great strides are being made in turning interpreted languages into self-hosting, compiling languages. For example, there are now not just one but many implementations of Scheme that compile to C. There is a version of Lua, LuaJIT, which improves the speed of Lua close(within 5-10x) to that of C# and Java. There is a VM, NekoVM, based on the idea of making language hosting an easier process with the help of a readable low-level syntax. And Python itself has a project, PyPy, which has just recently reached 1.0: it can compile a Python interpreter to C - or other languages - by running Python code; the end result is that Python will see huge optimizations in the next few years as PyPy improves.
Alternatively, one may look at how to better solve concurrency issues as we move into a multicore world. The popular trends in that area are twofold: functional programming, and multitasking languages. FP is well-known since it's been around at least since Lisp has been around. However, it doesn't seem to be a panacea, and especially not for games; games are based on changing state with every frame, whereas functional programming is based on immutable state. The end result is that you write code that looks unnatural and probably isn't optimal if you try to fit a whole game into a functional paradigm.
But multitasking languages look promising if they can get over some sticking points. The threading system used in C, and hence most places, is a blocking pre-emptive system; when Unix was designed, it was important for an operating system to share resources as equally as possible, so that processes don't run away with CPU time. Thus C threads are built to be useful for operating systems, by being focused on a "locking out the other threads" paradigm. But if you're making a game, you have no need to share in such a context, since you control the whole program - you want a more cooperative mode. But while there are many languages doing this under names like "tasklets" or "green threads," we lack for languages that use multiple cores in a cooperative context, since that is a much trickier problem than the most naive cooperative systems, which just go through a round-robin loop of code to execute. Erlang seems to be the front-runner for this; it is, in fact, being used by the MMO Vendetta Online.
Finally, the focus may shift away from AAA boundary-pushing titles if indies become prominent. In that case, all bets are off; it becomes mostly a matter of what people feel is easiest to learn and most flexible for their projects. But that probably won't be C++ either.
I think c++ will still be around for some time. The future? I guess that Java/C# won't be popular in gaming, people are already sick of changing their machines so often, and it may be a question of time when gamers will draw the line. And gaming consoles are not a definite answer. Something more speed efficient will have to be developed. Probably with a multi threaded paradigm, as multi core systems seem to be something of hype right now.
I wouldn't be surprised if the industry standard became not a specific language, but something of a tool, that would strongly integrate assembly, C/C++, shading languages, and something Python-like.
The idea of indies taking over the market would be interesting though, especially combined with the free/open source movement. But who am I to tell, I'm only an aspiring game developer. :)
I wouldn't be surprised if the industry standard became not a specific language, but something of a tool, that would strongly integrate assembly, C/C++, shading languages, and something Python-like.
The idea of indies taking over the market would be interesting though, especially combined with the free/open source movement. But who am I to tell, I'm only an aspiring game developer. :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
