4 ms·

Often libraries are far too specialized to share or as you point out, have dependencies/licensing that prevent open-sourcing/sharing. For example I've written

Often libraries are far too specialized to share or as you point out, have dependencies/licensing that prevent open-sourcing/sharing. For example I've written various entity/component allocators, pools, and free-list implementations that run ultra-fast and are reusable across almost any game that needs an entity system, but almost each one is optimized for the performance characteristics of the target game. When it comes to game dev, you generally can get much better performance by writing things for the purpose. Usually reusability and performance are at odds in these cases. That might sound counter-intuitive to some in the web world, but it's a fact. Even in website, you are better off doing things for example like pooling in garbage collected languages, avoiding extra allocations, and using more primitive data structures. This of course makes the code harder to read, test, maintain, etc. so developers in these cases tend not to do it or even be ignorant of these techniques. In games, you do things all the time for your specific use-cases and this really impacts testing and reusability. It sounds counter-intuitive, but over the years I've learned in most cases reusing things in games is a fantasy only inexperienced developers get hung-up on. That doesn't mean nothing gets reused, rather what tends to happen is you learn from your mistakes/drawbacks of previous code and rewrite it better. In effect, you are reusing the code but it's not a literal drag and drop/cut and paste into a new project. Over time, if something is really solid and doesn't have too many performance/usability drawbacks, it may finally make its way into some sort of cross-project more drop-in library. An example I've directly used EA STL. Even when you reuse something though, people tend to do the equivalent of fork it per project, again limiting reusability. I suppose in the age of better hardware with tons more ram, some of these concerns may be going away if your target platform is PC, but with mobile, more resource starved vs pc (ex: Nintendo 3ds) and embedded-like platforms gaining popularity, inevitably things circle back to the direction of optimizing per game and per hardware which hurts reusability. Is it really that valuable for example to dig up some library you used one 1 game in the lifecycle of the ps3 when you've already moved to the ps4 for example? Probably not for most developers unless you have a large window between your game start time and the platform lifecycle. Even on PC this is a problem as everything from graphics APIs to average hardware can obsolete a lot of what you've done or make it relatively inefficient/primitive in a new project.

lux 10y ago
I think there should be a small distinction between AAA and indie game development. Not all indie games need the level of specialization and optimization that AAA's do, and so they can get away with more reusable abstractions that let you move faster. But I've seen the rationale that games require too much optimization by a few indie devs as to why higher-level abstractions aren't used (not all, of course, and in some cases it's true), and that's where I think some indies that think in terms of reusable abstractions can gain an edge. It's a culturally held belief that I think sometimes gets adopted by new devs who then won't end up spending the time learning the abstractions. I'm no design pattern purist by any stretch, but you can often find ways of cutting corners while still keeping things abstract enough to be reusable. Documenting goes a long way towards that too, as does a culture of automated testing, and a better package manager with dependencies.

lux 10y ago

I think there should be a small distinction between AAA and indie game development. Not all indie games need the level of specialization and optimization that AAA's do, and so they can get away with more reusable abstractions that let you move faster. But I've seen the rationale that games require too much optimization by a few indie devs as to why higher-level abstractions aren't used (not all, of course, and in some cases it's true), and that's where I think some indies that think in terms of reusable abstractions can gain an edge. It's a culturally held belief that I think sometimes gets adopted by new devs who then won't end up spending the time learning the abstractions. I'm no design pattern purist by any stretch, but you can often find ways of cutting corners while still keeping things abstract enough to be reusable. Documenting goes a long way towards that too, as does a culture of automated testing, and a better package manager with dependencies.