The other day a friend linked this twitter thread: https://twitter.com/RustedMoss/status/1678809365975793664
I thought it was fairly neat that just starting with one system, (hair physics), by throwing it into a bunch of proof-of-concept demos it started to become clear what it was actually useful for (grappling hook mechanic). It kind of reminded me of another short talk I had seen some time ago where a developer over 20 minutes ran through about a dozen different scrapped projects. They were all platformers and it was pretty clear by the end they were basically all stemming from a single “base project”.
In theory putting together a base for a platformer is pretty straightforward if you make some assumptions about the types of things all of the theoretical platformers you’d ever like to make need. For instance:
- Movement + Collision system
- Player controller (ideally pre-tweaked for good gamefeel)
- Animation state machine
- Loading/Moving between maps or levels
With some other optional nice-to-haves
- Health, game over screen
- A basic “enemy” entity (kills/damages you on contact)
- Combat system (hitboxes, animation frametimes, “hitstun”/gamefeel)
- Depending on the engine, you may need some integration with third-party tools like level editors and such too.
Obviously all of these things are pretty well documented and solved features for most game engines. That being said, implementing them in a way that your future self could reuse and iterate on is not always that well explained. I don’t think what I’m saying here is that revolutionary or anything, but I don’t think I’ve ever put something together that really functions well as a “base” like this. I think there are some architectural concerns that you have to work around that you wouldn’t necessarily think about if you had a singular vision for a game and tried to just quickly make THAT idea specifically. You might want to engineer as much as you can as “modules” - things you can plug in and out depending on what you actually need. No need for a combat system if your game is just insta-kill spikes you have to jump over, for example.
I’m sure a lot of devs already work in a way like this, but it’s totally a skill in it of itself to write code that is easy to recycle throughout the future. Part of why I think I have avoided this kind of development is that I do tend to stress on implementing things super “broadly” and delve into just refactoring every couple months, when the truth is you just aren’t able to write code that adapts to every single situation or requirement you might have.
It does sound really useful to have something like this where if I do get some spark for a game concept, I could spend a week just playing around making the singular feature I have an idea for, and trust the rest of the boilerplate mechanics already work to my liking. You could start up and completely scrap something new every week until you find something that feels cool enough to turn into a larger project. And as you build and release smaller games, your “base project” over time gets more and more refined with features, and players can track over time the way your concepts improve.
Platformers are pretty straightforward but I’d be pretty interested to see what an architecture like this looks like across other genres, too, like RPGs, zeldalikes, and such. It could also be neat to build out some sort of “general use” base for people, and do a kind of challenge where different groups try to expand on it in different directions, gamejam-style. I’d be interested to hear if you know any devs who have work well in this way, or if you have any thoughts on how you approach this kind of modularity?