5 ms·

There's two big hindrances for success right off the bat: 1. Refusing to just use C/C++ 2. Attempting to support most of the platforms Both problems compound

There's two big hindrances for success right off the bat: 1. Refusing to just use C/C++ 2. Attempting to support most of the platforms Both problems compound each other. All platforms (even Android at this point) have C APIs for everything you need. Creating another layer of abstraction here causes more work and overhead. Trying to get Java running on iOS with 3D APIs is a huge task in and of itself. The same goes for C# (a task which Unity does for you). Languages that require JIT for performance don't work on mobile (unless supplied by the OS, e.g. JavaScriptCore). Debugging becomes extra-difficult. C/C++ are not convenient to use, but not hard to use either. It causes discomfort at first, but you get used to it. Being forced to do memory management manually also helps with learning how to structure programs, with a bonus of not having to wrestle GC pauses. Having said all that, using a commercial engine is totally fine, of course.

dakics 9y ago
Unity's multi-platform track record is quite solid at this point in time. I wouldn't bet on exotic Java attempts of "write once run everywhere" though.
- kuschku 9y ago
  Java is actually not that bad – Java with LWJGL gets you within a factor of 1.6 to C++ performance, while actually being "write once run everywhere" (for PC, at least). That’s good enough.
  - treehau5 9y ago
    there's actually a pretty serious niche of us Go game developers growing as well
    - pjmlp 9y ago
      I look forward to it.
  - karmadog 9y ago
    Maybe on a Hotspot VM with JIT, while using frivolous amounts of memory for good GC performance. You're not allowed to do JIT on consoles or mobile and you're memory constrained. A PC-only game engine is going to be a tough sell these days. Also, unless you're bundling a JVM (not sure about the legals here) you have to make your Windows (i.e. primary) customers install the obnoxious Oracle Java runtime.
- thehardsphere 9y ago
  Yes, the track record is often negative if you want to make action games on not-Windows because of GC pauses caused by Mono's inferior garbage collector. As for Java, Notch managed to do it for Minecraft, except for the mobile port which I think I remember reading was re-written from scratch on iOS because the performance was terrible.
Koshkin 9y ago
> Being forced to do memory management manually It may be worth repeating that in C++ the need to manually manage memory is drastically reduced compared with C (due to the native support of the RAII pattern).
davexunit 9y ago
I refuse to use C/C++. If that's what I have to use to make games, I just won't make games. Fortunately, there are other languages available with a C FFI. I don't think forced memory management teaches anyone much of anything besides how to manage memory manually. It doesn't make programs better. I'm very grateful for garbage collection so that I can spend my cycles thinking about the problem I'm actually trying to solve. edit: I think this came off a bit too dismissive, but I guess what I was after is that what technology you choose depends on what you value. Personally, I value using programming languages that are pleasant to work with, and I don't personally find C/C++ to be pleasant. I enjoy dabbling in game development, but it's not so important to me that I would use tools that I don't like to do it.
- emsy 9y ago
  >what technology you choose depends on what you value No, what technology you choose depends first and foremost on what you want to achieve. If you want a to run a realtime application on as many platforms and devices as possible with steady fps, a GC language is not the technlogy you can use. In contrast, you can write web applications in almost any language with little technical differences. That's the point where you can start to make a value assessment. >It doesn't make programs better Yes it does. With a GC you lose control over runtime, which is crucial to the performance. I'm not advocating against GC in general. Many desktop apps, most web apps and low-tech games can be fine with it. But saying manual memory management is outdated, when our 4 GHz Multicore machines struggle to run smoothly is ridiculous.
  - davexunit 9y ago
    >No, what technology you choose depends first and foremost on what you want to achieve. Maybe for you. But not for me. I find the rest of your post to be very mean spirited. I don't work in the games industry because those constraints sound miserable.
- z3phyr 9y ago
  Used to have a hard time with C, but after working with it for some time you might get to appreciate what computers do more. I oddly find C pleasing, and choose it to solve many problems by default.
pjmlp 9y ago
1. Refusing to just use Assembly. Was the reply we got in the old days, when one used C, Pascal, Basic, Amos. Thankfully many ignored that and moved the state of art to such languages. A few years later the reply would be, 1. Refused to use C When devs tried to use C++ or Delphi. State of the art in games development only advances thanks to those that manage to produce entertaining games, while ignoring such advices.
- karmadog 9y ago
  Game developers used Assembly to write games when it was the best tool for the job. They then moved to C when it was feasible and then to C++ when that was feasible. For their engines, they never moved on to anything else, because there still is no better tool for the job, all things (tooling, SDKs, platform support) considered. Unity, Unreal Engine and CryEngine are all written in C/C++. They have sometimes elaborate script bindings, but the engine remains in C/C++. There's a lot of people leaving college that have never learned how to use C/C++ and immediately they want something they're comfortable with, which is Java/C# or Javascript or maybe even Python. These languages are not good choices for a game engine, for the reasons I mentioned. Will there never be a better language? I did not say that, but it would be an uphill battle.
  - pjmlp 9y ago
    Usually game developers changed language when the OS or game console's SDK release forced them to do so. > These languages are not good choices for a game engine I have seen these words written against C, Turbo Pascal, Modula-2, C++. Some of the games I saw "written" in C for MS-DOS were like this all over the place: void my_func(void) { asm { /* 100% of my_func actual code */ } } Just as if C was a macro assembler.
    - karmadog 9y ago
      SDKs never forced anybody to move to C or C++, but the opposite is true: C/C++ compilers were either unavailable or limited. "I have seen these words written against C, Turbo Pascal, Modula-2, C++." So what? Those words probably had a good argument behind them, at the time. In the MS-DOS days, compilers weren't as good as today, so handwritten ASM paid off.

dakics 9y ago

Unity's multi-platform track record is quite solid at this point in time. I wouldn't bet on exotic Java attempts of "write once run everywhere" though.

kuschku 9y ago
Java is actually not that bad – Java with LWJGL gets you within a factor of 1.6 to C++ performance, while actually being "write once run everywhere" (for PC, at least). That’s good enough.
- treehau5 9y ago
  there's actually a pretty serious niche of us Go game developers growing as well
  - pjmlp 9y ago
    I look forward to it.
- karmadog 9y ago
  Maybe on a Hotspot VM with JIT, while using frivolous amounts of memory for good GC performance. You're not allowed to do JIT on consoles or mobile and you're memory constrained. A PC-only game engine is going to be a tough sell these days. Also, unless you're bundling a JVM (not sure about the legals here) you have to make your Windows (i.e. primary) customers install the obnoxious Oracle Java runtime.
thehardsphere 9y ago
Yes, the track record is often negative if you want to make action games on not-Windows because of GC pauses caused by Mono's inferior garbage collector. As for Java, Notch managed to do it for Minecraft, except for the mobile port which I think I remember reading was re-written from scratch on iOS because the performance was terrible.

Koshkin 9y ago

> Being forced to do memory management manually It may be worth repeating that in C++ the need to manually manage memory is drastically reduced compared with C (due to the native support of the RAII pattern).

davexunit 9y ago

I refuse to use C/C++. If that's what I have to use to make games, I just won't make games. Fortunately, there are other languages available with a C FFI. I don't think forced memory management teaches anyone much of anything besides how to manage memory manually. It doesn't make programs better. I'm very grateful for garbage collection so that I can spend my cycles thinking about the problem I'm actually trying to solve. edit: I think this came off a bit too dismissive, but I guess what I was after is that what technology you choose depends on what you value. Personally, I value using programming languages that are pleasant to work with, and I don't personally find C/C++ to be pleasant. I enjoy dabbling in game development, but it's not so important to me that I would use tools that I don't like to do it.

emsy 9y ago
>what technology you choose depends on what you value No, what technology you choose depends first and foremost on what you want to achieve. If you want a to run a realtime application on as many platforms and devices as possible with steady fps, a GC language is not the technlogy you can use. In contrast, you can write web applications in almost any language with little technical differences. That's the point where you can start to make a value assessment. >It doesn't make programs better Yes it does. With a GC you lose control over runtime, which is crucial to the performance. I'm not advocating against GC in general. Many desktop apps, most web apps and low-tech games can be fine with it. But saying manual memory management is outdated, when our 4 GHz Multicore machines struggle to run smoothly is ridiculous.
- davexunit 9y ago
  >No, what technology you choose depends first and foremost on what you want to achieve. Maybe for you. But not for me. I find the rest of your post to be very mean spirited. I don't work in the games industry because those constraints sound miserable.
z3phyr 9y ago
Used to have a hard time with C, but after working with it for some time you might get to appreciate what computers do more. I oddly find C pleasing, and choose it to solve many problems by default.

pjmlp 9y ago

1. Refusing to just use Assembly. Was the reply we got in the old days, when one used C, Pascal, Basic, Amos. Thankfully many ignored that and moved the state of art to such languages. A few years later the reply would be, 1. Refused to use C When devs tried to use C++ or Delphi. State of the art in games development only advances thanks to those that manage to produce entertaining games, while ignoring such advices.

karmadog 9y ago
Game developers used Assembly to write games when it was the best tool for the job. They then moved to C when it was feasible and then to C++ when that was feasible. For their engines, they never moved on to anything else, because there still is no better tool for the job, all things (tooling, SDKs, platform support) considered. Unity, Unreal Engine and CryEngine are all written in C/C++. They have sometimes elaborate script bindings, but the engine remains in C/C++. There's a lot of people leaving college that have never learned how to use C/C++ and immediately they want something they're comfortable with, which is Java/C# or Javascript or maybe even Python. These languages are not good choices for a game engine, for the reasons I mentioned. Will there never be a better language? I did not say that, but it would be an uphill battle.
- pjmlp 9y ago
  Usually game developers changed language when the OS or game console's SDK release forced them to do so. > These languages are not good choices for a game engine I have seen these words written against C, Turbo Pascal, Modula-2, C++. Some of the games I saw "written" in C for MS-DOS were like this all over the place: void my_func(void) { asm { /* 100% of my_func actual code */ } } Just as if C was a macro assembler.
  - karmadog 9y ago
    SDKs never forced anybody to move to C or C++, but the opposite is true: C/C++ compilers were either unavailable or limited. "I have seen these words written against C, Turbo Pascal, Modula-2, C++." So what? Those words probably had a good argument behind them, at the time. In the MS-DOS days, compilers weren't as good as today, so handwritten ASM paid off.