i spent 6 years in the gaming industry before starting rivet, an open-source project for orchestrating stateful workloads. the way people are using our software is starting to look a lot like how game developers build software.
but npm is getting in the way.
game devs commit their dependencies
game devs don't use package managers in the same way npm works. their dependency system looks a lot different than what you think of as a package manager.
when you install a package for a game, you literally copy the entire package into your repository and commit it to git. the expectation is that you are going to modify your dependency directly.
the exact process varies a bit per each engine:
- unreal plugins are vendored source in
Plugins/, engine itself is commonly forked from epic's github - unity asset store copies source into
Assets/, upm supports local/git packages you can modify - godot asset library downloads plugins into
addons/, they become regular project files you commit and modify freely - other engines vary from engine to engine, but the general practice is the same industry wide
this package management approach stems primarily from the need to customize everything on a per-title basis. these customizations usually stem from:
- customized rendering pipelines
- specialized netcode
- specialized physics engine behavior
- fine-tuning performance
- specialized platform support (consider yourself grateful for never having to ship a playstation/xbox/nintendo title)
games have less dependencies
but there's one important caveat to why this works: games have very few dependencies.
- the engine itself (yes, the engine gets forked too)
- physics engine (often part of the engine)
- vfx
- netcode
- artist pipelines
you're not going to find left-pad on the unreal asset store.
why ai is making all software more like games
in 2023, forking dependencies regularly would've sounded bizarre and unmaintainable.
however, there's 3 big shifts happening in ai-assisted software development:
#1: no more tiny libraries
tiny libraries used to be all the rage on npm. now ai can oneshot them perfectly.
our codebases are starting to look a lot like games where engineers prefer to rewrite tiny tools in-house from scratch.
our dependency list is getting smaller, but...
#2: frameworks are becoming even more important
llms need structure to work around. frameworks provide that rigid structure.
as our dependency list starts getting whittled down, the framework (e.g. nextjs, ai sdk, supabase, our work on rivet actors, etc) starts looking like the "game engine" for your software.
think of how a game engine lets a team produce thousands of entities for something like gta v. frameworks do the same thing for ai-generated code: they provide the structure to scale reliably.
#3: forking/patching is sooo easy
you no longer need to understand a codebase to fork or patch it. llms have made this a non-issue.
much like game engines that need to fork for customization, ai has made this a reality for the rest of the industry.
how we see this at rivet
we're watching this happen in real time at rivet. customers are forking our libraries, patching internals for their specific infra, and sending us the changes upstream.
but npm makes this painful. monkeypatching, version lock conflicts, no clean way to vendor a fork. it's fighting the toolchain every step of the way. we rely heavily on pkg.pr.new for being able to ship changes quickly from git commits, but it's a partial fix to a more complicated problem.
if dependencies were managed more like game engine plugins (vendored, forkable, expected to be modified) this would be much simpler.
and this isn't unique to rivet. any framework that becomes "the engine" for your codebase is going to hit this.
on the future of software development
game engines tend to have specialized tools for managing dependencies in this pattern & usually have complex build pipelines to support this.
it's possible to use git submodules or git subtrees today with npm, but there are quirks with build pipelines, collaboration, etc. that still need to be worked out.
maybe someone will replace npm with something that operates on submodules/subtrees instead of a node_modules folder. tbd, it deserves more thought.
tweet at me if you have thoughts/are adopting a similar pattern, i'm very interested to see where this is going.