The game industry suffers from the two-culture problem as game designers want high-level languages and game programmers want performant languages. C++ is common for game development today. Is the time ready to create a game development ecosystem in Julia?
If it is, what are the strengths and weaknesses of Julia? What niche should we explore first to capitalize on Julia’s strength? Optimistically, can we be greedy with game development too? Can we list what we want in a game/game engine?
Realistically, no. (Betteridge strikes again 
)
While there are FOSS games, and some of them are quite good, modern games are usually for-profit, commonly sold on a distribution platform like Steam. This requires coding the game in some framework (eg Unity once, mostly, then deploying on Windows, Mac, various game consoles, and (hopefully) Linux.
Julia does not offer anything special here: while some games can be computationally heavy, this kind of computation (graphics, 3D modeling) is at this point well-understood and mature. But it comes with some significant disadvantages, eg the difficulty of creating self-contained executables.
This is not to say that writing a game in Julia is impossible. But most of the time this will be done because the authors are already familiar with Julia, not because it is the best tool for the job.
I do not think Betteridge applies here, as this is a forum where people ask questions, and not a news source that is dodging accountability preventively.
I kinda agree with Tamas, but it depends on the game. Indie games that are not resource intensive and do not need a lot of graphic resources are probably viable. However, these games are not often the ones that need a whole other language for scripting so the “advanced developers” get the engine working and “script storytellers” just write the in-game events using the script language.
I’ve never done anything like game programming, but my understanding is it requires a lot of high level tools in addition to efficient code to be successful. So even if Julia was the indisputable master of speed across all hardware and algorithms, there would need to be years of working on user interfaces and product testing to become successful.
That doesn’t mean you can’t do smaller projects that might get some traction for hobbyists, but I’m just not sure how this is possible without millions of dollars being poured into every year.
To clarify, who said it’s gonna be easy?
I’m asking if we could create a game engine/etc to get Julia ready for game development.
We’re greedy! We want more!
I’m not trying to discourage anyone. I just assume that a lot of the work you’d have to do in developing a game engine is more about creating and interface for developers like Unity or Unreal have. People are definitely doing some interesting things that are relevant to gaming in a way but I wouldn’t say it’s going to make it to the game industry without the crow pleasing GUIs. I’m pretty sure I’ve seen stuff with ray tracing somewhere for example.
Maybe what we need is the ability to make the GUIs more easily because we have tons of direct GPU compiler work, geometric modeling, and other stuff being developed already for other applications.
Just to preface, I’ll be a bit of a downer for the most part but end on a hopeful note.
The faulty premise of your post is that this is a 2 language problem in game development. There’s more than 2 languages, and it’s not really a problem. Game developers don’t do the same things as game engine programmers, so they will not want to use the same tools. For example, you probably don’t want to be writing lines of code to build a video game level, you’d want a realtime rendering GUI. Many game engines allow developers to make whole indie games without touching code. The 2 language problem is about the awkwardness of using >=2 languages to do 1 thing; it was not about wanting 1 language to do everything, and nobody seriously wants that.
The other thing is that there isn’t a need for Julia to replace gaming languages right now, and it’s not really ready to. Precompilation, for the same use as AOT compilation in other languages, is still developing. Garbage collection (GC) cycles cause noticeable drops in frame rates, something that the Unity game engine grapples with, and while Julia has great tools to avoid heap allocation (people please use Accessors.jl more, it has a lot of potential), there aren’t good options for when you really need to allocate frequently.
All that said, I think people should absolutely try to make a game engine in Julia, or even just parts of one. The developments can be applied to so many other things, not just games: 3D modeling, GPU rendering, sound editing, music, soft real-time controls. Even without the expectation of supplanting today’s game engines, more work on these sort of tools greatly benefits the language and the ecosystem. All those problems I mentioned earlier were identified because people didn’t wait to try Julia in new areas.
I actually disagree with this pretty hard. The claim could be very slightly reworded to be about scientists or whatever and it may sound convincing, but it’s not true.
Game developers want to be writing high level code right up until the moment that becomes inappropriate and they need to reach into some internals, customize something, or bypass some slow code.
Having language barriers between those two professions is an impediment to this.
Of course, that’s not to say that it’d be easy or appropriate to slot julia into modern game dev, but I also don’t really see how the problems with julia’s large binaries or JIT latency would be a problem in a modern video game where you’d presumably precompile everything that’s performance sensitive.
I’d say the two languages problem often manifest itself in a subtle way, Games nowadays have good cosmetics because they can be utilized using no code, high-level code, or high-level c++ API, things like ray-tracing for example. However, take away the flashy cosmetics and the abstract representation of the game is usually crude hitboxes floating or dancing around. Rarely would there be a game logic involving millions of entities/etc… For these, high-performance simulation need to be accessible to game designers and it’d be a great win if Julia can make such a tool.
I’ve been casually trying to learn more about the GC and I think we could eventually get to the point where we have a lot more control over this. I think we could figure out a way to have custom schedulers and backends for the allocated data but there’s a lot going on with its development so i don’t know how likely any of this is at the moment (@mkitti and I have been bringing this sort of stuff up on github). I started doing a little mini garbage collector using a block of data from Libc.malloc.
Given the general attitude of core developers in Julia I’d think it’s reasonable that at some point someone presents a really cool well thought out idea for making allocation management more extensible and it follows a similar development path that our native compiler has.
I havea feeling that the GC will go modular soon. There are active forks with alternative garbage collectors out there.
Is that project intended to be a stepping stone to modularity or is it just an example. I’m not a part of the GC dev so I don’t know anything but what’s right in front of me
It seems like you’re talking about scripting languages, which I do agree that it’d be nice if those were also usable for the performant code. But coding is only one aspect of game development, and programmers only make up a fraction of the team. Granted, the roles that aren’t chiefly programmers often also code, but engines seem to be moving toward visual scripting for them. Some roles wouldn’t write code at all, though their tools would use software coded in some language.
Binary size overhead is negligible except for more limited hardware like a GBA. Presumably the JIT compiler would be omitted in the application because people want the loaded program memory to stay at a fixed size.
Do you have an example in mind? I could only imagine N-body simulations rather than the things the player would control directly, and that code would likely not be in the high level script to begin with.
RTS/RPG games? The more entities, you can support, the better.
Games with real physics simulation involving millions of particles? Minecraft was good because the world is buildable and destructible. What about higher resolution?
It is not just about doing what is currently being done, but about opening up new opportunities. I said that “it is rarely being done”.
Games do limit how much they render at a time around the player for performance. I know Minecraft has a render distance in blocks so I assume it renders the cube of that at a time. Bedrock has a maximum of 96 so the cube is under a million. There are mods for increasing that distance but obviously it requires more RAM to load your world.
But static blocks are also a lot easier to handle than entities that are moved independently. The example that came to my mind is cutting things into pieces in Metal Gear Rising: Revengeance, and the game starts lagging badly at a couple hundred pieces (though it’s possible the game is making up the displayed number rather than actually counting). Bear in mind these pieces aren’t just point particles, but generated models with hundreds to thousands of polygons. I’m not sure how switching languages would help things like that, it just seems like hardware limits.
Rendering or simulating? Rendering something is a whole bag of worm. I wonder if the current rendering system based on triangle meshes is still the way to go. Regardless, simulating things is different from rendering things.
I have no idea. It’s an independent effort, as far as I can understand. RelationalAI has some interest in this as far as I know.
Hey @Tarny_GG_Channie , just throwing my opinions into the ring here, it has long been on my mind about making some very simple sprite-type dungeon crawler games within Julia that could be a lot of fun. There have been a couple different attempts at this:
Additionally, if you are at all curious about creating dungeon maps, you could take a look at my blog post here about the marching squares algorithm to use as a foundation for building fun maps. Perhaps in contradiction to other folks here, I think making simple games within Julia could be great. You could also take a look at Luxor.jl for inspiration and perhaps even Javis.jl for ideas about animations. Happy to share more but I encourage this idea with of course the caveats mentioned previously!
~ tcp 
Only tangentially related but veloren is cool. It’s a game written in Rust and entirely open-source, so you can start the game with just:
cargo run
and it will compile and launch an entire 3D RPG… the only other dependency is cmake (on macOS).
Surely a direction to strive for
My first thought is shader compilation stutter: Shader Compilation and Why It Causes Stuttering, Explained | TechSpot
Gamers already suffer through stutters: I’m Sick and Tired of Shader Compilation Stutters.
And that have similar root cause with TTFX, games JIT compile DX12/Vulkan shader and although it takes only several milliseconds, it causes perceivable stutter. Julia have several second compilation time, gamers will definitely leave thumb down reviews in Steam review.
Unless Julia precompilation story is much better than now, which is what games do these days to solve the compilation stutter: Hi-Fi Rush is proof that Unreal Engine games can be gloriously stutter-free | PC Gamer