3 ms·
You think this is the case, but with specific implementations, new libraries aren't coming out every month or even every year. As an example, for nearly 20 yea
by andrewmcwatters 4y ago
You think this is the case, but with specific implementations, new libraries aren't coming out every month or even every year.
As an example, for nearly 20 years, the physics library choices game developers have had has been a small handful, and of those solutions, most use one of two major codebases.
No one is displacing that tomorrow, or next month, or even, I don't know, I'll be bold and guess 5 years from now. If anything, in 5 years, you might have one new entrant that might develop a solution worth considering.
You can absolutely have exponential growth and in major categories make zero impact to the industry.
- flohofwoe 4y agoAs far as physics engines go: Jolt currently seems to kinda disrupt the decades-long equilibrium, at least as far as I'm aware from my corner of the wood. I wouldn't be surprised if the physics engine landscape looks very different in 5 years compared to 5 years ago: https://github.com/jrouwe/JoltPhysics https://github.com/jrouwe/JoltPhysics
- andrewmcwatters 4y agoAbsolutely, and it's the only new entrant in a decade that I think may have staying power. And it too--is written in C++.
- flohofwoe 4y agoI wouldn't mind it being written in C++ if it had an official C API (so that it's easier to use the library from other languages than C++), but somehow physics engines are like UI frameworks, OOP seems to be more popular there than elsewhere ;) (there are a couple of externally maintained bindings though) PS: the most serious case against C++ for game development is probably the widening gap between "modern C++" and the kind of "sane C++" that's used in the game dev world (e.g. modern C++ is moving into a direction where most new features are entirely useless/pointless for game development). That was at least the main reason why I left C++ mostly behind and moved back to C (or realistically: a mix of mostly C and some C++ where needed to talk to libraries), and I keep a very close eye on Zig to eventually replace my use of C.
- andrewmcwatters 4y agoThis is exactly what I do at Planimeter, where we use primarily ANSI C and convert compilation units to C++ when we need to interface with existing solutions. This is the easiest way we can automate bindings to other programming languages without having to use larger instrumentation like SWIG. It's definitely not the industry standard recommendation I wrote about above, but internally we have other objectives that make it sensible. And we still get to use C++.
- HervalFreire 4y agoC++ limited it's growth. I think the rate of growth for libraries in rust will be more diverse and faster. I'm predicting we won't hit JavaScript levels of diversity (the problem space is just that much harder in gaming then in web) where the diversity itself is a hindrance but given the metrics of interest in rust and it's ease of use compared to C++ it's just a matter of time. If I'm wrong the only think I think I would be wrong about is when this inflection point occurs. Either we hit in the future or we just passed it.
- flohofwoe 4y agoDon't get me wrong: C++ sucks. But as far as Rust goes you are way too optimistic. In the context of game development, Rust suffers from a lot of the same problems as C++. Features like fast build times and debuggability actually matter there. It's not memory safety why game dev people are starting to get fed up with C++, it's the slow build times and feature creep of modern C++. In those areas, Rust looks even worse than C++.
- follower 4y ago> No one is displacing that tomorrow, or next month, or even, I don't know, I'll be bold and guess 5 years from now. Betting on the status quo is definitely a pretty safe bet--and particularly over the timeframes of AA-AAA game development. And particularly for someone who is wanting to pick up a job in the industry tomorrow. > for nearly 20 years, the physics library choices game developers have had has been a small handful Another way of looking at that is that it means there's 20 years of pent-up interest from people who want a physics library that can benefit from the past 20 years of programming language & software development methodology improvements. :) > If anything, in 5 years, you might have one new entrant that might develop a solution worth considering. I think it's important not to discount the impact build tooling like cargo can have on adoption of Rust libraries and the potential for developing libraries in Rust but also exposing them via C and/or C++ bindings and gain adoption via that path as well. And, due to a combination of "starting at the same time" & build tooling, the potential for cross-industry cooperation on development is greater too. (Questions about fields of endeavour aside, I note that Rapier physics-related projects are sponsored by both game companies & a mining-related company[0].) (And with regard to scientific computing & Python--well how many people know or care whether the "fast" library they use with Python is implemented in Rust or C++ as long as it's stable & reliable?) > You can absolutely have exponential growth and in major categories make zero impact to the industry. True. From my limited perspective it all comes down to whether Rust can deliver on the promises it makes & whether it can make the cost of switching compelling enough for teams to move. But there does seem to be quite a few people who are putting in a lot of work to try make that happen. Of course, it's entirely possible the games industry decides against such a wholesale change in which case I guess anyone who learned Rust in the interim will just have to take a less underpaid job in a different industry. :) [0] <https://dimforge.com/blog/2023/01/22/the-year-2022-in-dimforge/#sparkl-exploring-mpmphysics-simulation https://dimforge.com/blog/2023/01/22/the-year-2022-in-dimfor...>