Create your own Game Engine but don't use it
zeroequalsfalse.press
zeroequalsfalse.press
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.
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.
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.
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.
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.
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.
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.
In my perfect world, I'd be writing something for which there are no existing libraries to lean on.
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.
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 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.
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.
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 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.
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.
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.
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.
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.
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.
On that note, LLVM helps a lot here, too. Are there any LLVM-based languages that don't have some degree of C compatibility?
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.
> 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 */
}
}
"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.
> 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.
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.
I wouldn't bet on exotic Java attempts of "write once run everywhere" though.
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.
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.
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.
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/
Regardless, it's an amazing effort.
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.
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.
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
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.
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.
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 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.
Maybe I just caught the IRC channel on a really bad day, or asked some particularly offensive question, without knowing what I was doing.
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.
Ask that in 10 years; I believe there is always progress to be made.
What good is the tech in No Man's Sky if visiting untold numbers of planets feels like a slog through mud?
While their new games are still quite good, they seem to have begun to slip a bit after Carmack's departure.
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 Overwatch bits I'm talking about are champion abilities, which is against the entire premise of Quake 3 (everyone is equal).
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...
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.
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.
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.
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.
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.
Then again, Unity IS way easier to get started with, easy to script in and get something running and brilliant for prototyping quick ideas.
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.
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.
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.
What do you mean? How can there not be cameras? How then can you view a scene without that 3rd party module?