Gamedev with GLMakie (the path less taken). Is it possible?

New to Julia
, ,
1

I was looking for a programming language which I could call home, and after some analysis, I found Julia to suit my taste (Nim was a close second).
I would like to make games in this language. I looked at some packages, and liked the GLMakie backend (GLFW package is also an option). I know its mostly for plotting and visualisation, and I know I would encounter challenges. I am okay with that. But I want to know, is there anything stopping it from being used as a graphics backend for my game? Or should I choose Nim instead for gamedev?

Also, how would distributing the game look like in this case?

2 Likes
2

You might be interested in this project: I Created a 2D Platformer With Julia! (Download link) + An Update On JulGame. Note also on that page the links to a potential upcoming Julia Jam which could be nice to meet other like-minded people.

That being said, it really depends on what your aim is for game development.

If you want to have fun with a new language and are happy if the result is something unique but very limited. Then you can have fun with Julia (and probably the same with Nim). Make sure to have a very small game idea and keep it realistic. It’s much more fun to make a small 2D geometry racer rather than failing at a 3D game.

However, Julia is not a practical choice at the moment for game development. Games require a lot of tools (IO, sound, graphics, content, design, …) and there are not many game dev-specific tools available in Julia.

Nim seems a bit easier in that regard, as it is closer to C/C++ and hence you get more direct access to some libraries like SDL2 etc.

Something like C++ or directly the language related to a gaming engine (Gadot, Unreal Engine, etc) would allow you to make more impressive games.

As you said you look for a language to call home. Learning a statically compiled language (Nim, C++, Zig, …) is a good base, also for understanding Julia.

For distributing: There is PackageCompiler.jl for making a binary, but for this to work the Julia code needs to be designed from the beginning to be sufficiently compatible. It is possible, but not nearly as easy as in a compiled language.

1 Like
3

I have made little games in C++ too. And I know Nim is a more practical choice due to seamless integration with SDL. But the thing is, I fell in love with Lisp (but sadly S-expressions are not a thing in this modern world anymore). And Julia is the closest to Lisp (especially when it comes to macros and REPL driven development, correct me if I am wrong).
If I go with Nim, I give all of that up. I would have to work with AST manipulating macros of Nim, no dynamic dispatch, no REPL driven experience (though it does have a very nice syntax). I will figure out the tooling along the way. I will find projects I can build those tools upon (like I found GLMakie, and I just started exploring Julia today). Yes, compiling binary is a pain. I could not get SDL2 binding for Julia to compile. But I will figure it out, and Julia team is working on the compiler bit and smaller binaries, and I think they will figure it out too.
I appreciate your feedback and the link is also helpful. But I might give Julia a serious try before I move on.

3 Likes
4

I just want to point out there is a game engine for Common Lisp:

Which is more than Julia can offer currently I think.

1 Like
5

Yes, I have looked at trial too. Since Common Lisp is fading and Julia is rising, I thought I would go with Julia. But I think Lisp would be practical in this case because of optimised binaries and a full fledged game library. I think I would go with trial only. Thanks

EDIT: Actually, I would still stick to Julia. I think multiple dispatch is a feature that I would be using quite a lot. Plus, I like the tooling of Julia much better than ancient tooling of Common Lisp.

1 Like
6

GitHub - ashwani-rathee/Miner.jl: Voxel World Simulator written with Makie in Julia is a basic Minecraft-esque game made with GLMakie - not sure if something like this is what you’re looking for!

Generally, only the positions and textures of objects would be passed to the graphical backend, and it would be annoying to synchronize per-frame computations for example.

4 Likes
7

Thanks! Oh I didn’t know only the positions and textures would be passed. I don’t know a lot about how to use GLMakie, and looks like there is no documentation for it?
If thats the case, I would just use SDL and GLFW.

8

It’s an option, as shown by (the currently marked solution, though I dare say it’s the wrong option, and better available even in Julia for games; for plots, maybe nothing as good in any language), and I see in the docs:

Add one or more of the Makie backend packages GLMakie.jl (OpenGL), CairoMakie.jl (Cairo), or WGLMakie.jl (WebGL), RPRMakie (RadeonProRender)

[All of those support 3D, even CairoMakie, and RPRMakie ray-tracing. You may want that and OpenGL possibly, or its successor Vulkan.]

Possibly. Nim was on my short-list of interesting languages before I discovered Julia. It does have a possible advantage over Julia. Julia is garbage collected, and that choice is usually great. There are ways around it, as you want for real-time (still until we have real-time GC, as exists in e.g. Java). I don’t know for sure if GC pauses are a real problem if soft-realtime (as for games) is the goal.

Nim is used for audio, and audio is very latency-intolerant (why you want no GC, and thus Nim is good since it has such an option). You can play audio with Julia, and at least one solution to playing files does fork a new process to play it, so Julia’s GC isn’t involved, but it’s also not very elegant to do. GLMakie doesn’t handle any audio that I know of, since it’s a plotting/visualization library after all. There’s at least one recent 3D game engine in Julia, and two or more 2D game engines. Nim might have more or better, or integrate better with e.g. from C++.

I believe this B+ game engine may be the future for Julia, but I can’t yet try it:

(@v1.10) pkg> add https://github.com/heyx3/B-plus

You can add some of its subprojects, that are already registered, such as this (and BplusCore it adds):

(@v1.10) pkg> add BplusApp

that depends on GLFW and CImGui.

another option is GitHub - AliceRoselia/Nebula.jl: An ambitious game engine leveraging rich Julia ecosystem not sure why I can’t install it:

An ambitious game engine leveraging rich Julia ecosystem, inspired by Gamezero.jl and Starlight.jl in its pre-pre-pre-alpha stage.

[…]
The author believes that it is time for game developers to abandon the old scripted ways of game development and embrace the new paradigm of game development.
[…]
To achieve this ambition, this library leverages several libraries in the Julia ecosystem.

  • Leveraging the Julia’s ModelingToolkit ecosystem, game developers can make their own physics system easily!
  • With help from Julia’s GPU ecosystem, GPGPU compute rendering offers the flexibility of software rendering without sacrificing hardware power!
  • High performance simulation of entities/particle/etc leveraging Julia’s HPC ecosystem.
  • Juliaaudio ecosystem for audio processing and more!
  • To control entities, Julia offers an ECS of your choice such as OverSeer, a powerful ECS system!
  • When it comes to AI, Flux and Alphazero.jl come to mind!

and JulGame.jl is another option (games already made with, 3D coming later), and:

(@v1.10) pkg> add Starlight
[..]
⌅ [98e33af6] ↓ SimpleDirectMediaLayer v0.4.0 ⇒ v0.3.0

may be good already (but has no activity for 2 years):

Features of the default backend, Telescope, include:

If you have a 2D game in mind, then most any software could do, even Python, since it’s usually not too demanding. If you have 3D in mind, or advanced features, or mobile, then you really need to think carefully if Julia is the best option. It probably isn’t yet, but may get there.

You can likely call all Nim libraries (as opposed to reusing Nim frameworks for sure), and I count 18 projects across 4 categories, and I can tell you we’re far behind what is claimed there:

Game Libraries

  • nimgl - NimGL is a Nim library that offers bindings for popular libraries used in computer graphics.
  • glm - Port of the popular glm C++ library to Nim.
  • GLAD - Multi-Language Vulkan/GL/GLES/EGL/GLX/WGL Loader-Generator based on the official specs.
  • enu - 3D live coding with a Logo-like DSL for Godot, implemented in Nim.

Game Frameworks

  • […]
  • naylib - safe Raylib wrapper.
  • c4 - Modular and extensible 2D and 3D game framework for Nim.
  • paranim - A game library based around carefully chosen abstractions.

Game Engines

  • NimForUE - Nim plugin for UE5 with native performance, hot reloading and full interop that sits between C++ and Blueprints.
  • […]
  • godot-nim - Nim bindings for Godot Engine.
  • […]

Rules Engines

  • turn_based_game - A game rules engine for simulating or playing turn-based games.
  • pararules - A RETE-based rules engine made for games.
1 Like