12 ms·

Games are still in need of a better language. I have some skepticism and hope for Jai. I really wish D as better C worked better in that realm, but it's missing

by Bekwnn 8y ago

Games are still in need of a better language. I have some skepticism and hope for Jai. I really wish D as better C worked better in that realm, but it's missing a few crucial things. Rust asserts too much control over memory. I'm all ears for anything that's somewhere between C and C++ as an alternative to write games in. Most new languages just don't get the things right that C++ did, which is why despite it having a ton of deficiencies when it comes to game development, it's still what everyone in AAA is using. Companies in AAA spend so much money on software to even just somewhat improve places where C++ has gaping flaws. A better language should have been developed by now and I don't even want to think about how much money C++ has cost the industry as a whole, even just purely on iteration speed.

redahs 8y ago
Use regular C, but write the code in literate programming files which can be rendered into a portable design document describing the implementation and interaction of every subsystem in the codebase. 'Standard written English' is the best language available for modeling abstractions.
- tdsamardzhiev 8y ago
  Do you happen to know any open-source games that do this?
AnIdiotOnTheNet 8y ago
I was almost like OP for a while. Working on game, fed up with existing languages (even C), wanted a better C. I was excited about Jai, but as time goes on I'm finding it looks less and less what I want from a language. Seriously considered making my own. Then I started working with Zig[0]. It's about 90% the language I want and even though it's still immature and the syntax, std lib, and semantics are in flux, I still find the quality of life improvement so huge that all my current projects are in Zig. Zig is a better C to Jai's better C++, I think. It's a small language, it favors simplicity and explicitness, it has entirely manual memory management to the point that there isn't even a default allocator (we pass one in to anything that requires one). It even lets you import C headers directly to interface with C libraries. [0] https://ziglang.org/ https://ziglang.org/ (skip the "stable" 2.0 download, it's way out of date from master)
- annywhey 8y ago
  Zig is on my "must follow" list right now. It's still early enough in the going that I don't want to maintain code in it, but it's developing in a promising direction and making the kind of commitments that are reasonable to keep. A lot of language devs want to play with semantics but aren't into the whole "let's do the hard work of actually getting off of C as the baseline" idea so it's nice to have a project that does and has a fairly explicit goal of absorbing and replacing the existing infrastructure step by step.
- ndh2 8y ago
  Zig is Linux-first, though. I don't think they have any dev who runs Windows. For games especially, you don't want Windows to be an afterthought. Maybe they'll get to it eventually, but it doesn't seem a priority.
  - AnIdiotOnTheNet 8y ago
    I pretty much exclusively dev on Windows, and the only thing that's a problem for me is the lack of error and assert traces. Someone started implementing the support for it, but never finished it. It is complicated by the fact that Microsoft does not distribute DIA with Windows and Zig can't include it in its own distribution.
  - Bjartr 8y ago
    I expect this is a side effect of it being early in development.
- Bekwnn 8y ago
  Thanks I'll check it out. First glance looks promising.
Razengan 8y ago
> Games are still in need of a better language. I find Swift to be the best so far, its strong ties to the Apple ecosystem notwithstanding. Having tinkered with various environments since the Sinclair Spectrum's BASIC (though back then I had no idea what I was doing) I've successively fallen in love with Visual Basic (6.0, not the .NET impostor) and then C#, and now I'm smitten with Swift. In Microsoft land I was let down by their usual dichotomies that did not allow you full access to all their APIs (or hardware performance) from anything but C++ (though I did manage to make playable DirectX games in VB6). I don't know how that has changed in the last decade since I jumped ship to Apple, but .NET was treated as a second-class citizen for too long. With Swift, not only do I have access to everything that Apple's operating systems offer, it's also a modern language which feels naturally suited to game design patterns. Although until Swift 2 I often had to fight the language, since Swift 3 and especially now in Swift 4.2 I find it effortless to reason about most game architectures while sticking to the language's idioms. I also appreciate it for enforcing good practices and getting rid of most sources of ambiguity (such as the ++/-- operators and the legacy `for` syntax, or being specific about %/modulo and so on), even if it may feel annoying in the beginning if you're coming from "looser" languages. It also compiles to native code and can easily interop with C [0], but best of all: I am glad to be able to finally leave semicolons behind. C# honestly feels archaic in comparison now. As for the elephant in the room – that Swift is only good for iOS, macOS, tvOS and watchOS – well, those platforms have a combined userbase of over a billion users, and the most successful app market [1]; I don't feel that it's such a downside to be limited to those platforms. I do wish that the Apple TV came with a proper gamepad so we could only target that without losing users. It could be a serious contender to existing game consoles if Apple took that route. If you're in love with Swift too, I'm writing an open-source game engine which offers an Entity-Component-System architecture on top of Apple's APIs [2]. [0] https://theswiftdev.com/2018/01/15/how-to-call-c-code-from-swift/ https://theswiftdev.com/2018/01/15/how-to-call-c-code-from-s... [1] https://www.google.com/search?Apple+App+Store+payouts https://www.google.com/search?Apple+App+Store+payouts [2] https://github.com/invadingoctopus/octopuskit https://github.com/invadingoctopus/octopuskit
- pjmlp 8y ago
  With UWP and .NET Native, .NET (C#/VB) is as first class as C++. To the point the Windows UI team does all their graphics demos in C#.
tdsamardzhiev 8y ago
The AAA company I work for has tried everything possible to work around C++, and let me tell you, had they not started any such efforts, they'd have been way better off. Seeing the results of it all makes me super sceptical of any C++-killers.
- seventhtiger 8y ago
  Pure OOP is a poor fit for implementing games, but it's a fine base to build a entity-component-system layer on top of which is excellent for games.
  - je42 8y ago
    C++ is not pure OOP. you can write functional stuff quite well. the more recent C++ standard you are willing/are able to adopt the better it gets ;) C++17 is quite awesome.
    - pjmlp 8y ago
      Yep, one can even go Haskell like crazy if one feels like to. The only nagging point is the copy-paste compatibility with C. :\
nicwilson 8y ago
> I really wish D as better C worked better in that realm, but it's missing a few crucial things. Such as? We are always looking for for things that get in the way of use.
- Bekwnn 8y ago
  Under "unavailable features" https://dlang.org/spec/betterc.html#consequences https://dlang.org/spec/betterc.html#consequences 3, 4, and 5 are all pretty sore points. 2 would be as well if it weren't extremely likely that for any game you create roll some sort of reflection system. It would be a sore spot for small projects. 3 - No access to classes and polymorphism is a bit of a downer. Although I'm a big believer of data-oriented design, I think there are still many cases where modelling things as objects is the best way to go, especially for things like scene actors and game objects. 4 - No built in threading (core.thread) puts a hamper on any sort of distributed updating or performance optimizations you'd want to do. I'd imagine the workaround is external multi-threaded dlls or something, but it sounds like a pain to manage and deal with in a workflow. 5 - No dynamic arrays. This container is used abundantly in game development. It shows up 5 or more times for every heap/stack/queue. This may not be an issue if you want to write a special memory environment and your own containers, which is common in game development, but not having access to a standard one certainly hurts when it comes to smaller projects or graphics programming experiments. I may be somewhat off base here since what happened is that I read about those being missing and decided not to try it. Another note is that a big thing I'm looking for is massively improved compile times, which is one of the biggest things Jai looks to have over C++ in addition to its compiler hooks and #run.
  - FeepingCreature 8y ago
    It seems to me like you should just be using D, not "Better C-style D"? All those features are not in BetterC because they need a garbage collector, but they are of course in D proper. For smaller projects, I'd recommend just ignoring the GC until you run into actual issues with it, then optimizing for the specific issues.
    - 8y ago
hzhou321 8y ago
Here is a direction if you are all ears : instead of a new language, add a new layer. I tried creating my own languages before, some 15 years ago. While I had fun writing compilers, I missed a lot more writing actual programs. One day I suddenly realized I don't really need new language, what I needed is simply context dependent syntax and code block organization, which can easily implemented on the spot. It become MyDef and I have been programing with it entirely for more than 10 years now and wondering how others don't go down the same path. Actually in a broad sense, Knuth's literate programing adventure is very similar to mine. He also wondered how others were not as excited as he was. So rather than a new language, try a new dimension.
- dajomu 8y ago
  This sounds really interesting, can you provide a link so I can read some more about it?
  - akuji1993 8y ago
    This seems to be the Github repository for it: https://github.com/hzhou/MyDef https://github.com/hzhou/MyDef
- humanrebar 8y ago
  How is MyDef not another language?
  - hzhou321 8y ago
    Because when using MyDef, you are still thinking in the end language -- how the function, variable, type, stack works are all defined by the end language. With MyDef, you are just changing the way of expressing them -- just like giving creatures different clothes, but they are not new creatures. Here is a short example: page: test, basic_frame module: c $local int A[3] $for i=0:3 A[i] = i $dump A[0], A[1], A[2] Despite the look, if you know c, you recognize it as c. And as you get familiar, you see it exactly as C. `basic_frame` is merely a custom template so one doesn't have to always write the main function signature. $for is shorthand for `for-loop`, `$dump` is simply printf with simple type translations. Now that you had this meta layer, there is no limit on how you want to dress up your code. Examples: $local A[3]: int $sumcode(3) A[i]=i+3 $foreach A $dump $(t) or page: test, basic_frame $call declare $call init $call report subcode: declare $local pn_A[3] = {1, 2, 3} subcode: init $foreach pn_A $(t) = $(t)^2 subcode: report $(set:print_to=stderr) $foreach pn_A $print "%d: %d", $(i), $(t) There are lots of idioms and conventions, but it is not a problem as long as you recognize them only as clothing. Lastly, when dressing up the code makes little sense or you simply don't know better way of dressing them, you can simply write vanila C (or any languages that you are writing). MyDef never tried to compile your language.
WalterBright 8y ago
> I really wish D as better C worked better in that realm, but it's missing a few crucial things. Like ?
moopsit 8y ago
I feel like with languages (in games or anything else), it all boils down to "where there's a will, there's a way". People come up with a lot of reasons Language X won't be suitable for a project, but in the end it's the people who use whatever tools are at hand, who get the job done while the perfectionists are stuck at the starting line. Classic Tortoise vs. Hare situation. If you want to write games, use your favorite language, and just START. All limitations can be circumvented somehow.

by Bekwnn 8y ago

redahs 8y ago

Use regular C, but write the code in literate programming files which can be rendered into a portable design document describing the implementation and interaction of every subsystem in the codebase. 'Standard written English' is the best language available for modeling abstractions.

tdsamardzhiev 8y ago
Do you happen to know any open-source games that do this?

AnIdiotOnTheNet 8y ago

I was almost like OP for a while. Working on game, fed up with existing languages (even C), wanted a better C. I was excited about Jai, but as time goes on I'm finding it looks less and less what I want from a language. Seriously considered making my own. Then I started working with Zig[0]. It's about 90% the language I want and even though it's still immature and the syntax, std lib, and semantics are in flux, I still find the quality of life improvement so huge that all my current projects are in Zig. Zig is a better C to Jai's better C++, I think. It's a small language, it favors simplicity and explicitness, it has entirely manual memory management to the point that there isn't even a default allocator (we pass one in to anything that requires one). It even lets you import C headers directly to interface with C libraries. [0] https://ziglang.org/ https://ziglang.org/ (skip the "stable" 2.0 download, it's way out of date from master)

annywhey 8y ago
Zig is on my "must follow" list right now. It's still early enough in the going that I don't want to maintain code in it, but it's developing in a promising direction and making the kind of commitments that are reasonable to keep. A lot of language devs want to play with semantics but aren't into the whole "let's do the hard work of actually getting off of C as the baseline" idea so it's nice to have a project that does and has a fairly explicit goal of absorbing and replacing the existing infrastructure step by step.
ndh2 8y ago
Zig is Linux-first, though. I don't think they have any dev who runs Windows. For games especially, you don't want Windows to be an afterthought. Maybe they'll get to it eventually, but it doesn't seem a priority.
- AnIdiotOnTheNet 8y ago
  I pretty much exclusively dev on Windows, and the only thing that's a problem for me is the lack of error and assert traces. Someone started implementing the support for it, but never finished it. It is complicated by the fact that Microsoft does not distribute DIA with Windows and Zig can't include it in its own distribution.
- Bjartr 8y ago
  I expect this is a side effect of it being early in development.
Bekwnn 8y ago
Thanks I'll check it out. First glance looks promising.

Razengan 8y ago

> Games are still in need of a better language. I find Swift to be the best so far, its strong ties to the Apple ecosystem notwithstanding. Having tinkered with various environments since the Sinclair Spectrum's BASIC (though back then I had no idea what I was doing) I've successively fallen in love with Visual Basic (6.0, not the .NET impostor) and then C#, and now I'm smitten with Swift. In Microsoft land I was let down by their usual dichotomies that did not allow you full access to all their APIs (or hardware performance) from anything but C++ (though I did manage to make playable DirectX games in VB6). I don't know how that has changed in the last decade since I jumped ship to Apple, but .NET was treated as a second-class citizen for too long. With Swift, not only do I have access to everything that Apple's operating systems offer, it's also a modern language which feels naturally suited to game design patterns. Although until Swift 2 I often had to fight the language, since Swift 3 and especially now in Swift 4.2 I find it effortless to reason about most game architectures while sticking to the language's idioms. I also appreciate it for enforcing good practices and getting rid of most sources of ambiguity (such as the ++/-- operators and the legacy `for` syntax, or being specific about %/modulo and so on), even if it may feel annoying in the beginning if you're coming from "looser" languages. It also compiles to native code and can easily interop with C [0], but best of all: I am glad to be able to finally leave semicolons behind. C# honestly feels archaic in comparison now. As for the elephant in the room – that Swift is only good for iOS, macOS, tvOS and watchOS – well, those platforms have a combined userbase of over a billion users, and the most successful app market [1]; I don't feel that it's such a downside to be limited to those platforms. I do wish that the Apple TV came with a proper gamepad so we could only target that without losing users. It could be a serious contender to existing game consoles if Apple took that route. If you're in love with Swift too, I'm writing an open-source game engine which offers an Entity-Component-System architecture on top of Apple's APIs [2]. [0] https://theswiftdev.com/2018/01/15/how-to-call-c-code-from-swift/ https://theswiftdev.com/2018/01/15/how-to-call-c-code-from-s... [1] https://www.google.com/search?Apple+App+Store+payouts https://www.google.com/search?Apple+App+Store+payouts [2] https://github.com/invadingoctopus/octopuskit https://github.com/invadingoctopus/octopuskit

pjmlp 8y ago
With UWP and .NET Native, .NET (C#/VB) is as first class as C++. To the point the Windows UI team does all their graphics demos in C#.

tdsamardzhiev 8y ago

The AAA company I work for has tried everything possible to work around C++, and let me tell you, had they not started any such efforts, they'd have been way better off. Seeing the results of it all makes me super sceptical of any C++-killers.

seventhtiger 8y ago
Pure OOP is a poor fit for implementing games, but it's a fine base to build a entity-component-system layer on top of which is excellent for games.
- je42 8y ago
  C++ is not pure OOP. you can write functional stuff quite well. the more recent C++ standard you are willing/are able to adopt the better it gets ;) C++17 is quite awesome.
  - pjmlp 8y ago
    Yep, one can even go Haskell like crazy if one feels like to. The only nagging point is the copy-paste compatibility with C. :\

nicwilson 8y ago

> I really wish D as better C worked better in that realm, but it's missing a few crucial things. Such as? We are always looking for for things that get in the way of use.

Bekwnn 8y ago
Under "unavailable features" https://dlang.org/spec/betterc.html#consequences https://dlang.org/spec/betterc.html#consequences 3, 4, and 5 are all pretty sore points. 2 would be as well if it weren't extremely likely that for any game you create roll some sort of reflection system. It would be a sore spot for small projects. 3 - No access to classes and polymorphism is a bit of a downer. Although I'm a big believer of data-oriented design, I think there are still many cases where modelling things as objects is the best way to go, especially for things like scene actors and game objects. 4 - No built in threading (core.thread) puts a hamper on any sort of distributed updating or performance optimizations you'd want to do. I'd imagine the workaround is external multi-threaded dlls or something, but it sounds like a pain to manage and deal with in a workflow. 5 - No dynamic arrays. This container is used abundantly in game development. It shows up 5 or more times for every heap/stack/queue. This may not be an issue if you want to write a special memory environment and your own containers, which is common in game development, but not having access to a standard one certainly hurts when it comes to smaller projects or graphics programming experiments. I may be somewhat off base here since what happened is that I read about those being missing and decided not to try it. Another note is that a big thing I'm looking for is massively improved compile times, which is one of the biggest things Jai looks to have over C++ in addition to its compiler hooks and #run.
- FeepingCreature 8y ago
  It seems to me like you should just be using D, not "Better C-style D"? All those features are not in BetterC because they need a garbage collector, but they are of course in D proper. For smaller projects, I'd recommend just ignoring the GC until you run into actual issues with it, then optimizing for the specific issues.
  - 8y ago

hzhou321 8y ago

Here is a direction if you are all ears : instead of a new language, add a new layer. I tried creating my own languages before, some 15 years ago. While I had fun writing compilers, I missed a lot more writing actual programs. One day I suddenly realized I don't really need new language, what I needed is simply context dependent syntax and code block organization, which can easily implemented on the spot. It become MyDef and I have been programing with it entirely for more than 10 years now and wondering how others don't go down the same path. Actually in a broad sense, Knuth's literate programing adventure is very similar to mine. He also wondered how others were not as excited as he was. So rather than a new language, try a new dimension.

dajomu 8y ago
This sounds really interesting, can you provide a link so I can read some more about it?
- akuji1993 8y ago
  This seems to be the Github repository for it: https://github.com/hzhou/MyDef https://github.com/hzhou/MyDef
humanrebar 8y ago
How is MyDef not another language?
- hzhou321 8y ago
  Because when using MyDef, you are still thinking in the end language -- how the function, variable, type, stack works are all defined by the end language. With MyDef, you are just changing the way of expressing them -- just like giving creatures different clothes, but they are not new creatures. Here is a short example: page: test, basic_frame module: c $local int A[3] $for i=0:3 A[i] = i $dump A[0], A[1], A[2] Despite the look, if you know c, you recognize it as c. And as you get familiar, you see it exactly as C. `basic_frame` is merely a custom template so one doesn't have to always write the main function signature. $for is shorthand for `for-loop`, `$dump` is simply printf with simple type translations. Now that you had this meta layer, there is no limit on how you want to dress up your code. Examples: $local A[3]: int $sumcode(3) A[i]=i+3 $foreach A $dump $(t) or page: test, basic_frame $call declare $call init $call report subcode: declare $local pn_A[3] = {1, 2, 3} subcode: init $foreach pn_A $(t) = $(t)^2 subcode: report $(set:print_to=stderr) $foreach pn_A $print "%d: %d", $(i), $(t) There are lots of idioms and conventions, but it is not a problem as long as you recognize them only as clothing. Lastly, when dressing up the code makes little sense or you simply don't know better way of dressing them, you can simply write vanila C (or any languages that you are writing). MyDef never tried to compile your language.

WalterBright 8y ago

> I really wish D as better C worked better in that realm, but it's missing a few crucial things. Like ?

moopsit 8y ago

I feel like with languages (in games or anything else), it all boils down to "where there's a will, there's a way". People come up with a lot of reasons Language X won't be suitable for a project, but in the end it's the people who use whatever tools are at hand, who get the job done while the perfectionists are stuck at the starting line. Classic Tortoise vs. Hare situation. If you want to write games, use your favorite language, and just START. All limitations can be circumvented somehow.