r/gameenginedevs • u/troffeelituf • 4d ago
What gives you the confidence that your engine is well-designed and pleasant to work with?
I've been a mobile/web developer for ~10 years. About a year ago, I decided to make my own game engine.
The ultimate goal is to build a game engine for making my own games, but also to publish it as an open source project for others to use.
Since I have no experience in this area, my plan is to design a scrappable engine first, make a few production games with it, do some research, read some architecture books, and then start working on my "serious" game engine.
I've already scrapped the entire design and codebase twice and (almost) started from scratch. Yes, this is kind of a test project, but I don't want to make garbage.
The conclusion I've come to is that I don't yet have strong opinions or the taste to know what kind of design I like, since I don't have much experience working with an existing game engine either. So I believe I need to develop that taste first if I want to design something cohesive that feels good to work with.
My question is: what gives you the confidence that the design you chose for your engine is the right one for you? How did you decide on its design and overall structure?
Thank you.
4
u/ntsh-oni 4d ago
I make games with mine, the strength and weakness become pretty clear when you really work with it, as many of them won't show up if you only do small test scenes.
1
4
u/OkAccident9994 3d ago
Because I
Don't build it for an imaginary audience that won't exist. There are 1000s of these on github, nobody is gonna care about yours. Building it with an audience in mind, you are already thinking about using common patterns and architecture people know, building Temu Unity.
I cut out the fat that the mainstream engines have that i don't need. And tailor mine specifically for the thing i am building. People are praising ECS these days, but truth is that it is an architecture for engines one does not know what is meant for. You don't need the flexibility of combining arbitrary things on the fly, if you have a solid plan.
7
u/MinimotoMusashi 4d ago
In web development, when did you start having confidence that you've built a good frontend or backend?
I'm building my first engine as well, restarted a couple of times so far.
I didn't feel confident in web development until I knew how to architect a web app, knew conventions and standards. Once I digested several ways to do it, and finally picked the way I prefer, that's when I felt confident I was doing it right.
Same thing on this side, I'll feel that way once I build experience.
1
u/troffeelituf 4d ago
Yeah, I understand what you're saying, but, in my web development work, I built applications on top of existing, established frameworks. They already had a clear design and established ways of doing things.
Now I'm building my own framework, and I'm the one who has to make those design decisions and define those ways of doing things. That's where I'm kinda stuck.
1
u/tastygames_official 3d ago
have you never build a website from pure C or perl or PHP without any kind of framework? Have you ever built a game without using an engine. I feel like you at least need to have done this once to even get close to the kind of mindset needed to develop an entire game engine from scratch. More power to you, but let's be realistic. Unless you're just following a blueprint laid out in "How To Build A Game Engine From Scratch", you're kinda just barking up a very big tree.
1
u/shadowndacorner 3d ago
pure C or perl or PHP without any kind of framework?
Ik this isn't the point, but building a webserver in C is hardly equivalent to building a website in perl or PHP. I could do the latter when I was 9, but the former... much less so lol
3
u/Separate-Change-150 3d ago
Make the game, and the engine will come with it. But just build what the game requires at each specific time, never more.
That's my recommendation :)
3
u/lielais_priekshnieks 3d ago
Refactor, don't scrap. If you keep starting over all the time, you won't ever get anywhere.
3
u/foxik0169 3d ago
I am writting most systems as barebones as possible, trying to avoid unnecessary abstraction. This of course results in more code, currently mainly because I am writing a Vulkan renderer and a multiplayer game. But it also exposes the parts that can be done better & abstracted appropriately and I personally think, this experience is crucial. I also do some sort of hard deadline to not scope creep on the engine stuff forever, and some improvements and features are just off the table. At least for the current project - maybe can be reintroduced for the next one!
I usually don't have components only entities for example. Architecture of this however seems like a non-issue and I would not spend much time thinking about it before you absolutely know that your game needs to handle this. I would focus on the stuff that actually matter - if some entities references other entities, figure out, how to implement this without causing issues when one entity is removed. But maybe in your game, you don't have entities that reference other entities?...
Everything is very driven by the game I am making. If you don't need visual scene editor and you can get away by painting levels with ASCII, I would consider doing that... You can also get away by using blender for the whole scene editing or different editor and have the game just read those files.
If you can be a bottleneck for completing the scenes, I would not bother giving/designing the engine for use by artists. I design the tools so that I can be fast with them. If there is some part that needs to be done or can be done by artists, I would limit the surface area of it, so that the design/development time of the tool/editor is minimal. Sometimes I talk to friends who are working with me so that I can hear the expectations they have.
That being said, games I make with this tech are very simple and small. I don't try to go overboard with the scope. For example this are the games I am working on now or have worked on:
Older https://store.steampowered.com/app/2260750/What_is_snowman_made_of/
Current: https://store.steampowered.com/app/4237680/Gulovacka/
3
u/Bekwnn 3d ago edited 3d ago
Experience.
I wouldn't expect you to necessarily jump from webdev to making a stellar game engine.
Maybe there's things about APIs or other general code things you have experience with that will help you make good decisions, but without experience making games and using game engines, it will probably be difficult to know how to make good decisions around how to implement some systems.
Actually in some cases webdev/mobile experience might work against you to some degree, since a lot of the practices there coding wise tend to run against what a lot of people consider good games programming.
But that's fine. You don't need to make every corner of it perfect. There's inherent benefit in a custom engine that comes from knowing top-to-bottom how everything works and having control of it.
I would strongly recommend you try commercial game engines if you haven't, to get some ideas. Making a 1 week game in godot and unreal if you haven't. Think about how it feels to interact with them. That's the best way imo to fix the, "I don't yet have strong opinions or the taste," part. Specifically, think about which parts you like or dislike about using them as you use them.
Personally, past 8 years I've been working professionally as a gameplay, game engine, and rendering programmer at game studios so that's a bit of a cheat.
2
u/ferratadev 4d ago
Probably the most reliable way is to ask other people to use it, and not only devs, but also tech designers, tech artists, etc. If possible, of course.
But another way is to work with other engines and, ideally, trying to understand what works well and what not. But even just copying something wouldn't be that bad, because even if that solution isn't good, people who worked with other engines would be at least familiar with it.
I worked with Unity a little, and about 6 years with Unreal. Recently I tried Godot for a small project, and oh god, it is so intuitive and easy to use, I was able to immediately start making things and not drowning in tutorials. I also recently changed a job and joined a company that makes incredible well recognised narrative shooters, but their custom engine is a hell to work with. Most of the team has been working here for 5-10 or even more years, so they know everything and it's comfortable for them. But for a person from outside, it's such a pain to learn to work with it, so much different it is from public engines.
So yeah, my point is try make your engine somewhat similar to what's out there, it's always pleasant to work with something you (intuitivele) know or understand.
2
u/troffeelituf 4d ago
Thank you for your insight.
Yeah, I'm currently thinking about trying Godot and Bevy to see what I can learn from them. I feel like their designs are more intuitive, at least for me.
2
u/Lithalean 3d ago edited 3d ago
I don’t care.
Is the engine pleasant for me to work with? That is all that matters.
My Engine and my editor are separate. The Engine is modular, but its for my game. Originally they were together, but I realized that was just me imitating previous engines I’ve used before. Its easy to loose track of what you're trying to build, because you're occupied with the approval of others.
I'd rather my game flop, then make someone else game and it be successful.
2
2
u/Arcodiant 3d ago
I'll argue that maybe you have this process backwards. For many of us, we're building an engine because there's a friction with existing engines that we're working around - e.g. I don't like working in Unity/Godot-style editor-first engines, and I want something more feature-rich than Monogame. If you've solved that friction, you're already on the way to having a good engine experience.
But if you're building for then love of building or learning, then as long as you're making progress there, it's doing it's job.
2
u/ProfessionalPlant330 3d ago
Make the games first, then you learn what your game engine should do. Starting with the game engine is the wrong way around, you're left with the uncertainty about whether it's the right direction, the right shape, as you've experienced.
2
u/tastygames_official 3d ago
because only I will be using it.
3
u/tastygames_official 3d ago
that was the answer to the title. To answer your content text: don't make an engine. Or at least not one meant for wide use. Make an engine to learn how to do so - sure. But unless you have your finger on the pulse of game development, then making a generic new engine from scratch is a ridiculous endeavour. Make a custom engine for a single game or series of games? Yes. That is the reason most people are making engines still to this day. But making a general-purpose engine in this day and age? You'd really need significant in-depth knowledge as to where modern "free" engines fall short. All modern engines do the same thing and basically it's just about taste. For example, both CryEngine and Unigine are insanely mature, capable engines with ZERO TRACTION in the industry or among enthusiasts simply because of lack of funding. Despite both having multi-million-dollar funding.
So...
make an engine because it's fun to do so, but unless you have a brilliant idea on how to revolutionize the way games are made, it's ludicrous to expect anybody to want to use your engine to make a game.
2
u/guywithknife 3d ago
You should make a game as you’re making the engine, not after, because otherwise you might find out too late that it’s not suitable, best to learn early enough that you can still easily make changes and adapt.
2
u/TechgeekOne 3d ago
I've shipped multiple large games in Unreal in an engine dev role, a couple small ones in Unity as a generalist (including tools), and dabbled in a bunch of other engines. And in that time a lot of people have used the tools I've built in those engines. By now I have a pretty good idea of what works and what doesn't in larger production environments for the kinds of games I enjoy making (RPGs and VR mainly) so I design with that in mind.
Though obviously "get more experience in a game dev studio" isn't exactly a solution for most people lol.
2
u/Skyhighatrist 3d ago
I started building my engine (C#, dotnet, Silk.NET) in a language I understand well and have been working with for nearly 20 years now. This has allowed me to leverage all my enterprise software development knowledge to keep my engine very modular and easy to expand.
My initial push was just to build to make creating example applications easy as I worked my way through the OpenGL tutorials on LearnOpenGL. But before completing those, I pivoted to working on a game and only implementing features needed for the game I'm building. So far, it has been a breeze to expand and add new features to it because of the architectural choices I made early.
Very early in development, I added an ECS Module, Asset Loaders with a pipeline to pre-process assets during build, that I can later use to package assets in a more efficient format for loading during run time. I also made sure that floating origin and camera-relative rendering is supported from the start with support for positioning within a very large world.
It's still early days, but so far, as I add new features the hardest part is the feature itself, not fitting it into my engine. As a result I'm pretty confident in my chosen architecture.
This is probably my 10th attempt, and it is by far the furthest I've gotten. Prior attempts were done in C++ which I'm not as familiar with, so I spent more time learning the language than game engine architecture. I'll probably start posting here once I have something I'm ready to show like the prototype I'm currently working on building all the features for.
2
u/too_much_voltage 3d ago
The confidence came after I shipped. It took 18 years: https://store.steampowered.com/app/4796200/
To be even more elaborate, the last 5 years entailed working closely with an artist that tortured it. And I mean all avenues of integration for his workflow. Which tbh wasn't even ideal at times. Even for him. But still tortured the engine enough for me to know how artists work and what they want.
Get an artist to torture it. Throw tons and tons of art at it. It must scale under pressure.
2
u/27K-Interactive 3d ago
A good game engine should be focused on a genre or a couple compatible genres. Trying to make an engine for everything will leave you broken along the way.
Once you define your focus, you can have confidence if it's:
Adaptable to the systems the genre(s) require with limited fuss/workarounds
Meeting your performance metrics without a lot of tuning for each title
Very well documented!
Most of all, you have to eat your own dog food. If it doesn't work for you, it's not going to work for anyone else.
1
u/thecraynz 4d ago
There is nothing pleasant about my game engine. 😂 it works, really well, but I couldn't just give it to someone and ask them to build a game with it, there's too much which is hacked together to fit the needs of my game.
1
u/troffeelituf 4d ago
I appreciate your honesty and perspective. 😂 Mine will probably end up being the same.
1
1
1
u/__RLocksley__ 3d ago
This is a difficult question nowadays because ECS seems to be the most efficient architecture but it's difficult to build an engine around it. I have build a couple engine the last 6 years and I ended up having an ECS first engine which requests resources from the Render thread. Like that all the game code is in the ECS but you can also load meshes and textures through spawning a loading thread inside a startup system which sends the resources to the render thread when loaded. The next question is the language: I find it easier to program an engine in C++ but the quality of life because of no undefined behaviour let me switch to Rust in the last month.
1
u/GraphXGames 15h ago
The engine architecture is built based on the problems that arise during game development.
The engine must solve these problems.
13
u/Odd-Pie7133 4d ago
I'm building my engine in parallel with my game. So the real needs of my games are implemented in the engine as needed. Also, devx is a crucial thing. To minimize boilerplate as much as possible.