Screwing around with tooling and languages seems to be a common pitfall to not finishing a game.
Why not just use the best ecosystem like Unreal/Unity and get the game out of the door fast?
That said, I think many of the decisions towards his rewrite in Jai seems to come from him picking the wrong language (D) at the start. He should have sticked with C++ in the first place, even with all its warts and complexities. It's a proven language that has shipped countless games, have tons of tooling developed around it, and provides one of the biggest ecosystems available to a game developer (and unlike D, has debuggers that actually work!). And you can certainly improve compile times a lot by using unity builds, managing your header dependencies well, and not going too overboard with templates (though I agree this can become a major pain point, especially if you're using a laptop).
But at what cost? Using Unity/Unreal incur the cost of lower flexibility in your design, more time spent learning "the unreal way"/"the unity way", and a finished product that looks and feels like every other unity/unreal game.
Of course the argument for unity/unreal is also true: Building your own game engine takes lots and lots of time.
So it's a tradeoff, like all things.
UnrealScript has long been dropped in favour of C++, but I'm pretty sure Unreal Engine wouldn't exist today, or would be a very different beast, if it hadn't been for UnrealScript and the Unreal Editor being bundled with the original Unreal and its sequels/follow-ups, and Tim's personal interest and research into how programming languages might improve game development, in much the same way that Jonathan Blow is doing now.
Can I assume your use of the phrase "this person" means you are unfamiliar with Mr Blow, and his track record in game development? You might want to look him up -- he's an interesting character and has developed some interesting and influential games.
Not OP, but I'm fairly sure "this person" refers to the blog post author, not JB.
laughable. absolutely laughable.
I'm not even talking about politics of using an engine versus writing one; unity and unreal are complex tools with their own problems. if you value what you are producing, and if you value quality and you want your game to be just the way you want it, Unity and Unreal will fight you just as hard as D or C++ have been for the blog author.
Unity/Unreal are also simply not capable of a lot of things. They are definitely not a pure win for someone making a game.
Edit: The only style I would think would be infinite/strange geometry, like Manifold garden (great game!). But, it’s Unity.
They are very difficult to use if the game play semantics are complicated and require lots of interaction with world state or world geometry. If you're making a common FPS, they are great.
Could you give an example? I’m trying to understand what the limits look like. It appears to be trivial to you, but for someone outside of game design, I can’t imagine what those might be.
We ended up implementing more and more tooling outside the engine, and there comes a point where UE4 became a IO/Rendering system. We'd've been happier if the engine were modular in design from the get-go.
> we found that pushing gameplay systems beyond the prototype stage would require more and more effort
I understand that you're saying that some systems exist that can't work. I'm trying to understand what those systems would look like, and how the user would see it as being different. Do you have an example of the system/mechanic that can't work?
A game that doesn't require a multi-gigabyte download and a top-tier GPU and CPU to render stuff in 2D? ;)
There are many reasons people might want to opt out of existing game engines: full control over rendering pipelines, assets and dev. experience might be some of them.
Besides that there are multiple games where people use their own engines:
- Possibly among some of the most technically complex ones are Factorio (e.g. https://www.youtube.com/watch?v=zRYQcVb_5W0) and Noita (where every single pixel in the humongous world is simulated https://www.youtube.com/watch?v=prXuyMCgbTc)
- Among the AAA-level crowd there's Decima (Death Stranding https://www.youtube.com/watch?v=tCI396HyhbQ and Horizon Zero Dawn https://www.youtube.com/watch?v=u4-FCsiF5x4) and REDEngine (Witcher 3 https://www.youtube.com/watch?v=YdHc3JZixRY, Cyberpunk 2077 https://www.youtube.com/watch?v=BO8lX3hDU30)
- There are smaller ones like Monkey X (Crypt of the Necrodancer, https://www.youtube.com/watch?v=u_avgU1u6yM)
- There are bigger ones like Clausewitz (basically all of Paradox Interactive's games like Crusader Kings https://www.youtube.com/watch?v=0M9qKVCl6HQ and Stellaris https://www.youtube.com/watch?v=eoAkomMEFQo)
In general, once you know what you're doing it sometimes pays to develop your own engine that is specific to what you're doing. Unity and Unreal are generalist enines that you still to bend to your will to do what you need to do and may have opinionated setups of things that are hard to work around, or maybe are omitted from the engine, or just plain don't allow you to do.
This I was my question, and its context in this thread.
From this list, I suspect Noita is the only one that couldn’t be achieved with Unity or Unreal. That’s a good example!
It’s really not laughable.
I’ve made games with off-the-shelf engines and I’ve made games using just code and libraries. Sometimes not even libraries.
The main concern here is that you have a limited amount of time to work on your game. Some people try to sidestep this concern by saying that they’ll “spend as much time as it takes” or something like that, but since these projects often fail due to attrition, I’m skeptical.
Engines like Unity and Unreal have plenty of constraints and they fight you, but you don’t have to fight them unless you have powerful, immovable, inflexible opinions about how the game code should be implemented. Otherwise, these engines give you a surprising amount of freedom. This freedom is not apparent to casual users of the engines and it’s not apparent if you read forums explaining how these engines are used.
> They are definitely not a pure win for someone making a game.
Sure. Not a pure win. In some sense, however, time is interchangeable with time. By choosing an engine like Unity or Unreal, you save some time in some areas of the project, and that time can be reinvested in other parts of your project. You end up with a higher-quality game in the same amount of time, in typical scenarios. Or you end up with a similar-quality game in a smaller amount of time, in typical scenarios.
I’ve gone in more depth discussing Unity “off the beaten path” before and I think people really overestimate how much you are constrained by the way Unity works. This applies both to seasoned Unity developers and to people who only take a quick look at Unity.
I claim,
- You can use your own physics engine with Unity,
- You can model entities however you want with Unity, even not modeling them as GameObject instances containing MonoBehaviour components,
- It is completely reasonable to develop an actual, real game this way, under realistic staff / expertise / schedule / budget constraints. (In fact, it is known that certain successful commercial games do this.)
Just to focus on a more specific example—let’s say you need your own physics engine. What’s an easy way to do that? Create your physics engine, and have it control the positions of Unity GameObject instances. This way you can easily set up test scenes in the Unity editor and see the results by hitting “play”.
Unity gives you this fantastic GUI for setting up these test scenes and a renderer you can use to visualize your physics engine behavior.
This is really not “abusing” the Unity engine in any way. The engine provides physics simulation, but it does not force you to use it.
Likewise—I’ve written games in Unity that do a lot of procedural generation, and I’ve written games without an off-the-shelf engine that do procedural generation. There are a lot of things that make it easier in Unity, and I’m not spending as much time fussing about with builds, or dealing with input, or figuring out how to port my game to other systems. Unity provides an API for me to create a mesh at run-time. During procedural generation, I generate the meshes for generated chunks of terrain, and the data structures look very similar to the way I would have written the data structures in my own engine.
Though from my four years of experience in Unity (albeit at a non-professional level), I was always fighting with the engine when trying to build new things. Trying to build complex UI code using Unity's built-in system was a mess, the serialization system always had weird errors and didn't really work well with version control, adding custom rendering to the rendering engine was full of hacks, and the documentation was quite poor for the more obscure/hidden aspects of the engine up to the point that I was thinking "I can just write these in C++/OpenGL, why do I have to go through all of this crap?". Nowadays I do gamedev at a lesser capacity (and doing more general graphics programming in C++ instead), and since several years ago I haven't really looked too deeply into the engine. I think doing all of these in Unity isn't impossible, just that I'm expecting a lot of friction while doing it.
There always seems to be some really good indie developers who are stretching Unity to its limits though (such as Manifold Garden). I always wondered how much they were fighting with the engine to make some specific features.
There definitely are limitations in the render pipeline, and I’ve spent time frustrated because I know how to do something in OpenGL but can’t figure out how to do it in Unity. But the rendering pipeline in Unity has become far more flexible in recent years, and you can make your own custom rendering pipeline. Look up "custom SRP" videos on YouTube if you want to see what that’s like. Here’s one such video: https://www.youtube.com/watch?v=91zUwJwkXNQ
I do remember serialization + version control problems long ago, but these days, serialization uses a text format by default and if you are sufficiently adventurous you can solve merge conflicts in your serialized data. Better to avoid merge conflicts in the first place, though.