After having worked on my own (2D) game engine [1] for about 5 years now and having worked on related stuff for paid work I'd like to explain one thing that many people might not find so obvious.
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.
And this is just a small sample of all the features and things that need to be done in order to be able to leverage the engine part.
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.
This is basically what I did a couple years ago [1]. SDL2 and a bit of C++ to create a "sprite" class. Some collision code in the sprite class...
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.
Many people often say that making an engine from scratch takes too long. But how long does it take to properly learn Unreal or Unity such that you can have an idea and turn it into a game without friction? Presumably, once your engine is finished, you are at that level of expertise instantly, which is a huge time saver. In my opinion, the more experienced of an engineer you are, the more the scales tip in the favor of rolling your own, from a time-spent perspective.
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.
> I genuinely believe making games without a big "do everything" engine can be easier, more fun, and often less overhead. I am not making a "do everything" game and I do not need 90% of the features these engines provide.
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.
I am always super curious to read such posts. They make me happy for no reason. I do not make games these days, but I love to read about excited and happy people explaining the process they love to do. At the same time I learn new perspectives to understand what is going on in the world of indie games. I keep this (not so) secret wish in the back of my head because I have to work for some money to support my family and my country (Ukraine). Maybe some time later I will do more of games...
I use Lua & Love2D to make games with a similar ethos. Being able to set my own constraints is fun, and that's what game dev is about for me. As soon as something stops being fun, I know I'm doing it wrong and there must be a better way.
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
For anything I have ever tried to make, I always find myself fighting the engine. Whether it is Godot, Unity or Unreal.
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.
Made me realize that most of the games I really enjoyed have their own custom engines (made for a single game or franchise): Starbound, Stardew Valley, Minecraft, Factorio, RollerCoaster Tycoon, Empire Earth, The Sims, Project Zomboid ...
Only exception might be Portal, but even that is using an in-house solution mostly for developed for one franchise.
Like with most things: If you are new and have to learn everything or if you actually need to pump titles out you should prefer quantity over quality and the major game engines are the way to go. But, if you really want to polish something it will require a long long time and then investing in engine development can pay off. The trap is starting with the later if you haven't made a few dozen games yet and never shipped anything. Then it will stay that way.
I agree with a lot of this, and am similarily working on my own code-only C# game framework meant as a spiritual successfor to XNA/Monogame (using Sokol instead of SDL):
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:
I like to start all my software projects from scratch. Everyone who are used to working on large software projects know that it's very slow. But starting from scratch is fast! You just implement the bare minimum. But also on later stages of the development when you have abstractions going, then it becomes even faster to implement new features. Working on an enterprise software project and your own engine that you've written from scratch is nothing alike, you can work 1000x faster when you have written the thing yourself and can just cut out and refactor everything you want. This is why I advocate micro service architecture and small teams. Things are much smoother when you do it yourself and from scratch. There are however landmines you have to hit and it will take years of trail and error until you get a feeling for what architecture and abstractions work and which doesn't as well as learning the in and outs of the language and platform you are working on.
Game engine is an art tool in the same way like Blender or Photoshop are. You have to learn its tips and tricks the same way artists do. Usually programmers consider anything that does not have a dedicated UI as fatal flaw hence all the bias towards big engines.
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.
I'm an indie game developer with over 10 years of experience. I'm not using Unity or Unreal, but I do have some frameworks that handle things like rendering graphics or playing audio. However, I write all the game logic, data manipulation, and entity management from scratch for each game I make. It seems to be the smoothest option for me, since I have full control over how my games actually operate, but I don't have to reinvent the wheel as far as the low-level architecture goes.
- If you're building an engine without a game in mind, you're just going to end up with tools you don't use.
- If you have a game you want to see to the end, and make an engine for it, you're going to build exactly what you need and nothing else. With the bonus of having lots of code you can reuse for the next project.
All that said I'm sticking with Godot since I have limited time, and if I want to bang out a quick gameplay idea to see if it even works, I don't want to start from nothing. (I say all this after building a 2.5D-ish engine with c# and monogame)
From the limited game dev experience I have/had, my recommendation is to introspect whether building the tech is just fun escapism from working on the really hard part of game dev: designing something that's really fun to play.
Building your own engine may "feel" like progress but it isn't. A fun game loop implemented with the most rudimentary frameworks, (or sometimes even pen and paper!) is more valuable than just a fancy custom engine implementation without a fun game mechanic.
Very often I find some friends of mine still in gamedev getting sidetracked by the intellectual stimulation that building tech gives them (because they are programmers) and burn out before they actually design/discover a fun game mechanic that they can actually ship a game with.
All this is ofcourse assuming you want to make money off your game. If you are just having fun with a hobby project or doing it to hone your programming skills, go nuts with the custom game engine code; more power to you!
That was a great post. I had no idea modern .NET had hot-reloading built-in like that. From my experience programming games, that's the biggest time saver you can ask for. Does it work well (or at all) with Godot/C#?
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 believe a majority of prospective game developers got into it because of interest in game engine development. For such people, Unreal/Unity/Godot take all the fun out of game dev.
It really feels like all the open-source projects are getting more and more capable. I recently went back to fedora linux on my desktop and the nvidia support is so much better on there than it was even a year or two ago. Hyprland is such a smooth wm that wasn't around even a few years ago. I've been using wgpu for cross-platform GPU rendering, but I've heard about SDL3's recent official release, and I really want to try out those GPU rendering capabilities. What a time to be alive.
It's refreshing to see someone advocate for small, custom tooling not from a "purist”"standpoint but because it's actually fun and practical for their workflow
That was a very fun read! While I’m using Godot for my hacking simulator game, Botnet of Ares [0] I think the native C# approach is very much justified in this case, and Noel clearly has had massive success with Celeste.
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.
I really miss the days of Flash when I could write lots of mini-engines as needed (e.g. platformers or side scrollers or 2.5D, multiplayer, chat ... all hand coded but reusable) and rely on being able to mix lots of different pipelines for vector art, bitmaps, 3D, audio and UI. There's nothing like that now. I tried to reinvent a few wheels. But at this point... a fairly low level (for script) rendering library like PixiJS is really the best we have. No frameworks, please.
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.
Good example of game with custom game engine is Factorio.
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.
One of my first bigger programming projects was a side-scroller in Processing. Processing.org was an amazing way to get into programming since you could draw onto the screen with minimal code.
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.
As a "for fun" side project, I've started building clones of retro classics in Pygame as a way to help beginners gain knowledge of procedural game dev fundamentals.
Python seems like a nice entry point and Pygame works well for the 2D classics like Frogger or Defender or Dig Dug or whatever. It's a lot of fun, but, woah! It's a lot more work than I was expecting.
If you're serious about making video games, you should probably be using a commercial engine. Period. No exceptions. Unless you're EA or Microsoft, you're just not going to develop a custom engine that can compete with Unity and Unreal. You may be able to write a good basic rendering pipeline and event loop, but the major engines have enormous ecosystems of tooling and talent, ready to go, and they're available across all major platforms including proprietary consoles. Things will go much, much easier for you if you just use those.
If you're just fucking around, do what you want, but if you actually want to ship, it's Unity or Unreal all the way.
And no, I don't think Godot is "there" yet. If Unreal is Photoshop, then Unity is Photopea and Godot is GIMP.
Game dev here, building a game using the "engine-only" version of PlayCanvas (a 3d engine). Asset loading, rendering, physics, object management, update loops, raycasting is all handled by the engine (js). My code is everything else, including a low-tech drag and drop scene editor.
I've got to say it's the deepest I've ever been in the abstraction stack for building a game. I have to hand build everything. I definitely wouldn't want to write engine code itself unless I was building an engine; building a good engine takes heaps of engineering and time which I don't have.
I will say though, I absolutely love the level of fine control I have over every aspect of my game (when compared say to a Unity game or even a PlayCanvas game built by their editor).
Since you've been making games for 20 years, I'm guessing you're at least in your thirties. Just curious - do you develop games purely as a hobby, or are you able to make a living from it?
If it's the latter, I'd love to hear your perspective on how to build a successful indie game-development business!
I recently wrote a game in Javascript (2D; Canvas). I was amazed at how simple it was and how performant plain-old-Javascript and Javascript objects were. Despite thousands of animating things moving on screen, and animated stereo audio, I couldn't get the frame rate to spill over an animation frame.
Making a video game "without an engine" is basically another way to say "making your own game engine". Which is a fine thing to do, but you're "just" making a bespoke engine for one game (or series of games). Sometimes those engines get large enough to be used by others. That's why it's called "Unreal Engine", because it has heritage in the Unreal games.
I really liked this post. I've recently been learning OpenGL and C++, and the libraries surrounding it, like ImGui, which I like using a lot !
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 author says that they tend to load all of the assets on init. This sidesteps the issue of the C#'s garbage collector (GC). I am not a C# developer, but seem to recall reading that GC can cause unexpected slow downs. Web search shows articles on tips and tricks for optimizing GC in C#, so it seems like a real issue.
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?
That's kind of an engine though ? An engine is just a bunch of low level types, DS, algos that go onto build mid level abstractions that go onto form systems. In this case you can argue the game itself (aka the runtime) is the game engine?
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).
A lot of the time the indie game developer is a former professional programmer. This of course affects how they interact with the game development process.
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."
there is a minor mistake in this.." their minds jump to what it looked like circa 2003 - a closed source, interpreted, verbose...", C# was never interpreted. From the beginning, C# code has always been compiled to Intermediate Language (IL), which is then JIT-compiled by the .NET CLR at runtime.
I've never delivered a game anyone's really paid for, so take with a grain of salt, but imho the big win when you are writing your own stuff is you get to decide what not to include.
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)
Isn't that a huge effort? I remember few games which developed their own game engines from scratch (factorio, limbo, bg3). But, wouldn't it be easier and better to use game engines like godot?
Please help me figure out the best way to share code between Github repositories...
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.
Making video games (without an engine) in 2025
(noelberry.ca)561 points by selvan 20 May 2025 | 244 comments
Comments
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:
And this is just a small sample of all the features and things that need to be done in order to be able to leverage the engine part.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.
[1] https://github.com/ensisoft/detonator
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/
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.
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.
Thank you for writing this post, Noel!
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
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.
Only exception might be Portal, but even that is using an in-house solution mostly for developed for one franchise.
Like with most things: If you are new and have to learn everything or if you actually need to pump titles out you should prefer quantity over quality and the major game engines are the way to go. But, if you really want to polish something it will require a long long time and then investing in engine development can pay off. The trap is starting with the later if you haven't made a few dozen games yet and never shipped anything. Then it will stay that way.
https://zinc.graphics/
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...
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.
- If you're building an engine without a game in mind, you're just going to end up with tools you don't use.
- If you have a game you want to see to the end, and make an engine for it, you're going to build exactly what you need and nothing else. With the bonus of having lots of code you can reuse for the next project.
All that said I'm sticking with Godot since I have limited time, and if I want to bang out a quick gameplay idea to see if it even works, I don't want to start from nothing. (I say all this after building a 2.5D-ish engine with c# and monogame)
Building your own engine may "feel" like progress but it isn't. A fun game loop implemented with the most rudimentary frameworks, (or sometimes even pen and paper!) is more valuable than just a fancy custom engine implementation without a fun game mechanic.
Very often I find some friends of mine still in gamedev getting sidetracked by the intellectual stimulation that building tech gives them (because they are programmers) and burn out before they actually design/discover a fun game mechanic that they can actually ship a game with.
All this is ofcourse assuming you want to make money off your game. If you are just having fun with a hobby project or doing it to hone your programming skills, go nuts with the custom game engine code; more power to you!
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 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/
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.
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.
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.
Python seems like a nice entry point and Pygame works well for the 2D classics like Frogger or Defender or Dig Dug or whatever. It's a lot of fun, but, woah! It's a lot more work than I was expecting.
If you're just fucking around, do what you want, but if you actually want to ship, it's Unity or Unreal all the way.
And no, I don't think Godot is "there" yet. If Unreal is Photoshop, then Unity is Photopea and Godot is GIMP.
I've got to say it's the deepest I've ever been in the abstraction stack for building a game. I have to hand build everything. I definitely wouldn't want to write engine code itself unless I was building an engine; building a good engine takes heaps of engineering and time which I don't have.
I will say though, I absolutely love the level of fine control I have over every aspect of my game (when compared say to a Unity game or even a PlayCanvas game built by their editor).
If it's the latter, I'd love to hear your perspective on how to build a successful indie game-development business!
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
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?
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).
Not looking for a flame war, just knowledge
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."
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)
I used to be up to date with .NET and Mono and stuff but I'm 10 years out of date
https://rosebud.ai/p/800a3295-ea07-4c80-a4f1-10fd8db24088
https://openjam.ai/lonely_ant_702/v3nyt4if54
https://rosebud.ai
https://openjam.ai/
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?