Create your own Game Engine but don't use it(zeroequalsfalse.press)
zeroequalsfalse.press
Create your own Game Engine but don't use it
http://www.zeroequalsfalse.press/2017/07/12/engine/
112 comments
I once wrote an OAuth client library for a language that didn't have one and learned so much. Now any time I do anything OAuth related I feel that I have a better understanding.
Would you mind sharing your text editor?
Indeed, but there are a lot of situations where a focused specialized widget made by a small team will be better than a general "best widget" made by a large team. The further you stray from the use cases of the "best widget" the worse it gets.
Writing another HTTP server does seem like an inefficient expenditure of time, but we wouldn't have Nginx or smaller tools like Mongrel if the existing "best tools" were good enough. Game engines benefit you even more to be custom because the further your game strays from another Unity game, the further it stands out from the crowd of 100,000 smartphone games.
Writing another HTTP server does seem like an inefficient expenditure of time, but we wouldn't have Nginx or smaller tools like Mongrel if the existing "best tools" were good enough. Game engines benefit you even more to be custom because the further your game strays from another Unity game, the further it stands out from the crowd of 100,000 smartphone games.
>Getting over the "not invented here" mentality allows us to focus on doing things that are novel, or things that are custom.
I remember gradually coming to accept this as an intermediate programmer. Once you do, it's incredibly freeing. You can stop thinking in terms of "I'm gonna write SOOO much complex code to solve this problem!" to "I bet I can pipe together 5 different CLI programs and not write a single line of code".
You learn that it's all about layers of abstraction, and understanding that the human brain is far more useful and efficient at problem sets higher and higher on that scale of abstraction than it is at twiddling bits.
I remember gradually coming to accept this as an intermediate programmer. Once you do, it's incredibly freeing. You can stop thinking in terms of "I'm gonna write SOOO much complex code to solve this problem!" to "I bet I can pipe together 5 different CLI programs and not write a single line of code".
You learn that it's all about layers of abstraction, and understanding that the human brain is far more useful and efficient at problem sets higher and higher on that scale of abstraction than it is at twiddling bits.
Except for some of us, it isn't actually that fun to spend 5 minutes gluing together 6 libraries with no documentation, and 4 hours figuring out an undocumented bug deep in the source code. We would rather write someone from scratch :)
Not that you can really afford to do that in a paid position, but for a side hobby like making a game? Absolutely. If you are making a game for fun, do what is fun to you.
Not that you can really afford to do that in a paid position, but for a side hobby like making a game? Absolutely. If you are making a game for fun, do what is fun to you.
> 4 hours figuring out an undocumented bug deep in the source code
For me at least, this is the real issue. Gluing together random libraries isn't fun, but it's fast and productive and lets me spend my energy and attention building something bigger than I could have solo.
Gluing together broken libraries, though... Well, I thought encapsulation and black boxing were genius from the day I learned about them until the day I actually tried to build something nontrivial. Now I just think of Douglas Adams: "The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair."
Finding myself 5 pages deep in Google trying to fix a fundamentally broken Android API is way less pleasant, and ultimately slower, than working around the API altogether. It's also why all the people I know maintaining long-standing Rails projects have heartburn - using someone else's tools only saves time when those tools are trustworthy.
For me at least, this is the real issue. Gluing together random libraries isn't fun, but it's fast and productive and lets me spend my energy and attention building something bigger than I could have solo.
Gluing together broken libraries, though... Well, I thought encapsulation and black boxing were genius from the day I learned about them until the day I actually tried to build something nontrivial. Now I just think of Douglas Adams: "The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair."
Finding myself 5 pages deep in Google trying to fix a fundamentally broken Android API is way less pleasant, and ultimately slower, than working around the API altogether. It's also why all the people I know maintaining long-standing Rails projects have heartburn - using someone else's tools only saves time when those tools are trustworthy.
Everything is broken at some level. Your own code will have bugs just like the lib you import will.
Usually what is nice is your own code has a lot less lines of code, so you SHOULD be able to find the bug sooner.
Usually what is nice is your own code has a lot less lines of code, so you SHOULD be able to find the bug sooner.
Yep, I certainly don't mean to imply my code is right. But it's usually shorter, and it's mine. So when I find the bug, I can make the sane fix on the schedule I need.
For particularly good OSS libraries, I guess providing a PR would only be a little slower than fixing internal code. But for anything poorly maintained, or with closed development, discovering those bugs often means writing an enormous workaround or switching libraries entirely - they just won't be fixed any time soon.
For particularly good OSS libraries, I guess providing a PR would only be a little slower than fixing internal code. But for anything poorly maintained, or with closed development, discovering those bugs often means writing an enormous workaround or switching libraries entirely - they just won't be fixed any time soon.
I've got that same feeling when I started using zapier. The amount of tasks you can automate without modifying nor writing any code is incredible. Since last year, I added webhooks to every action in every system I make, and then I use both zapier and huginn to send analytics, add users to mail groups, notify me when something goes wrong, and even make systems that write everything to Google sheets.
When do you use Zapier, and when do you use Hugin, and when both? Thanks (:
Piping together the other programs is certainly practical and efficient...but spending a whole ton of time writing complex code is fun. I tend to take the practical route at work, an the impractical route when I'm writing something for fun.
In my perfect world, I'd be writing something for which there are no existing libraries to lean on.
In my perfect world, I'd be writing something for which there are no existing libraries to lean on.
This is apparently what I've been doing for about two years.
Except I still haven't gotten to the "engine" part, it's more "a bunch of wrappers around Lua and SDL2 and some random stuff that seems useful, and probably the worst ECS ever."
I actually did almost get to an actual game, though. But I was so disgusted with it that I gave up and started everything over from scratch. Mind you, everything worked fine, I just hated every thing about the code.
And this is why I am an amateur programmer and a professional box-pusher.
Except I still haven't gotten to the "engine" part, it's more "a bunch of wrappers around Lua and SDL2 and some random stuff that seems useful, and probably the worst ECS ever."
I actually did almost get to an actual game, though. But I was so disgusted with it that I gave up and started everything over from scratch. Mind you, everything worked fine, I just hated every thing about the code.
And this is why I am an amateur programmer and a professional box-pusher.
I think a lot can be said for someone trying to go their way, and learning the value of a prebuilt solution. A lot of people would stubbornly keep trying to build their own "because they could build better" rather than focusing on the end outcome of a playable product.
On the other hand, I find my game engines, particularly (unfortunately) open source ones, are in a terrible state.
They often try to support many platforms, then it turns out they usually support one platform well, and the others are various degrees of broken. Then, when you want to get your game working on Android, the engine is too massive and complex for me to have any chance of figuring out how to fix it.
They often try to support many platforms, then it turns out they usually support one platform well, and the others are various degrees of broken. Then, when you want to get your game working on Android, the engine is too massive and complex for me to have any chance of figuring out how to fix it.
Too massive and complex, plus if you want to do anything a little unusual (eg, procedural generation) you'll often find most engines are working against you.
I can't imagine writing a 3D game from scratch in this day and age, but for 2D games I think it's absolutely justifiable to just grab something like SDL2 and go.
I can't imagine writing a 3D game from scratch in this day and age, but for 2D games I think it's absolutely justifiable to just grab something like SDL2 and go.
This is why i prefer frameworks like LÖVE 2d. it's so simple that I can keep everything I need in my head. I like just staying in the text editor.
I really wanted to like love 2d, but I found the community very unfriendly, and there were some fairly simple old bugs that have been around a long time.
Also, I was looking for something to teach children, and they seem to like "hilarious" library names like anal. (This is not one of the problems I asked about, I knew better than to ask someone to rename something).
Also, I was looking for something to teach children, and they seem to like "hilarious" library names like anal. (This is not one of the problems I asked about, I knew better than to ask someone to rename something).
They recently (about a year ago at least) changed nearly all of the library names.
They also had the friendliest community I had ever been in on IRC, besides maybe #haskell. Sorry to hear you had a poor experience, I'm shocked to hear things had changed on that front.
They also had the friendliest community I had ever been in on IRC, besides maybe #haskell. Sorry to hear you had a poor experience, I'm shocked to hear things had changed on that front.
I'll have a look, because I am still on the lookout for something after scratch -- I currently use pygame but I love the idea of love2d.
Maybe I just caught the IRC channel on a really bad day, or asked some particularly offensive question, without knowing what I was doing.
Maybe I just caught the IRC channel on a really bad day, or asked some particularly offensive question, without knowing what I was doing.
Seems to be a subset of libraries and frameworks in general. They are not up front with the limitations of their software, so you have to invest a lot of hours finding them.
Interesting contrast to the Carmack school of thought: _do_ build your own game engine and don't even reuse anything you made before, because you'll know better this time.
Also remember that id Software wrote an engine specific to the game they were creating (it's debatable whether you can call them engines at all, really). Things are a lot more streamlined if you take this approach because you rarely, if ever, have to answer the question "would this work for some other title?". Or worse, "would this work for any future title that may not even be in the same genre?"!
That, I think, is the mistake many game devs (who write their own engines) make. They make an engine for all possible games, then try to use it for their 2D match-3 puzzler, which uses about 5% of the code they've written, and even then they have to cludge some bits.
That, I think, is the mistake many game devs (who write their own engines) make. They make an engine for all possible games, then try to use it for their 2D match-3 puzzler, which uses about 5% of the code they've written, and even then they have to cludge some bits.
They (id tech 2-4+) definitely are considered full on world class engines, FPS specific but still. They each have a renderer, physics, scripting, asset pipeline, map and data formats, tooling, etc. and were used to make other games. They are too big, unified, oppressive (as in - they control the main loop, their elements are all together, you can't mix and match easily, your game code is on a level of a plugin for the engine code to call, not the other way around) and multi domain to be considered libraries/frameworks.
Most of us aren't John Carmack, though. When you're the guy that basically invented the genre of code you're talking about, there's a very good chance that your next project will advance the state of the art. When you're basically a hobby coder looking to get an game in the app store, it's a slightly different story.
Beyond that, it's not the 90s anymore; what novel feature are you going to implement that is going to wow anyone in the way that Carmack's engines did?
> what novel feature
Ask that in 10 years; I believe there is always progress to be made.
Ask that in 10 years; I believe there is always progress to be made.
Yes, there is always progress to be made, but the thing is that it gets more incremental every time. I don't think we're likely to see games that look as starkly different as Virtua Fighter 1 and 2 did anymore. By contrast, Tekken 6 and 7 are separated by ten years and don't look anywhere near as different as those two games, released one year apart, did.
I wish modern games could get the basics as right as Carmack's engines did.
What good is the tech in No Man's Sky if visiting untold numbers of planets feels like a slog through mud?
What good is the tech in No Man's Sky if visiting untold numbers of planets feels like a slog through mud?
Game mechanics were a lot of what always set id apart from everyone else. You could always count on them for smooth, fast-paced action, without much in the way of frills.
While their new games are still quite good, they seem to have begun to slip a bit after Carmack's departure.
While their new games are still quite good, they seem to have begun to slip a bit after Carmack's departure.
Huge Carmack fan here but I feel the need to defend the latest hi-octane Doom incarnation from 2016 - IMHO great controls, fast old-school gameplay, superbe graphics.
I'd agree. The single-player for the new Doom was excellent, but not groundbreaking.
The new Quake I'm not as much of a fan of, since it tries to be Quake 3 with some Overwatch bits tacked on.
The new Quake I'm not as much of a fan of, since it tries to be Quake 3 with some Overwatch bits tacked on.
If tacking on a few Overwatch bits means I'll be able to find matches, let it be. Quake Live has been pretty dead for a while now.
The matchmaking in Quake Champions is god-awful.
The Overwatch bits I'm talking about are champion abilities, which is against the entire premise of Quake 3 (everyone is equal).
The Overwatch bits I'm talking about are champion abilities, which is against the entire premise of Quake 3 (everyone is equal).
I mostly do play single player these days, which I found excellent as well :)
It's worth pointing out that without id's engine licensing business that depended on other companies NOT following the Carmack school of thought, it would've been harder to justify writing a new engine for every game.
I'd argue it's probably better to think of most of the later games as elaborate tech demos for the engine business
Where did you get that information from? Id tech is a clear engine family/line, they aren't named 1, 2, 3, 4, 5 and 6 for fun(except for the first one which really doesn't fit the rest).
1. Carmack himself says he wrote D3 renderer inside Q3 in C and then ported it to C++ (Doom 3 was first C++ id game). 2. Carmack himself says between Q1, 2 and 3 the move was "evolutionary" and lots of code stayed the same. 3. On Mac the main of D3 is even called quakeMain. 4. Radiant - GtkRadiant is shared between many games and various radiants (Net, Dark, Gtk, etc.) share a lot of code with each other, DarkRadiant is for example a fork of GtkRadiant meant for D3 and TDM. 5. The MegaTexturing code must definitely be shared between 4, 5 and 6 because it'd be crazy to reinvent this from scratch each time to do the same thing.
The only big/throw everything away jumps are from previous odd games (Commander Keen which was 2D, Wolf3D which was a super simple ray caster) to id tech 1 (Doom 1 and 2, pure software, fake 3D) to id tech 2 (Q1 and 2 and beyond, GL but often with software fallback, real 3D). And that kind of jump is like giving web devs shit for not writing Java browser applets and thus "not reusing what they made before". From 2 and beyond it's evolutionary with the data formats, editors, code, etc. and never a total rewrite from scratch. Case in point: the use of OpenGL (or wrapping other APIs in a GL like one when there is no GL), Carmack used to (90s) prefer it over DirectX but much later in life (2010s) switched his preference but the code stayed with OpenGL out of inertia. Even Rage and new Doom use OpenGL (id tech 5 and 6 respectively). Why would this happen instead of switching to DX if they threw everything away with each new engine and never reused code?
Granted: lots of stuff and the ENTIRE scripting system (and Carmack's opinion of scripting) change almost each iteration but "change most of stuff but it's very evolutionary and lots of code is same" is far from your claimed "don't even reuse anything".
As for his opinion on writing your own engine it's not super clear, few years back he admitted that Epic dominated that field, but he was happy to stop licensing his tech to outsiders because it was a burden and started almost by an accident ("It's interesting when you look at our technology licensing -- it was never really a business that I wanted to be in. In the very early days, people would pester us, and we'd just throw out some ridiculous terms, and we were surprised when people started taking us up on it."). He is also reportedly a very calm, reasonable and polite person so even if he thinks reusing engines is shit he won't tell us. One interviewer who interviewed him said he just turned around in his chair, didn't even say 'hi', answered all questions in length in detail with no BS and then just thanked for the interview and turned back away to his screen without a 'bye'. Embodiment of pragmatism and niceness, despite the lack of 'hi' and 'bye'.
Sources: http://fabiensanglard.net/doom3/renderer.php http://fabiensanglard.net/doom3/interviews.php http://icculus.org/gtkradiant/developers.html https://en.wikipedia.org/wiki/Id_Tech_6 http://www.gamasutra.com/view/news/125324/E3_ids_Carmack_Wil...
1. Carmack himself says he wrote D3 renderer inside Q3 in C and then ported it to C++ (Doom 3 was first C++ id game). 2. Carmack himself says between Q1, 2 and 3 the move was "evolutionary" and lots of code stayed the same. 3. On Mac the main of D3 is even called quakeMain. 4. Radiant - GtkRadiant is shared between many games and various radiants (Net, Dark, Gtk, etc.) share a lot of code with each other, DarkRadiant is for example a fork of GtkRadiant meant for D3 and TDM. 5. The MegaTexturing code must definitely be shared between 4, 5 and 6 because it'd be crazy to reinvent this from scratch each time to do the same thing.
The only big/throw everything away jumps are from previous odd games (Commander Keen which was 2D, Wolf3D which was a super simple ray caster) to id tech 1 (Doom 1 and 2, pure software, fake 3D) to id tech 2 (Q1 and 2 and beyond, GL but often with software fallback, real 3D). And that kind of jump is like giving web devs shit for not writing Java browser applets and thus "not reusing what they made before". From 2 and beyond it's evolutionary with the data formats, editors, code, etc. and never a total rewrite from scratch. Case in point: the use of OpenGL (or wrapping other APIs in a GL like one when there is no GL), Carmack used to (90s) prefer it over DirectX but much later in life (2010s) switched his preference but the code stayed with OpenGL out of inertia. Even Rage and new Doom use OpenGL (id tech 5 and 6 respectively). Why would this happen instead of switching to DX if they threw everything away with each new engine and never reused code?
Granted: lots of stuff and the ENTIRE scripting system (and Carmack's opinion of scripting) change almost each iteration but "change most of stuff but it's very evolutionary and lots of code is same" is far from your claimed "don't even reuse anything".
As for his opinion on writing your own engine it's not super clear, few years back he admitted that Epic dominated that field, but he was happy to stop licensing his tech to outsiders because it was a burden and started almost by an accident ("It's interesting when you look at our technology licensing -- it was never really a business that I wanted to be in. In the very early days, people would pester us, and we'd just throw out some ridiculous terms, and we were surprised when people started taking us up on it."). He is also reportedly a very calm, reasonable and polite person so even if he thinks reusing engines is shit he won't tell us. One interviewer who interviewed him said he just turned around in his chair, didn't even say 'hi', answered all questions in length in detail with no BS and then just thanked for the interview and turned back away to his screen without a 'bye'. Embodiment of pragmatism and niceness, despite the lack of 'hi' and 'bye'.
Sources: http://fabiensanglard.net/doom3/renderer.php http://fabiensanglard.net/doom3/interviews.php http://icculus.org/gtkradiant/developers.html https://en.wikipedia.org/wiki/Id_Tech_6 http://www.gamasutra.com/view/news/125324/E3_ids_Carmack_Wil...
I've worked with Unity from the beginning of my career as a developer. (Used to be a game designer and producer before that). I haven't quite understood what's so special about it before I tried other solutions, including open-source (Cocos) and in-house ones; turns out, a LOT of things that Unity devs take for granted (like asset pipeline and management) are lacking elsewhere.
Sure, a senior developer should be able to write his own game engine from the lowest level - but he almost never should actually do it on a real project.
Sure, a senior developer should be able to write his own game engine from the lowest level - but he almost never should actually do it on a real project.
I think a lot of developers who come into game dev have a mistaken view of Unity as the "budget" choice based on the poor quality of many of the indie titles shovleled out with it. But Unity is probably the most advanced game engine in existence today. Far beyond Unreal 4 in terms of both performance and tooling.
The reason the average quality is so low with Unity titles is because of just how easy the technical aspect of making a video game has become with modern engines. The barrier to entry for creating a game with AAA graphics is now a $20 shader pack and the ability to hack together some C# scripts.
The reason the average quality is so low with Unity titles is because of just how easy the technical aspect of making a video game has become with modern engines. The barrier to entry for creating a game with AAA graphics is now a $20 shader pack and the ability to hack together some C# scripts.
> Far beyond Unreal 4 in terms of both performance and tooling.
No, that's untrue. First it's much much easier to develop a game from scratch with Unreal without a single line of code, which isn't possible with Unity.
Second Unreal "vanilla" is more advanced in every ways. Unity is a toy compared to it. Unity is "budget" and successful because it used to be much much more affordable than Unreal. That's barely the case today. There is very little reason to use it instead of Unreal.
I started game dev with all that C++ bullcrap and DirectX headers with its insane API and message pump, and there is absolutely nothing better than Unreal in my book today, both in terms of ease of use, pricing and performances.
No, that's untrue. First it's much much easier to develop a game from scratch with Unreal without a single line of code, which isn't possible with Unity.
Second Unreal "vanilla" is more advanced in every ways. Unity is a toy compared to it. Unity is "budget" and successful because it used to be much much more affordable than Unreal. That's barely the case today. There is very little reason to use it instead of Unreal.
I started game dev with all that C++ bullcrap and DirectX headers with its insane API and message pump, and there is absolutely nothing better than Unreal in my book today, both in terms of ease of use, pricing and performances.
Vanilla Unity tooling is a joke. Of course it's enough for most games. Store solves some issues, but not all.
I don't know what tools you're talking about, Unity comes with hardly any tools at all. You have to buy them in the Asset Store if you want anything a little bit more advanced.
Then again, Unity IS way easier to get started with, easy to script in and get something running and brilliant for prototyping quick ideas.
Then again, Unity IS way easier to get started with, easy to script in and get something running and brilliant for prototyping quick ideas.
I have pretty much no experience with game development, but why is UE4 such a popular choice for commercial games if that's the case?
Most big studios are still on UE as a matter of momentum and the aforementioned biases. Unity really only became viable in the past 3 years, which is shorter than the average AAA game development cycle. Also certain games such as FPS are still better off with UE, as that's what it was designed for.
You are selling UE short in a whole lot of ways. Anywhere Unity's performance is higher it's because the feature set is less advanced. It's a matter of two different approaches.
Unity started out targeting low-end PC, then got into mobile a long time ago when mobile was very weak. So, naturally it used very basic techniques that are crappy but fast. Over time, Unity has been adding more and more advanced tech.
UE is the opposite story. It started out targeting consoles and high-end PC. It started targeting mobile when mobile was already pretty capable. At first, the tech it used was not feasible on mobile. But, over time the perf improvements of UE and mobile hardware have been converging.
Unity started out targeting low-end PC, then got into mobile a long time ago when mobile was very weak. So, naturally it used very basic techniques that are crappy but fast. Over time, Unity has been adding more and more advanced tech.
UE is the opposite story. It started out targeting consoles and high-end PC. It started targeting mobile when mobile was already pretty capable. At first, the tech it used was not feasible on mobile. But, over time the perf improvements of UE and mobile hardware have been converging.
> Also certain games such as FPS are still better off with UE, as that's what it was designed for.
What game types would you consider Unity to have better performance and/or tooling for? Also, if you're feeling generous, why?
What game types would you consider Unity to have better performance and/or tooling for? Also, if you're feeling generous, why?
>What game types would you consider Unity to have better performance and/or tooling for? Also, if you're feeling generous, why?
The main difference IMO is that Unity has become the de facto standard for anything VR related. UE is doing a good job with their VR support too, but it's really clear which engine is favored by SteamVR, the Oculus SDK, and the community at large.
Unity also has a first class asset store which can save you months of development time when it comes to things like networking or doing complex shaders.
Other than that it really comes down to personal preference. Scripting with Unity vs. Blueprints with UE, C++ vs C#, etc.
The main difference IMO is that Unity has become the de facto standard for anything VR related. UE is doing a good job with their VR support too, but it's really clear which engine is favored by SteamVR, the Oculus SDK, and the community at large.
Unity also has a first class asset store which can save you months of development time when it comes to things like networking or doing complex shaders.
Other than that it really comes down to personal preference. Scripting with Unity vs. Blueprints with UE, C++ vs C#, etc.
Well, the examples I had in mind are, like, Guilty Gear Xrd or Tekken 7, where there isn't any obvious history or genre reason (to me) to pick it. But maybe it's just old prejudices, as you said.
Possibly leveraging existing C++ experience.
Oh, yeah, that's the obvious answer. Thanks.
Agree, Unreal Engine still has a lot of catching up to do in terms of ease of use and performance (even importing an FBX file in the editor is a slow affair).
[deleted]
A year is nothing in the grand scheme of things. If you can't invest a year into building tools that could be your foundation for the next 3 decades, then what you are building is just a quick-rich scheme that doesn't matter. Use whatever you want because it doesn't matter...and your game probably isn't going to sell anyway. Those are the odds.
But as they've pointed out, you kind of need to know that stuff anyway, so it's time well spent.
I don't have a ton of gamedev experience, but at least graphically that game isn't doing anything you can't do in a few hundred lines of C++. Maybe that's part of their problem. Why use Java if you want to make a mobile game and it isn't well supported on one of your primary platforms? That sounds like a bad fit.
Unity and Unreal are super cool but they are also bloated with features that you don't need and lacking in others you do. For the longest Unity required you to use 3rd party modules for a camera. A camera....something that takes a few lines of code for a basic implementation. Why didn't that come standard?
If you really want to hurry to market yet another game by all means use one of the existing engines. It might even work really well. But if you want to do anything interesting, you're gonna be doing custom stuff anyway.
But as they've pointed out, you kind of need to know that stuff anyway, so it's time well spent.
I don't have a ton of gamedev experience, but at least graphically that game isn't doing anything you can't do in a few hundred lines of C++. Maybe that's part of their problem. Why use Java if you want to make a mobile game and it isn't well supported on one of your primary platforms? That sounds like a bad fit.
Unity and Unreal are super cool but they are also bloated with features that you don't need and lacking in others you do. For the longest Unity required you to use 3rd party modules for a camera. A camera....something that takes a few lines of code for a basic implementation. Why didn't that come standard?
If you really want to hurry to market yet another game by all means use one of the existing engines. It might even work really well. But if you want to do anything interesting, you're gonna be doing custom stuff anyway.
>For the longest Unity required you to use 3rd party modules for a camera.
What do you mean? How can there not be cameras? How then can you view a scene without that 3rd party module?
What do you mean? How can there not be cameras? How then can you view a scene without that 3rd party module?
Google "unity camera scripts" for an idea of the kind of functionality that people were grafting onto Unity a few years back.
This is good knowledge for whatever your field is. I've created a few ORMs. I don't use any of the ones I wrote, but I learned a lot in doing so. I've created a few web routing systems. Again, you can learn a lot, but unless you actually want to spend a lot of time writing and extending one, just use what you learned to help you pick a good one.
This blogpost gives the other point of view:
http://www.spacesofplay.com/blog/why-we-built-our-own-tech-f...
Essentially that the engine you use can constrain what you create, so write your own.
http://www.spacesofplay.com/blog/why-we-built-our-own-tech-f...
Essentially that the engine you use can constrain what you create, so write your own.
I've considered a stack like that myself for less exotic looking games. It's nice to know someone who actually has gotten farther than I have is making similar choices and that those choices are working for them.
I think the choice boils down to project scope and the relative size and skill of the team. If a game of your scope is already well served by an existing engine, it makes sense to use it. If you have a large team with a particular skill set, it makes sense to cater to their skill set by picking the engine they know. For any other case, rolling your own makes sense, provided you know what the scope of the project is in advance.
The common mistake (that maybe the guys in the parent article also made) is that they assume "game engine" is some necessary prerequisite to making games, so they spend time working on all of these technical problems that are not actually their game they want to make.
I think the choice boils down to project scope and the relative size and skill of the team. If a game of your scope is already well served by an existing engine, it makes sense to use it. If you have a large team with a particular skill set, it makes sense to cater to their skill set by picking the engine they know. For any other case, rolling your own makes sense, provided you know what the scope of the project is in advance.
The common mistake (that maybe the guys in the parent article also made) is that they assume "game engine" is some necessary prerequisite to making games, so they spend time working on all of these technical problems that are not actually their game they want to make.
Thank you for presenting an encouraging counterpoint. I think own game engines can work, but you'll probably have to stick to 2D or 2.5D because 3D introduces such great amounts of additional complexity - and even though 3D is not extremely hard, it's a huge time sink.
Other games with interesting/different visual “looks” and custom 3D engines are Reset and The Witness.
Having a broader understanding of your domain at a different level of abstraction is always extremely valuable.
For anyone interested in the detail of _how_ to create a game engine from scratch, I'd recommend checking out Handmade Hero https://handmadehero.org/
For anyone interested in the detail of _how_ to create a game engine from scratch, I'd recommend checking out Handmade Hero https://handmadehero.org/
Handmade Hero is over 380, hour or two long videos last i saw. How far are you into it?
Regardless, it's an amazing effort.
Regardless, it's an amazing effort.
I've watched pretty much every episode, mostly live. It is pretty amazing. It also pretty much single-handedly reinvigorated my love of programming.
But there are definitely entire weeks (or weekends these days) of video that aren't all that useful unless you're trying to build exactly what Casey is trying to build.
https://hero.handmade.network/episodes is a must if you want to cut some corners on what you watch.
Off the top of my head, here's my suggestions:
* Weeks 1-15 are all useful - it's really a great introduction and kool-aid provisioning system
* Week 20 and 21 has some introductory lighting stuff.
* Week 23 and 24 has some good performance profiling stuff.
* Week 25 and 26 has some multithreading job queue stuff.
* Week 28 and 29 has SIMD/SSE sound mixing implementation
* Weeks 36-38 has debug/performance infrastructure
* Day 235 and weeks 48 and 49 are the start of OpenGL initialization.
* Week 74 discusses particle systems
* Weekend 3 discusses compression
* Weekends 6-14 are the core software-renderer-to-OpenGL days
* Weekend 23 is a re-implementation of lighting
The other stuff is exploration of concepts that are either specific to Handmade Hero, or are much deeper implementation detail type stuff - not entirely necessary if you're skimming.
But there are definitely entire weeks (or weekends these days) of video that aren't all that useful unless you're trying to build exactly what Casey is trying to build.
https://hero.handmade.network/episodes is a must if you want to cut some corners on what you watch.
Off the top of my head, here's my suggestions:
* Weeks 1-15 are all useful - it's really a great introduction and kool-aid provisioning system
* Week 20 and 21 has some introductory lighting stuff.
* Week 23 and 24 has some good performance profiling stuff.
* Week 25 and 26 has some multithreading job queue stuff.
* Week 28 and 29 has SIMD/SSE sound mixing implementation
* Weeks 36-38 has debug/performance infrastructure
* Day 235 and weeks 48 and 49 are the start of OpenGL initialization.
* Week 74 discusses particle systems
* Weekend 3 discusses compression
* Weekends 6-14 are the core software-renderer-to-OpenGL days
* Weekend 23 is a re-implementation of lighting
The other stuff is exploration of concepts that are either specific to Handmade Hero, or are much deeper implementation detail type stuff - not entirely necessary if you're skimming.
>But there are definitely entire weeks (or weekends these days) of video that aren't all that useful unless you're trying to build exactly what Casey is trying to build.
That's been one of my biggest problems with Handmade Hero - Casey isn't teaching people how to write C/C++ and build a game engine, he's teaching them how he builds one specific game and mixing his personal habits (and idiosyncratic prejudices) along with some very useful programming knowledge.
And he also shut down comments on the Youtube feed at some point, which I find very unfortunate. The commenters helped me gauge the BS factor for any particular episode before jumping in.
That's been one of my biggest problems with Handmade Hero - Casey isn't teaching people how to write C/C++ and build a game engine, he's teaching them how he builds one specific game and mixing his personal habits (and idiosyncratic prejudices) along with some very useful programming knowledge.
And he also shut down comments on the Youtube feed at some point, which I find very unfortunate. The commenters helped me gauge the BS factor for any particular episode before jumping in.
'he's teaching them how he builds one specific game '
While I would agree that there may perhaps exist a better alternative, most of us have learned a difficult concept or two by finding a working example. This is that, but taken up to 11. Assuming you actually follow on and try to make -small- variations to ensure you understand whats going on, you will probably be in a great position
While I would agree that there may perhaps exist a better alternative, most of us have learned a difficult concept or two by finding a working example. This is that, but taken up to 11. Assuming you actually follow on and try to make -small- variations to ensure you understand whats going on, you will probably be in a great position
Yeah, it grossly understates the effort required to create a decent game.
It seems like you can learn a lot of that by building a game without using a game engine at all.
There's no absolute answer to the "build vs buy" conundrum. A lot of us are biased towards "build" and its useful to recognize that bias in our decision making. But the "buy" side often has hidden costs. In the author's case, which involves targeting multiple platforms, the "buy" side gets more attractive. In general you are deciding whether to code on platform X or on platform Y built on top of X.
Fashions come and go, and if you invest heavily on top of Y it may become "obsolete". Will you be willing to stay on Y when the developer/community has abandoned it? You may have to reinvest to port onto Y', while X remained somewhat stable.
The higher level the platform, the more likely you are to hit surprising limitations late in the process. Your role gradually transitions from technology producer to technology consumer.
Programming an AVR chip in C gives you a great feeling of space and power because the platform is so clean, while using Arduino you rapidly hit limitations and spend your time getting around them. Higher level platforms tend to make the easy things easier and the hard things very hard.
I wouldn't rule out the subjective factors. For many of us building is more fun than sorting through what others have built. The brain works a lot better when having fun, which is why MBA-style decisions about programming don't always work.
Fashions come and go, and if you invest heavily on top of Y it may become "obsolete". Will you be willing to stay on Y when the developer/community has abandoned it? You may have to reinvest to port onto Y', while X remained somewhat stable.
The higher level the platform, the more likely you are to hit surprising limitations late in the process. Your role gradually transitions from technology producer to technology consumer.
Programming an AVR chip in C gives you a great feeling of space and power because the platform is so clean, while using Arduino you rapidly hit limitations and spend your time getting around them. Higher level platforms tend to make the easy things easier and the hard things very hard.
I wouldn't rule out the subjective factors. For many of us building is more fun than sorting through what others have built. The brain works a lot better when having fun, which is why MBA-style decisions about programming don't always work.
Developing indie games is hard enough. Starting off by building your own engine is crazy (unless there are _very_ good reasons). They unnecessarily and gravely harmed their chances of success in a very competitive niche.
There's two big hindrances for success right off the bat:
1. Refusing to just use C/C++
2. Attempting to support most of the platforms
Both problems compound each other.
All platforms (even Android at this point) have C APIs for everything you need. Creating another layer of abstraction here causes more work and overhead.
Trying to get Java running on iOS with 3D APIs is a huge task in and of itself. The same goes for C# (a task which Unity does for you). Languages that require JIT for performance don't work on mobile (unless supplied by the OS, e.g. JavaScriptCore). Debugging becomes extra-difficult.
C/C++ are not convenient to use, but not hard to use either. It causes discomfort at first, but you get used to it. Being forced to do memory management manually also helps with learning how to structure programs, with a bonus of not having to wrestle GC pauses.
Having said all that, using a commercial engine is totally fine, of course.
1. Refusing to just use C/C++
2. Attempting to support most of the platforms
Both problems compound each other.
All platforms (even Android at this point) have C APIs for everything you need. Creating another layer of abstraction here causes more work and overhead.
Trying to get Java running on iOS with 3D APIs is a huge task in and of itself. The same goes for C# (a task which Unity does for you). Languages that require JIT for performance don't work on mobile (unless supplied by the OS, e.g. JavaScriptCore). Debugging becomes extra-difficult.
C/C++ are not convenient to use, but not hard to use either. It causes discomfort at first, but you get used to it. Being forced to do memory management manually also helps with learning how to structure programs, with a bonus of not having to wrestle GC pauses.
Having said all that, using a commercial engine is totally fine, of course.
> Being forced to do memory management manually
It may be worth repeating that in C++ the need to manually manage memory is drastically reduced compared with C (due to the native support of the RAII pattern).
It may be worth repeating that in C++ the need to manually manage memory is drastically reduced compared with C (due to the native support of the RAII pattern).
I refuse to use C/C++. If that's what I have to use to make games, I just won't make games. Fortunately, there are other languages available with a C FFI.
I don't think forced memory management teaches anyone much of anything besides how to manage memory manually. It doesn't make programs better. I'm very grateful for garbage collection so that I can spend my cycles thinking about the problem I'm actually trying to solve.
edit: I think this came off a bit too dismissive, but I guess what I was after is that what technology you choose depends on what you value. Personally, I value using programming languages that are pleasant to work with, and I don't personally find C/C++ to be pleasant. I enjoy dabbling in game development, but it's not so important to me that I would use tools that I don't like to do it.
I don't think forced memory management teaches anyone much of anything besides how to manage memory manually. It doesn't make programs better. I'm very grateful for garbage collection so that I can spend my cycles thinking about the problem I'm actually trying to solve.
edit: I think this came off a bit too dismissive, but I guess what I was after is that what technology you choose depends on what you value. Personally, I value using programming languages that are pleasant to work with, and I don't personally find C/C++ to be pleasant. I enjoy dabbling in game development, but it's not so important to me that I would use tools that I don't like to do it.
>what technology you choose depends on what you value
No, what technology you choose depends first and foremost on what you want to achieve. If you want a to run a realtime application on as many platforms and devices as possible with steady fps, a GC language is not the technlogy you can use.
In contrast, you can write web applications in almost any language with little technical differences. That's the point where you can start to make a value assessment.
>It doesn't make programs better
Yes it does. With a GC you lose control over runtime, which is crucial to the performance.
I'm not advocating against GC in general. Many desktop apps, most web apps and low-tech games can be fine with it. But saying manual memory management is outdated, when our 4 GHz Multicore machines struggle to run smoothly is ridiculous.
No, what technology you choose depends first and foremost on what you want to achieve. If you want a to run a realtime application on as many platforms and devices as possible with steady fps, a GC language is not the technlogy you can use.
In contrast, you can write web applications in almost any language with little technical differences. That's the point where you can start to make a value assessment.
>It doesn't make programs better
Yes it does. With a GC you lose control over runtime, which is crucial to the performance.
I'm not advocating against GC in general. Many desktop apps, most web apps and low-tech games can be fine with it. But saying manual memory management is outdated, when our 4 GHz Multicore machines struggle to run smoothly is ridiculous.
>No, what technology you choose depends first and foremost on what you want to achieve.
Maybe for you. But not for me. I find the rest of your post to be very mean spirited.
I don't work in the games industry because those constraints sound miserable.
Maybe for you. But not for me. I find the rest of your post to be very mean spirited.
I don't work in the games industry because those constraints sound miserable.
First of all, I'm talking about game engines, not games. Both Unity and the earlier Unreal Engine (afaik) used GC-ed languages for scripting.
However, if you want to make a quality game, you can not afford long GC pauses. I know that lots of people make games with GC pauses in them anyway. It is a value judgement, for sure.
It's certainly possible to work around GC pauses, but that effectively means you are manually managing your memory manager (instead of the memory), which can be surprisingly difficult.
It's also possible that whatever you do is so "small" that GC pauses never affect you. Enjoy your free lunch then.
However, if you want to make a quality game, you can not afford long GC pauses. I know that lots of people make games with GC pauses in them anyway. It is a value judgement, for sure.
It's certainly possible to work around GC pauses, but that effectively means you are manually managing your memory manager (instead of the memory), which can be surprisingly difficult.
It's also possible that whatever you do is so "small" that GC pauses never affect you. Enjoy your free lunch then.
Even if there was entirely non-stop GC (e.g. through reference counting) it's still wouldn't be a good choice for games since a game is, essentially, just a neatly arranged data structure in memory. Compared to the amount of memory a game reads/writes every frame all other I/O channels are just noise. You actually want to manage your memory instead of trying to figure out how to force a foreign memory system to do what is best.
Some of the work done to work around GC feels similar to the work you'd do in C/C++ to work around memory fragmentation issues. Also, depending on the language/runtime, you might be able to influence the GC algorithm, or at least the frequency with which it runs. If you can e.g. run a GC every second for not longer than ~1 frame, then pauses won't be noticeable.
A dropped frame is always noticable. What you can do is keep a budget for GC and then force-collect every frame.
Used to have a hard time with C, but after working with it for some time you might get to appreciate what computers do more. I oddly find C pleasing, and choose it to solve many problems by default.
I've spent enough time writing C to know that I want to minimize my time spent writing C. It's been an important language to know for dealing with foreign function interfaces, but I work almost exclusively in high-level, memory safe languages now. I'm much happier and my programs are much less vulnerable to exploitation.
I think C is pleasing because the program does nothing that you don't explicitly tell it to do, and because just about everything that you can tell it to do maps clean(ish)ly down to the machine language that implements the equivalent code. It's possible to know exactly what's going on, and when.
1. Refusing to just use Assembly.
Was the reply we got in the old days, when one used C, Pascal, Basic, Amos.
Thankfully many ignored that and moved the state of art to such languages.
A few years later the reply would be,
1. Refused to use C
When devs tried to use C++ or Delphi.
State of the art in games development only advances thanks to those that manage to produce entertaining games, while ignoring such advices.
Was the reply we got in the old days, when one used C, Pascal, Basic, Amos.
Thankfully many ignored that and moved the state of art to such languages.
A few years later the reply would be,
1. Refused to use C
When devs tried to use C++ or Delphi.
State of the art in games development only advances thanks to those that manage to produce entertaining games, while ignoring such advices.
I don't really feel like this is a fair statement if you have done any game engine related development. Even 'writing from scratch' is still gluing together a whole soup of libraries and many of those libraries are C API only. Fonts? Use freetype. PNG's? use libpng. COLLADA? Audio? Audio files? Input? OpenGL/DX?
As soon as you say you are throwing out C/C++ you better have amazing alternatives that make sense for the language you are working on. Games are large enough projects with broad enough scope that if you don't have a language that works well with a bunch of external libraries you are immediately in the weeds once you end up with a problem that isn't covered by what is already available. If you find this out too late in the project (especially in a hobby/side project) this can be a death knell.
This is a constant problem in game engines or other large frameworks- once you get off the rails in a significant way all your development time is going to making that kludge work. If you are using a language that is just wrapping C API libraries often a lot of this development time is just fixing the wrappers to the actual library instead of getting anything done.
If you know the end product is 100% covered by a game engine you can save all the game engine development time and the kludge fix time all at once. I had written a whole tutorial series based on XNA for instance because it was easy to demonstrate the concepts I wanted to share, but when trying to start working on a particular topic I realized the engine's limitation and it all went to hell and I had to scrap it.
As soon as you say you are throwing out C/C++ you better have amazing alternatives that make sense for the language you are working on. Games are large enough projects with broad enough scope that if you don't have a language that works well with a bunch of external libraries you are immediately in the weeds once you end up with a problem that isn't covered by what is already available. If you find this out too late in the project (especially in a hobby/side project) this can be a death knell.
This is a constant problem in game engines or other large frameworks- once you get off the rails in a significant way all your development time is going to making that kludge work. If you are using a language that is just wrapping C API libraries often a lot of this development time is just fixing the wrappers to the actual library instead of getting anything done.
If you know the end product is 100% covered by a game engine you can save all the game engine development time and the kludge fix time all at once. I had written a whole tutorial series based on XNA for instance because it was easy to demonstrate the concepts I wanted to share, but when trying to start working on a particular topic I realized the engine's limitation and it all went to hell and I had to scrap it.
A growing number of languages are ABI-compatible with C. A small but significant subset of those languages is ABI-compatible with C++. Quite a few languages (Perl 6, Julia, Tcl w/ critcl, pretty much everything that uses libffi AFAICT) are able to do this without having to write full-blown wrappers for a whole C/C++ library (though you still need to wrap specific functions in most cases).
Julia JIT compiles C calls via LLVM, so there's no libffi performance overhead (similar to LuaJIT's CFFI, though that does not use LLVM).
Neither does Tcl's critcl AFAIK (I think it just sticks the C code in a Tcl extension and compiles it using the system compiler). My intent there was just to list cases where wrapping a whole C/C++ library is unnecessary, not to imply that Julia uses libffi :)
On that note, LLVM helps a lot here, too. Are there any LLVM-based languages that don't have some degree of C compatibility?
On that note, LLVM helps a lot here, too. Are there any LLVM-based languages that don't have some degree of C compatibility?
Parse error on my part, excuse the pedantry :) Tcl is such a weird and wonderful language, and I occasionally miss it (though I don't miss working with a GUI written in C++ wrapped around tk).
On a past life I used to be an IGDA member, attended GDCE a couple of times, and knew personally developers working in a few European game studios, until deciding boring IT work was a better way to make a living and enjoying life.
Game developers used Assembly to write games when it was the best tool for the job. They then moved to C when it was feasible and then to C++ when that was feasible. For their engines, they never moved on to anything else, because there still is no better tool for the job, all things (tooling, SDKs, platform support) considered.
Unity, Unreal Engine and CryEngine are all written in C/C++. They have sometimes elaborate script bindings, but the engine remains in C/C++.
There's a lot of people leaving college that have never learned how to use C/C++ and immediately they want something they're comfortable with, which is Java/C# or Javascript or maybe even Python. These languages are not good choices for a game engine, for the reasons I mentioned. Will there never be a better language? I did not say that, but it would be an uphill battle.
Unity, Unreal Engine and CryEngine are all written in C/C++. They have sometimes elaborate script bindings, but the engine remains in C/C++.
There's a lot of people leaving college that have never learned how to use C/C++ and immediately they want something they're comfortable with, which is Java/C# or Javascript or maybe even Python. These languages are not good choices for a game engine, for the reasons I mentioned. Will there never be a better language? I did not say that, but it would be an uphill battle.
Usually game developers changed language when the OS or game console's SDK release forced them to do so.
> These languages are not good choices for a game engine
I have seen these words written against C, Turbo Pascal, Modula-2, C++.
Some of the games I saw "written" in C for MS-DOS were like this all over the place:
> These languages are not good choices for a game engine
I have seen these words written against C, Turbo Pascal, Modula-2, C++.
Some of the games I saw "written" in C for MS-DOS were like this all over the place:
void my_func(void)
{
asm {
/* 100% of my_func actual code */
}
}
SDKs never forced anybody to move to C or C++, but the opposite is true: C/C++ compilers were either unavailable or limited.
"I have seen these words written against C, Turbo Pascal, Modula-2, C++."
So what? Those words probably had a good argument behind them, at the time.
In the MS-DOS days, compilers weren't as good as today, so handwritten ASM paid off.
"I have seen these words written against C, Turbo Pascal, Modula-2, C++."
So what? Those words probably had a good argument behind them, at the time.
In the MS-DOS days, compilers weren't as good as today, so handwritten ASM paid off.
> So what? Those words probably had a good argument behind them, at the time.
> In the MS-DOS days, compilers weren't as good as today, so handwritten ASM paid off.
Just like C compilers had enough money spent into their optimizers, that eventually made them competitive against Assembly, so can C#,Go,D, <whatever language> have enough work placed into them, that eventually they will become competitive against C.
People believed they could make C competitive against Assembly, just like they believe they could make C++ competitive against C.
So it is a matter if one wants to believe and lead, or don't and follow.
> In the MS-DOS days, compilers weren't as good as today, so handwritten ASM paid off.
Just like C compilers had enough money spent into their optimizers, that eventually made them competitive against Assembly, so can C#,Go,D, <whatever language> have enough work placed into them, that eventually they will become competitive against C.
People believed they could make C competitive against Assembly, just like they believe they could make C++ competitive against C.
So it is a matter if one wants to believe and lead, or don't and follow.
If <whatever language> makes certain assumptions and guarantees on behavior, then no, belief is not enough. It has to be plausible. GC alone really is a big issue and all the research (of which there is a lot) has not solved fundamental issues.
There are of course languages (like Rust) that have the fundamentals to match C/C++, but then it's still a matter of adoption. C++ also still develops.
There are of course languages (like Rust) that have the fundamentals to match C/C++, but then it's still a matter of adoption. C++ also still develops.
The fundamental issues is that science only advances one memorial at a time, as there is no amount of technical proofs that will change the mind of luddites.
Unity's multi-platform track record is quite solid at this point in time.
I wouldn't bet on exotic Java attempts of "write once run everywhere" though.
I wouldn't bet on exotic Java attempts of "write once run everywhere" though.
Java is actually not that bad – Java with LWJGL gets you within a factor of 1.6 to C++ performance, while actually being "write once run everywhere" (for PC, at least). That’s good enough.
Maybe on a Hotspot VM with JIT, while using frivolous amounts of memory for good GC performance.
You're not allowed to do JIT on consoles or mobile and you're memory constrained. A PC-only game engine is going to be a tough sell these days.
Also, unless you're bundling a JVM (not sure about the legals here) you have to make your Windows (i.e. primary) customers install the obnoxious Oracle Java runtime.
You're not allowed to do JIT on consoles or mobile and you're memory constrained. A PC-only game engine is going to be a tough sell these days.
Also, unless you're bundling a JVM (not sure about the legals here) you have to make your Windows (i.e. primary) customers install the obnoxious Oracle Java runtime.
Yes, the track record is often negative if you want to make action games on not-Windows because of GC pauses caused by Mono's inferior garbage collector.
As for Java, Notch managed to do it for Minecraft, except for the mobile port which I think I remember reading was re-written from scratch on iOS because the performance was terrible.
As for Java, Notch managed to do it for Minecraft, except for the mobile port which I think I remember reading was re-written from scratch on iOS because the performance was terrible.
[deleted]
The mistake that most people make is thinking about whether or not they should make a "game engine" when what they really want to do is make a game.
If you want to make a game, make it. If it makes sense to use somebody else's engine to make it, then by all means do so. If you aren't going use someone else's game engine (which is a perfectly valid choice), skip straight to making your game. After you've made a game or two, you'll know whether making a "game engine" out of what you've written previously is a worthwhile effort for your next game.
If you want to make a game, make it. If it makes sense to use somebody else's engine to make it, then by all means do so. If you aren't going use someone else's game engine (which is a perfectly valid choice), skip straight to making your game. After you've made a game or two, you'll know whether making a "game engine" out of what you've written previously is a worthwhile effort for your next game.
Working on low level engine things for 15+ years lets me wield Unity like a sword now. It's a mid-level sword, but my technique makes up for that.
This blog post and the comments here are amazing. In no other software field but indie game dev does spending a year trying to build your own toolset instead of $ACTUAL_PRODUCT_THAT_MAKES_MONEY draw praise.
It's cargo-cult word-thinking. "Game engine" is associated with "game" because of the success of id Software, Epic Games, Valve, CryTek, et al. So people who don't think the way programmers do, have the impression that a game engine is a required step in the software development process to have a successful game.
I really don't think the issue was with "creating x from scratch", but from the purpose it was built for.
Game engines like Unity are general-purpose engines, they are not made for a specific type of game, and can be used for basically anything. The trade-off is flexibility and performance.
What they tried to do was to basically create a "clone" of Unity, that is, they tried to create a general purpose engine, and that does not make any sense at all for an indie developer.
If you're going to create a game engine + editor, then do it for a specific genre of games (e.g. FPS), and do it only if you're planning to create a series of games that belong to that genre only.
Unless you want to create a business out of selling game engines, then have a specific game in mind before creating a game engine, and tweak it for that purpose only.
Game engines like Unity are general-purpose engines, they are not made for a specific type of game, and can be used for basically anything. The trade-off is flexibility and performance.
What they tried to do was to basically create a "clone" of Unity, that is, they tried to create a general purpose engine, and that does not make any sense at all for an indie developer.
If you're going to create a game engine + editor, then do it for a specific genre of games (e.g. FPS), and do it only if you're planning to create a series of games that belong to that genre only.
Unless you want to create a business out of selling game engines, then have a specific game in mind before creating a game engine, and tweak it for that purpose only.
The article is pointing out something that should be obvious; if you're making a widget as part of a larger task, your implementation will probably be lacking compared to one developed by a team solely focused on making the best widget they can. I could write an HTTP server or a threadpool or a database connection layer if I really wanted to, but thousands of talented people have invested millions of hours in those tasks already, and I'm not likely to do better than them on my own.
Getting over the "not invented here" mentality allows us to focus on doing things that are novel, or things that are custom. In my day job, I'm working on a (relatively) trivial problem that's never been done before, because there are about ten people in the world that need it. As a hobby I work on a text editor that is completely customized to my personal workflow, and which will probably never be used by anyone else.