Skip to main content
GameDev.net gamedev.net
🔒 Locked

Help with Correct Programming Language and Graphics Library for Non-Editor Focused Game

Started by bones_94 Aug 6 at 6:12 PM 1 replies 450+ views
Original Post
bones_94
bones_94

I want to make a small procedurally generated game. An engine such as Godot, Unity, or Unreal is overkill for the project. I began to make the game using Godot with C# and found myself not enjoying the inherently OOP programming style and ultimately not using the editor much at all.

Rust

High performance and memory safety is important to me, so I naturally gravitated towards Rust. The two graphics library options seem to boil down to WGPU and various bindings like SDL3 via sdl3-sys. My issue is that I am spending more time making a wrapper and worrying about if I am managing C stuff and lifetimes than making the engine. Additionally, almost all of this wrapping code requires unsafe blocks which feels counterintuitive. I understand the mentality is to isolate and abstract the unsafe parts first so later the engine/ game code becomes purely safe Rust, but I have a lot of engine code ahead yet. Rust is also extremely verbose and difficult to work in when wrapping C libraries. This could simply be due to my lack of Rust experience.

WGPU seems great, but it doesn't seem as portable as C/C++ with SDL3. I would also need a multitude of other libraries to cover window management, audio, etc. Compile times are also slow, especially with extra large libraries. I know this from using bevy, which even with dynamic compiling (I can't remember exactly what it is called), it still left much to be desired. I know people say C++ can be slow, but I managed to get my entire, albeit small engine (~3000 LOC) that used SDL3, GLM, and a JSON library compiling in under ~1.7 seconds.

C++

Should I move back to plain C++ and SDL3-GPU? I moved away originally because I became increasingly worried about memory safety, overall language bloat, and due to readings like: https://blog.habets.se/2026/05/Everything-in-C-is-undefined-behavior.html. This article explains that even "correct" C/C++ code contains UB, possibly application or game breaking. Is this an overreaction for game development specifically?

C#

C# is an option, but I think I would have to write it in an unusual manner to avoid GC allocations/ stutters within core engine hot paths. I have also heard it can be a nightmare to port to other platforms, but that could be outdated information. I think Unity created an entire compiler for it to translate C# to C++ for that exact issue.

I know this is a long post, but I would appreciate any input from anyone with more experience. What language would be best? Should I ditch porting capabilities for Rust, a little performance for C#, safety for C++, or something else entirely?

Alberth
Alberth

FWIW, I don't agree with the linked blog post. C and by extension C++ are bare-metal languages. The basic assumption is that you know what you're doing. It gives you full control over how how it stores and computes things. By default, It warns about or refuses to do dangerous stuff, but you can always override. Obviously, overriding doesn't impress the underlying hardware, so if you override be very much aware you're not crossing the hardware limits.

Overriding default compiler limits makes "impossible" things possible in case you need it (eg control custom hardware, or eliminate a bottleneck by outsmarting the compiler). Other languages simply say "NO" and you're stuck in these cases.

So yes, you cannot blindly mix different types of pointer data, do a C-style cast between them without making sure about alignment (which C++ can assist in iirc, but I never do such magic). Shifting data in signed integers can obviously modify the sign of the integer. That's not the fault of C++ but it's how the hardware works. C++ advises to use unsigned integers for bit-manipulation. For the float to int conversion: yes, if you insist to do things "manually", there are a lot of edge cases to deal with. However, C++ library has a 'round' (and probably also a 'floor' function) out of the box: https://en.cppreference.com/cpp/numeric/math/round out of the box.


Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.