What other languages are out there that compile into machine code?
Ask HN: If C++ is so bad, what should game developers use?
81–90 of 127 posts
Re: Ask HN: If C++ is so bad, what should game developers use?
#82Re: Ask HN: If C++ is so bad, what should game developers use?
#83"C++ sucks" because it is widely used, its socio-techical landscape is well explored, including the "sucks" segment. In other words, most other languages suck as much as C++, they're just not that widely used, or have not been around as much. If you're writing your own game project you can use a sane, minimalistic and syntactically pleasing subset of C++ and gain all the pedal-to-the-metal advantages. Don't discard C…
Pragmatically, for the OP, I think it's safe to say that C++ and Haskell are both very challenging languages that take a long time to master. The advantage of C++ is that there's ample evidence of its suitability for various domains. The advantage of Haskell is that you'll learn a different way of programming. The decisive factor may be whether it's your own money on the line.
Re: Ask HN: If C++ is so bad, what should game developers use?
#84Earlier quoted context omitted.
Well, for once, it's not particulary fast, but that's not a concern for all games(it's not slow either, but it's quite hard to optimize). The real deal is that it's a completely functional language with not much support, as far as games go. You won't find any graphics libraries, so you'll have to make them from scratch. Unless you have been programing in funcitonal languages for a long time, this will take an absurd…
Functional languages are good at math. Graphics involves a lot of math.
Re: Ask HN: If C++ is so bad, what should game developers use?
#85I am under the impression that Lua is widely used for video games.
Lua is often used as an embedded scripting language within level editors, for example to keep track of the progress made on a quest or to trigger an event when the character reaches a certain point. Lua isn't used to code the game engine itself (in the vast majority of cases, there may be some obscure examples of game engines written in Lua)
Re: Ask HN: If C++ is so bad, what should game developers use?
#86Contrary to popular belief. Java is actually pretty good.
Re: Ask HN: If C++ is so bad, what should game developers use?
#87Most of the performance of a game stems from finding a sweet spot combination of data structures and data relationships so that data is processed at real-time rates, is accessible everywhere, and can be immediately applicable to the algorithms you plan to use.
If you design relationships-first, the way you would design a database, you can figure out a data layout that doesn't involve any high-level semantics to speak of, just classic data structures from CS: lists, arrays, graphs and trees to order things, records and hashes to name them. Go through each type of value and cross-index it across all the structures it needs to be accessed by.
Then write intersectable queries into the structures to express a complex gameplay question like "Find all the enemy actors that are near mission objective X" as the composable "Find positions between boundaries A,B,C,D, that belong to actors of the enemy type, where A,B,C,D are some distance relative to the position of the objective entity with the name of X." Since you aren't writing a generic all-purpose database, this isn't a hard problem. It's just time-consuming to nail down the data model that captures all of it.
I think you will agree that a fancy language isn't necessary to implement such an approach to game programming. Done that way, data mostly ends up being pointers.
If your game is processing-light(which with today's desktop hardware primarily means avoiding 3d computation), you don't need a fast language: I'm most familiar with doing game code for Python and Flash and they can do just fine on modestly-sized datasets too.
Re: Ask HN: If C++ is so bad, what should game developers use?
#88Earlier quoted context omitted.
Language X is fine if you use what you need and take the time to actually understand the tools you're using. You can justify using any language by saying that. Such a vague statement.
Precisely ! That's kind of the point, isn't it? I use the languages that I am most familiar with, because I am far more effective with them than I am with whatever this year's new awesome language is. If I had been doing Ruby from the beginning, then I should continue doing Ruby, and not use C++ just because someone else says so. Likewise, if I've been doing C++ for as long, it doesn't make sense for me to switch to…
Using your example languages. I can think of situations where using C++ rather than Ruby would be idiotic, and likewise situations where the reverse is true.
Re: Ask HN: If C++ is so bad, what should game developers use?
#89Earlier quoted context omitted.
The complexity is "baroque" because, in modern times, we've invented ways around it. Type inference would kill half of the pain involved in C++ without sacrificing performance. Cleaning up the syntax enough that definitions could be found context-free would eliminate the need for declarations, and in most cases .h/hpp files. The complexity is redundant because they included features of C that they should have depreca…
Type-inference is needed in C++ (and is already part of the next standard, you can enable the auto keyword with gnu gcc already). But it's needed for entirely different purposes than what scripting languages use it for: it's a feature for writing better templates. It's confusing because there are two types of type-inference (run-time and compile-time). You do lose performance with run-time type-inference, which is wh…
As long as it also had C syntax, and something close to the C memory model, and was recognizably object oriented and/or functional. And came with a lot of libraries. And 3D graphics engines. And physics engines.
Unless some independent game developer does something in a new language that other developers can't easily duplicate with their current ecosystem (not that it couldn't be done in C++), and it catches on, there's no incentive to do anything other than continue to evolve things in the most backwards compatible way. There are always more C++ programmers coming off the assembly lines who want nothing more than to work on games.