← Back to context

Comment by alkonaut

9 months ago

> wait I can't add this new thing because things will no longer compile, and there's no workaround other than code restructuring

I definitely think that's a great feature. I want to learn on day 2 that the design is a dead end, not on day 101 when I ship on day 100 and there was a race condition on day 2 I never noticed.

But the thing about gamedev (I guess - I'm not a game developer) is that the code being great and doing what you hope it will do isn't 100% of the job as it is in other disciplines. In gamedev you may want to run the code, and the way it runs (fun, feel, whatever) might be bad even though it compiles, works according to a spec and so on. So while I'm usually happy to write code for a week and never run it - game development feels like it's all about the iteration.

That said, game development is also game engine development. And Rust seems absolutely perfect for engine development (you need "fearless" concurrency and performance and there are zero mainstream languages that will do that other than rust). For people who feel it's too rigid or hard to iterate with perhaps hybrid could work. Like Rust + Lua or something sounds like it could be worth trying.

I think the point is that there are few "code related" dead ends in game code with good game play that can't be dealt with using enough effort. There are plenty of "game play related" dead ends that no amount of clean code can help out.

To that end, whatever can help you explore the game play the fastest is what you want.

  • Quick iteration perhaps isn't the biggest strength of C++ either. Rust does have some friction when it comes to "I'll try this with a dirty impl and if it flies, then I cam make a clean one later". I guess if that friction is worth it will depend on how much faster you get on other things, e.g. refactoring without spending a lot of effort worrying about introducing hard-to-spot bugs like races, or - worse - having to spend valuable time fixing those bugs instead of adding fun to the game.

    • This is fair. Always curious to see why so much effort is used to move a game's codebase into a single language codebase. Seems far more useful to move the core of a game's engine to an interpreter loop and build on top of that, with all of the affordances one usually gets from that.

> game development is also game engine development

not necessarily. Loads of games and game developers do not engage in any engine development at all, they just use an off the shelf engine and make their game, treating engine developing about as close as web devs treat database development.