But for my projects I think I'll keep using Godot. I really want to make a game, and not the tooling required to make a game. That said, I've dabbled in GDExtension, and if I really need to have something performant, I'll use that.
I've got huge amounts of respect for people doing it this way though. They have a level of control over their work that a Unity or even Godot developer cannot hope to have. It has, like any game dev approach, it's pros and cons
The key difference is the code driven development workflow that makes it easy to keep different concerns like visual assets, collision boxes, navigation, etc separate.
If you do this in Godot, the standard editor features become meaningless, because they are optimized for throwaway workflows with extremely tight coupling (e.g. a player character IS a node containing subnodes, rather than the player character being a high level concept, whose nodes merely represent the player character).
So I essentially had to write my own physics, collisions, trigger functionality, ways of describing levels, enemies etc. The resulting game wasn't really fun, but I loved the process and the lessons learned.
Turns out writing your own game engine is a pretty good way of learning to understand existing ones.
The more unique and niche your game is, the more true this is. Stumbling around Unreal's horrid UI for 3 months just to realize that the thing you want to do is barely even possible due to how general and off-the-shelf the engine is, is not a good experience. On the other hand, if you want to make a hyper-realistic, open-world RPG, then rolling your own is probably not a good idea.
I also believe that even if it's not always the most efficient thing to do, placing limitations on yourself by using a custom-made specialized engine makes the creativity really flow, and your game, even if not the most advanced, will be a lot more unique as a result of that.
For a more concrete argument. You also said learning Unreal using tutorials took a few days, which is certainly not possible, unless we are talking only about a very basic understanding. In the same vein, it also takes a few days to make a very basic engine built on top of OpenGL.
If the game fits a rather "standardized" template, this is likely true. But the more you move away from these "mainstream structures", the less true the second part of your claim becomes.
One obvious example is physics behavior, which you can add to your game in under a minute, but with your own engine you'd need a day or two to properly integrate an external library. All the internal state visualization that Noel's showing off here is already built in by default in Unity. It has nice tools to draw and modify bounding boxes, and in the rare cases where the engine's behavior isn't enough, it's highly extensible (using ImGui or Unity's Yoga-based CSS engine, which I prefer). Unity has countless features like this: a sophisticated particle editor, a high-level "write once, run anywhere" shader language with enormous amounts of complexity abstracted away, systems for streaming and keeping track of modular data, and much, much more.
In an ideal world, I'd want to write these things myself, but time ticks away and unfortunately I'd prefer to prioritize finishing games more quickly.
Graphics are anything from rendering 2d, 3d, shaders, scene graph, animation.
Physics and related interact with the scene graph.
The game part allows for dynamic behavior and of course the game logic/triggers.
Add some ui, and resource management, abs lastly of course ai.
Creating your own engine with different architectures is indeed the best way to learn how/why an engine works. But alll the details that come with it. That’s really a lot and probably way too much for one person. You’d be surprised how much is in there (in unreal engine)
I once experimented with creating my own game engine. It took me about a year of building and learning along the way (through trial and error, with many dead ends initially). It featured lots of things you'd typically find in a game (3D rendering with all the bells and whistles, an adaptive UI framework inspired by flexbox, skeletal animation, a save file format, a smart object system, path finding, a scripting language, audio, physics, et cetera, et cetera)
Specifically, I tried to recreate Braid's system (without knowing it existed), where you can rewind your game to any point in time. It required support from all the engine's subsystems - to rewind scripts, physics, etc.
Knowing every little detail about your game engine was certainly a plus. After the engine was more-less complete, adding a feature, however ambitious it was, took about a couple of hours at most. When something didn't work, I knew exactly what was going on.
However, after a year of building, I was somewhat exhausted, and all my motivation to continue disappeared :)
Not necessarily. You can write your own "snapshotable allocator" that allows you to rewind back in time anything, even the state of unmodified 3rd party libraries and interpreters (as long as you can configure them to use your allocator).
I wrote about it in https://www.jfgeyelin.com/2021/02/a-general-state-rollback-t...
I think this is dangerous and can lead to remote execution attacks:
>The snapshot could even be exchanged over the network, assuming the receiving side has the same endianness, the same pointer size, is running the same binary, and can mmap the same memory location.
For physics, I needed to restore all those remembered motion vectors; for audio - current playback time, etc. Same as yours:
>The rest of the memory (the textures, the 3D models, the audio, the UI, etc...) should be allocated by your usual non-snapshotting allocator"
I love LibGDX for personal projects but for serious development where deadlines matter having stuff like dialog trees, UI, etc. that just work out of the box and have the edge cases polished is Very Nice.
And ofc, cross platform with consoles is way harder rolling your own and that's often a big deal.
That sorta thing is why Slay the Spire switched to Unity/Godot for the sequel
The best tool is the one you know, even if your vision is weird or niche. At the end of the day, you can always ignore all the bits and pieces unity gives to you and just write custom logic in your MonoBehaviour scripts and use it as a platform toolkit, input handler, content pipeline, scriptable editor, and renderer. There's a lot to be said for the features you get from that especially in the long term as you said.
Most likely never?
Obviously understanding what `GameObject.Instantiate(myPrefab, Vector3.zero)` takes several orders of magnitude less than implementing all that is required to properly perform that, even for such a basic operation.
Imagine when it comes to 2D/3D physics, shaders, platform support, etc.
If your goal is to build an engine, build an engine. If your goal is to actually deliver a game, build a game.
I would say its the exact opposite to that. For that genre, its best to roll your own engine, or pick something open-source. The list of problems that i firsthand experienced:
There are lots of features and options in the engines, but they are not all usable at the same time. One feature disables the other. You look at the list of all the nice things the engine can do, but then at some point you figure it can't do (or can't efficiently do) what you absolutely need. All those awesome looking graphics are not practically usable, simply not performant or not compatible to be usable.
There are features that only work in "baked" mode. You "bake" it in the engine editor, and there is no way of changing that at game run time. Unreal is the most limited in this, but Unity is not much better. Some game developers reverse-engineer Unity internal asset formats with a hex-editor, so that they can change feature behavior at runtime. At that point, rolling your own engine makes more sense. One example i saw was a developer reverse engineering the light probe group asset file, so that he could add a new light probe group at runtime.
Engine API's change drastically from version to version. All the code and scripts need refactoring, all the time. You run into a breaking bug, and the only solution is upgrading, but upgrading means breaking your whole codebase.
You need to go trough the engine's abstractions, and bad luck if that can't be done efficiently. An example of this: Unity HDRP applies screen-space ambient occlusion (among other effects). It applies the effect over the whole screen. If there is a third-person view of the character from close or first-person hands/weapons rendered, then even over that. That results in a white halo around the first-person hands/weapon, looks bad. In a custom engine, the solution is simple, apply the full-screen effect before the first-person hands are rendered, then render the hands without the effect. Its a matter of switching the order of a couple of lines of code.
The solution is github and the BSD/MIT/Apache licensed game engines and libraries.
You've asked two different questions - how long does it take to properly learn Unreal or Unity, and how long does it take so you can have an idea and turn it into a game without friction? If you gave me a half baked idea we could be playing it in a few hours with both tools. Unity requires programming up front, but Unreal you can get well into "I can almost ship a game" (particularly if it's a single player game) with just blueprint.
Here [0] is a 10 minute video where someone prototypes a super hexagon style game in 10 minutes. Obviously, this isn't feasible without knowing exactly what you're building, but I think this shows just how powerful these tools are for building out these game ideas. There's very little unity specific stuff in there, other than components. Everything else is stuff that I would classify as "gamedev agnostic" - input handling, update vs fixedUpdate, vector math, sprites, etc. The prefab for the spawner is about the only unity-specific thing in that video and it takes up about 15 seconds of the 10 minute video. I'm a game developer (Unreal) and I'd wager I could put together a similar prototype in about an hour in Unity, give or take
If you have enough game dev knowledge to make an engine...then it's seriously like a day to learn these things to begin to bang out a prototype.
They take a long time to master but if your goal is to work on the game its not in the same universe of turn around time.
Engines are the easy part.
The real meat & potatoes is all the tooling and content and asset pipelines around the engine. If you think about it, you need to implement:
- importing data from various sources and formats, textures, audio, model files such as gltf, fbx, animations etc etc.
- editor app with all the expected standard editing features, cut, copy, paste, undo, redo, save, delete etc.
- all the visualizations and operations that let the game developer use the editor to actually create and manipulate data, entities, animations, scenes, audio graphs, scripting support etc. etc.
- all the data packaging and baking such as baking static geometries, compiling shaders, resampling and packing textures, audio, creating game content asset packs etc
- etc etc.
When all this is done you learn that the actual game engine (i.e. the runtime part that implements the game's main loop and the subsystems that go brrr) is actually a rather small part of the whole system.
This is why game studios typically have rather small teams (relatively speaking) working on the engine and hordes of "tools" programmers that can handle all the adjacent work that is super critical for the success of the whole thing.
When working on your own engine you also feel as if 90% of the time is spend on user interface creation if you actually want to have an visual editor.
People don't realize that they will spend 95% of the time on the engine and 5% on the game.
Which is ok if you don't want to make a commercial living out of it.
But unless you are making a game with extremely specific needs (eg Factorio) using your own engine will probably kill you commercially.
Keep it super simple. Or that game will never come out.
> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
Sometimes the best way to tackle that 3% is upfront when you're deciding on your system architecture.
So a day on their game wasted over efficiently removing an item from an array of 20 items every 5-10 minutes.
> If I optimize this, how much time is it going to save the whole world? What will be the sum of time saved by everyone who will ever run this code? Is that less than the time required of me to do the optimization? Then, don’t do it!
That question was relevant quite often.
The big optimizations though really mattered. And, required planning before initial implementation to set the system up to be optimizable.
No - spending a lot of time making tools you don’t need is the problem. You can write your own engine and leverage existing tools.
> Most people think of a “game engine” as code that is shipped with the game executable. However, that’s only half of it. The other half, which I’d argue is more significant, is the code that is not shipped with the game - level editors, content pipelines, debugging/profiling tools, development workflows, etc.
Writing tools is arguably more boring and tedious compared to writing an engine, and that's where lots of "making a game with custom engine" type of project grinds to a halt
[1] https://ruoyusun.com/2025/04/18/game-sequel-lessons.html
(and the same is becoming more and more true for shader compilers vs 3D APIs - all the interesting stuff is happening in the shader compiler, while the 3D API is just there to kick off shaders and feed them with input data)
Either way, once you get the tooling up and running, the next big step is actually designing a game and creating all the content. :)
This depends a lot on the type of game that you create. For example, if a lot of content is procedurally generated, for example the map editor can be simpler, and you need less kinds of data formats to import. Also, some genres require a lot more "external content" than other genres. Even if you keep the genre constant, you will find games where the "value proposition" lies more in the game engine vs those where the "value proposition" lies in the assets.
In particular for indie games, you can be much more flexible on how you structure your game compared to AAA titles.
I wonder if there'd be any value in someone making a FOSS engine-agnostic editor designed to be as easy and powerful to adapt to any other engine/framework/etc as possible.
Although come to think of it, you could probably do most of that in Blender, so maybe such an thing already exists.
(1) Build a generic and extensible UI tool which at the core is a 3D scene viewer, object outliner and an asset browser (similar to how VSCode is such a tool for 'mostly text data' for 3D scenes). Implement anything else as engine specific plugins - Blender can be that tool, but it would be important to do a complete UI overhaul to get the modelling and animation features out of the way.
(2) Integrate the editor UI right into your engine, which is quite trivial with Dear Imgui - the tricky part here is that game state data should either be organized for editing, or for runtime performance. Mixing both isn't a good idea (unless moddability is a priority).
About a decade ago I would probably have opted for option (1), nowadays I tend towards option (2).
Unity, Godot, Unreal, Defold and others kind of get away with it, by having editors that work for most game types.
But also: a tool doesn't have to cover all bases, especially a free/FOSS one.
I see one problem (there very likely exist a lot of others) in the fact that a lot of frameworks and engines are "deep ecosystems" that take a lot of effort to get deeply into. Once inside the engine ecosystem, a lot of concepts are "very integrated/intertangled" (though not necessarily in the "best possible way").
So, a lot of implementation time will have to be invested for each individual supported engine so that the editor properly integrates with it.
I would really love something like it.
I’ve been doing Game Dev for the better part of 15 years now which is almost all of my career. I’ve been almost solely focused on building Tools and almost always building Editor internals and the interactions with the engine/assets systems.
There’s just so so much nuance to how editing works. You also want to be as close to how the engine will render so there’s also the need to either embed or have an api on your game to edit content live. People need hot reloading, people need things to look and act correct.
Just rendering a model accurately can be a challenge. Don’t get me started on animations
For example for 2d games it is possible to use Tiled as a level editor if you build your game (or some tool) to parse out tiled's file format and turn it into in-game levels.
A more general purpose editor in line with Unity or Godot's that includes the ability to attach functionality to everything would be much harder since the specifics of that will be much more engine specific.
And there are plenty of libraries and frameworks that can be pulled in to handle things like UI, compression, etc. The OP uses imGUI which is an excellent, small UI library for making in-game editors.
When choosing to go down that path you're not making, "an engine for all games." So there is a ton of work you're not doing.
And every external libary you do pull in, to ease some of the workload, is just waiting to go abandonend next year. So instead of focusing on release by that time, you will now focus on reinplementing that needed functionality that just stopped working.
Then we added "State machines as Lua exported from Excel". Rows are states, columns are events, cells are code to execute given a state+event combo. I've done this a few times. It makes huge state machines manageable.
Our games were very stats-heavy and our designers liked Excel. So, a new thing we added as "Dynamic data sources as grids of Lua exported from Excel". So, fill out Excel sheets like normal. But, instead of Excel script, every cell is evaluable Lua code. Strings, numbers, bools, functions are all values in Lua. So, a cell might contain a number. Or, it might contain a function checking the contents of two other cells and optionally triggering an event on some other object.
We shipped multiple games on a single executable using this system. Artists could lay out 3D scenes and 2D UIs with hooks for the Lua to control it. And, the designers could populate scenes and UIs from Excel dynamically according to the state of the game. The programmers mostly worked on game-agnostic features in C++, and the heavier side of scripting in Lua for game-specific features.
Aside: Lua is being so dynamically typed makes it not great for large-scale software engineering. But, https://teal-language.org/ might be a good TypeScript-For-Lua. I haven't tried it. Also, are there any Lua debuggers newer than the ancient https://github.com/unknownworlds/decoda that require zero integration? Decoda just need a pdb of your executable and it can automatically debug any scripts passing through the Lua library.
Eventually, we switched to Unity for corporate reasons. As a primary implementer of our custom engine, I think the switch was overall a good thing. Our games had started to outgrow what our little engine team could deliver. The artists reported they felt slightly less productive working in Unity's editor. I switched roles to finding and working around the undocumented bugs in Unity that we ran into. Then later finding which bugs had been fixed without being mentioned in the release notes so I could delete my work-arounds. It was a very boring couple of years until the company burned to the ground because of the same corporate reasons that lead us to switch to Unity :P
---
> The real meat & potatoes is all the tooling and content and asset pipelines around the engine.
When people talk about engines they often include the asset pipelines and editors by default. Engines today are not just a main loop + 3D API calls. Very few devs will say we're going to use Unity but only for its rendering code.
(Of course I'm not implying as long as you use Unity/Unreal you'll never need to write your own asset tools.)
Already the biggest market is small games on tablets/phones
Now making those games is becoming exponentially faster and easier
Roblox, allowing people to quickly create their own games, was already a huge hit. Now that experience is getting supercharged with AI
The article is about creating video games without an engine, and the top comment is about what is hard about making video games
My comment is about how all of that is changing right now and how the public is reacting to it
If it's the latter, I'd love to hear your perspective on how to build a successful indie game-development business!
I suspect it isn't since the competition is fierce, there has to be something beyond making a good game
Now that I’m quite a bit older, I have come to appreciate the game part a lot more - it’s maybe less techie, but it’s actually also why people make games. When I play with my kids then don’t see the tech - they see the game !
Thank you for writing this post, Noel!
When I start a new game I’m often paralised by the sheer volume of engines out there. When I first started making games all I had was GWBASIC…
If unity gets you making the thing or making the engine gets you making the thing, most important thing is motion.
You gotta avoid the paralysis and just pick the thing that seems feasible and start typing ;).
That sounds obvious but it really isn't. One example: maybe you don't need any object culling at all. Nobody tells you this. Anything you look up will talk about octrees, portals, clusters, and so on - but you might be totally fine just throwing everything at the renderer and designing your game with transitions at certain points. When you know your constraints, you're not guessing, you can measure and know for a fact that it's fine.
Another example: shader programming is not like other programming. There's no subclassing or traits. You have to think carefully about what you parameterize. When you know the look you're going for, you can hardcode a bunch of values and, frankly, write a bunch of shit code that looks just right.
The list goes on and on... maybe you don't need fancy animation blending when you can just bake it in an external tool. Maybe you don't need 3d spatial audio because your game world isn't built that way.
Thing is - when you're writing an _engine_ you need all that. You don't get to tell people writing games that you don't really need shadows or that they need to limit the number of game objects to some number etc. But when you're writing a _game_ (and you can call part of that game the engine), suddenly you get to tweak things and exclude things in all these ways that are perfectly fine.
Same idea applies to anything of course.. maybe you don't need a whole SQL database when you know your data format, flat files can be fine. Maybe you don't need a whole web/dom framework when you're just spitting out simple html/css. etc. etc.
I think this headspace is pretty common among gamedevs (iiuc large projects often copy/paste dependencies and tweak between projects rather than import and support a generic api too)
> Thing is - when you're writing an _engine_ you need all that. You don't get to tell people writing games that you don't really need shadows or that they need to limit the number of game objects to some number etc. But when you're writing a _game_ (and you can call part of that game the engine), suddenly you get to tweak things and exclude things in all these ways that are perfectly fine.
When you're making an engine it's perfectly fine to bake in constraints. Probably most famously PICO-8 does that very intentionally and is written by just one person. Similarly RPGMaker and a bunch of other 'genre specific' game engines also do this. It's just that everyone tries to make something super general purpose which is really a Sisyphean task.
That being said, games are kind of dead. The idea of spending another year or two on another indie game that barely cracks the top 50 for a couple days on an app store is... depressing. Going through the bureaucratic hoops to even get it there and maintain it seems like an exercise in self-torture. I'm kinda back to just making art in my spare time - screen savers, weird web experiences, one-off toys. I think having all my mini-engines in Flash suddenly deleted forever just made me realize how pointless it all was.
Maybe I just spent 20 years getting to be great at the wrong thing. I don't know of a historical parallel of someone spending their life perfecting an art that literally was burned down and blackholed overnight, in quite the same way. I imagine the scribes at Alexandria could at least have gone and scriven somewhere else the following year. So screw it, when I started learning code I was 8 and my brother was a CS major, he gave me his laptop to learn BASIC, and he said "we're just writing on sand." I finally learned that was true.
That said I have been pursuing the sustainable elements of gaming for years at this point, seeing the same issues - and for me what it comes down to is what I summarize as "the terrarium problem" - the bigger the software ecosystem you build the game over, the more of the jungle you have to port to the next platform du jour. When we approach gaming as a software problem it's just impossible, we can't support all the hardware and all the platforms.
But within that there are elements of "I can plan for this". Using tech that is already old is one way; Flash, for example, is emulated now. But if you go back to an earlier console generation or retro computers, you can find even more accuracy, better preservation. I took the compromise of "neo retro", since there are several SBCs around that mix old chips with new stuff - those have much more comfy specs to tinker with, while building on some old ideas. Tech that assumes less of a platform is another: I've taken up Forth, because Forth is the language that assumes you have to DIY everything, so it perpetuates ground-up honesty within your software, especially within a retro environment where there's no API layer to speak of and you have full control. And tech that has more of a standardized element is good: if something is "data structure portable", it's easier to recreate(this is why there are many homebrew ports of "Another World" - it's all bytecode).
The last piece of the puzzle in it is - okay, if I take things in that direction, how do I still make it fun to develop with? And that's the part I've been working on lately. I think the tools can be fun. Flash found some fun in it. But Flash as a model is too complex, too situated in just supplying every feature. PICO-8 is also fun, but very focused on a specific aesthetic. I think it's related to data models, conventions and defaults. Getting those things right clears the way.
They all feel like a ready made game that you add assets and mod. The problem for me is that I mostly don't want to make that game.
An analogy that comes to mind from the web dev world, it feels like the engines are like wordpress. Prebaked and ready to show content, but the moment your objective does not completely align with their preconfiguration you have to do a huge amount of hacking and workarounds.
All that might be acceptable for an adware befouled "idle RPG" style game on mobile (and they're all that kind of game these days). But it really galled me that people were using Unity so heavily for VR. It's extremely difficult to get a Unity game to work well on the standalone VR headsets. To hit the performance targets required by the Meta Quest Store, you really have to rewrite large portions of the engine to get around the fact that Unity is a disorganized, single-threaded, allocation-happy mess.
If you want your game to be a quality piece of software, you can't start with a garbage as your foundation.
And if you open Steam games and go to the newest, you see that nearly half of the releases is some version of a generic Unity/Unreal template game in a slightly altered "skin":
https://store.steampowered.com/app/2488370/Cash_Cleaner_Simu...
https://store.steampowered.com/app/2073910/A_Webbing_Journey...
https://store.steampowered.com/app/3498270/Better_Mart/
https://store.steampowered.com/app/2625420/Drive_Beyond_Hori...
https://store.steampowered.com/app/3163790/Toy_Shop_Simulato...
https://store.steampowered.com/app/3023600/Horse_Farm_Simula...
https://store.steampowered.com/app/3124550/Liquor_Store_Simu...
Not looking for a flame war, just knowledge
It's also cross-platform and has multiple deployment modes: you can ship the runtime and the program separately (good when you control the end-user machines, like in an enterprise settings), you can tree-shake the runtime and ship it with the program, or you can tree-shake the runtime and use the AOT compiler to ship a go-like native binary.
The JIT compiler is still better for long-running processes like servers, but for one-shot programs where the startup time is critical, like CLI tools and FaaS, the AOT compiler is really great.
I used to be up to date with .NET and Mono and stuff but I'm 10 years out of date
https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
I like Godot because of the UI primitives built into the engine. For a UI heavy simulation game like mine, the game engine does a lot of the heavy lifting. Sure, I don’t use 90% of the 2D/3D features of the engine, but that’s okay.
[0] https://store.steampowered.com/app/3627290/Botnet_of_Ares/
In OP's post as well he brings up some of the main factors that make modern C# incredible:
- Cross platform development (and runtime).
- NativeAOT Compiling (great for consoles, provided you have backend headers).
- Native Hot-reloading.
- Reflection
I'd also add:
- Source Generators
Modern C# is incredible. I think people still discount it due to its admittedly bad legacy, but the past five years of C# and CoreCLR development make me feel like it's truly a language that has everything necessary but isn't baroque or overburdened. My only major request, Union types, is also in proposal and will (hopefully) come in the next year or so:
https://github.com/dotnet/csharplang/blob/main/proposals/Typ...
I am familiar with low-level game engine stuff in C/C++, but always discarded C# as not being viable for cross-platform projects (as in game consoles). Guess I was wrong. :)
Does anyone have any first hand experience they would like to share? Is it easy to avoid the GC slowing down your game unexpectedly? Is it only a problem for a certain class of games?
An overview article: https://blog.applied-algorithms.tech/a-sub-millisecond-gc-fo...
Long discussion thread with many graphs with measurements: https://github.com/dotnet/runtime/discussions/115627
I don’t yet have hands-on experience with that Satori GC, though.
If you want to call what I added an "engine" it was more like a pedal-assist bike.
Too often I find "engines" end up driving the project/game. That is, you end up writing the game to the engine. It's why I've avoided Unity, etc. — high-level engines like that seem to guide you to writing the same game everyone else is writing — just with different assets.
Never mind you spend too much time, in my opinion, learning the engine and not getting the game written. To be sure there was a learning curve just pulling in SDL, but the curve was slight and it seemed more universally useful to know SDL as it can be employed in other cross-platform projects I might undertake — not just games.
[1] https://store.steampowered.com/app/2318420/Glypha_Vintage/
A few years ago, a notorious developer in the GameMaker community wrote a tool that added live reloading to it, and immediately it got widely adopted by big projects.
In terms of prototyping, I think an 'ideal' engine for extremely fast iteration would be something like GameMaker 8.1, but with hot reloading and slightly better window management inside the editor itself.
I don't share the core needs of the author though, I prefer using an engine with a built-in editor, specially in the beginning of a project. I really wanted to like Godot, by the abstractions it provides never 'clicked' with me. I can't think of a game like a bunch of nodes. That's unfortunate for me as Godot it the most popular free game engine AFAIK, with all the goods that comes with that.
I also really don't want to spend years mastering a proprietary tool again.
I fully concur, that was a great post. And on full time Linux, just incredible. Definitely it's given me the itch to try a few new things :)
As others say, getting data (Assets) in/out of the engine is the hard part. Especially as they are the real contribution to the shipped game been so large (unless smart compression, delivery optimisation is used, sadly not common).
They also documented their development a lot on their website and I think they have no problem to answer anything regarding developing own engine in their forum.
For example, you want to make and thumbnail picture of a 3d model/character. My first thought as a programmer on "correct" approach to that in UE was like well I need to setup a separate world with brand new lightning and have some renderer features off. The perfect "hack" for this is to have a separate "dressing room" under the level where the model teleports into and then back during single frame. Hundreds of such nuances can be only learned.
https://rosebud.ai/p/800a3295-ea07-4c80-a4f1-10fd8db24088
However, kids don't care too much about thought. They care a lot more about attention and fun
With these tools you get to the fun part faster and can give them a lot more attention
You also get to co-create with them and they get to express their creativity seeing results in realtime
My game YOYOZO is a tiny 39KB but made it to Ars Technica's "Best Games of 2023" list alongside heavyweights like Super Mario Wonder and Tears of the Kingdom! https://news.ycombinator.com/item?id=38372936
I love C#, and I acknowledge Github as the king of source control.
I make a new Repository a couple times a week, and use Visual Studio Code to clone it, and open a terminal and "dotnet new gitignore" and then use dotnet to make new projects all over the place...
On multiple machines, even. On a VM on my NAS. On my Windows machine. On my Windows laptop. On a VPS.
And I'm happy.
But how in the holy hell am I supposed to share code from one repository to another?
I want to make VikingCoderLib as a C# library (classlib), and drop in all of my favorite Extensions for generics and strings, and etc.
And then make another classlib for some of my Protocol Buffer utilities. And another classlib for setting up a terminal.js console for an app. And...
What's the best way to do that?
Submodules?
They really seem to suck. I can't easily make changes here, and use them there, without it being a huge pain in the rear.
Am I doing this wrong? Am I missing something?
Perhaps the only thing that sucks a bit about submodules, might be if you work with multiple people and some reference of a submodule is updated and you need to go into the submodule directory to update the reference locally. But I think that's the only thing, no big deal. I don't think you deal with this issue much when you work by yourself on a solo project, on a single machine.
It feels like there should be a good way to have a dotnet classlib in one repository, and use it from others, but it just doesn't feel like they fit together the way they should.
I want my code to be private...?
Someone who's coming from a different walk of life (say, an artist or a TTRPG designer trying to make a game) will obviously be much more productive with an off-the-shelf engine like GameMaker or Unity. They accept the engine with its editor as the only way to make a game and get cracking.
A programmer opens the editor and is presented with the 3D scene editor. "Nonono, where's main()?" they immediately ask. "Why is there a 3D scene editor if I want to procgen my levels?" "How do mods work?" "Who told you I needed physics simulation in my game by default?" "Running the game inside the editor is cool and all that, but I'd rather run the editor inside the game."
danielbarla•8h ago
At that point, of course, you don't need the engine. Having said that, every time I've really deep-dived into some particular feature of an engine - such as inverse kinematics and animation blending in Unreal - I've come away thinking "boy, am I glad I didn't spend several weeks trying to code that up from scratch".
There's definitely an argument to be made for minimalism and anti-bloat, but the reason engines are popular is that they really do some heavy lifting for you.
rishflab•8h ago
FABRIK IK algo is a ~100 loc function.
danielbarla•7h ago
rishflab•5h ago
audio can also have unending scope if you want to do physically simulated Spatial Audio.
Im not sure if AI/pathfinding are worth developing as part of an engine. I feel like their implementation is heavily dependant on the game type, engine implementations often get in the way, rather than helping.
rendering is a beast, especially if you need a long draw distance and have a world that doesnt fit into gpu memory.
The whole task of putting all the pieces together into a cohesive package is a huge undertaking as well.
canpan•8h ago
However, for my fun hobby 2D projects, I still self roll without dependency in the web canvas. You could call the browser an engine though.
billfruit•7h ago
Reinventing the wheel isn't that fun for most people.
pjc50•6h ago
StefanBatory•6h ago
Of course - sometimes you just need to learn how it works below, but if your goal is to ship, and you don't have a lot of time, then what I said strikes true to me.
ben_w•6h ago
I think this is also true beyond games, e.g. for all the different UI libraries.
bob1029•5h ago
I think a lot of developers lean on ideological angles to deflect rational criticism of their lack of progress and direction.
Unity and Unreal are absolute powerhouses if you have an actual idea and a burning desire to express it as quickly as possible to as many customers as possible.
aleph_minus_one•3h ago
If your game idea fits well into the structure of these engines: perhaps.
But I can tell you that lot of ideas that I have for games ("games" is to be understood in a somewhat more broader sense) don't fit these structures well. So I am very certain that for the game ideas that I have in mind, writing an own game engine would very likely be the better choice.
pjmlp•7h ago
This is a single bullet point on modern engines feature list.
gyomu•7h ago
pjmlp•5h ago
This kind of stuff is fun, if the end goal is to become a game engine or tools engineer, if the goal is to make a game, it is mostly yak shaving.
gyomu•7h ago
If your goal is several decades of a career as an independent developer (like OP), what is an investment of a few weeks for a) understanding a topic deeply and b) having source code that you deeply understand, 100% own, and can reuse across future projects?
ido•6h ago
My only regret were the times I tried to roll my own, I would have saved a lot of time and effort focusing on picking the best tool for the job that saved me as much work as possible.
At the end I want to make games and not engines, and only do as much programming as I have to. All those person-millennia spent at epic/unity/etc actually spent doing a lot of stuff (even if you don't need 90% of it, 10% 1000s of people working for decades is still a lot).
chickenzzzzu•6h ago
ido•5h ago
yakcyll•6h ago
I have decided a couple years back that my setup will have a hand-rolled physics engine, specifically for the reasons you outlined - having complete understanding over what the code does, how it's structured and how it manages data - but after starting actually-not-so-arduous process of getting it together, it quickly became rather clear that whatever I could implement would pale in comparison to solutions that are robust, field-tested and generally created by professionals.
Physics development in particular is known for wonky nonsense, but there are better and worse heuristics and ways to deal with their shortcomings; a handful of books and Youtube presentations still couldn't prepare me for the actual depth of the problems ahead. What I have now works, is relatively stable in initial demos and I am proud of it, I'm going to tweak and use it in the game I'm working on. It is however pretty obvious already that a lot of time is yet to be spent on massaging jank out of the equations.
I wholeheartedly recommend spending more than several weeks on implementing various subsystems if one either is generally interested in how these things work or silently wishes for that badge of honour (it shines brightly). However, as they say, if you want to make games, do NOT make an engine. Not just because of the time it takes - it doesn't have to take that much (even though it usually does) - but also because along with total control over the medium for expressing your creative vision, it gives you total responsibility for it as well. Sometimes it's better to work in the confines of rules set out by actual engine developers.
meheleventyone•6h ago
https://www.youtube.com/watch?v=zVmd2vmZrVA
But it's tightly scoped, there is only really one thing that needs to be dynamic, although it worked admirably with more. We wanted big impulses so could get away from questionable cases easily and could deal with crushing cases simply by exploding the ship.
Likewise the players on the ship running around and the players when they're jetpacking about are all different sub-sets of code implementing that specific behavior.
A lot of "make a game, not an engine" is working out what the minimal thing you need to build is rather than making everything extremely generalized.
danielbarla•6h ago
monkeyelite•1h ago
Either this is a central feature of your game, and writing it is worth it. Or it’s a technical boondoggle, and you don’t need it.
jayd16•1h ago
andrewflnr•1h ago
raincole•35m ago