4 ms·

Two years? Why does it take two years?

by andai 4mo ago

TheSamFischer 4mo ago
Unless you’ve written one before, it’s the natural learning curve. You can always generate one using LLM if you don’t care about how it actually works.
- dahart 4mo ago
  And if you have written one before, it might take five years. ;) At least, that was my actual experience at a game studio. The engine team wanted to rewrite the engine but underestimated how much was there, how much was worth keeping, and how much work needed to be done. But that was a long time ago, and the studio’s now on Unreal.
- flohofwoe 4mo ago
  > You can always generate one using LLM if you don’t care about how it actually works. Lol, right. That might work for some of the runtime parts of a very simple engine, but not the other 90%, especially when you "don't care about how it actually works". A game engine (like UE or Unity) easily exceeds the complexity of an entire desktop operating system (not necessarily in line count, but in number of features, their diversity and complexity).
  - TheSamFischer 4mo ago
    I’m certain there’s enough actual game engine code in the datasets that with enough token spend, you could have a platform layer, basic renderer, entities moving around. There would be absolutely no point in creating one over using one that exists and since there’s no learning that’ll come of it, it’s kinda wasting money.
    - flohofwoe 4mo ago
      Sure, but that part is only the "trivial 10%" of what's called a game engine these days. The actually important and much bigger part is the tooling.
      - TheSamFischer 4mo ago
        Absolutely. tooling is very rest of the owl when it comes to building something rather than just working with debug data.
legends2k 4mo ago
Two if you're lucky, and work full time on it. More like 5+ plus if you are inexperienced/part time.
flohofwoe 4mo ago
Because 90% of the work on an engine goes into the tooling (DCC tool exporters, asset pipelines, editor tools, ...), e.g. the "actual" engine runtime is just a small (and frangkly: quite trivial) thing dangling off the end of the asset pipeline. And game engine tools development is a never ending rabbit hole that's never quite finished (UI tools development got much easier though thanks to Dear ImGui). IME two years sounds about right starting from scratch until getting everything into a state that can be called a basic game engine (if a bit optimistic). You can start earlier building a game on the in-progress-engine of course and tbh that's the only way to not develop an entirely useless engine. But that way you'll also end up with an engine that's mostly only useful for that one game, and progress on the game will be atricious in the first year or so. And of course developing both side by side means spreading the butter even thinner. In the end though I have seen at least as many game projects fail using an off-the-shelf engine (in that case: Unity) compared to using an inhouse engine. The decision to use inhouse tech versus off-the-shelf engine doesn't make or break a game, in the end the failure always lurk within the team (but the engine is usually blamed first when things went south heh).

Two years? Why does it take two years?

by andai 4mo ago

Two years? Why does it take two years?

Unless you’ve written one before, it’s the natural learning curve. You can always generate one using LLM if you don’t care about how it actually works.

dahart 4mo ago
And if you have written one before, it might take five years. ;) At least, that was my actual experience at a game studio. The engine team wanted to rewrite the engine but underestimated how much was there, how much was worth keeping, and how much work needed to be done. But that was a long time ago, and the studio’s now on Unreal.
flohofwoe 4mo ago
> You can always generate one using LLM if you don’t care about how it actually works. Lol, right. That might work for some of the runtime parts of a very simple engine, but not the other 90%, especially when you "don't care about how it actually works". A game engine (like UE or Unity) easily exceeds the complexity of an entire desktop operating system (not necessarily in line count, but in number of features, their diversity and complexity).
- TheSamFischer 4mo ago
  I’m certain there’s enough actual game engine code in the datasets that with enough token spend, you could have a platform layer, basic renderer, entities moving around. There would be absolutely no point in creating one over using one that exists and since there’s no learning that’ll come of it, it’s kinda wasting money.
  - flohofwoe 4mo ago
    Sure, but that part is only the "trivial 10%" of what's called a game engine these days. The actually important and much bigger part is the tooling.
    - TheSamFischer 4mo ago
      Absolutely. tooling is very rest of the owl when it comes to building something rather than just working with debug data.

legends2k 4mo ago

Two if you're lucky, and work full time on it. More like 5+ plus if you are inexperienced/part time.

flohofwoe 4mo ago

Because 90% of the work on an engine goes into the tooling (DCC tool exporters, asset pipelines, editor tools, ...), e.g. the "actual" engine runtime is just a small (and frangkly: quite trivial) thing dangling off the end of the asset pipeline. And game engine tools development is a never ending rabbit hole that's never quite finished (UI tools development got much easier though thanks to Dear ImGui). IME two years sounds about right starting from scratch until getting everything into a state that can be called a basic game engine (if a bit optimistic). You can start earlier building a game on the in-progress-engine of course and tbh that's the only way to not develop an entirely useless engine. But that way you'll also end up with an engine that's mostly only useful for that one game, and progress on the game will be atricious in the first year or so. And of course developing both side by side means spreading the butter even thinner. In the end though I have seen at least as many game projects fail using an off-the-shelf engine (in that case: Unity) compared to using an inhouse engine. The decision to use inhouse tech versus off-the-shelf engine doesn't make or break a game, in the end the failure always lurk within the team (but the engine is usually blamed first when things went south heh).