Between the Boughs by Evergreen Games

who are big game engines for?

following my last post and this excellent post by Noel Berry, I'd began to think "who are big engines for?" since I see myself likely to move away from Godot as my all-purpose dev environment. it always expands my perspective when I ask "who is this for?", as when I think about it that way, it makes it clear if something is the best choice for me or not, while also helping me appreciate those it does best serve.

and first of all I'd like to say: if Godot, Unity, Unreal, etc. feel like they're for you, then they're for you! this isn't a polemic against big game engines, but a reflection on the process of picking what best suits us.

big game engines are good for teams

I feel where they offer the most is in medium-to-large team-based environments. everywhere, for me, that tools like Godot become a friction point in my usage, it is likely to be a boon in larger team environments.

especially when we're thinking about environments where you're recruiting job positions. you want someone to come on and be able to start contributing with as little onboarding as possible. with these engines, they create immediate common ground. even if there's a big learning curve for these engines' idiosyncracies and best practices, it is one that is highly transferrable between team environments, and equally lends to having a wide base of support for solving common problems.

additionally, these engines can be more welcoming to non-programmers, inviting them to implement game data and assets themselves all in one environment.

when you're not a medium-to-large team, the double edged nature of these advantages can turn against you. you have a lot more scaffolding than you'll ever need, and you're not as worried about being on the same page when it's just a few co-programmers or just yourself. sometimes you spend more time working with the engine than on your ideas. in these cases, it can be easier to just program what you need in a lighter weight environment.

they're made for larger projects

a notable element of these engines is how they streamline asset pipelines and give you a fairly integrated workflow right out of the box. in games that use complex 3d or ones with huge scopes, this immediately solves a lot of finnicky boiletplate you would otherwise unnecessarily waste a lot of time on.

most (all?) of them have source control integration in a way that's easy for anyone on a team to work with, which tends to get especially necessary and intricate as scope expands, as well as having features like hot reloading and live debugging that shift from handy conveniences to near necessities as compile times lengthen.

they have unique workflows

every game engine has its own structures and opinionation on how you should make games. this means that you get a unique experience as a creator with each one, and any of them might be more or less suited to how you like to work, or how you might like to work on a specific project.

for example, I've really been enjoying pico-8 lately because its combination of all-in-one features (code/art/sound/mapping) and forced minimalism help keep me focused on making a thing rather than engineering, and I find it cute and fun besides.

while using Godot, I found its node system really interesting, dynamic and fun. if you take full advantage of them, it can enable some unique sorts of games that would require more groundwork to get going in other environments.

if you're not making the most of these unique features and workflows, they can wind up getting in the way. for example, if you're using pico-8 and you start wanting to use an external code and sprite editor, you start having friction with the system itself such that you might enjoy a different environment more that's built for such a thing, like love2d.

they're made for beginner developers

this might sound contradictory, but much of the same way they benefit teams can also benefit beginners. having a lot of tools right in front of you means you can get to making things faster without as much pre-existing knowledge of programming or frameworks. you still have to learn the engine itself, but they're abundant in tutorials and answers to common questions and needs. when you zoom out to low and no-code engines like Construct and Game Maker, these advantages become even more emphasized.

after you have more experience under your belt, both as a designer and a programmer, it's easier to know what you do and don't need. it requires planning and foresight, skills that are typically honed through years of experience. until then, it benefits a lot of people to have more than they need at their fingertips, giving them room to expand as they go.

and what of more purpose-built engines?

for solo and small teams, the disadvantages of all-purpose engines can becomes advantages again with purpose-built game engines. these are the likes of RPG Maker, Ren'Py, Twine, Puzzlescript and others.

interestingly, pico-8 has the functionality of an all-purpose engine, but instead in a minimalistic environment that makes it feel purpose-built.

what all of these engines offer is focus. these engines strong opinionation streamlines the process of working with them to a very fine level, which subsequently makes their resulting works also feel like a genre unto themselves. you aren't just "making a game in RPG Maker", but rather you're making an RPG Maker game, or a Pico-8 game, and that is a unique experience unto itself which entire communities tend to emerge around.

these engines are great choices when you want to participate in those genres/communities or when what they provide gives you exactly the set of tools you need for what you want to make. in essence, this can be a similar choice to working without an engine, as you're only adopting the exact level of functionality you need and thoughtfully scoping yourself in similar ways.

with all this said, I believe all-purpose engines might work best for you if:

and I believe these sorts of individuals are served best without game engines:

and ultimately, of course, go with whatever calls to you, and always remember you can try new things along the way!

as creators, we're never static in what we're interested in and what works for us, it's always evolving over time. thus, it's natural for our interest in various tools to change, as well as for the tools we use themselves to evolve. godot was right for me last year when I needed a straightforward jumping in point back to game dev, and pico-8 is right for me right now while I just want to sketch ideas out there. and I already see my needs shifting again to other areas once I'm done here. whatever we choose, I think it's valuable not to set ourselves in stone and make sure our tools serve us, whichever, wherever and whenever.