Many games wouldn't exist without guys making own engine as they felt they needed to. There will be still guys like those in future. Then there is others who doesn't want and goes full with ready engines. Its everyones choise.. but in all cases i always admire guys who build own engines hands down 100% every time.
For those arguing whether he is right or wrong, you need to understand perspective. You can consider it like comparing "street racing" to "F1 racing". Both have different perspectives and goals. Asking "is it better to use a game engine or create my own game engine?" is too generic. Just like saying "is it better to modify a stock car or design a car from scratch?" is too generic a question to answer for someone who wants to race cars. - Street Racing: Buys an existing car and modifies it to try and be faster than the competition. These people probably know a lot about cars, but aren't really interested in the physics or anything. They understand what modifications will improve their car for the best price and will go with that. - F1 Racing: Builds a car from the ground up to be the literal fastest car that can exist. This requires a deep understanding of physics and requires a lot of testing. However, what you end up with is a faster car than anything that could be obtained via street racing. Cars for street racing are built from cars designed for general purpose use. You can modify the car but there are limitations. For 99% of people who want to race, they will probably just do this because it is easier and does what they want to do. However, for that 1% that wants full control over their vehicle, they will most likely get into F1 racing. So you can think about Jonathan Blow trying to explain to a street racer why F1 racing is more preferable, but the street racer will disagree and claim it is too much effort and you can get most of the way to performing as well as an F1 car by just modifying an existing car. Both parties here are correct in what they are saying. However, they want a different outcome. A street racer wants to be good enough to beat their competition, which they can do by modifying stock cars. An F1 racer wants to have the literal fastest car that exists. For games, an existing engine is almost always the correct answer for most developers. There is still a niche for custom engines, but it's mostly just innovation. I would argue that Jonathan Blow's games shouldn't need a custom engine though. He's currently in the process of designing his own programming language for games which obviously would require a custom engine. He just has the mind of someone that wants to try and innovate, much like the F1 racer. It's not correct for most people, but that doesn't mean it isn't correct for him to say what he is saying.
I don't understand why people would disagree I mean he just said engines are perfectly usable if you don't need anything specific or you don't care about future compatibility problems I'm starting so I'm going to use Godot or Unity and I don't feel any animosity because he thinks he can do better by all means to ahead xD. If you enjoy doing things yourself why not go ahead and make your own engine? Have complete control over it and not depend on a general use engine that has way too many variables that may be intertwine in complex ways taking a lot of time and joy from working on your project because you may be spending more time making the engine work around the problems you need it solve that actually working on the project. I don't know about you but I prefer doing the things I know how to do myself Instead of getting used to the tools make tools that fit your needs.
@@FamastChannel "a general use engine that has way too many variables that may be intertwine in complex ways taking a lot of time and joy from working on your project because you may be spending more time making the engine work around the problems you need it solve that actually working on the project" This is very well said, making a game is a very specific problem and every game is built very differently, but game engines are extremely general and try to support all possible games. That just results in a totally garbage workflow.
@@FamastChannel Godot even feels like an entirely different argument given that it's an open source engine, so you could start from square 100 instead of 1 and make a custom version of Godot if you really wanted/needed to.
F1 cars aren’t really designed to be “the literal fastest car that exists”. F1 imposes a lot of very specific technical requirements on the vehicles, some of which are limiting the performance these cars can achieve. For example, they banned continuously variable transmission because it would provide too much of an advantage to one team that had such system. There are lots of restrictions on metals that can be used in order to keep engine development costs down and make the playing field more level between all teams.
It isn't at all. Ironically, Unity games are probably going to last longer than most closed source games because they're so easy to reverse engineer. It's trivial to decompile C# Unity games. He hasn't made a game that's done anything interesting technically either. Unreal and Unity could do what his games do in their sleep.
@@magnuscritikaleak5045 What do you mean by that? Like, if a game is exported and compiled for a platform, and the platform updates, it is almost impossible to upgrade the game?
@Reuben Sandwich Unity releases yearly versions that have some period of being considered experimental and after they are finalized are guaranteed to have 'long-term support' for about two years. That means that if you don't upgrade the version after that period, if you are publishing for a walled-garden platform like a console or iOS and they introduce a regular required upgrade to their SDK, the version of the engine you're using becomes incompatible with that platform and it is no longer possible to commercially publish for it without changing version (of course this problem gets even bigger when considering porting across console generations, etc). Upgrading across a 1-2 yearly versions probably won't be a big deal, but in the 10+ year timeframe Blow is talking about, it most likely will be. For example, the input example is on point as Unity has completely changed the paradigm of their input system in the last 5 years. Rolling your own engine would have some similar issues in that a console manufacturer could drastically change how their hardware and APIs work between generations meaning that there still would be a lot of work involved porting, however I think he is right that it would be easier to guarantee small nuances of how, e.g. character control works if you have full control over everything after that point yourself. Furthermore, there is the question of what happens if the engine developer stops operating in the next 10-20 years, and even if it is possible to hack a port together whether it would be legal to sell it or not, etc. These aren't necessarily fatal issues that offset the productivity benefits of 3rd party engines, especially considering most games aren't commercially successful enough to care about these kind of timeframes. But he does bring up some legitimate points that are meaningful for the projects he is known for.
Yeah and thank goodness we don't have to invent the thing with which we create that universe. But Blow did. He's creating his own programming language lol.
@@nngnnadas TinyVerse, a new simplified universe! It has all the goods of our universe, minus all the unnecessary things, such as planets, solar systems, and *humanity's nature to destroy everything around it, including itself, slowly and painfully...*
@@proksenospapias9327 undertale is very unique, i think what i meant is unique to can help you make unique game, but if you're a really good artist and you know what exactly you want to make the tool doesn't matter
The short answer should just be "Bloat". A custom made engine has the potential to be orders of magnitude more efficient than a general purpose software suite like Unreal, Unity, Godot, etc.. but that depends on the talent of the programmer(s). That's why Doom can run on practically anything, but if you remake Doom using Unity, it will be enormous and slow by comparison.
I know someone that used unity, then they changed the code to C# only and he couldn't do it anymore, and then had to rewrite all the code. So his apple rotted. But I think that an engine can be good if it's designed correctly and is free to use.
Engines are great if your team is very small with very limited resources. I love JoBlow and I love The Witness, but it's easy to say "just write it from scratch" when you have all the Braid money backing you up. They could afford spending seven years developing a niche game with a relatively big team. This is not the reality for most indie devs though.
@@franciscofarias6385 But he made Braid without "Braid money", correct? And he could take parts of the Braid engine to use for The Witness. I'm pretty sure they would've made a different game if they didn't have all the money for it, but maybe not. Jon is risk taker, so we can't say for sure.
@@Kniffel101 well Braid is a 2D game and The Witness a 3D one, so the technical challenges to tackle are pretty different, and 3D is to a whole new scale. Even the most important technical features of Braid (being able to go back and forth in time, keeping the state of the game at moment T) wasn't reused in The Witness. For Jonathan Blow I think the joy of tackling the technical challenge is the most important. If he hadn't Braid's money, he may have spent 14 years making the game and working on the side to pay the bills, but he wouldn't have used Unity.
"then they changed the code to C# only and he couldn't do it anymore" He could have kept using the version he had. Don't phrase it like they take away the engine against your will. Simply stop updating and finish your game.
@@forasago in video game industry, programmers tend to stick with one version of their engine / tools to avboid upgrading isssues... Sometimes it seems tempting to have new features/ optimization, but you surely have some work to port. (I remember the developers of Distance having a hard time keeping the physics of their game consistent between 2 versions of Unity...) Often changes are not worse, just different. and changing everything takes time. Still, old version are still there, and that's not because there is a new version that the previous one becomes suddenly bad.
I feel unity is great but its very biased towards making certain types of games. Keeping huge collections on sync every frame is too garbage heavy and there is no good ways of linking structs with the actual gameobject. ECS shows promise but it still has a long way to go.
True! Unity memory management for huge games is a pain.. but avoiding gameobjects over use and proper polymorfism you can have a powerful game, my problem is with the libraries, in the future i will work with them directly, you know "ehem OpenGL", lets say Unity is great friendly software for getting a lot of knowledge before jumping into more deph custom engines where you deal with the giant beast. Greetings 😁
Surely at a certain point it takes just as long to learn to use a complex piece of software, and adapt it for your particular purpose, as it does to create a more simple piece of software that's tailored to your own needs.
As somebody who has shipped an indie game on a from-scratch C++ engine, I can say that while it was a (mostly) enjoyable exercise, it was a monumental waste of time. That was back in 2011 when Unity was still pretty rough and Unreal was only for AAA licensing. Nowadays, honestly, you'd have to be crazy not to use an existing engine.
"Nowadays, honestly, you'd have to be crazy not to use an existing engine." Or you might just not want to deal with problems like Unity policy switching. Or you are making games for the web and don't need an engine to do so.
This is really rare for me, but I think Jonathan and everyone else here of whom's comment I have read are kind of missing the point. I think the best combination of both worlds, isn't a game engine custom or not, but rather a game engine software library, which knows how to render to the screen, and map textures and all the low level graphics, but still requires you to compose those resources together into a discrete software solution. So it's less starting from scratch, but also not restricting yourself in the way that he's describing.
It is possible to build your own engine and can be even good and customized to your special needs but just use some great libraries to help you along the way, WGPU or BGFX for cross platform rendering, RmlUI or EGUI for GUI, Rust for killing bugs at compile time, etc.
I don't think Jon would agree. You're making time compromises when you advocate for adopting library x or framework y. It's not that hard to write your own GUI system to fit your needs. Vulkan or OpenGL isn't bad either. You also lose out on learning exactly how the lower level systems actually work by depending on too many layers of abstraction.
Maybe a dumb question but why would a game made from scratch be more easily deployable on future tech? Wouldn't changing OS and hardware still require the Dev to adept to the new environment?
Jonathan is very correct in all of his arguments about using game engines in general. Specifically The Witness though is laughably possible in Unity, maybe the aesthetics and lighting would've been harder to get right but he shouldn't pretend like the functionality is so out there that is beyond what something like Unity or Unreal can do.
The movement system in The Witness is very unconventional. Unlike other games, it's mathematically impossible for the player to get stuck somewhere or escape the boundaries of the map, which is very important considering the game constantly saves your progress. I don't think it could have been built in Unity, at least not easily. Casey has a very interesting lecture on how it works: ruclips.net/video/YE8MVNMzpbo/видео.html
@@xIronWarlordx that's a great lecture, I always love content from Casey. You're right that a basic, out of the box first-person controller made from a tutorial probably wouldn't implement something like this. I do however wholesale reject the idea that this algorithm couldn't have been implemented in Unity, it seems completely possible, and probably wouldn't have the arbitrary technical restriction of "no pre-computation" that came from Blow. I could be missing something but is there anything he does in this algorithm that you think is beyond Unity's capabilities?
I like Johnathan but I don't really agree, it would be 100% possible to make his games in Unity or Unreal and probably a lot faster. At the end of the day I just want to focus on gameplay programming but I'm sure having your own engine kicks ass for a long term project or if you're going to make future games with that same engine. But for most indie games there is really no reason to go from scratch.
Depends on the scope, in my opinion. If you're going to make a platformer like Super Mario Bros, for example, it's not that big a deal putting together graphics, audio and input wrappers. But putting together a game editor is too much work for a relatively trivial project. If you're going to make a big game, as an indie studio, it kinda makes sense if you're not willing to pay for Unity Plus or Pro, and decide to just make an engine and editor.
unity is shitted on for using C# unreal is a problem because of the tools provided (that end up being slower than they should believe it or not) there is a theory with game engines where, your game can only be up to as fast as the engine it's self if you want it to be faster you can only make it possible from scratch
@@Malsavahara As long as you can get a good stable framerate doing whatever you're doing who cares? For engines this mostly means understanding how to optimize within their framework and understanding c# (unity) or c++ (unreal) optimizations as well. If you think you can write a better engine from scratch than these multi billion dollar companies than go for it but it will most likely just be a gimped version of something that already exits
@@tc14hd23 They mention Unity & Unreal 4 and a third one that I can't make out, and it seems Jonathan Blow said he considered the third one but something about licensing terms made him not go with it. What is that third one?
What's comical is that he's such an ego case he thinks his tiny little games have such hard problems to solve. As if you couldn't make his pissant games in Unreal.
I don't really understand the tone of the question-asker. It's like he *wants* Blow to use Unreal or whatever. Same tone as: but why *don't* you drive a Tesla?
Another perspective: this question is like saying to a painter why not using acrilycs instead of oil based painting (or viceversa), or even why using color pigments with oil instead of buying the already assemble paint in a package. But I think the crucial and most important point is the first want: because they want. It is the way they wanna work, the tools they want to use, and per se the results they are looking for.
Exactly, making your own oil paint doesn't mean you are "reinventing the wheel", it is just what gives you, personally, creativity, and something you enjoy. Your painting, subject matter, and expression would be completely different if you had just used the store bought paint, because of the different frame of mind. Maybe you find a new color that changes the whole direction of the painting. But just because you make your own paint doesn't mean you harvest your own cotton to make your own canvas.
@Suhail Alhegry I guess I'm comparing using Unreal to starting with a whole engine, making the engine rather than off-the-shelf. That doesn't happen too often these days, but maybe thats just down to availability. There are a lot of artists and designers who already have experience in these engines, I can imagine the development cycle and costs tend to favour Unreal and Unity.
@@captlazerhawk I know what your saying, but there is a fairly big difference between an engine for a game, and a game engine. Making an engine for a game is par the course, making a game engine is a massive endeavour and investment that most companies can't afford. I actually quite miss using libraries and building up that way and knowing how everything works, but that's out of the question for most modern game projects IMO. Even small teams and solo's need to be practical and avoid the procrastination that these things can introduce.
More like flour. You can do a lot with flour. You can bake bread or pie, noodles etc. The catch is, you must bring your own ingredients and it MUST contain flour. Soup? Hope you like chunky flour soup. That's my metaphor for Unity.
There never had been a lasting game engine except the nes gamekit. It's sort of like leggo kits based on star wars scene. It's nice and easy to do. But your stuck with what these prefab parts. And yes you can mod them. But once the clay is set it's hard to remold. And there are hooks that don't work anymore or you get stuck because you don't have support or documentation. And you have to learn it's flow. And so you just learn to learn their flow instead of being creative. Maybe Godot is better and maybe using the visual tiles will be better because you can at least see what's your options from a few tiles where with scripting you have an infinite number of rocks to look under if you get stuck. Unless it's for a very fps or run off the mill. But then stuck too because now everyone is competitive in that same style. But for Crissy roads yeah it's fine.
Backwards compatibility?`well then you need to design the game which should not majorly depend on the apis, but rather have some sort of adapter or proxy design pattern which can be easily adjusted to the news Unity input system, without breaking the major core base of the game.
Yeah but that adds more layers of abstraction and possibly Overhead and could make everything even harder. And still, you will still need to upgrade your adapter system from time to time, so still there is a point to doing your game from scratch, you just need to evaluate the pros and cons for your particular ambitions, jhon is obviously very ambitious, hence his view on the matter.
As a counterpoint most of his concerns wouldn't really apply to Godot or another open source engine. You can modify it to your needs, or rip out the parts you want to put into your own engine.
Yes they would apply. You have to start digging into code you don't understand and didn't write yourself. This idea that because it is open source you can just change it. Well yes technically you can change it, but you any project that a few 1000s of lines of code you are spending time modifying code that you haven't written, might not understand and probably wouldn't need to change if you had just implemented something yourself.
Blender linux 4k, while sculpting cursor would be so small, almost impossible to see. So i thought "hey blender is open source, i can just modify the part that draws the cursor while sculpting". Anyway it took me whole day to find it and change the cursor to something visible, and some headaches while compiling, missing libs and such, and optix was not working if i recall corretly. Now I can't imagine adding a custom render pass to godot or adding deferred lighting or trying a different physics engine. I feel like i am pretty much limited to what developers give me in open source projects.
@@akshayazariah Yeah I agree. It's a framework. Enginedevs just constantly want to make things harder for themselves. MonoGame solves that problem imo.
@@SuperCamelFunTime Plus, there's BRUTE by Sickhead Games with transpiles the C# code to C++ for portability, so that's handy. Heaps is great too, but Kha is my goto for Haxe; it's like a roided-up version of SDL lol.
That logic also applied to other fields. Web frontend is a good example, where staying in vanilla JS world means a lowered maintenance cost in the long run.
The percentage of programmers who are seemingly allergic to thinking and hard work is frankly disturbing. I wonder why so many people go thru the trouble of getting a degree in CS just to end up writing code snippets and gluing things with python. You should be designing optimizing compilers, people.
but why? Programming is just a tool. Artists don't manufacture their own canvas, they just draw on it. I loved the compiler course and would love doing it for a living, but I neither studied CS for writing compilers nor did I ever see the need to write one for my work (whether personal or corporate).
Failed very hard to convince me honestly. I'm pretty sure most game engines compile to an EXE so it will certainly be runnable no matter what. I think what it comes down to is that Jon, Casey and all the big boys prefer having full control over their game and they can afford to do so. For a solo dev or a small studio, creating an engine from scratch is possibly the dumbest thing they could do, unless it's a basic 2D platformer, and it certainly sets them up for failure. I can definitely understand the appeal of the "from scratch" mindset, it's just like how people go live in the woods and make their own shit. However you need to evaluate your goals, your situation and decide what's the best. Personally I cant afford to start from scratch because I know I would fail. Think about it: we wouldn't have game engines if games weren't so damn difficult to make and yet games are so underappreciated, it's sad.
It's not even Caliber, it's cost and experience! The cost of making a game engine is immense, even for those who are experienced in building game engines! Most indies cannot afford that time. Moreover, performance on modern hardware is not a major issue for most indies, and needing to build your own asset streaming pipeline is getting more and more niche
Perhaps you’re not interested in owning what you make? I get that. Perhaps you lack patience and discipline? -Me too! Perhaps you just want to get something on the screen and move onto something else? Sure, sounds good.
For example, if you want to you'rr game moddable and you're using Unity, you'd work around the engine instead of in it and that is a huge pain in the ass.
I feel like a lot of indie devs just want to re-hash the same tired old game format with their "quirky pixel/lowpoly/ps1 art" and "an unique story" so for that kind of shovelware developer, game engines are perfect. As long as the engine was designed for the kind of game you want to make, it'll be a perfect. For more unique games though, you'll need to coerce the engine a little, and in those cases it might be really fun to just make your own engine; it's not impossible, just hard, and maybe not worth it, but there's no limit to what you can do after that.
sounds a bit like AAA developers, just a bit different. With their cute soulless photogrammetry textures and models. Maybe games are indeed just games.
Jonathan Blow is quite talented, but I feel like he's VERY opinionated and dogmatic. If you would like to create an engine just for the challenge, then do it, but if you just want to make a game, and it is a game that can be done on an existing engine there's no technical reason not to just use the existing engine.
Is that not what he said? If you want a standard FPS game, use a game engine. If you want a game with more nuanced things, build your own engine. Seems reasonable to me.
@@xIronWarlordx Commercial engines can be used for way more than an fps. Subnautica runs on unity and kingdom come deliverance runs on cryengine. Both are much more technically impressive than either of JB's games
@@lincolnsand5127 Sure they can. That doesn't mean building your own engine is never a good idea. A technically impressive game isn't necessarily better or more fun to play. People have different tastes in games. Personally, I enjoyed playing The Witness more than the latest Assassin's Creed or whatever.
@@xIronWarlordx Not sure what enjoyment factor has to do with it. You were implying that commercial game engines only work for fps games and I just showed two examples that prove that's BS. And I never said "you should never build a custom engine". But I would say most indie devs could probably do just fine using commercial engines.
@@lincolnsand5127 Subnautica is technically impressive? It takes minutes to load, and when you swim around, the geometry and details of the sea floor very noticeably pop in and out of existence. If you go too fast, you can get somewhere before the world loads in, then it loads in the same spot as your sub and it gets stuck. The PRAWN suit randomly gets stuck on land and occasionally falls through the ground. Creatures clip through structures. Your tools always render as if they're underwater even when you're not. Sometimes wrecks don't load properly and the laser cutter doors get loaded in multiple times, and you have to cut through all of them one by one to get through. Compare to The Witness, which loads in just a few seconds and has no noticeable pop-in, despite being just as graphically complex as Subnautica. I've had absolutely no problems with the walk system in The Witness, whereas Subnautica's PRAWN suit has gotten stuck for no reason, floated in the water, and fallen through the ground. Subnautica is definitely playable and is a lot of fun, but there are undeniably a lot of issues. I would hardly call it a good example of using an engine to develop a technically impressive game.
20 years from now… no offence but does he really think someone will care about his games 20 years from now? there are very few games played today that are that old, usually there’s a remake if they are that popular,
Braid is from 2009, which was 15 years ago. Yes, people still talk about it, and play it. Steam charts hovers around 25, there's also the anniversary edition and other platforms. I can imagine this is important to him. I would feel the same way.
Why does Jon believe his custom coding language is gonna give us more longevity in playability? If this is his concern, then it's mighty interesting that the original Braid has been removed from steam. I thought you were about preservation, Jon...
Launchers like Steam are DRM, so they are irrelevant for preservation purposes. The important part is whether there is at least one preservable version somewhere, and there is, the standalone gog executable. A better question is whether the Anniversary Edition is going to get a DRM-free release as well. What matters to Blow is that he can port the game to new systems in 20 years without being encumbered by some random old piece of software he doesn't have control over.
There's literally 0 reasons to reinvent the wheel and make your own engine other than wanting to look cool and flex. All his points were also wrong and based on the fact he's never used them, but I won't go into detail.
Define "the wheel". Is Unity the wheel? Is Unreal the wheel? Is Godot the wheel? Also: ever heard of Frostbite? That engine powered Dragon Age: Inquisition. You might want to read the story of that game's development, and how much time was wasted to work around its limitations.
Which of the wheels are we talking about? Car or train? Or motorcycle? Or F1 racing car? Unreal, Godot, Unity, Frostbite, RPG maker, Creation, REDEngine, Source²... Plenty of wheels out there. There are many reasons to reinvent the wheel. Especially if you're making 2d. Or quest game. Especially after the s***show Unity performed last autumn.
Using the game 20 years from now - in the sense that Doom was ported to almost every platform - implies that he open sourced it. And assuming it was written in JAI, he would have to finish that also. So we have no JAI, we have no source, we have no valid point.
A) The JAI private beta starts in a month. B) He's not necessarily talking about open-sourcing, he's also talking about his own ability 10 years from now to go back to an old project and maintain it C) The argument also applies to his previous projects, like The Witness and Braid, which were certainly not written in JAI as JAI didn't exist yet.
@@BaremetalBaron I thought it was already in a private beta? when is public compiler gonna come out? Do i have to stream snipe Jon in FPS so he can focus on finishing it?
Many games wouldn't exist without guys making own engine as they felt they needed to. There will be still guys like those in future. Then there is others who doesn't want and goes full with ready engines. Its everyones choise.. but in all cases i always admire guys who build own engines hands down 100% every time.
For those arguing whether he is right or wrong, you need to understand perspective. You can consider it like comparing "street racing" to "F1 racing". Both have different perspectives and goals. Asking "is it better to use a game engine or create my own game engine?" is too generic. Just like saying "is it better to modify a stock car or design a car from scratch?" is too generic a question to answer for someone who wants to race cars.
- Street Racing: Buys an existing car and modifies it to try and be faster than the competition. These people probably know a lot about cars, but aren't really interested in the physics or anything. They understand what modifications will improve their car for the best price and will go with that.
- F1 Racing: Builds a car from the ground up to be the literal fastest car that can exist. This requires a deep understanding of physics and requires a lot of testing. However, what you end up with is a faster car than anything that could be obtained via street racing.
Cars for street racing are built from cars designed for general purpose use. You can modify the car but there are limitations. For 99% of people who want to race, they will probably just do this because it is easier and does what they want to do. However, for that 1% that wants full control over their vehicle, they will most likely get into F1 racing.
So you can think about Jonathan Blow trying to explain to a street racer why F1 racing is more preferable, but the street racer will disagree and claim it is too much effort and you can get most of the way to performing as well as an F1 car by just modifying an existing car.
Both parties here are correct in what they are saying. However, they want a different outcome. A street racer wants to be good enough to beat their competition, which they can do by modifying stock cars. An F1 racer wants to have the literal fastest car that exists.
For games, an existing engine is almost always the correct answer for most developers. There is still a niche for custom engines, but it's mostly just innovation. I would argue that Jonathan Blow's games shouldn't need a custom engine though. He's currently in the process of designing his own programming language for games which obviously would require a custom engine. He just has the mind of someone that wants to try and innovate, much like the F1 racer. It's not correct for most people, but that doesn't mean it isn't correct for him to say what he is saying.
Cries in GroupB rally fastest time in asphalt as good as f1.
I don't understand why people would disagree I mean he just said engines are perfectly usable if you don't need anything specific or you don't care about future compatibility problems I'm starting so I'm going to use Godot or Unity and I don't feel any animosity because he thinks he can do better by all means to ahead xD. If you enjoy doing things yourself why not go ahead and make your own engine? Have complete control over it and not depend on a general use engine that has way too many variables that may be intertwine in complex ways taking a lot of time and joy from working on your project because you may be spending more time making the engine work around the problems you need it solve that actually working on the project. I don't know about you but I prefer doing the things I know how to do myself Instead of getting used to the tools make tools that fit your needs.
@@FamastChannel "a general use engine that has way too many variables that may be intertwine in complex ways taking a lot of time and joy from working on your project because you may be spending more time making the engine work around the problems you need it solve that actually working on the project" This is very well said, making a game is a very specific problem and every game is built very differently, but game engines are extremely general and try to support all possible games. That just results in a totally garbage workflow.
@@FamastChannel Godot even feels like an entirely different argument given that it's an open source engine, so you could start from square 100 instead of 1 and make a custom version of Godot if you really wanted/needed to.
F1 cars aren’t really designed to be “the literal fastest car that exists”. F1 imposes a lot of very specific technical requirements on the vehicles, some of which are limiting the performance these cars can achieve. For example, they banned continuously variable transmission because it would provide too much of an advantage to one team that had such system. There are lots of restrictions on metals that can be used in order to keep engine development costs down and make the playing field more level between all teams.
From this crusty old game dev using Unity for the first time on a commercial project - what Jon said.
Everything Jon Blow is saying here is so on point!
It isn't at all. Ironically, Unity games are probably going to last longer than most closed source games because they're so easy to reverse engineer. It's trivial to decompile C# Unity games.
He hasn't made a game that's done anything interesting technically either. Unreal and Unity could do what his games do in their sleep.
I like how he did not insult game engines and tried not to appear conceited while he delivered his message.
He still pointed out it is stupid of Unity to not have backwards compatibility.
@@magnuscritikaleak5045 What do you mean by that? Like, if a game is exported and compiled for a platform, and the platform updates, it is almost impossible to upgrade the game?
Definitely surprising coming from him lol
@Reuben Sandwich Unity releases yearly versions that have some period of being considered experimental and after they are finalized are guaranteed to have 'long-term support' for about two years. That means that if you don't upgrade the version after that period, if you are publishing for a walled-garden platform like a console or iOS and they introduce a regular required upgrade to their SDK, the version of the engine you're using becomes incompatible with that platform and it is no longer possible to commercially publish for it without changing version (of course this problem gets even bigger when considering porting across console generations, etc).
Upgrading across a 1-2 yearly versions probably won't be a big deal, but in the 10+ year timeframe Blow is talking about, it most likely will be. For example, the input example is on point as Unity has completely changed the paradigm of their input system in the last 5 years. Rolling your own engine would have some similar issues in that a console manufacturer could drastically change how their hardware and APIs work between generations meaning that there still would be a lot of work involved porting, however I think he is right that it would be easier to guarantee small nuances of how, e.g. character control works if you have full control over everything after that point yourself. Furthermore, there is the question of what happens if the engine developer stops operating in the next 10-20 years, and even if it is possible to hack a port together whether it would be legal to sell it or not, etc.
These aren't necessarily fatal issues that offset the productivity benefits of 3rd party engines, especially considering most games aren't commercially successful enough to care about these kind of timeframes. But he does bring up some legitimate points that are meaningful for the projects he is known for.
@@nahfamimgood true lol. I do like Jon Blow, but he can come off as pretty arrogant and smug a lot of the times
If you want to create a game from scratch. You must first invent the universe.
opengl was here before the universe existed
Yeah and thank goodness we don't have to invent the thing with which we create that universe. But Blow did. He's creating his own programming language lol.
I don't know if you mean "well you're using libraries so that invalidates your point" but if you are that's not true
Well the universe has a lot of cruft, I"m sure one could invent something much more simple.
@@nngnnadas TinyVerse, a new simplified universe! It has all the goods of our universe, minus all the unnecessary things, such as planets, solar systems, and *humanity's nature to destroy everything around it, including itself, slowly and painfully...*
I admit there are certain things I prefer an engine to handle, like outline fonts, cross-platform shaders, localization, async texture loading.
is this the I am not Norm but for Jonathan BLow fans
there's no such thing as general engine, make your own DOOM engine or ZZT editor or whatever, unique tools makes unique games
Upvote for ZZT :). Check out Megazeux if you're at all interested in that kind of game still.
So you're saying undertale was not unique?
@@proksenospapias9327 undertale is very unique, i think what i meant is unique to can help you make unique game, but if you're a really good artist and you know what exactly you want to make the tool doesn't matter
@@proksenospapias9327 undertale is not unique
The short answer should just be "Bloat". A custom made engine has the potential to be orders of magnitude more efficient than a general purpose software suite like Unreal, Unity, Godot, etc.. but that depends on the talent of the programmer(s). That's why Doom can run on practically anything, but if you remake Doom using Unity, it will be enormous and slow by comparison.
thought about this video again given the current situation with Unity
I know someone that used unity, then they changed the code to C# only and he couldn't do it anymore, and then had to rewrite all the code. So his apple rotted. But I think that an engine can be good if it's designed correctly and is free to use.
Engines are great if your team is very small with very limited resources. I love JoBlow and I love The Witness, but it's easy to say "just write it from scratch" when you have all the Braid money backing you up. They could afford spending seven years developing a niche game with a relatively big team. This is not the reality for most indie devs though.
@@franciscofarias6385 But he made Braid without "Braid money", correct? And he could take parts of the Braid engine to use for The Witness. I'm pretty sure they would've made a different game if they didn't have all the money for it, but maybe not. Jon is risk taker, so we can't say for sure.
@@Kniffel101 well Braid is a 2D game and The Witness a 3D one, so the technical challenges to tackle are pretty different, and 3D is to a whole new scale. Even the most important technical features of Braid (being able to go back and forth in time, keeping the state of the game at moment T) wasn't reused in The Witness.
For Jonathan Blow I think the joy of tackling the technical challenge is the most important. If he hadn't Braid's money, he may have spent 14 years making the game and working on the side to pay the bills, but he wouldn't have used Unity.
"then they changed the code to C# only and he couldn't do it anymore"
He could have kept using the version he had. Don't phrase it like they take away the engine against your will. Simply stop updating and finish your game.
@@forasago in video game industry, programmers tend to stick with one version of their engine / tools to avboid upgrading isssues...
Sometimes it seems tempting to have new features/ optimization, but you surely have some work to port. (I remember the developers of Distance having a hard time keeping the physics of their game consistent between 2 versions of Unity...)
Often changes are not worse, just different. and changing everything takes time. Still, old version are still there, and that's not because there is a new version that the previous one becomes suddenly bad.
I feel unity is great but its very biased towards making certain types of games. Keeping huge collections on sync every frame is too garbage heavy and there is no good ways of linking structs with the actual gameobject. ECS shows promise but it still has a long way to go.
True! Unity memory management for huge games is a pain.. but avoiding gameobjects over use and proper polymorfism you can have a powerful game, my problem is with the libraries, in the future i will work with them directly, you know "ehem OpenGL", lets say Unity is great friendly software for getting a lot of knowledge before jumping into more deph custom engines where you deal with the giant beast. Greetings 😁
@@igs4112 Unity has been a great tool for me. Without it, I doubt I would've never stepped into the game-programming world!
Just about every engine has this problem. They have a certain workflow in mind that can make some games just a pain to make.
Two years later and ECS is not production ready.
@@JohnSmith-ox3gy yep ECS was a fad xD
Surely at a certain point it takes just as long to learn to use a complex piece of software, and adapt it for your particular purpose, as it does to create a more simple piece of software that's tailored to your own needs.
As somebody who has shipped an indie game on a from-scratch C++ engine, I can say that while it was a (mostly) enjoyable exercise, it was a monumental waste of time. That was back in 2011 when Unity was still pretty rough and Unreal was only for AAA licensing.
Nowadays, honestly, you'd have to be crazy not to use an existing engine.
Totally agree and you get the unreal source to fit it to your needs.
"Nowadays, honestly, you'd have to be crazy not to use an existing engine."
Or you might just not want to deal with problems like Unity policy switching. Or you are making games for the web and don't need an engine to do so.
This is really rare for me, but I think Jonathan and everyone else here of whom's comment I have read are kind of missing the point. I think the best combination of both worlds, isn't a game engine custom or not, but rather a game engine software library, which knows how to render to the screen, and map textures and all the low level graphics, but still requires you to compose those resources together into a discrete software solution. So it's less starting from scratch, but also not restricting yourself in the way that he's describing.
@Andai Exactly. MonoGame one of the best things if you wanna make a games without huge restriction and constant changes from engine side.
For example?
@@etodemerzel2627 So bevy made in Rust for example.
@@etodemerzel2627 I think Raylib might be one
I agree. what you are describing is a game framework. would recommend libGDX - very similar to monogame but imho much cleaner
totally agree with him
this shadow blow photo is so meme lol
It is possible to build your own engine and can be even good and customized to your special needs but just use some great libraries to help you along the way, WGPU or BGFX for cross platform rendering, RmlUI or EGUI for GUI, Rust for killing bugs at compile time, etc.
I don't think Jon would agree. You're making time compromises when you advocate for adopting library x or framework y. It's not that hard to write your own GUI system to fit your needs. Vulkan or OpenGL isn't bad either. You also lose out on learning exactly how the lower level systems actually work by depending on too many layers of abstraction.
"Rust for killing your productivity" Fixed that for you 👍
"Rust for killing bugs" HAHAHAHAHA
Well you can't say he didn't warn us
Maybe a dumb question but why would a game made from scratch be more easily deployable on future tech? Wouldn't changing OS and hardware still require the Dev to adept to the new environment?
Jonathan is very correct in all of his arguments about using game engines in general.
Specifically The Witness though is laughably possible in Unity, maybe the aesthetics and lighting would've been harder to get right but he shouldn't pretend like the functionality is so out there that is beyond what something like Unity or Unreal can do.
The movement system in The Witness is very unconventional. Unlike other games, it's mathematically impossible for the player to get stuck somewhere or escape the boundaries of the map, which is very important considering the game constantly saves your progress. I don't think it could have been built in Unity, at least not easily.
Casey has a very interesting lecture on how it works: ruclips.net/video/YE8MVNMzpbo/видео.html
@@xIronWarlordx that's a great lecture, I always love content from Casey. You're right that a basic, out of the box first-person controller made from a tutorial probably wouldn't implement something like this.
I do however wholesale reject the idea that this algorithm couldn't have been implemented in Unity, it seems completely possible, and probably wouldn't have the arbitrary technical restriction of "no pre-computation" that came from Blow. I could be missing something but is there anything he does in this algorithm that you think is beyond Unity's capabilities?
@@zacharychristy8928 I guess you could use a navmesh. It's essentially how it works.
You also have to understand that The Witness started development almost 10 years ago, Unity was very different back then.
@@rafaelbordoni516 Jesus Christ, ten years?
I like Johnathan but I don't really agree, it would be 100% possible to make his games in Unity or Unreal and probably a lot faster. At the end of the day I just want to focus on gameplay programming but I'm sure having your own engine kicks ass for a long term project or if you're going to make future games with that same engine. But for most indie games there is really no reason to go from scratch.
Depends on the scope, in my opinion. If you're going to make a platformer like Super Mario Bros, for example, it's not that big a deal putting together graphics, audio and input wrappers. But putting together a game editor is too much work for a relatively trivial project. If you're going to make a big game, as an indie studio, it kinda makes sense if you're not willing to pay for Unity Plus or Pro, and decide to just make an engine and editor.
@@akshayazariah Also, Unity/Unreal are awesome for game jams.
@@ducksoop.x Agreed.
unity is shitted on for using C#
unreal is a problem because of the tools provided (that end up being slower than they should believe it or not)
there is a theory with game engines where, your game can only be up to as fast as the engine it's self
if you want it to be faster you can only make it possible from scratch
@@Malsavahara As long as you can get a good stable framerate doing whatever you're doing who cares? For engines this mostly means understanding how to optimize within their framework and understanding c# (unity) or c++ (unreal) optimizations as well. If you think you can write a better engine from scratch than these multi billion dollar companies than go for it but it will most likely just be a gimped version of something that already exits
Do you want to make games or tools to make games? Both can be fun.
What is that other engine they mention at 0:03 and 0:07 that Jonathan considers? I can't make out the words
I think the first one said Unreal 4. Don't know about the second one...
@@tc14hd23 They mention Unity & Unreal 4 and a third one that I can't make out, and it seems Jonathan Blow said he considered the third one but something about licensing terms made him not go with it.
What is that third one?
Perlenspiel
Everything but the last point stands imo. You can still solve hard problems on top of existing engines.
What's comical is that he's such an ego case he thinks his tiny little games have such hard problems to solve. As if you couldn't make his pissant games in Unreal.
I don't really understand the tone of the question-asker. It's like he *wants* Blow to use Unreal or whatever. Same tone as: but why *don't* you drive a Tesla?
people were making fun of unity's game engine even back in the day.
Good points. Like this video.
Another perspective: this question is like saying to a painter why not using acrilycs instead of oil based painting (or viceversa), or even why using color pigments with oil instead of buying the already assemble paint in a package.
But I think the crucial and most important point is the first want: because they want. It is the way they wanna work, the tools they want to use, and per se the results they are looking for.
Exactly, making your own oil paint doesn't mean you are "reinventing the wheel", it is just what gives you, personally, creativity, and something you enjoy. Your painting, subject matter, and expression would be completely different if you had just used the store bought paint, because of the different frame of mind. Maybe you find a new color that changes the whole direction of the painting. But just because you make your own paint doesn't mean you harvest your own cotton to make your own canvas.
Lol
Yup.
Unreal licensing is 5%, can't really argue with that compared to starting from scratch!
You're on youtube comments and think people can't argue about something? =)
Yeah, good point. Besides, there's no arguing with JB :D
@Suhail Alhegry I guess I'm comparing using Unreal to starting with a whole engine, making the engine rather than off-the-shelf. That doesn't happen too often these days, but maybe thats just down to availability. There are a lot of artists and designers who already have experience in these engines, I can imagine the development cycle and costs tend to favour Unreal and Unity.
@@stunthumb Actually 40% of games on steam i made with custom engine of some sort ... happens way more often than you think.
@@captlazerhawk I know what your saying, but there is a fairly big difference between an engine for a game, and a game engine. Making an engine for a game is par the course, making a game engine is a massive endeavour and investment that most companies can't afford. I actually quite miss using libraries and building up that way and knowing how everything works, but that's out of the question for most modern game projects IMO. Even small teams and solo's need to be practical and avoid the procrastination that these things can introduce.
Sounds a lot like front end JavaScript frameworks 😅
Unity feels like making soup from a stone.
More like flour. You can do a lot with flour. You can bake bread or pie, noodles etc.
The catch is, you must bring your own ingredients and it MUST contain flour. Soup? Hope you like chunky flour soup.
That's my metaphor for Unity.
There never had been a lasting game engine except the nes gamekit. It's sort of like leggo kits based on star wars scene. It's nice and easy to do. But your stuck with what these prefab parts. And yes you can mod them. But once the clay is set it's hard to remold. And there are hooks that don't work anymore or you get stuck because you don't have support or documentation. And you have to learn it's flow. And so you just learn to learn their flow instead of being creative. Maybe Godot is better and maybe using the visual tiles will be better because you can at least see what's your options from a few tiles where with scripting you have an infinite number of rocks to look under if you get stuck. Unless it's for a very fps or run off the mill. But then stuck too because now everyone is competitive in that same style. But for Crissy roads yeah it's fine.
Backwards compatibility?`well then you need to design the game which should not majorly depend on the apis, but rather have some sort of adapter or proxy design pattern which can be easily adjusted to the news Unity input system, without breaking the major core base of the game.
Yeah but that adds more layers of abstraction and possibly Overhead and could make everything even harder.
And still, you will still need to upgrade your adapter system from time to time, so still there is a point to doing your game from scratch, you just need to evaluate the pros and cons for your particular ambitions, jhon is obviously very ambitious, hence his view on the matter.
As a counterpoint most of his concerns wouldn't really apply to Godot or another open source engine.
You can modify it to your needs, or rip out the parts you want to put into your own engine.
Yes they would apply. You have to start digging into code you don't understand and didn't write yourself.
This idea that because it is open source you can just change it. Well yes technically you can change it, but you any project that a few 1000s of lines of code you are spending time modifying code that you haven't written, might not understand and probably wouldn't need to change if you had just implemented something yourself.
Blender linux 4k, while sculpting cursor would be so small, almost impossible to see. So i thought "hey blender is open source, i can just modify the part that draws the cursor while sculpting". Anyway it took me whole day to find it and change the cursor to something visible, and some headaches while compiling, missing libs and such, and optix was not working if i recall corretly. Now I can't imagine adding a custom render pass to godot or adding deferred lighting or trying a different physics engine. I feel like i am pretty much limited to what developers give me in open source projects.
If only it worked the way you imagine it.
just use monogame ex dee
MonoGame is actually solid.
@@akshayazariah Yeah I agree. It's a framework. Enginedevs just constantly want to make things harder for themselves. MonoGame solves that problem imo.
@@SuperCamelFunTime Plus, there's BRUTE by Sickhead Games with transpiles the C# code to C++ for portability, so that's handy. Heaps is great too, but Kha is my goto for Haxe; it's like a roided-up version of SDL lol.
@@akshayazariah I forgot about Haxe actually. It's good stuff!
@@SuperCamelFunTime Yeah, check out Heaps!
That logic also applied to other fields. Web
frontend is a good example, where staying in vanilla JS world means a lowered maintenance cost in the long run.
The percentage of programmers who are seemingly allergic to thinking and hard work is frankly disturbing.
I wonder why so many people go thru the trouble of getting a degree in CS just to end up writing code snippets and gluing things with python. You should be designing optimizing compilers, people.
Chris Sawyer is Tails.
but why?
Programming is just a tool. Artists don't manufacture their own canvas, they just draw on it. I loved the compiler course and would love doing it for a living, but I neither studied CS for writing compilers nor did I ever see the need to write one for my work (whether personal or corporate).
@@vornamenachname594 don't take them seriously, most of them are nerds they live in computer. Software is just a tool that's it.
Why reinvent the wheel?
software is not just a tool, it's an art@@-Engineering01-
in godot you can modify the engine as you please
You can override source code in Unity too but source code access is limited to the Unity Enterprise license unfortunately
The best games tend to be built in tandem with an in-house game engine
Failed very hard to convince me honestly. I'm pretty sure most game engines compile to an EXE so it will certainly be runnable no matter what. I think what it comes down to is that Jon, Casey and all the big boys prefer having full control over their game and they can afford to do so. For a solo dev or a small studio, creating an engine from scratch is possibly the dumbest thing they could do, unless it's a basic 2D platformer, and it certainly sets them up for failure.
I can definitely understand the appeal of the "from scratch" mindset, it's just like how people go live in the woods and make their own shit. However you need to evaluate your goals, your situation and decide what's the best. Personally I cant afford to start from scratch because I know I would fail.
Think about it: we wouldn't have game engines if games weren't so damn difficult to make and yet games are so underappreciated, it's sad.
True. For us normies engines are fine. For someone at Jonathan Blows caliber writing your own engine is fine.
It's not even Caliber, it's cost and experience! The cost of making a game engine is immense, even for those who are experienced in building game engines! Most indies cannot afford that time.
Moreover, performance on modern hardware is not a major issue for most indies, and needing to build your own asset streaming pipeline is getting more and more niche
Perhaps you’re not interested in owning what you make? I get that. Perhaps you lack patience and discipline? -Me too! Perhaps you just want to get something on the screen and move onto something else? Sure, sounds good.
I think what Jon Blow is trying to say is that if the game you are designing requires something that the engine cannot do, then you're fucked.
For example, if you want to you'rr game moddable and you're using Unity, you'd work around the engine instead of in it and that is a huge pain in the ass.
I feel like a lot of indie devs just want to re-hash the same tired old game format with their "quirky pixel/lowpoly/ps1 art" and "an unique story" so for that kind of shovelware developer, game engines are perfect. As long as the engine was designed for the kind of game you want to make, it'll be a perfect. For more unique games though, you'll need to coerce the engine a little, and in those cases it might be really fun to just make your own engine; it's not impossible, just hard, and maybe not worth it, but there's no limit to what you can do after that.
you sound so full of yourself
Hahahah no, you can do whatever you want with your engine, unless you're writing a new graphics functionality that doesn't exist
sounds a bit like AAA developers, just a bit different. With their cute soulless photogrammetry textures and models. Maybe games are indeed just games.
Jonathan Blow is quite talented, but I feel like he's VERY opinionated and dogmatic.
If you would like to create an engine just for the challenge, then do it, but if you just want to make a game, and it is a game that can be done on an existing engine there's no technical reason not to just use the existing engine.
Is that not what he said? If you want a standard FPS game, use a game engine. If you want a game with more nuanced things, build your own engine. Seems reasonable to me.
@@xIronWarlordx Commercial engines can be used for way more than an fps. Subnautica runs on unity and kingdom come deliverance runs on cryengine. Both are much more technically impressive than either of JB's games
@@lincolnsand5127 Sure they can. That doesn't mean building your own engine is never a good idea. A technically impressive game isn't necessarily better or more fun to play. People have different tastes in games. Personally, I enjoyed playing The Witness more than the latest Assassin's Creed or whatever.
@@xIronWarlordx Not sure what enjoyment factor has to do with it. You were implying that commercial game engines only work for fps games and I just showed two examples that prove that's BS. And I never said "you should never build a custom engine". But I would say most indie devs could probably do just fine using commercial engines.
@@lincolnsand5127 Subnautica is technically impressive? It takes minutes to load, and when you swim around, the geometry and details of the sea floor very noticeably pop in and out of existence. If you go too fast, you can get somewhere before the world loads in, then it loads in the same spot as your sub and it gets stuck. The PRAWN suit randomly gets stuck on land and occasionally falls through the ground. Creatures clip through structures. Your tools always render as if they're underwater even when you're not. Sometimes wrecks don't load properly and the laser cutter doors get loaded in multiple times, and you have to cut through all of them one by one to get through.
Compare to The Witness, which loads in just a few seconds and has no noticeable pop-in, despite being just as graphically complex as Subnautica. I've had absolutely no problems with the walk system in The Witness, whereas Subnautica's PRAWN suit has gotten stuck for no reason, floated in the water, and fallen through the ground.
Subnautica is definitely playable and is a lot of fun, but there are undeniably a lot of issues. I would hardly call it a good example of using an engine to develop a technically impressive game.
20 years from now… no offence but does he really think someone will care about his games 20 years from now? there are very few games played today that are that old, usually there’s a remake if they are that popular,
Braid is from 2009, which was 15 years ago. Yes, people still talk about it, and play it. Steam charts hovers around 25, there's also the anniversary edition and other platforms. I can imagine this is important to him. I would feel the same way.
Why does Jon believe his custom coding language is gonna give us more longevity in playability? If this is his concern, then it's mighty interesting that the original Braid has been removed from steam. I thought you were about preservation, Jon...
Launchers like Steam are DRM, so they are irrelevant for preservation purposes. The important part is whether there is at least one preservable version somewhere, and there is, the standalone gog executable. A better question is whether the Anniversary Edition is going to get a DRM-free release as well.
What matters to Blow is that he can port the game to new systems in 20 years without being encumbered by some random old piece of software he doesn't have control over.
Some opinions exist to support one's exceptionalism.
Ironically the witness looks no diferent from an unity asset store game.
to a hylic maybe
He’s trying really hard to motivate why but fails, it’s pretty clear there are not many good reasons to not use an engine
There's literally 0 reasons to reinvent the wheel and make your own engine other than wanting to look cool and flex.
All his points were also wrong and based on the fact he's never used them, but I won't go into detail.
Define "the wheel". Is Unity the wheel? Is Unreal the wheel? Is Godot the wheel?
Also: ever heard of Frostbite? That engine powered Dragon Age: Inquisition. You might want to read the story of that game's development, and how much time was wasted to work around its limitations.
Which of the wheels are we talking about? Car or train? Or motorcycle? Or F1 racing car?
Unreal, Godot, Unity, Frostbite, RPG maker, Creation, REDEngine, Source²... Plenty of wheels out there.
There are many reasons to reinvent the wheel. Especially if you're making 2d. Or quest game. Especially after the s***show Unity performed last autumn.
An unity game like Celeste on linux uses 100 threads.
@Zero Bytes Celeste was created using the XNA framework, not Game Maker Studio.
Using the game 20 years from now - in the sense that Doom was ported to almost every platform - implies that he open sourced it. And assuming it was written in JAI, he would have to finish that also. So we have no JAI, we have no source, we have no valid point.
A) The JAI private beta starts in a month. B) He's not necessarily talking about open-sourcing, he's also talking about his own ability 10 years from now to go back to an old project and maintain it C) The argument also applies to his previous projects, like The Witness and Braid, which were certainly not written in JAI as JAI didn't exist yet.
@@BaremetalBaron I thought it was already in a private beta? when is public compiler gonna come out? Do i have to stream snipe Jon in FPS so he can focus on finishing it?
@@turinreza The private beta officially started the last day of 2019, so Tuesday. So yeah, it's started now, but hadn't when I wrote that comment
@@BaremetalBaron Can I join the private Beta? I am junior game designer/modder for 3d and Mobile games.
@@BaremetalBaron I need the join code mate.