1. 66
  1.  

  2. 7

    There are more game engines written in Rust than there are games4, and none of them are mature enough to actually produce games with. Engine tech can be much more fun and straightforward to program than a proper game, so it’s understandable that folks working in their free time are drawn to it. However, I’m a strong believer in the Write Games, Not Engines philosophy, and I think that “writing an engine” is a very dangerous task to get sucked into if you’re interested in making games.

    I found this super interesting. While it’s also kind of a screed against writing game engines, I do think it says something fairly profound about both the language and the community.

    A follow on question I have is - how can people create game engines in a language with relatively poor support for game dev to begin with?

    This might also suggest that the community should gently encourage devs to broaden and deepen the supporting libraries rather than re-inventing the wheel yet again :)

    (Totally fascinated by rust - but don’t use it. Sadly I do not think Rust will ever be a useful work-a-day tool for what I do.)

    1. 17

      While it’s also kind of a screed against writing game engines, I do think it says something fairly profound about both the language and the community.

      I hung out on gamedev.net forums from 2000-2007 or so, and this was a very common occurrence: users writing elaborate game engines in C++ and forgetting about the game part. I think this is a temptation of anyone who enjoys programming, rather than a particular ecosystem.

      Nowadays it can seem a bit odd, given the proliferation of commercial middleware, but there’s always a pull.

      1. 5

        You can also see that in the FOSS world. Almost everyone writes or contributes to a fancy library or framework, but finding people working on full products with longevity (like a GUI app or such) is hard.

        1. 2

          The meta aspect of programming is more fun usually.

      2. 13

        Part of the reason for so many libraries is that there are traditional game code patterns that don’t translate cleanly to Rust, and so there is a need to figure out how to create good, scale-able game architectures within this new context.

        1. 10

          I think this is a pretty great aspect (and I know some game programmers that agree), but this will just take time. I’m very relaxed on that front.

          1. 1

            Would you or @skade care to elaborate at all? Why is this so? Does it have to do with Rust’s ownership & borrowing model, a lack of traditional objects, or something else?

            1. 3

              Ownership and borrowing are the reason. Traditional design patterns in OO game code often rely on a lot of shared ownership / mutable access to resources. Translating those directly into Rust does not work, and so care needs to be taken to figure out a structure that enables all the relevant parts you care about to access the data they need.

              I seem to recall there being a blog post by someone who wrote an Entity Component System engine in Rust, discussing their issues with making it work, but I can’t seem to find the link. I’ll see if I can find it later, as it is a good concrete example of this issue.

                1. 3

                  Yes! Thanks Steve!

                2. 1

                  Ah, what Rich Hickey calls “Place based programming” - yeah, interesting how baked in these assumptions are at a fairly low level in all kinds of places.

            2. 9

              Another thing to remember is making games is a creative, artistic endeavor. Making game engines is more engineering or exploring algorithms. People into the latter might naturally enjoy the unique challenges of a game engine but not waste time trying to actually design a game.

              I was one of those people once learning some UI coding on Windows by building Pacman and Frogger clones. It was hard work because of the pitfalls, esp graphics bugs. Made me appreciate “simple” games a bit more. If I had patience, I couldve also made consumer or business apps with better looking UI’s than common at the time. :)

              1. 9

                A follow on question I have is - how can people create game engines in a language with relatively poor support for game dev to begin with?

                (note: am talking in context not using Unity or idTech or other off-the-shelf engine)

                Some friends and I did gamedev (do still, on and off), and we used to have the joke “MAKE ENGINES NOT GAMES”. And then we became dissatisfied with our supporting libraries, and started joking “MAKE LIBRARIES NOT ENGINES.” And at least once we became dissatisfied with our languages of choice (C and C++)…yeah.

                The thing is that game code? Game code is sprawly and weird and hacky and full of special cases and really can only be “grown” as you start with a game update-render loop and decide to add features. It’s ugly and hard work, and there’s always of sense of impermanence. Each codebase is probably going to get thrown away by the time you’re done.

                Engine code, by comparison, is a chance to Build Things Right (tm). You get to abstract out common functionality (input systems, action maps for key binding, framebuffers and rendering targets, networking stuff, entity properties, etc.) and do so in relative peace and quiet.

                And hey, you get to make your house exactly how you want it, since learning a new engine is hard, and it might not even support the gameplay you need! Look at that Braid guy–he built his own tech, right? We should too!

                Nobody is impressed by making a game as they are by making an engine, right, because people churn out bajillions of games every day–but to be the person who makes the tools? Man, you must be a hardcore hacker!

                The sad thing is that what counts as an “engine” nowadays really is a content pipeline and runtime to render that content, not just applying a normal map to a spinning triangle that changes colors when you hit a button.

                1. 5

                  I find low level libraries that can be combined and composed more useful than giant frameworks, though I am not a game developer.

                  I can also understand how a powerful game engine can save development time if your game vision is a good fit for the engine.

                  1. 4

                    I like frameworks composed out of well-separated libraries with clear boundaries. Having worked on two of those, that’s a tough job though.

                2. 5

                  I would love to hear more about this code hotloading solution. Does anyone have any experience in this area? Seems really cool.

                  1. 10

                    Short answer: Most code goes into a dylib, and the executable (which contains the main game loop) reloads the dylib in between iterations if it notices that the dylib has changed on disk.

                    1. 5

                      I have been experimenting a little with that, especially around keeping a stable boundary that could vanish at runtime. Would you be open for bikeshedding somewhere else? Maybe users.rust-lang.org?

                      1. 3

                        Happily! Feel free to kick something off and send me a link.

                  2. 4

                    After working with Rust for a longer time while writing a book on it, I’m starting to miss many of the niceties of Haskell: namely the REPL, higher-level programming and greater maturity. I think I’ll be spending some time in that world in the near future. The last time I was there was almost 10 years ago, and I hear many practicalities have progressed quite nicely.

                    Shameless plug: https://www.packtpub.com/application-development/mastering-rust is nearing completion :)

                    1. -1

                      Kinda don’t understand how Haskell and Rust can be readily compared, other than that they’re both programming languages.

                      One is a compiler and produces fast, memory efficient code, the other is an interpreter, optimized for provable correctness and category theory.

                      1. 4

                        Rust’s type system is largely derived from / inspired by Haskell’s type system, so there is a certain degree of direct connection between the two languages.

                        1. 5

                          One fun related thing: some people have observed that Rust’s type system is gaining features in the reverse order that they were included in Haskell; this affects things like idioms, etc.

                          1. 2

                            Oh, that’s a really interesting point. I’m not so familiar with the order of addition of features to the Haskell type system. It’d be interesting to maybe update the relevant FAQ sections with a more in depth comparison of the languages in this respect (in particular, a discussion of some notable Haskell GHC extensions which Rust does not currently offer an equivalent for, along with some information on efforts to potentially change the situation).

                        2. 2

                          They both have similar, ML-derived type systems. They both have typeclasses, pattern matching, and don’t offer conventional OO inheritance. There is a certain amount of syntactic similarity.

                          (I believe Haskell is compiled? And it is often fast, and certainly not the optimal language for provable correctness or category theory)

                      2. 3

                        He very very briefly mention Jai for future game development if the compiler is released. Looking over the doc he links to about Jai I’m surprised that Myridian hasn’t caught on with game dev (yet).

                        1. 2

                          I can’t see the link, but Jai is the creation of a vocal self-promoter; I would treat anything advertising it with a fair chunk of skepticism.

                          1. 7

                            You make it sound like he’s some fitness guru or something. His self promotion is dozens of hours of video of him explaining decisions behind the languages, and demoing the compiler and a game written in the language.

                            He’s also paying people (at least 1 ATM) to work on the compiler, with his money from his successful game dev career, while a lot of interesting languages are hobby projects.

                            1. 1

                              I’m automatically skeptical of anyone who prefers to explain things through video rather than in written form - that sets off my guru-dar. IIRC he was a vocal figure who seemed to be deliberately courting controversy when he was pushing the game that made his name?

                              1. 2

                                He mentions in his videos that he’s doing it for fun and as an experiment. I enjoy watching them, I’ve learned a lot about low-level optimization and new ideas in compiler design for gamedev. It’s a different kind of learning experience than just reading a blog post or a book. It’s feels like peer programming with an expert in their field. Watching how they decide to tackle, stumble through, and solve a problem is something you can’t get with other mediums.

                            2. 3

                              to be fair, Rust and Go are not without a cadre of aggressive vocal promoters.

                          2. 2

                            No games tag @pushcx ? :P

                            1. 4

                              It’s about programming, not game design or analysis.

                              1. 8

                                It’s games + programming though.

                                I figure implementation of games should count too, since it’s a weird niche part of software.