"we have been using Unity for the past three months."
Ew.
this post was submitted on 29 Apr 2025
80 points (93.5% liked)
Programming
20613 readers
59 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
"I regularly use AI to learn new technologies, discuss methods and techniques, review code, etc. "
Ew!
Nah AI can be extremely useful for learning technologies. You just need to be careful to verify they aren't bullshitting you.
For example find an explanation of PPM compression that is concrete and simple. As far as I can tell it doesn't exist.
But I could ask ChatGPT and it told me how it works (probably) in just a few seconds. I haven't verified yet (at a BBQ) whether it is the correct algorithm but it's certainly a plausible one that would work.
It told me that you use a trie (typically) of symbol prefixes to record the probability of the following symbols, so for example you know that for the prefix "Th" the probability of "e" is 90%. Then you encode the symbol with arithmetic coding using the modelled probabilities. Apparently the typical max context length is 4-6.
That would have taken me hours to find by reading code and ancient papers but I can verify it a lot quicker.
Using the term "discuss" is just creepy. It's a piece of software. Do people actually think they're conversing when they use an LLM?
what are you on about, it's literally a chatbot.
They're fanatics
This is luddite behavior. AI can be a very valuable tool for learning unless you're working with some truly exotic shit (in which case pray to RAG to save you)
This was a great blog post. I love Rust and Bevy, but I can definitely see why you made the switch.
The primary issue with your decision to use Rust/Bevy, for me, was that you were taking on the task of getting others to work in a difficult language for novice developers. I would never suggest Rust as someone's first language, coupling that with a regularly-changing library like Bevy.
I would love to know what the pros and cons were between Unity and Godot. If you were going to switch to C# anyway, Godot seems like the next logic choice to me, so I'm curious about what your team's evaluation was for that engine.
Not here to doubt their decision, they had good reasons to switch.
For the sake of discussion though, would it have been easier though if they had focused more on abstractions with their code architecture? I haven't done any serious projects in Rust, but those issues with low-level coding and API thrash seem like more of a code architecture problem. Like, that example of a function signature seems like they should have bundled up their paperdoll logic more into a single "PaperdollLoadout" struct and moved that into a separate game logic function separate from the view related code. It's more code to write, but that's the up-front cost of strict type checking.
Modding and learning definitely seem like a big barrier for Bevy overall though.
One decision i will question is picking Unity over Godot, though maybe they were still reeling from the learning issues on Bevy.
Quick google search points out this blog post for tips and tricks for prototyping stuff like game features in Rust: https://corrode.dev/blog/prototyping/
Definitely something that I'm going to try when I have to time to get back into Rust. Probably good advice for most people who are unhappy with Rust. Being attracted by Rust's unique optimization tools too early on seems like a big beginner trap.
I'm really impressed with the management of this project. Using rust isn't more important than the game itself.
This reminds me a lot of LogLog Games doing the same thing this time last year. It also talks about similar issues and goes pretty deep into normal Rust responses.
Reads okay for the most part. But I like how we see the same point about AI as a feature in some more serious real-life projects. There, we frame it as "Rust makes it harder for a 'contributor' to sneak in LLM-generated crap".
In what situation are you accepting contributions that you haven't vetted thoroughly enough to detect crap code? I've seen a lot of crap from developers that's as bad or worse than LLM generated crap so there's no way I'll ever accept contributions to an important system without thoroughly vetting them unless they're from one of a very few number of people I trust implicitly.
if nothing else it should be easier with rust because:
a) That fucking syntax is probably more legible to an AI than a human (sue me, Rust absolutists)
b) The language has more safety barriers; making use of AI safer by association
I agree about the rust gui situation highlighted in a few of the comments here. It's tough to make it work in a truly native-feeling, rust-idiomatic way with the frameworks out there.
If you want a language with memory safety features, I can recommend D. GC pauses are negligible if you don't go above a certain memory size and 60Hz, otherwise you also can do manual memory management if you're experienced enough with that, especially if you're willing to learn an alternative runtime (might require you to write C bindings or your own libraries).
Limiting framerate to 60hz? In [current year]??
Because I absolutely NEED 144 Hz in my turn-based strategy game.
If you're writing a small indie game, or a quick prototype, then you could do much worse
YO; extremely rare D mention
I discovered digitalmars back in the very early days; it's been on my watchlist for over 15+ years now
Welcome GC pauses :) I wonder how do those manifests in real life.
Games might be an area where it isn't too bad since you can disable the GC while doing all your physics and graphics, and then just after you've dispatched a frame trigger a GC with a hard time limit.
I don't know if Unity works like that but it should.
I don't think that's even possible - to have that much control over GC engine that is.
It definitely is.
It's not trivial as it seems. See https://github.com/dotnet/runtime/issues/37667 and enhancement that happened only in .NET 8.
Interesting. From the sounds of it Unity added their own API for it though.
There are plenty of games made with C# and Unity.
You surely played a few of them, let's be honest.
So, if you're asking this question, I guess the answer is: "you don't even realize it's happening"...
Rust marketing; since Rust has became popular, GC became a problem, out of no where, and segfaults became the most terrible bug a software can be afflicted with.
If C# and Unity are working well for them, good for them.
TBH I almost don't play games and I'm genuinely curious whether GC pauses are noticeable. And not only Rust, there is Swift as well.
C# uses ref counting, which has much less impact on that. I do however use D for my game engine, which some say is infamous for its GC pauses, but they only happen if you allocate with the GC itself, and otherwise if you work work the GC, you can get some performance gains compared to dumb manual memory management, but not so much if you actually can manage your own memory, or write your own automatic memory management system, like I did on top of numem. Otherwise the pauses are negligible for smaller projects, and some of the larger projects like The Art of Reflection uses GC only for loading assets, with my engine also going in that direction.
Um, no, C# most definitely uses GC, not ref counting, and you can't not use it.
Ref counting is still GC...
I don't think so. Ref counting is a counter associated with the object which counts references to it and when it becomes ~~null~~ 0, object is destroyed. Hence ref counting. While GC does graph traversal to find which objects can be reached and marks unreachable ones as candidates for destroying.