7 ms·

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 man

by samiv 1y ago

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. [1] https://github.com/ensisoft/detonator https://github.com/ensisoft/detonator

NotGMan 1y ago
This. 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.
- jeffhuys 1y ago
  Even factorio started out on tried-and-tested libraries before moving away from them primarily because of optimization concerns (right?)
  - xandrius 1y ago
    Yep, people forget one of the core notions of development which is not to prematurely optimise stuff. Especially something as complex as a game. Keep it super simple. Or that game will never come out.
    - ms-menardi 1y ago
      some games require a certain level of scale and for those games you should optimize in the pre-planning stage.
      - brulard 1y ago
        I think you are missing the point. The larger the scale is, the more things may be optimized and the more you need to be careful to focus on the important "3%". That said, it doesn't hurt to analyse in advance which parts might be critical and steer the architecture based on those observations.
      - xandrius 1y ago
        Statistically speaking, 99% of game devs won't ever make a game like that. And if they do, they will probably know ahead of time they are making it.
        danielscrubs 1y ago
        100% of hobby game devs do it as a hobby. The learning process is the fun part. Which is also why 99% give up on their game when they see more learning potential in another area.
    - meheleventyone 1y ago
      The full quote is: > 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.
- monkeyelite 1y ago
  > using your own engine will probably kill you commercially. 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.
- dismalaf 1y ago
  Visual editors are a waste of time. For 2D, lots of solutions exist (Tiled for example). For 3D, you can use Blender as your editor. The key to making no engine work is to make only what you actually need.
  - whstl 1y ago
    That’s a great idea. I have limited experience scripting Blender, but there is a BPY API to add custom panels, so adding metadata to “entities” and simplifying the export workflow is probably feasible to the point it will be very close to an editor.
    - dismalaf 1y ago
      Even without scripting Blender, GLTF is a "scene" format. GLTF files hold information about models, textures, lights, etc... So you can create your scene then import straight into your game with GLTF (open source, super common). And of course since Blender is used for movies, it does scenes well already.
  - Supermancho 1y ago
    Visual editing is how all UI is designed. It's not a waste of time. Visual editing is the primary way to prototype, which means it's heavily used at the beginning and less as development goes forward. Projects have some process to translate the prototypes into scaffolding UI in the Editor, then modify with state where necessary. This pipeline is common across all types of software.
    - dismalaf 1y ago
      Sorry, I thought the context was clear given the parent. Making your own visual editor is a waste of time when ones exist that will output a format you can simply put into your game.
  - johnnyanmac 1y ago
    > For 3D, you can use Blender as your editor. Really depends on the team size, composition, and game. If you have designers on the team who aren't dedicated programmers, I don't think blender will cut it for them.
interludead 1y ago
Yep, the tooling is where the real grind (and magic) happens
insraq 1y ago
I have recently done an engine rewrite for my sequel game and I very much agree with this. In my postmortem[1], I wrote: > 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 https://ruoyusun.com/2025/04/18/game-sequel-lessons.html
- philistine 1y ago
  So that’s where Chris Robert’s billion dollar went.
flohofwoe 1y ago
I keep saying that the engine is just that little runtime attachment dangling off the end of the asset pipeline ;) (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)
leonard-somero 1y ago
It really is a miracle that any video games get shipped at all.
pwitvoet 1y ago
Writing an editor from scratch is a lot of work. That's one reason why I would use an existing editor whenever possible. For example, TrenchBroom (Quake editor) + func_godot seems to be getting more popular among Godot users, and Tiled looks pretty good for 2D games. For game data management I've seen CastleDB (never used it though), which now seems to be integrated into Hide, a full-blown 3D editor. Either way, once you get the tooling up and running, the next big step is actually designing a game and creating all the content. :)
Keyframe 1y ago
Not saying it's a lot less work, it's still a ton of work, but you could always build your tooling around a DCC application by either extending it with scripts or modifying or attaching parts to it like Blender, Maya, etc. Maybe even flat out game engine editors like Godot, Unity, Unreal to build stuff and export out to be used by your own engine.
aleph_minus_one 1y ago
> The real meat & potatoes is all the tooling and content and asset pipelines around the engine 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.
Llamamoe 1y ago
> 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: 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.
- zoky 1y ago
  The problem is that the type of assets you need to design varies tremendously depending on the type of game you’re making. A 2D pixel-art platformer, a multiplayer FPS, a top-down strategy sim, and a puzzle game are all going to require completely different types of assets with unique design requirements. You’d need an all-singing-and-dancing tool that probably wouldn’t be as good at any one thing as the existing specialized tools, FOSS or otherwise. Although come to think of it, you could probably do most of that in Blender, so maybe such an thing already exists.
  - flohofwoe 1y ago
    There's basically two paths: (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).
    - whstl 1y ago
      I feel like path #1 would also run into the same problems as #2 as soon as there was any need for real-time editing of scenes.
  - whstl 1y ago
agentultra 1y ago
Keep in mind that when writing your own "engine," you don't need it to be as general as possible to handle every possible kind of game. You just need it to handle your game. 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.
- lukan 1y ago
  It is still a lot of work. 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.
  - agentultra 1y ago
    Definitely, it’s a trade off. Pulling in dubious dependencies can be a risk. Might be worth writing your own library or forking the dependency and vendoring it in your source. There’s a spectrum of options here.
  - Narishma 1y ago
    > So instead of focusing on release by that time, you will now focus on reinplementing that needed functionality that just stopped working. That makes no sense. A library being abandoned doesn't mean it suddenly stops working.
    - Balooga 1y ago
      The library would continue to work but may no longer be usable if other dependencies require a later version of "n" that the abandoned library is incompatible with. Ruby or Python runtimes are the classic example.
    - johnnyanmac 1y ago
      Support for any studio larger than a few people is the most important part of 3rd party tools. If (and inevitably, when) a tool has a bug or can't do something you need, there's reassurance being able to tell someone else to fix the problem. Using abandoned tools either means you're very sure all use cases are covered, or that your own engineers are willing to hack around should it not be sufficient. And I think anyone who works with legacy code knows that navigating already written codebases without guidance can take just as long as whipping up a custom implementation.
corysama 1y ago
At the indie studio I used to work at, we had some folks with engine experience. So, we rolled our own 3D engine and asset pipeline from scratch. But, we didn't have the budget for an editor. Instead we set up the asset pipeline to hot-reload everything. Meshes, scenes, materials and animations from Maya. Textures from Photoshop. Audio as a pile of WAVs. Scripting in Lua. UI layout in XML. Changing the asset files would change the game live. 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/ 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 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
- wsc981 1y ago
raincole 1y ago
> Engines are the easy part. > 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.)
nico 1y ago
Vibecoding is probably going to take this whole industry by storm 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
- raincole 1y ago
  [flagged]
  - nico 1y ago
    Such a hostile comment. Just trying to open up the conversation. No need for snark or aggressive name calling 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
    - yua_mikami 1y ago
      Nah he's right, people are fed up of hearing about AI all the time, it's off topic here.
    - iFire 1y ago
      Even if you vibe code a game engine your best llm will need to do the work of world class technical team of like 12 people, you’ll need to get 10-20 teams to be able to find that dataset. Each run costing a few million usd.
      - nico 1y ago
        Not sure what that use case is. Why would you need all of that? As an individual, if you are just trying to build a basic game with your kids you don't need to build a whole engine nor a world class technical team or a huge dataset You can either use chatgpt or something more basic like openjam.ai or something specialized like rosebud.ai Maybe the people at rosebud.ai have been doing what you are suggesting to build their platform
glouwbug 1y ago
The engine is the fun part. Assets and game design are near impossible as a solo dev
- johnnyanmac 1y ago
  Impossible but necessary. It's the big difference between an engine programmer and an indie dev. The latter needs to wear multiple hats to get something out while the former can specialize and work within a team of other specialists.
- rienbdj 1y ago
  I somewhat agree. Good game design requires a great idea, but more than that a lot of iteration. If you are working solo you need to hold the implementation and design in your head, which is incredibly difficult. Iteration is slow. You need someone to bounce ideas off of. The best indie combo is a programmer plus a designer/artist in my opinion. Alternatively, you can spend a very long time iterating solo. Most don’t have the runway for this. This is also why big studios produce technically impressive games with mechanics seen thousands of times before. The production risk is much lower for “make spectacular assets” than for “come up with a novel game mechanic”.
qingcharles 1y ago
When I was a game dev I spent way more time on tools than on the engine. Those days of small teams are gone now, so at least in a professional setting you are likely to be able to concentrate on the engine while some other person has to build the editors.
cypherpunk666 1y ago
Word! i've done some ground-up 2D games with no engine library. So i hand-rolled resources, frame rate, collision, simple physics, etc. One has no graphics assets. Another other does. https://github.com/raould/pn0gstr0m https://github.com/raould/pn0gstr0m https://github.com/raould/sheepgate https://github.com/raould/sheepgate
ocornut 1y ago
> 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: The sum of all those parts IS the actual meat of the engine imho. People mistakenly assume that rendering something and having a Dear ImGui frontend constitute an engine but it's only the tip of iceberg. Actual real world issues, productivity concerns, getting shit done is the meaningful work.

by samiv 1y ago

NotGMan 1y ago

This. 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.

jeffhuys 1y ago
Even factorio started out on tried-and-tested libraries before moving away from them primarily because of optimization concerns (right?)
- xandrius 1y ago
  Yep, people forget one of the core notions of development which is not to prematurely optimise stuff. Especially something as complex as a game. Keep it super simple. Or that game will never come out.
  - ms-menardi 1y ago
    some games require a certain level of scale and for those games you should optimize in the pre-planning stage.
    - brulard 1y ago
      I think you are missing the point. The larger the scale is, the more things may be optimized and the more you need to be careful to focus on the important "3%". That said, it doesn't hurt to analyse in advance which parts might be critical and steer the architecture based on those observations.
    - xandrius 1y ago
      Statistically speaking, 99% of game devs won't ever make a game like that. And if they do, they will probably know ahead of time they are making it.
      - danielscrubs 1y ago
        100% of hobby game devs do it as a hobby. The learning process is the fun part. Which is also why 99% give up on their game when they see more learning potential in another area.
  - meheleventyone 1y ago
    The full quote is: > 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.
monkeyelite 1y ago
> using your own engine will probably kill you commercially. 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.
dismalaf 1y ago
Visual editors are a waste of time. For 2D, lots of solutions exist (Tiled for example). For 3D, you can use Blender as your editor. The key to making no engine work is to make only what you actually need.
- whstl 1y ago
  That’s a great idea. I have limited experience scripting Blender, but there is a BPY API to add custom panels, so adding metadata to “entities” and simplifying the export workflow is probably feasible to the point it will be very close to an editor.
  - dismalaf 1y ago
    Even without scripting Blender, GLTF is a "scene" format. GLTF files hold information about models, textures, lights, etc... So you can create your scene then import straight into your game with GLTF (open source, super common). And of course since Blender is used for movies, it does scenes well already.
- Supermancho 1y ago
  Visual editing is how all UI is designed. It's not a waste of time. Visual editing is the primary way to prototype, which means it's heavily used at the beginning and less as development goes forward. Projects have some process to translate the prototypes into scaffolding UI in the Editor, then modify with state where necessary. This pipeline is common across all types of software.
  - dismalaf 1y ago
    Sorry, I thought the context was clear given the parent. Making your own visual editor is a waste of time when ones exist that will output a format you can simply put into your game.
- johnnyanmac 1y ago
  > For 3D, you can use Blender as your editor. Really depends on the team size, composition, and game. If you have designers on the team who aren't dedicated programmers, I don't think blender will cut it for them.

interludead 1y ago

Yep, the tooling is where the real grind (and magic) happens

insraq 1y ago

I have recently done an engine rewrite for my sequel game and I very much agree with this. In my postmortem[1], I wrote: > 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 https://ruoyusun.com/2025/04/18/game-sequel-lessons.html

philistine 1y ago
So that’s where Chris Robert’s billion dollar went.

flohofwoe 1y ago

I keep saying that the engine is just that little runtime attachment dangling off the end of the asset pipeline ;) (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)

leonard-somero 1y ago

It really is a miracle that any video games get shipped at all.

pwitvoet 1y ago

Writing an editor from scratch is a lot of work. That's one reason why I would use an existing editor whenever possible. For example, TrenchBroom (Quake editor) + func_godot seems to be getting more popular among Godot users, and Tiled looks pretty good for 2D games. For game data management I've seen CastleDB (never used it though), which now seems to be integrated into Hide, a full-blown 3D editor. Either way, once you get the tooling up and running, the next big step is actually designing a game and creating all the content. :)

Keyframe 1y ago

Not saying it's a lot less work, it's still a ton of work, but you could always build your tooling around a DCC application by either extending it with scripts or modifying or attaching parts to it like Blender, Maya, etc. Maybe even flat out game engine editors like Godot, Unity, Unreal to build stuff and export out to be used by your own engine.

aleph_minus_one 1y ago

> The real meat & potatoes is all the tooling and content and asset pipelines around the engine 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.

Llamamoe 1y ago

> 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: 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.

zoky 1y ago
The problem is that the type of assets you need to design varies tremendously depending on the type of game you’re making. A 2D pixel-art platformer, a multiplayer FPS, a top-down strategy sim, and a puzzle game are all going to require completely different types of assets with unique design requirements. You’d need an all-singing-and-dancing tool that probably wouldn’t be as good at any one thing as the existing specialized tools, FOSS or otherwise. Although come to think of it, you could probably do most of that in Blender, so maybe such an thing already exists.
- flohofwoe 1y ago
  There's basically two paths: (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).
  - whstl 1y ago
    I feel like path #1 would also run into the same problems as #2 as soon as there was any need for real-time editing of scenes.
- whstl 1y ago

agentultra 1y ago

Keep in mind that when writing your own "engine," you don't need it to be as general as possible to handle every possible kind of game. You just need it to handle your game. 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.

lukan 1y ago
It is still a lot of work. 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.
- agentultra 1y ago
  Definitely, it’s a trade off. Pulling in dubious dependencies can be a risk. Might be worth writing your own library or forking the dependency and vendoring it in your source. There’s a spectrum of options here.
- Narishma 1y ago
  > So instead of focusing on release by that time, you will now focus on reinplementing that needed functionality that just stopped working. That makes no sense. A library being abandoned doesn't mean it suddenly stops working.
  - Balooga 1y ago
    The library would continue to work but may no longer be usable if other dependencies require a later version of "n" that the abandoned library is incompatible with. Ruby or Python runtimes are the classic example.
  - johnnyanmac 1y ago
    Support for any studio larger than a few people is the most important part of 3rd party tools. If (and inevitably, when) a tool has a bug or can't do something you need, there's reassurance being able to tell someone else to fix the problem. Using abandoned tools either means you're very sure all use cases are covered, or that your own engineers are willing to hack around should it not be sufficient. And I think anyone who works with legacy code knows that navigating already written codebases without guidance can take just as long as whipping up a custom implementation.

corysama 1y ago

At the indie studio I used to work at, we had some folks with engine experience. So, we rolled our own 3D engine and asset pipeline from scratch. But, we didn't have the budget for an editor. Instead we set up the asset pipeline to hot-reload everything. Meshes, scenes, materials and animations from Maya. Textures from Photoshop. Audio as a pile of WAVs. Scripting in Lua. UI layout in XML. Changing the asset files would change the game live. 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/ 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 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

wsc981 1y ago

raincole 1y ago

> Engines are the easy part. > 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.)

nico 1y ago

Vibecoding is probably going to take this whole industry by storm 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

raincole 1y ago
[flagged]
- nico 1y ago
  Such a hostile comment. Just trying to open up the conversation. No need for snark or aggressive name calling 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
  - yua_mikami 1y ago
    Nah he's right, people are fed up of hearing about AI all the time, it's off topic here.
  - iFire 1y ago
    Even if you vibe code a game engine your best llm will need to do the work of world class technical team of like 12 people, you’ll need to get 10-20 teams to be able to find that dataset. Each run costing a few million usd.
    - nico 1y ago
      Not sure what that use case is. Why would you need all of that? As an individual, if you are just trying to build a basic game with your kids you don't need to build a whole engine nor a world class technical team or a huge dataset You can either use chatgpt or something more basic like openjam.ai or something specialized like rosebud.ai Maybe the people at rosebud.ai have been doing what you are suggesting to build their platform

glouwbug 1y ago

The engine is the fun part. Assets and game design are near impossible as a solo dev

johnnyanmac 1y ago
Impossible but necessary. It's the big difference between an engine programmer and an indie dev. The latter needs to wear multiple hats to get something out while the former can specialize and work within a team of other specialists.
rienbdj 1y ago
I somewhat agree. Good game design requires a great idea, but more than that a lot of iteration. If you are working solo you need to hold the implementation and design in your head, which is incredibly difficult. Iteration is slow. You need someone to bounce ideas off of. The best indie combo is a programmer plus a designer/artist in my opinion. Alternatively, you can spend a very long time iterating solo. Most don’t have the runway for this. This is also why big studios produce technically impressive games with mechanics seen thousands of times before. The production risk is much lower for “make spectacular assets” than for “come up with a novel game mechanic”.

qingcharles 1y ago

When I was a game dev I spent way more time on tools than on the engine. Those days of small teams are gone now, so at least in a professional setting you are likely to be able to concentrate on the engine while some other person has to build the editors.

cypherpunk666 1y ago

Word! i've done some ground-up 2D games with no engine library. So i hand-rolled resources, frame rate, collision, simple physics, etc. One has no graphics assets. Another other does. https://github.com/raould/pn0gstr0m https://github.com/raould/pn0gstr0m https://github.com/raould/sheepgate https://github.com/raould/sheepgate

ocornut 1y ago

> 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: The sum of all those parts IS the actual meat of the engine imho. People mistakenly assume that rendering something and having a Dear ImGui frontend constitute an engine but it's only the tip of iceberg. Actual real world issues, productivity concerns, getting shit done is the meaningful work.