Comment by mjr00
9 months ago
In my experience, fundamentally when you're starting a software project, you need to make a strong up-front decision between two things:
1. I am using technology in order to build this thing.
2. I am building this thing in order to use this technology.
Developers often fall in the (2) camp but don't admit it. There's an allure to using the new, sexy tech that will solve all their problems, whether that's Rust, Kubernetes, LLMs, etc.
If you're in the (1) camp, you should stick with what you know; and if you know that what you know isn't enough to build the thing, you should use whatever is most common and straightforward, not something off the beaten path.
Games seem to be the biggest trap, because solo devs often end up building a game engine when they set out to build a game. If you really want to build a game, just use Unity/Unreal/Godot, I promise it'll go better for you.
I know rust, I don't know game development (I've dabbled slightly). If I choose to build a game I either need to make it work in rust* or I need to learn a new language (Unity -> C#, Unreal -> blueprints, Godot -> gdscript).
So your advice to "just use Unity/Unreal/Godot" is the opposite of your advice "you should stick with what you know" in my case. I suspect the former is good advice, and the latter is therefore wrong.
* For the sake of argument, we can pretend I only know rust. In reality I know a fair number of other languages as well, but the list doesn't happen to include C# or "random game engine specific scripting language", which seems to be the options if we're going with an established engine for big 3d games.
This falls in the "you know that what you know isn't enough to build the thing" bucket, presumably. Even if you're a Rust expert, do you know how to manage game asset content pipelines? Sound and music? Have you done graphics programming at all in Rust? How are you going to store levels in your game, and how are you going to make them? How are you doing multiplayer? etc...
You're going to have to learn something new, and it's a bit of a judgment call, but picking up C# or gdscript given that you already know programming should be straightforward compared to re-implementing all of those things yourself in Rust.
Unless, of course, you do know a bunch of great Rust game development libraries that solve all those problems--in which case yeah, building a game in Rust might be the best choice. It's not impossible!
> but picking up C# or gdscript given that you already know programming should be straightforward compared to re-implementing all of those things yourself in Rust.
Right, this is practically my point. I suspect that the tools available from those languages mean that learning one of them would more than pay for itself in the course of developing a (single) game. Many many times over really.
Like, yes, I've dealt with both sound, basic graphics programming (though I'd need to learn a bit more to make a modern looking 3d game), networking, ... in rust. If I had to program my sound system and graphics engine from scratch myself I'd do it in rust (and I believe I'd be more productive in rust than I'd be in <other language> while doing so). But I don't have to do everything from scratch, and the best not-from-scratch versions aren't in rust, and the cost of switching to something I don't know just isn't that high.
Also OP is definitely right that rust has some anti-features that would be pain points for game development.
Perhaps the more appropriate advice is : Use the right tool for the job.
Use C++ for writing a high performance library or a database engine.
Use Go or Java for writing a server.
Use C for writing a kernel module.
Use shell scripts for automation.
Use python for trying out ML ideas or heavier duty scripts.
Use Rust for ... I'm not quite sure what it's the right tool for yet. I suspect it's trying to become the right tool for all of the above and not succeeding much in practice.
> a high performance library or a database engine
> a server
Rust is a great tool for these. The focus on performance and reliability (versus fast iteration) is a perfect fit for these domains specifically.
1 reply →
Use Rust if crashes or memory bugs are not an option. For everything wasm, Rust is much more pleasant with good libraries than the competition.
2 replies →
It's C++ replacement just not yet there for game dev (maybe never for game dev)
6 replies →
Learning a new language is basically trivial relative to the effort of bootstrapping everything yourself to compensate for a lacking ecosystem, or the effort of banging your head against the fundamental unsuitability of a tool for a job.
Anyone who's learned one or two languages should be able to pick up the basics of any of the standard ones pretty much instantaneously.
Exactly
When all you have is a hammer, everything looks like a nail. When all you have is programming expertise, all your game production obstacles look like programming problems.
I think everyone in games has met an “engine person” who spends a lot of time iterating on tech, but never quite getting to the creative expression that got them in the game. I think part of it comes a bit from mythologizing breakthrough games like DOOM, where cool technology made something completely fresh. We begin to think that emulating id Software is how you make compelling art, ignoring the latter half of Kushner’s novel.
Well said, I am weary of all the 'game' programmers that just fetishize working on the tech and particularly rendering.
People like to program on tasks that aren't given to them, to practice their craft in a less restricted form than professional life usually allows. So they make things for themselves and its natural that those things are what they are familiar with and enjoy. So you often meet the programmer, almost never from the game industry, who wants to make his or her own game engine. It's about as likely to be a productive endeavor as making your own spreadsheet program.
> you need to make a strong up-front decision
Can one always realistically do so? I suspect the underlying unspoken assumption is that one must be ideally informed about all the possible potential pitfalls and gotchas they may face when using any given technology. Aka having a very good (ideally, perfect) knowledge of the technology and its surrounding ecosystem.
It wasn't just once or twice when I've picked some very promising library or tool only to learn something isn't exactly as I hoped (or as it was advertised - docs can lie, too) after I've already spent some non-negligible time implementing something with it. Save for some teenage keyboard mashing some decades ago I'm not a game developer, but I suspect this is universal experience no matter the niche.
> Developers often fall in the (2) camp but don't admit it.
There's also a mixed approach, where people admit "I want to build this thing and use this technology, and I suspect they're a potential good match so I'm gonna try both at the same time". Any even slightly creative person must have an urge to learn and explore new things, even if they aren't exactly necessary for a task at hand. Checking on the promise, if it holds true - sometimes it does and you get a new tech you love, quite frequently it doesn't and you have a bad day.
> Can one always realistically do so? I suspect the underlying unspoken assumption is that one must be ideally informed about all the possible potential pitfalls and gotchas they may face when using any given technology. Aka having a very good (ideally, perfect) knowledge of the technology and its surrounding ecosystem.
Exactly. You need to make some choices up front about program design despite rarely having enough information to make the correct decision, nor enough time to evaluate alternatives in detail. If we had known 15 years ago what we know now our then green field project wouldn't have been done this way - but we are still discovering things that the decisions we made 15 years ago are making hard to do today. That is on top of all the existing things we know are wrong that we often cannot feasibly correct.
You have to make choices. Some of those choices will be impossible to undo without starting over after a while. Some of the negatives will take a decade to figure out. There is no way anyone sane will give you enough time to figure out what those negatives are for each choice - even if the did you will be dead before you finish.
I'm in the 1 camp. After several decades of C++ I know it very well. Well enough to find some of the things that those Rust and Ada people are saying about their respective languages intriguing. I'm at the point where I need to spend some time with each to see how/if they work with my problems in the real world. Because eventually you have to admit that while you can drive a screw with a hammer there are other ways and maybe it is time to learn how to use a screwdriver.
This is what I like to call the artist vs engineer dilemma.
1. An engineer solves problems, learning and using tools. 2. And artist learns and uses tools, for the sake of it.
Neither is wrong, and some times they benefit each other. I believe much of academia and research is heavy on the artist side. You just have to be clear on which one you are at any given point.
I'm not gonna use assembly for my $JOB where we need some basic web backend. That's not gonna stop me from trying on my free time tho.
How about "I'm building this thing and I want it to enjoy the unique combination of performance and memory safety offered by this technology"?
It's certainly close to (1), but also a perfectly rational way to be a The Rust Way fundamentalist avoiding refcounting and unsafe who appears suspiciously (2).
The "rewrite in Rust" meme surely does not come from thin air and there is certainly some skill honing and challenge seeking involved. But perhaps a rewrite ever couple of decades isn't all that bad? And if it isn't, could there be a better time for it than "in Rust"?
Advice should be - you should do what you like and try to align it with your client (employer) - otherwise you'll burnout rather quickly.
It's not easy to find an employer that'll agree with your preferences. I chose to find fun and value in the way I collaborate and reach end goals, not the tools. If the tooling in my dept sucks, I just treat it like a challenge and deal with it.
Healthy.