A few folks have pointed out that the Unity project I'm comparing against is converting from old-style GameObjects instead of being built as DOTS from the ground up, and that this impacts how much can be read into the results. This is a valid concern and it's something I should have done better to clarify in the video. I don't believe this completely invalidates the results, I personally still find the data very interesting, but I'm pinning this comment so (hopefully) future viewers are aware of this point.
Yeah it makes sense. The more layers you strip away between the hardware and the software the faster something can run. Now time to try it in machine code lol.
@@Nexus-rt1bm Not surprised, I write firmware for relatively small devices and frequently insert assembly functions. No matter when main code in written in C++. Some critical operation as registry unlock sequences can't be made in C++ due time restrictions. Every cycle counts.
@@adamw.8579 Damn, sounds thrilling and at the same, incredibly boring. Still kinda cool though. I'll just sit back on the good abstraction layer that is rust.
@@Nexus-rt1bm ASM inserts are in fact some type abstraction layer, similar to driver functions. In desktop app programming these functions are yet implemented and programmer simply use it from library, but in microcontroller world coder is responsible to made all near from scratch. Of course there are advanced library frameworks as Atmel ASF. Simple use but very ineffective (as mentioned "rust"). Universal library = easy use, custom library = top efficiency. Ethernal truth in programming.
@Qrly Hey, all I ever did with OpenGL is a curve with a stickman on a bicycle and a ray-tracing collidoscope with only spheres and discs as supported shapes; so I have a very vague idea of how to even approach creating something of that complexity, furthermore with support of external models, animations and textures. Hats off to the dude. (Re-reading my original comment I thought it sounded a bit rude)
@Qrly Maybe for you making the video would have been way harder, but for many people, that is not the case. I would argue just based on the difference in complexity between the two, if you take someone with equal skill and experience in each, the video would have taken much less effort than getting all the lighting, texture mapping, etc working with opengl.
@Qrly Your reasoning is fundamentally flawed as different people have wildly different skill sets. For example, I am a professional animator and editor so making a video like this would take some time but would honestly be a breeze whereas coding a handbuilt engine from scratch is something completely out of my league even though I do have a bit of programming experience under my belt.
I love the comparison. The performance gain is significant, given the same level of expertise. I must say though that there are a few other considerations I'd make, especially considering that the Handmade project used a much much different architecture. Let me start by saying that the "converting MonoBehaviour to entities" thing is not a big deal, as it is the de facto way of working with DOTS as per the documentation. There's no other way that doesn't involve building all entities by code, but that would increase code complexity by at least an order of magnitude, and the performance gain is negligible (I've tried). Secondly, the ECS example was made to show relative performance, i.e. compare the performance of creating, simulating and deleting GameObjects VS DOTS Entities. That said, this Unity Sample is an example of a badly performant codebase, simplified for clarity to be used in a Slides Presentation. When actually using DOTS in the real world you would add and remove the Disable component to bullets instead of deleting and creating new ones, for an example. The point is: comparing this code sample (bad performance by design) and an unreadable simplicity/performance first codebase does give some insight, but needs a very healthy pinch of salt. Thirdly, the DOTS example is a lot easier to build upon and contribute. And I don't mean only DOTS specifically, but ECS in general. If you were to integrate my favorite ECS library, EnTT, instead of directly hardcoding data manipulation, you'd instantly lose some of that ~10x performance. But then comes Jerry and wants you to add Walls, Conveyor Belts, Cameras, Alarms, X new enemies, Weapons, [...], you'll have a much easier time with EnTT/DOTS than the hardcoded specialized approach AND better performance in the end result, with the much much easier parallelizing. That also affects teams/contributors. If working on a team, ease of extendability is all that more important. Overall, I am actually impressed with how many lines you managed to complete this, I expected at least twice that number. This video is pretty old already, so it might also be interesting to state that DOTS changed a lot this year. So much that you'd need to rewrite most of the code from the original sample to get it running. The changes not only brought better performance, but also made the API a lot more sane than it was before. If I was to remake this comparison today, I'd make sure to use ECS on both sides, and would use the same optimizations on Unity whenever possible. Enable the burst compiler, and make sure to parallelize systems execution whenever possible. And lastly, but not leastly, make something a bit more complex as a test of extendibility; extend both Unity's prototype and the handmade counterpart with a few more features. And if you read all of this, congratulations! You are probably interested in seeing some code. Look me up on github and you'll find a DotS project that is a tad bigger than this prototype, and with the new v0.16 API.
Expansion/ adding more items etc should be easy since you already have all the movement mechanics etc. You are only adding a new item and the new functionality if there even is new functionality. A new enemy only requires a new model while using the same movement and collisions where a conveyor belt needs to perform specific function such as spawning and moving items. I agree that the unity example wasn't built efficiently and his time investment was building a "game engine" for HIS game instead of a game engine for EVERY game which unity has to support. I think that is where the biggest differences in performance come in. These game engines are like the F35 joint strike fighter. Good at lots of things but great at none because it has to fill many rolls and be adaptable. That is where a modular approach can help but then you need multiple versions of many features that can be interchanged. Instead of 1 global Data Structure you are building many etc. (I know you need many anyway it is just an example). I also think many people would lack the skills to even build their own game from scratch. Unity's most popular add-ons are still those node based low code solutions.
@@excitedbox5705 I'm not sure what you are referring to in your first paragraph, but I'll assume it is about an ECS version, and I would strongly agree. If it is not about the ECS version, then you clearly did not look at the source code before commenting if you honestly believe building up on that would be that trivial. Read that code, and if you still believe that all it takes to add a new enemy is to copy the new enemy's FBX then I must have no clue how C++ programming works; but I believe am proficient in C++. The Unity example wasn't just "not built efficiently", it was deliberately built inefficiently for both readability's sake and to make a good relative benchmark. It had to create and delete gameObjects and entities when it wasn't necessary, akin to a synthetic benchmark. And a relative benchmark at that. It created unnecessary workload just to test how one API fared against the other. The C++ project, on the other hand, was built to have "feature parity", comparing its performance to something that was intentionally built to have bad performance. This is akin to comparing the PI to the nth decimal using Gregory-Leibniz and _#define__ PI = 3.14159[paste all digits until the nth here]_ . Like comparing Cinebench and an image visualizer with a PNG. It simply makes no sense, these have different applications and different objectives. I'm not saying a specialized game engine won't have better performance, it probably will. I'm saying that this comparison does not reflect Unity's real performance. I'm also saying that a hardcoded programming style is not a good alternative for game development, whatever the *initial* performance gains are. So it makes no sense to pretend this hardcoded approach would work for anything other than a simple arcade game/demo. Don't get me wrong, the C++ code would not pass any code reviews here where I work, entanglement. Check what files would need to be changed if we wanted to add 3 new features: 1 - slow motion (without breaking playtime tracking) 2 - a triple form boss 3 - walls and doors In a less hardcoded C++ code, maybe even using ECS, this would be fairly easy with the boilerplate in place. In this example's hardcoded code, you'd need to change almost all source files. Imagine that list with not 3, but 300 entries. This complexity grows exponentially. This ends up misrepresenting both Unity's and C++’s performance.
Thanks for taking the time to share your thoughts. In terms of using the particular sample as a point of comparison, I mostly selected it because Unity Technologies themselves presented it as a "look at how good DOTS performance is" example, and also it looked fun enough for me to even bother going through this whole exercise :P. I'm certainly open to the idea that there's a more suitable project out there to compare against. It's true that if the scope of the game were to be changed then this comparison becomes less and less applicable. This is why I was very careful with my "for this particular game, for this particular developer, here's a single data point" disclaimers. I apologise if it still seemed like I was misrepresenting the situation. It would be interesting to do this again today! However, if I had the time to do something like this again I'd probably try do a different comparison, like with UE, or between rendering APIs or maybe ECS vs non-ECS in handmade. I'll take a look at your project on github! Happy coding!
@@NickCastonNZ They actually presented it as "look at how good DOTS API performance is compared to MonoBehaviour", and they made a comparative and readable benchmark for that. That was made to compare both APIs. If you ever want to make a follow up to this one, be it ECS vs OOP or revisit this Unity vs C++, I'd be up to lending a hand
@Screw Kalergi In case you were asking me it's because it's a superior 3d engine compared to Unity. If you want 2d then I guess you could choose on your own.
@@necrago In case you're still available to comment on that, I'm interested on your thoughts on why Unreal Engine is superior to Unity. Or perhaps you'd refer me to an article or a post?
Great video! This is the kind of video you search for years without any success, and suddenly goes into your recommendations randomly. As I've never written an engine by myself, I am looking out for finding an answer if writing your own engine is worthy or not. You made an excellent comparison between how faster an in-house engine performs compared to a general-use commercial engine! Also, maybe another thing to take into consideration is that you don't have to pay any amount of money (in revenue) if the game comes out as a big hit for using your own custom engine. It probably won't be anyone's concern, but I think it is a thing to keep in mind. Subbed.
There are revenue free engines like Godot available out there. You can also freely customize the source code from Godot to fit your needs when needed. Basically I would only recommend building in-house engines if you're either trying to make something extremely unique that requires a new way of thinking about something that game engines didn't consider. Or if you want to either make a really big AAA product pushing the hardware. Or the polar opposite, building a really small indie project where performance is important. I don't recommend custom engines for basically all mid-sized projects. Anything from large indie to small AA studio is best off just using a generic engine.
Making your own engine for a game only makes sense when the game is either too weird or unique to do it in an existing engine or because you want to build an engine.
I promise, if you are an independent developer, making your own engine does not make sense. It only makes sense for educational purposes. The additional effort easily eclipses the performance gains. Recreating this sample scene might have only been 4x effort (for a C++/openGL expert), but adding weapons, enemies, and levels will become exponentially more difficult with the handmade approach.
@@billymonks7771 Would it be? Once you have the shader and material systems created, you can reuse them for all the things in your game, so at some point the amount of effort will be equal between the two engines.
The reason why I am building an engine is because I enjoy the challenge, I wanted to learn more about how engines work, and just to improve myself really and have fun. If you're interested in making a game then you should use a prebuilt engine, if you are looking for a challenge building an engine would actually be a nice pay-off as you know exactly how it works too. My honest answer would be, if you're making a huge complicated 3d game then you should probably use a prebuilt engine (unless you're like me and enjoy a fun challenge) although everyone forgets that 2D games exist while talking about game engines 2D games in my experience so far aren't too difficult to make while building your own engine. Sure it's still time-consuming, but not as time-consuming as a 3D game. And just to give an example I started a new 2D project completely from scratch and in 1 day I was able to get sprites and collisions and movement and stuff like that. Sure in a prebuilt you could just drag and drop a sprite in and probably do it in less than 30 minutes, but a day after work for all of that isn't a lot either. In one week I had a nice level laid out.
imagine being that comfortable that you're just like *a few days later* "Okay so I built the thing from scratch for this youtube video" and then doing so.. so much more than the average programming benchmarker
wow, that is actually inspiring. if it's only 4 times harder to build, but you end up with better control understanding and performance with margins this big(I know that results may differ, I've seen my coding skills). maybe going full rogue wasn't that much of a bad idea after all.
I bet that it takes him only 4x as long Because he has experience in the field, and lots of experience writing low level graphical renderers. If you want to jump in and do it for your first time, it’s likely going to be 10-100x as long as the math required to truly understand it all is *very* heavy.
@@krele14 yes because ALL I ever coded with was SDL and I definitely started only 4 years ago and never had ANY other experience with multiple OS and wanted a simple and mostly easy interface to work with instead of literally making everything from scratch whenever I move from Windows to Mobile to Linux or whatnot. it's not that I literally tried to search for tools that are easy to teach others and are a simple way to get away from "engine coding" into "real coding". and it's definitely not that I mostly code demoes and other things that are almost completely different to everything I have made prior and the things on the internet are explicitly from the first few revisions so they are less obfuscated by debugging and other things and can be reverse engineered into better products. I can show the revised Chess game I made but it's completely different and only uses the inferred logic from the original one. pretty much anything was exported into a LUT, the scoring system is revised, there are board hashing and multiple levels of optimization. anyone reading it would either need prior knowledge of the way chess engines work, or would need a lot of time to understand most of the "meaningless" changes that are there literally only for runtime optimization. it also moved to a fully portable codebase which includes the CLI using calls for system on both windows and linux depending on the system and uses the ANSI way of printing formatted text to the screen. I know it may seem like some of us are incompetent but for the most part it's something we want the newbies to think so they can believe "I can do this too", it's not for A-holes to lord over you with no knowledge of how writing a manual works. don't try to gatekeep if you are not even capable of knowing who is this you are gatekeeping.
I think this question of unity vs hand built is a general problem with all development. For me this is the "the right tool for the job" question. If my game requires a low amount of graphical needs, an adventure game, puzzle game, or whatever then yes unity might be a good option. It has all prebuilt code and based on the needs of your game you will never tax that system. If you are trying to make a fast paced FPS or top down that is using hordes of enemies while your player character is wielding 30 types of weapons at once at 4k resolution... then ya you may have to go hand built for that. The correct solution is always what will get the job done per the requirements in the fastest time possible.
Why is the algorithm just barely giving me this, over a year later? I would have loved to see it when it was fresh. Also, I agree. I've had more luck writing bare C++ than I have with a pre-made engine.
Phenomenal Nick. This problem is always happening in software development of all kinds. Great capturing the problem, constructing a problem setup, and putting the work in in attempt to reveal something instructive. Also learned what could be accomplished in the hands of an expert. Thanks for your video. I've walked away with a lot.
I thought it's a clickbait and started watching this video with a bias but man this is very accurate comparison. Thanks for all your efforts (1084 EU (effort units) for unity and 3638 EU for handbuilt :)
Also check some interesting you low level languages like Zig, Rust, Nim and maybe even Odin, And do not forget after you learned OpenGL to use libraries like WGPU, BGFX or TheForge for cross platform rendering capabilities so you will have a uniform graphics API that targets all of the devices
Thankyou very much for this effort, after some tweeks and hours I was able to compile your example, I Will make a pull request to extend the instructions for a more fast compilation phase
Oh nice! I chucked it on github in a bit of a rush before I went on my xmas break and looking back I see the instructions are a bit brief. Glad you got it working! I'm more than happy to accept a PR
Great demonstration and I appreciate you making this video. Another measure I think would be very important is the amount of development cost both demos would require. Something like (Amount of hours * median game dev salary) for both the Unity and handmade engine. My old manager said it perfectly: Making optimized quick code saves our customers money. Making unoptimized slow but working code saves US money. Thus this metric could argue in favor of using a pre-made engine simply because it's the most economical option. Lack of time and resources are the biggest bottleneck of every software project after all.
It depends on your goal as a business and a company. If your goal is just to use generic solutions for your product, then using pre-made solutions is obviously the way to go. However, if you also focus on other aspects rather than the specific thing a custom solution may be what you need. Pre-existing engines makes a lot of sense for a lot of game studios who just want to make games. But for studios which want to make innovation, they bet on their own engine because they can have control over the technology. It could also be that you want to be in the business of making your own engine, or technology around it.
16:49 It's interesting that the progression of frame time against bullets is roughly a parabola (O(n²) for Unity and a straight line (O(n)) for handbuilt.
I'm quite surprised it only took you ~4x time to do it from scratch. Given how hight level Unity is and complexity of writing shaders and rendering code yourself, I would have assumed different to be at least x50 if not x100. You ml must be really fluent in low level graphical development. For me it would have only taken couple of days reading articles and papers on how to implement basic techniques like shadows and bloom, something we take for granted with high level engines.
You see, that's the problem... People think that building a custom engine for your game is useless simply because IT MUST HAVE the same features! It's like an unwritten rule. "Gee dude, you're building a story driven, linear style FPS? ON A CUSTOM ENGINE? BLASPHEMY! You'll never release your game... you'll also have to code features XYZ that allow you to also create a third person camera open world game, because that's what -insert favorite commercial engine here- does. If you don't code those useless features that you'll never need or use, your engine will suck". The thing is, a large percentage of that commercial engine's features are simply dead code for you. What many don't understand is that, if you know what you're doing, it doesn't take that much more time to build a custom engine for your specific use case. Your engine might only be able to do FPS games (if those are the only features you insert), but it's gonna do a MUCH BETTER JOB at running your FPS game, with higher flexibility, than Unity or Unreal will ever be able to. True, the "startup" time of the project (aka groundwork) is going to be higher, but once you have all the basic tools, the overall time of the entire project is gonna match the time it would take to build it in a commercial engine.... sometimes it might even be lower. Not to mention the payoff at the end... having access to the entire codebase, being able to apply quick fixes and optimizations, not being tied to some company, being able to support your game for a long time and having a flexible code base etc. Another benefit is having the possibility to reuse that custom engine / functionality / libraries in the future on another project (no need to rewrite them... simply refine and optimize over time). Also, these big engines are GENERAL USE engines. Meaning they need to have a predefined framework (that most of the time restricts what you can or can't do inside the engine... which sucks big time) that you must respect. If you're trying to do something innovative / groundbreaking / interesting, the engine is going to make it hard to do anything other than generic/standard things for which it was designed. You might end up having to rewrite big portions of that engine trying to build your custom functionality (if you even get access to the engine code), which pretty much defeats the purpose of these big engines, and you might as well have written a custom one in the first place. Not to mention that this is EXACTLY what companies are going through when building their next game. P.S: Even if you use Unity, you'll still have to write your own custom shaders.
@@Borgilian I mean some people like to build their own cars so it has everything they specifically want, but most people just prefer buying existing cars because it can get them from point A to point B without them needing to do much work on how it got them there ya know. Their concerns isn't what the car is made up of it's to get them to their destination as soon as possible.
Interesting watch, but I'm left wondering how long it would take an experienced Unity developer to optimize that (intentionally brute-force algorithm to show DOTS strengths) sample further, and how much of a difference in performance that would achieve. Without those data points it's really hard to make any serious conclusions even just limited to this one project. I'd also love to see a face off between 2 people coding the same project - one experienced Unity developer and another experienced in C++/OpenGL - give them both a week and see what the results would be.
Yeah.. This is interesting but in the end it is just a single exceptionally marginal case where you instantiate thousands of objects in a single frame. THe point is.. nobody forces you to do this. If you really want to have this specific case where you shoot thousands of bullets you can easily handle all the bullets in a shot with a single gameobject and have pretty much the same performance of a custom built engine. This is also the perfect example where you are supposed to use object pooling and not create/destroy gameobjects.
@@BrunodeSouzaLino By lowering the amount of objects you absolutely could. Do not get me wrong you are not touching a custom built engine in terms of ram usage, That being said they're bloated for a reason. Those generic game engines hold Complete non biased Implementations of everything you need. With a custom game engine you can cheat. You can cut corners and make assumptions however these assumptions are not viable for a game engine that wants to support many different types of games.
@@sirdiealot7805 It's totally possible it's just not worth anyones time. Not to mention the results will still work better On a custom game engine for the reasons I outline above.
Not gonna lie, making resource heavy application natively would probably make sense, due to performance benefits, but nowadays multi-platform'ality is kinda a must.
Just use SDL and some of the 1000s of libraries for GUI, ECS, pathfinding, etc. If your platform does not have a c++ compiler and SDL support it's probably not worth supporting. Though that said I only have experience with pretty small projects. And never done anything for a console. But another overlooked benefit of your own engine/rendering code is that it all belongs to you and you alone. And it will still work in 30 years when unity might be long dead. (or the effort of making it work will not be insane)
@@TheR971 Wrong, you must update your engine in order to make it work with new quickly changing technologies, now more than ever, using an game engine is a must.
This is awesome. I'm positive DOTs will be a nice change, but I'm very impressed by your hand-building! I can't wait to learn to build game engines someday.
You can start now. Learn SDL2 (window manager + sound library and input manager) and OpenGL (learnopengl is a good resource). If you are familiar with C or C++ you can probably build a small first project within a week.
@@joey199412 Thanks! Hadn't heard of SDL before. I don't have any experience with C or C++, but I have spent quite some time in monogame. From what I've read SDL is another step lower than monogame (not sure you'd say it like that). Would be a fun project to learn when I've got time, but I've been planning on learning C++ so that'll have to happen first.
@@tomasbenders922 After you learn OpenGL, It is best for you to move to using open source cross platform rendering abstraction layers like WGPU or BGFX, Also use cross platform audio libraries such as OpenAL or others, Enitity component system libraries like EnTT and physics libraries like PhysX or Bullet and others, And after that you will be in a good shape to make your own engines and engines tailored to specific games and use cases.
@@astroid-ws4py I've heard of all except WGPU and BGFX. Been watching some cherno which is fun. Have since been using c++ and opengl, mainly doing basic graphics stuf so I'm on my way :)
Every game studio i worked at used their own engines primarily. Cater it to what you need, genres, etc and then if you are lucky you have an engine which you can try to sell on or share across studios if you get bought out etc. Also, no licensing fees :)
True but running your own engine also incurs costs. You need to have engineers to develop it and add new features. And documentation to actually make the engine useable by employees. I worked with the Playstation phyre engine as part of a Uni project and it was one of the worst projects I've worked on. Poor documentation led to frustrating attempts of jerry rigging code together to try and get things to work. Also no 2 engines are equal. One engine might be focused towards FPS whilst another might be focused towards RPG's. Perfect example of when not to use a company made engine is with EA's Anthem. Forcing bioware to use that engine for a game it wasn't suited to, whilst also not having the engineering staff to make proper character creation systems within the engine caused major project issues. Aside from poor management decisions. Unity is great because it's a generic engine, pretty good at everything. Sure it's not the most performant but there's always ways around that. Where as developing your own engine from scratch takes additional time and money, neither of which you might have.
Yeah, its pretty much only AAA studios that make custom engines, and when that is not the case it usually means the game is some simple 2D game, or at least a simple 3D game, without advanced physics, animations, graphic effects and so on. There are a few examples where it has happened. Like Serious Sam. But its pretty rare an indie studio uses a custom engine for complex games.
I usually prefer to go the hand-built route for my projects, just because it's more fun and I get more experience with things I wouldn't have.. Plus I like having more control over my projects, yes it does mean that there a many more ways you can go wrong, but hey, at least now I know I'm actually gaining a significant amount of performances for my work, so it's quite reassuring!
Btw, Very great video!!! Very love to see finally there is people make performance comparison on game made with raw/pure code with internal api's and compare it to game created using game engine.. im soo interesting to performance optimization topic like this, im sub man.
Interesting, thanks for making this video. Ok so you spent 3-4x the time to make it work from scratch. But then you'll also have a code base to reuse in future games, you basically have a mini game engine you can reuse. So for the next game it will maybe take 2x the time compared to Unity. And then continue to be smaller for each project. I almost always code my stuff from scratch for this reason. You cut away the bloat, you get better performance, and you'll learn more too. But for something simple that doesn't require high performance, Unity is of course the way to go.
When we need to develop for general purpose, we need to balance between trade-offs. When we develop for single purpose, we can focus on single goal. The latter usually have more opportunity of optimizations. Generally, the observations made in this video makes sense, and I'm not surprised. Unless you have multi-person team that includes non-technical members, for small projects, the handbuilt solution seems the better option. Good to know.
And that's the reason that the graphics are improving more slowly. Because games are becoming more demanding due to easy production, using ready-made algorithms, and hardware is also becoming more powerful. This does not greatly benefit end-users, but it becomes easier and more profitable for developers, especially indie developers.
Alright, that's literally one of the best video I found on internet. Well done, please keep it up! Also, you're a very skilled game engine developer :)
Great performance comparison. The mixed version from unity that still uses gameobjects is a fair representation of how most developers will start with ECS.
A note for those who want to benchmark something: closing applications often isn't enough, from my experience even windows downloading an update can take up 30% of CPU. Just pause updates and check that there aren't apps that use much of system resources
It's obvious performance would be a winner in a software made for the hardware. The main issue is, now clone the lighting, shading system, post processing effects, animation system that allows you to both animate and add scripts to animations, direct Blender and model rigging etc. In the super long run it's a winner, but unless you're gonna be a huge experienced team with a massive budget project, then it's better to use another engine that gets updated and gives you the tools to start making your game right now. A good example is WARSHIFT and Overgrowth. WARSHIFT was made by one guy in Unity for a couple of years and is a marvel in independent development. Overgrowth is a masterpiece in responsive and great gameplay and was hand crafted work can be from scratch. But even the developer himself admits he did a lot of flaws and wrongs with this approach. As it's taken him many many years to just get a playable campaign to it. Personally I'd say get experienced in an engine like Godot or Unity, make some games and learn the structure and code design with software and hardware as well as library structure. Then you can start practicing from scratch as that's a huge difference. Even with open source graphical programs and physics engines. It would take a lot of time to get to a big triple A level compared to in Unity. I'd rather make a laggy masterpiece in Unity, then spend my time optimizing it. It also helps with motivation to see your work rather than spending more time making a work station for your project then make a custom map editor before getting started on the actual game.
I wonder if this result scales. In my opinion, it does not. The effort can be 3 times for a small project, but it can be much greater for a more complex / complete game. The other thing that must be taken into consideration is that it is much easier to train someone to be Unity programmer than to be an C++ game programmer. The real effort is the cost of building that and it will be more costly to pay someone to build it from scratch than to use Unity. The last point is that you are cloning a project that was built on Unity. A fair comparison would be using a design document as reference. The good thing about engines is the ability to iterate over ideas, because you have access to a lot of resources and prebuilt components. Doing stuff from scratch with an ambiguous goal is very challenging.
To your first concern, I agree. But for small games (the kind you would make on your own anyway) and for specific genres (not asset heavy/procedural, mechanics focused for example) your own engine can still go a long way. About writing C++, you can very easily hook something like Lua into your own engine if you have more design/gameplay focused programmers in your team that you wouldn't want to be concerned with engine code.
@@Radgerayden-ist On the other hand I'd say it also depends. If you have small team without much game engine related knowledge it's still might be worth to use Game Engine just because nowadays there isn't much difference if a game need 55 or 500... even about 800 MiB of RAM should be ok. It's because it "steals" your focus. It's not something running in the background that uses resources that other application could use.
Thanks! Interesting comparison. Sour but needed reality check for state of DOTS. I'm aware of few optimizations that Unity version could employ (stripping bloat of data from bullet entities and changing how instancing happens to be more memory-friendly) but for sake of performance-vs-productivity comparison this is still a valid sample project to test.
This is why I coded my own 3D engine in C++ from scratch on my RUclips channel. Like you I also get massive performance gains even on low end mobile devices.
@@luckylove72 You always paid money for lack of skills or time. It doesn't matter if it is today or was 1000 years ago. Technology changed, professions changed but principle is the same.
Zero, if you choose your libraries correctly. I'm writing a game in c++ and (once I got the IDE to work) it compiled just fine on windows (I usually run on linux) and even ARM Linux as well. Of course if you want to go to consoles it will be harder.
Would be interesting to know how this scales going further into the project. Like, does the hand built version count as a lot of groundwork, or does the effort continue to be 4x the unity effort?
Thank you! This was extremely informative. It makes a case for handbuilt games in the indie space, especially in some niche, data-oriented genres like bullet hells. Losing the easy multi-platform support is something to be seriously considered, though.
This would be easy multi-platform as well. OpenGL and window managers like SDL run on basically everything so you would just need to recompile it for every platform and maybe revise resolutions a bit to match handheld devices and it wouldn't be very different. I agree with your main point and I think small indie projects in particular would benefit the most from hand-made engines. Especially if you want to do something unique. Notch's Minecraft comes to mind which would have been impossible to develop with UE3, Unity or Source Engine at the time it was made.
Great comparison! However you have to take into account many other factors. Unity is a well known game engine. Working in a team requires everyone to be aware of what they are doing, which is very difficult to achieve for handmade solutions. People are used to certain workflow. Total effort/performance ratio could be way different for a game that has slightly larger scale. I think for very small games you could go with either handmade or unity (cause unity overhead for small games usually doesn't show up, unless you have really complicated stuff going on) For middle scale games unity is a way to go. For large AAA games you have to make your own game engine.
Thanks for the feedback and input! Originally I had more discussion in the video about this kinda stuff but it got way too long so I decided to cut it down to just background context and raw results with a "this is just one data point" disclaimer. At any rate... I agree that looking at a project of this size means a lot of factors which are important for larger projects don't get represented. I realize I might come off a bit handbuilt-biased (and maybe I am slightly) but it can't be denied that a huge number of successful projects have been built with Unity (and other engines). You make a good point about being used to certain workflows. Using a widely-adopted engine definitely has its advantages there. I have a huge selection bias, but I've seen a lot of experienced devs getting frustrated with Unity when they don't have the control they'd like. So it's possible to go both ways. It's definitely a very nuanced decision, dependent on the project, the team, and the available resources. And hopefully this video helps someone out there, not as a complete answer, but an interesting anecdote.
Nicely explained. Now I'd like to refer to this as a "rookie" programmer. As for my skill: I've never done big projects or anything like this in 3D. I only once made a sample 3D platformer and all you could do was move, jump and collect coins. No cam rotation, no animations. I only make simple 2D projects, currently working on a GeometryDash-like gravity-based platformer, so I'm not good at all :D But even so I stumbled upon many problems regarding the fps amount. Like- simple 2D UI animations can lag the game a bit for no reason. But the biggest issue I had was with Audio Source. I tested a few options of putting it into the game and, surprisingly, when I put it on a moving player object, my fps dropped from 250 to 30. I tried putting it on static object, resulted in 40-50 fps. Putting it on canvas gave me 70-80 fps with occasional spikes. And the only way not to hurt the fps was putting it on an empy object, which gave me 230-250 stable fps once again. I find these small issues with Unity interesting and although they are not that big of a deal for me, who does nothing impressive, I can't imagine this issue on a bigger project. I know there must be better optimization and many things I don't know, but still... To wrap it up- if you look at it from a newbie point of view, the difference between effort needed for Unity and handbuild game is huge. Just consider point of view of someone who literally knows 0 about game dev. For me, learning to write "OnCollision" is like 10 times faster than learning to make a collision for handbuild games. To put it this way- I think Unity is great for beginners to get them hooked into this. If they want to improve and move on to something different afterwards, then leaving Unity behind is good. As for me- I think I will stick to Unity. I'm a lone developer, I know only a little stuff and I don't have great ambitions for this anyways (I'm more of a story writer and teacher than pro developer. My stories brought more attention than game projects themselves...). I'll be glad if I release 1 successful game for now. I have 2 released shitty projects behind me, so it's time to make something better. Who knows? Maybe you'll some time in the future play my game, guys :D
I think using Unity (or any third-party engine) is a perfectly valid choice in many situations - and it sounds like you've landed on a decision which works well for you! My goal with this video was just to provide some data and leave it up to the viewer to decide how it applies to their situation. Best of luck with your games!
It's like with using C++: usually most compilers generate good enough machine code for most of the cases, but if it doesn't or you want it to go faster and you have the knowledge you can usually outperform it. Answering the question whether it's worth it is entirely up to you. Setting up your own engine with physics, logic, graphics, animation, sounds and everything else is a massive undertaking and is an order of magnitude harder than using a general-purpose engine like Unity.
The exponential growth in frame time in the Unity version doesn't seem to correlate to any of the other metrics gathered. I wonder what is causing that? Is it possible, for example, that something like lighting per particle in the Unity version is leading to some material*light complexity? (What happens if particle lighting is disabled?)
I was thinking it might also be an issue of CPU cache being exhausted at a certain point. Once CPU cache is exceeded for the critical code/data paths, you can really hit a performance wall. So, related to RAM bandwidth in the previous reply, but closer to CPU cores.
With sure, doing in C++ is very faster to execute, very better performance and we can use too Data-Oriented design in C. The main problem inside Unity is the quantity of layers to abstract from low to high level of programing and the builds to more plataforms with the same code. And the problem with C++ is the time to develop all code. Unity has the advantage too of constant atualizations to new platforms with the same code. I remember not so long time ago, 1 month to do a good water simulation, and now, drag and drop and it is ready, because this game engine as Unity is all. Very good comparisions ! Some especialized applications need to be in C++ yet where performance is more important.
My opinion on this (that this video also seems to support) is that pre made high level engines like unity are useful for smaller projects or prototypes, where it's mostly important to get the project working without it taking too much time and effort to make, while making a project from scratch is better for more advanced projects where optimisation is important.
Thanks for the video, it was something I thought about recently (since my project doesn't really use much from the engine itself). I would maybe suggest some followup where you'll try to implement the bullets (and only bullets) in the optimized fashion in the Unity. I somewhat know the UE and the general workflow is to "build it fast" with the Unreal and then optimize away... just implementing "BulletManager" (instead of bullet actors) will be significantly easier than building the whole solution, but It still might not get as far as your fully native implementation. It would be interesting to see this, instead of the naive unity implementation, so to speak. That being said, would you expect your 3-4x effort ratio to go up, or down if the project would be bigger? I would argue that it might go lower, but I have no real frame of reference for it.
Thanks for the feedback! There's definitely a lot of room for other investigations to be done here. In terms of the effort ratio, I don't have any experience with large Unity games, so it's just my thoughts. I expect the ratio would go down as the project gets larger. Getting a 3D animated model running around and shooting is like Unity bread and butter, whereas a lot (not all) of the costs for building from scratch are front-loaded. Later on in large projects is where the lack of control in Unity might start to hurt (e.g. if you start running into serious memory problems). This seems to be reflected in industry with large AAA companies more skewed towards custom engine and indies skewed more towards third-party engine - of course there are plenty of exceptions and lots of factors at play, but it seems to be a general trend.
I would argue that depends on what your scope is in this case where it just needs to run on a single system on a single platform it's probably fine. However you do need to keep in mind Many publishers won't take you if you have a custom game engine Because they don't want to have to sit there and port your massive code base to xbox or playstation. Playstation in particular if I remember correctly has their own graphics API. Also it also would depend on how long you've been using the engine and how many engines you've made prior. If this is the 1st game with the engine and you've never made an engine before then trying to create a first person shooter without networking Is going to be a lot more time consuming if you are originally doing a first person shooter with no networking. So I would argue it really depends on what you're trying to do. Not to mention you also have no tooling, Every tool needs to be created by you which can add up But it can also mean that you can streamline your workflow.
If my memory is correct, compiled empty unity project cost about 60MB storage. They still include core things before our project is added to the engine (I am not sure how since compiled game is encrypted) But in scratch code, we may code more freely without many feature like unity do. But building engine from scratch is so time consuming and needs more than knowing math and it is computer science
The best example of this is Crysis. When you build your engine from the ground up with the most important parts being written in Assembly, you can do things other generic engines can only dream of. The price being, you have to worry about compatibility, coss platform and all that fun stuff etc.
Apparently, no. He thought that this sample project is the most optimized implementation of shown gameplay that Unity can make. It's sad to see how many people see this as a good comparison.
@@sacredgeometry I don't know about that. Sure it has a ton of overhead (abstraction, generalization, etc) just like Unity, but the user code is also C++ instead of C#. You might be right, but I certainly would like to see the hard data.
@@cagefury3789 Unity has IL2CPP, also unity is made with C++. Sure you would have performance differences, but that mostly comes from memory management which isn't an issue on this scenario .
Been usin unity for 3 years, i must say that using a game engine makes it considerably harder to ubderstand concepts such as rendering and shading. Hoever game engines also make life way easier for the developer as the dev mostly needs to code in the game mechanics. Great video and really well explained
Thanks for this Nick. I did the same a while back when deciding to write a 2d game that's been in my head for 10+ years. I'm not a coder but know how to code, I'm old school (z80, 6800, Cobol, c, c++ and c#) and as such struggled with Unity structure. That said, I was prepared to learn Unity but wanted to make sure I was making the right decision as I had heard that performance was an issue for Unity. I did what you did but with not as much detail, I just wanted to know about memory usage and fps. I was so surprised by my results that I was sure that I'd made a mistake because the Unity results were so poor. Granted that this was a few versions of Unity ago but I'm glad that I decided to use c++ although writing a UI library sucked but I won't have to write one again. I used DirectX 11 with DirectXTK to aid with maths and audio. I'm not scared by the low-level nature of DirectX but I do understand that this scares a lot of people which is why Unity is great at hiding it all. Unity is great if you're not an experienced programmer or want to prototype something, but if want to write a complicated game, either in graphical or data detail, it may struggle. I'm aware of a few teams that had to almost start again as they couldn't get Unity to perform as desired, even sending their codebase to Unity didn't help.
Really cool to hear about your journey. Thanks for sharing! It's interesting to hear you went down a similar path and reached a similar conclusion. I'm also glad I went down the C++ path for my game, but I do totally understand the case for using an existing engine. Good luck with your project!
very informative, thank you. For the difference of effort, I feel like the difference will be more significant if we include the time to learn Unity/OpenGL if you are not an export.
From my personal experience it's a lot harder to learn unity than it is to learn OpenGL. OpenGL feels like just a library of functions. While unity is a sophisticated tool that makes you feel lost in a forest. If you want to start you can just do so with OpenGL and only uncover features as you need them. With unity though you need to learn how to navigate the entire toolset. How they are used etc which is significantly harder.
@@joey199412 But unity has a huge community and tons of resources. My experience with OpenGL is limited but I had little place to look for help when in my game engine class when we were using it.
Very interesting videos, and I'm commenting on all of them to improve their metrics based on engagement.. thank you for all your effort, I love these videos!
@@igorgiuseppe1862 Vulkan is simpler and more fun than OpenGL. But for maximum performance it is just as complex as the dx12. But still Vulcan loves to work with high level C++ and std. OpenGL looks more like "uglest" C.
@@Lord2225 Vulkan is simpler than OpenGL? As far as i peeked, it looked significantly harder. If you have any good sources for learning Vulkan please do share.
@@Navhkrin @Navhkrin I used to learn from source. It wasn't my first graphic lib and all of them usually repeat same pattern so it wasn't so hard to learn for me. For someone that is new in CG learining vulcan from doc could be confiusing. Form my perspective it is more modern, gose with trends and it is intuitive.
At the start of the video, you mentioned that one of the strong points about game engines was the ease of making games for multiple platforms. It would be interesting if you took that into consideration in your comparison, specially in terms of amount of effort. It seems to me that if the comparison was made for a multiplatform project, and not for windows only like it is stated in your github project, the difference in terms of amount of effort would be much greater. Good video, nonetheless!
Did you ever consider comparing unreal engine 4 with c++ to unity and the hand-built? Would be fascinating to see how ue4 compares using c++ as opposed to handmade c++
It isn't the C++ that provides the speedup. Sure there's some overhead it removes from the C# runtime stuff but the real gain in performance is because you remove the overhead of engine features you're not really using but are still being applied behind the scenes. UE4 while performing better in optimal cases than Unity would still perform significantly worse than a special made engine for a single task.
Nice work, but I don't think the result suggests anything. In programming, making something go fast is only one of the concerns, out of many. More important than that is keeping the code manageable, extendible, portable, modular, and usable by multiple people. That's what Unity solves; that's what any game engine solves: management of complexity. They don't advertise DOT's speed stand alone; anyone can code simple graphics that are fast. They advertised their speed _given that it's running on Unity_ , a full engine. You might as well say "I've written a for loop in C that outperforms a for loop in Python by 500x!!". Nicely done, but it's not really Python's claim to be faster than C, and it won't compel any Python user to switch. (That seems a bit harsh, sorry about that, don't mean it this way)
This was a VERY good video! I didn't know much about game engines or how it compares to making things from scratch, but this gives some great insight into it.
Nick, really interesting video. I can define you approach like an engineereistic approach and I find this the best you could have chosen. Thank you so much!I think i will use the handbuild approach cause even if it's longer , I can learn a lot from it.
Great Video, You did a great job showing some of the Big disadvantages of a game engine vs doing it from scratch. For the people reading this it's important to understand the value of maintainability and the ability for multiple people to work on it at once, as well as the abstraction of ideas. As a sole developer you may be able to get away with understanding every detail, but on a large scale project you would be better off being able to outsource some of the stuff you don't know how to do to either; the engine, or another person. I really enjoyed watching this though!
Conclusion - use Unity for quick demos and "sketching", whilst building the end product using "hand-built" method. I don't know why, but this kind of comparison reminds of the story how Crysis was created, where they build the game and the engine to match the quality of the cinematic movie
Thats only viable for AAA studios. For individuals or small teams, making an engine from scratch for every type of game that you make is just not possible. Only make a game engine when you are sure you want to make a specific type of game, and only if the already existing engines don't provide the features or performance you are looking for. Unity /Unreal etc should be enough for 95% of the games that you can dream of
I think this is hugely flawed, given how small it is. You might notice that much of a performance difference with such simple and basic tests, because Unity still has all of that background, abstraction, etc to load. If you look at a game like Kerbal Space Program, I would say the difference in performance of a custom built solution vs Unity is going to be much smaller. And this is coming from someone who always likes to write their own implementations of things. Also the same applies to developing a larger game in terms of effort as well. For larger projects it works much better. For a small basic project like this I think you're right. But for a larger project I think things get much closer.
Man, that was awesome. I never thought that handbuilt game could be SO much better in performance than what unity team achieved with all: ECS, Jobs and Burst compiler. Now, thanks for you, I will think twice on: “should I use existing game engine or try to write game from scratch”?, for my future games.
Why? Game engines like Unity aren't about providing you with the best performance. They are about providing you with the tools you need to build games. It can take, literally, years to build a game engine and that's before you even start building a game with it. Unless that's what you want to do why waste your time? Before I discovered Unity, Unreal Engine, Godot etc I was making my own game engine in C++. I'd spend months and all I'd achieve is some playable 2D sprites on the screen. With Unity (or equivalent) I can get a 3D first person shooting game up and running.
@@odo432, I didn't say anything about how easy(or fast) is to create your own game(or game engine). Why did you start to point it out? Also, what is the meaning behind "wasting" time? What if I care about the game, but not about the money and time I spent on it? What if my game involves high computations and it requires better perfmormance? What about the time and effort you spent learning Unity or other game engines? Is it really good to depend on someone's engine? What if you want to make changes to the internal work of the engine? The answers to all those questions are not exact and depend on people's personalities, experiences, abilities, goals, etc.
@@rasulseidagul As you said. All depends on what you want. Given that both Unreal Engine and Unity have both been used in AAA games and games requiring lots of computations it really doesn't make any sense to build your own game engine other than for it to be a hobby or learning experience. Building a game engine is like trying to recreate the wheel. Someone's already done it. You're really not going to achieve much of anything by making your own. As for "is it really good to depend on someone else's game engine". We are talking about game engines that have had YEARS of development by hundreds/thousands of developers and battle tested by millions of users. I have no issues with trusting them. They are very stable.
@Mat O ok, so what about people who do create their own game engines or write their games from scratch(as, for example, Jonathan Blow do)? Do you think they are recreating the wheel? And, you know, there is a well-known product: Google Docs, which has been "battle-tested" by billion users but still has annoying and not elaborated control over images in the text. Having a big community means that the most popular cases are covered(at least), but not all of them guaranteed to be solved. And yeah - it does make sense to write your game from scratch if it requires better performance than Unreal and Unity could provide you with their bloated insights. The video, under which we are talking, has clearly shown that.
@@rasulseidagul Well, yes. The only reason to create your own custom engine is if it offers you something that an already created game engine does not. And there really isn't much in that regards. Also, unless you are an exceptionally good programmer, chances are any game engine you create is going to be riddled with a lot more bugs and issues than one that's already been created.
After you spend a significant amount of time creating the tooling required for your game, then the time differential starts to diminish and you would find that at times, the tooling you created would give you a boost in development speed compared to unity, because Unity need to account for a lot of possible scenarios, where your tooling is specific for this single game. This is why triple A game studios spend a lot of money developing their own internal game engines, and training developers to use it, because it pays off later and you start to spill games like a production line. This is why Assassins Creed games launch every year probably xD
Greate comparison. You had old information about the release date. DOTS was planned to be released on Q1 of 2020 a long time ago, it was pushed back. I think it is possible to write own rendering solution in DOTS instead one provided and reduce memory usage but it would require the extra effort of course.
Seeing Godot performance would be cool too. It's seem like it's quite capable and gained some popularity so it could be nice to see how open-source engine perform compared with both Unity and handbuilt.
@@elementiro Godot does allow you to code in C++, doesn't it? Shouldn't that mean that (unless there's some huge rendering overhead or something) you could write efficient C++ and get the same performance as the hand-built version in the video?
@@ThePC007 No, Godot will not perform better because the issue is not C++ vs C# (or any other language that doesn't completely trash performance). Yes, there's a difference between the two but the main bottleneck in this benchmark was memory access, not CPU time. If both solutions were close to the 100% CPU utilization, you could make the argument that C#'s JIT compiler either takes too much time to optimize or not doesn't optimize well enough. But that is not the case.
@@DLCSpider @DLC Spider The memory access bottleneck might stem from the fact that the memory is laid out less efficiently in the Unity version. The video has shown that every bullet needs ~500 bytes of memory for some reason. While we don't know precisely what that memory is used for, it may very well be something that wastes precious cache line space and thus hits the memory access bottleneck sooner than the C++ version. In C++ we have tight control over how memory is laid out, so it's very much possible that Godot + C++ might achieve similar performance as the self-built version.
@@ThePC007 just like DLC Spider said, it shouldn't be the case - the better performace doesn't come from different language (I believe handbuilt C# version should have similar performace as handbuild c++, maybe slightly worse) but because you're omitting extra layers and features that come with ready general-purpose game engine.
Awesome comparison video. You forgot to include the difference between skilled handbuildist vs unity developer. I takes a lot more years and more money to train and hire a skilled handbuildist. And even if that was not the case, 7 days instead of one day would justify using Unity is the better choice for most games.
1 day vs one weak may not sound like a lot, but if your project takes 1 year to be complete, then it would take 7 years without an engine. and if you want to make an comercially viable game, you will need to spend time developing it. (i know we cant extrapolate like that, but it helps put it into perspective)
I think it would be even more extreme. A simple hardcoded project takes 4x as much time as in Unity. But imagine introducing tons and tons of new features.
@@АртёмСабадырь writing your own engine is an good option if you have tons of employees. it uses more resources from the company, but the performance pays off at the end, those companies can solve the time difference by puting tons of employees. (eg: 100 employes to do in 1 year, what 10 employees would waste 10 years to do, its just an example, in pratice its not so simple, most of the time you cant throw 10x more people at an problem and expect it to be solved 10x faster) writing your own engine work at scale, but for smaller companies it might not have the desired result, quite the contrary. in any case, if you plan to start your own engine, you probably wont want to reinvent everything. unreal licenced part of its code to companies who were willing to pay and nowadays its open source for everyone. many of those other engines were born out of parts of licenced code from thirdy parties. (eg: lumbeyard) godot is another good option of open source engine. i recomend contributing back to those projects instead of starting from scratch.
@@nilstrieb i think the main issue is iteration. i mean, what if the feature that took you ages to implement end up not being fun? you wasted years to discovery it, and now you will waste more years to code another feature... an game engine allow you to test new ideas quickly, either for gameplay or for art direction or for anything... then, when you are satisfied with the results you can decide if you will need to make it on your own code base (due to the performace requirements) or if you gona use the engine.
I'm not sure if this has been discussed already, but default build in windows would be using direct X. There would also be definitely some difference there unless you forced OpenGL on Unity? It's a lot more difficult making a game engine with a great API. I remember making a 3D Game Engine using OpenGL to target Android, Linux and Windows at the time using Free Pascal. Most of my time was spent making the API easy to use.. and it was built completely from ground up including math, windowing, input, everything and was modular so someone could add a different input module very easily. But that took a loooooong time. So patch building a quick engine that won't hold up for future games is easy.. making one that everyone can use in many scenarios and targets and examples.. that's the time consuming part. Edit: Also worth some discussion is if you used HDR mode, Forward rendering / deferred, and other quality settings like antialiasing. I'm sure you looked into those already.
Your comparison is not correct. It's not pure Unity DOTS thing, it's just the simple example, where half of project is using old Unity Engine techologies: old GameObjects, old physics, etc. Bottleneck of this Unity sample is old GameObjects using. Old GameObjects are very slow and vast a lot of RAM. So DOTS should solve this trouble. You can use Boids Demo as example of pure DOTS. github.com/Unity-Technologies/EntityComponentSystemSamples/tree/master/ECSSamples/Assets/Advanced/Boids
Unity one is just an example and its super unoptimized code, bullets are GameObjects with a MonoBehaviour to control it. The c++ code is the oposite, bullets are like Transforms: position and rotation only. To do something similar on unity you would need to use only a list of transforms, doing it yourself the calculations on 4 threads (or even ComputeShaders) and render on a particle shader. No DOTS needed.
A few folks have pointed out that the Unity project I'm comparing against is converting from old-style GameObjects instead of being built as DOTS from the ground up, and that this impacts how much can be read into the results. This is a valid concern and it's something I should have done better to clarify in the video. I don't believe this completely invalidates the results, I personally still find the data very interesting, but I'm pinning this comment so (hopefully) future viewers are aware of this point.
And why u didn't build the game with IL2CPP enabled for unity it gives much more performance because when u run it in editor it gives bad performance
great comparison
I think that if you're a solo indie dev, use unity guilty free, I want to be a game dev, not a game engine engineer
@@kunkerkar true
@@kunkerkar He clearly stated he wasn't going to use run time because of the mandatory splash screen. He built the game, didn't run it on the editor.
"Let me open my fancy IDE"
*opens notepad*
lol , only legends can code in notepad
IDE's are anyways bloat
Use vim
@@mustafazakiassagaf1757 Did you mean: *emacs*
@@sdrawkcabmiay Hey man, come on now. Notepad was the shit for writing batch script text based adventure games on your grandmas windows xp
Difference between specific solution and generic solution, good video.
So what to drink?
@@vladmakarenko6641 wine
@@kristiyanivanov7414 wine drink only Linuxoids🌚
@AngryJoeIsRacist Super Racist me
@AngryJoeIsRacist Super Racist I definitely am.
12:02 no full auto in the buildings!!!
*"It's not full-auto."*
"That's not full-auto?"
*"This is."*
*_12:03_*
*"That's full-auto."*
"Damn, bro! Okay."
This meme is useless though. Full auto IS for close quarter combat....so you spray everywhere and hit everything. Unless there is a hostage situation.
@@danielkolev Hi
@@danielkolev in IRL combat full auto is only useful for suppressing fire, control and accuracy is a lot more important.
@@matheusgclassen Read my message again. I was reffering to close quarter combat...
Yeah it makes sense. The more layers you strip away between the hardware and the software the faster something can run. Now time to try it in machine code lol.
Assembly coding critical functions is very good solution, commonly used up to now, when any single opcode counts.
You would suprised by the number of people who write assembly for "fun"
@@Nexus-rt1bm Not surprised, I write firmware for relatively small devices and frequently insert assembly functions. No matter when main code in written in C++. Some critical operation as registry unlock sequences can't be made in C++ due time restrictions. Every cycle counts.
@@adamw.8579 Damn, sounds thrilling and at the same, incredibly boring. Still kinda cool though. I'll just sit back on the good abstraction layer that is rust.
@@Nexus-rt1bm ASM inserts are in fact some type abstraction layer, similar to driver functions. In desktop app programming these functions are yet implemented and programmer simply use it from library, but in microcontroller world coder is responsible to made all near from scratch. Of course there are advanced library frameworks as Atmel ASF. Simple use but very ineffective (as mentioned "rust"). Universal library = easy use, custom library = top efficiency. Ethernal truth in programming.
this video is just a flex on how good you are with Open GL, isn't it?
(I will give it to ya, looks waaaay too good)
@Qrly Hey, all I ever did with OpenGL is a curve with a stickman on a bicycle and a ray-tracing collidoscope with only spheres and discs as supported shapes; so I have a very vague idea of how to even approach creating something of that complexity, furthermore with support of external models, animations and textures.
Hats off to the dude.
(Re-reading my original comment I thought it sounded a bit rude)
@Qrly Maybe for you making the video would have been way harder, but for many people, that is not the case. I would argue just based on the difference in complexity between the two, if you take someone with equal skill and experience in each, the video would have taken much less effort than getting all the lighting, texture mapping, etc working with opengl.
@Qrly Your reasoning is fundamentally flawed as different people have wildly different skill sets. For example, I am a professional animator and editor so making a video like this would take some time but would honestly be a breeze whereas coding a handbuilt engine from scratch is something completely out of my league even though I do have a bit of programming experience under my belt.
@@kanjakan bruh
@@shreksthongg bruh
I didn't realize I just watched 28 minutes of this, you got me really engaged, great job.
What the heck, I didnt even scroll the comments until after the 20 minute mark.
I love the comparison. The performance gain is significant, given the same level of expertise.
I must say though that there are a few other considerations I'd make, especially considering that the Handmade project used a much much different architecture.
Let me start by saying that the "converting MonoBehaviour to entities" thing is not a big deal, as it is the de facto way of working with DOTS as per the documentation.
There's no other way that doesn't involve building all entities by code, but that would increase code complexity by at least an order of magnitude, and the performance gain is negligible (I've tried).
Secondly, the ECS example was made to show relative performance, i.e. compare the performance of creating, simulating and deleting GameObjects VS DOTS Entities.
That said, this Unity Sample is an example of a badly performant codebase, simplified for clarity to be used in a Slides Presentation.
When actually using DOTS in the real world you would add and remove the Disable component to bullets instead of deleting and creating new ones, for an example.
The point is: comparing this code sample (bad performance by design) and an unreadable simplicity/performance first codebase does give some insight, but needs a very healthy pinch of salt.
Thirdly, the DOTS example is a lot easier to build upon and contribute. And I don't mean only DOTS specifically, but ECS in general.
If you were to integrate my favorite ECS library, EnTT, instead of directly hardcoding data manipulation, you'd instantly lose some of that ~10x performance.
But then comes Jerry and wants you to add Walls, Conveyor Belts, Cameras, Alarms, X new enemies, Weapons, [...], you'll have a much easier time with EnTT/DOTS than the hardcoded specialized approach AND better performance in the end result, with the much much easier parallelizing.
That also affects teams/contributors. If working on a team, ease of extendability is all that more important.
Overall, I am actually impressed with how many lines you managed to complete this, I expected at least twice that number.
This video is pretty old already, so it might also be interesting to state that DOTS changed a lot this year.
So much that you'd need to rewrite most of the code from the original sample to get it running.
The changes not only brought better performance, but also made the API a lot more sane than it was before.
If I was to remake this comparison today, I'd make sure to use ECS on both sides, and would use the same optimizations on Unity whenever possible.
Enable the burst compiler, and make sure to parallelize systems execution whenever possible.
And lastly, but not leastly, make something a bit more complex as a test of extendibility; extend both Unity's prototype and the handmade counterpart with a few more features.
And if you read all of this, congratulations! You are probably interested in seeing some code.
Look me up on github and you'll find a DotS project that is a tad bigger than this prototype, and with the new v0.16 API.
Expansion/ adding more items etc should be easy since you already have all the movement mechanics etc. You are only adding a new item and the new functionality if there even is new functionality. A new enemy only requires a new model while using the same movement and collisions where a conveyor belt needs to perform specific function such as spawning and moving items.
I agree that the unity example wasn't built efficiently and his time investment was building a "game engine" for HIS game instead of a game engine for EVERY game which unity has to support. I think that is where the biggest differences in performance come in. These game engines are like the F35 joint strike fighter. Good at lots of things but great at none because it has to fill many rolls and be adaptable. That is where a modular approach can help but then you need multiple versions of many features that can be interchanged. Instead of 1 global Data Structure you are building many etc. (I know you need many anyway it is just an example).
I also think many people would lack the skills to even build their own game from scratch. Unity's most popular add-ons are still those node based low code solutions.
@@excitedbox5705 I'm not sure what you are referring to in your first paragraph, but I'll assume it is about an ECS version, and I would strongly agree.
If it is not about the ECS version, then you clearly did not look at the source code before commenting if you honestly believe building up on that would be that trivial.
Read that code, and if you still believe that all it takes to add a new enemy is to copy the new enemy's FBX then I must have no clue how C++ programming works; but I believe am proficient in C++.
The Unity example wasn't just "not built efficiently", it was deliberately built inefficiently for both readability's sake and to make a good relative benchmark.
It had to create and delete gameObjects and entities when it wasn't necessary, akin to a synthetic benchmark.
And a relative benchmark at that. It created unnecessary workload just to test how one API fared against the other.
The C++ project, on the other hand, was built to have "feature parity", comparing its performance to something that was intentionally built to have bad performance.
This is akin to comparing the PI to the nth decimal using Gregory-Leibniz and _#define__ PI = 3.14159[paste all digits until the nth here]_ .
Like comparing Cinebench and an image visualizer with a PNG.
It simply makes no sense, these have different applications and different objectives.
I'm not saying a specialized game engine won't have better performance, it probably will.
I'm saying that this comparison does not reflect Unity's real performance.
I'm also saying that a hardcoded programming style is not a good alternative for game development, whatever the *initial* performance gains are.
So it makes no sense to pretend this hardcoded approach would work for anything other than a simple arcade game/demo.
Don't get me wrong, the C++ code would not pass any code reviews here where I work, entanglement.
Check what files would need to be changed if we wanted to add 3 new features:
1 - slow motion (without breaking playtime tracking)
2 - a triple form boss
3 - walls and doors
In a less hardcoded C++ code, maybe even using ECS, this would be fairly easy with the boilerplate in place.
In this example's hardcoded code, you'd need to change almost all source files.
Imagine that list with not 3, but 300 entries. This complexity grows exponentially.
This ends up misrepresenting both Unity's and C++’s performance.
Thanks for taking the time to share your thoughts.
In terms of using the particular sample as a point of comparison, I mostly selected it because Unity Technologies themselves presented it as a "look at how good DOTS performance is" example, and also it looked fun enough for me to even bother going through this whole exercise :P. I'm certainly open to the idea that there's a more suitable project out there to compare against.
It's true that if the scope of the game were to be changed then this comparison becomes less and less applicable. This is why I was very careful with my "for this particular game, for this particular developer, here's a single data point" disclaimers. I apologise if it still seemed like I was misrepresenting the situation.
It would be interesting to do this again today! However, if I had the time to do something like this again I'd probably try do a different comparison, like with UE, or between rendering APIs or maybe ECS vs non-ECS in handmade.
I'll take a look at your project on github! Happy coding!
@@NickCastonNZ They actually presented it as "look at how good DOTS API performance is compared to MonoBehaviour", and they made a comparative and readable benchmark for that. That was made to compare both APIs.
If you ever want to make a follow up to this one, be it ECS vs OOP or revisit this Unity vs C++, I'd be up to lending a hand
As an artist
Thank you for considering us and other team members hahahahaha
time to learn that so called "Handbuilt" engine
I think you ought to move to unreal engine if you want to learn something
@Screw Kalergi In case you were asking me it's because it's a superior 3d engine compared to Unity. If you want 2d then I guess you could choose on your own.
@Screw Kalergi I did not mean...
hmmmmmmmmmm
@Screw Kalergi nintendo gives you special tools for unity but doesn't actually require you to use it
@@necrago In case you're still available to comment on that, I'm interested on your thoughts on why Unreal Engine is superior to Unity. Or perhaps you'd refer me to an article or a post?
Wow good job reimplementing this complex shadows, models and animations in C++
OpenGL magic
@@passivecryptoearnings3605 black magic*
Great video! This is the kind of video you search for years without any success, and suddenly goes into your recommendations randomly. As I've never written an engine by myself, I am looking out for finding an answer if writing your own engine is worthy or not. You made an excellent comparison between how faster an in-house engine performs compared to a general-use commercial engine!
Also, maybe another thing to take into consideration is that you don't have to pay any amount of money (in revenue) if the game comes out as a big hit for using your own custom engine. It probably won't be anyone's concern, but I think it is a thing to keep in mind.
Subbed.
There are revenue free engines like Godot available out there. You can also freely customize the source code from Godot to fit your needs when needed.
Basically I would only recommend building in-house engines if you're either trying to make something extremely unique that requires a new way of thinking about something that game engines didn't consider. Or if you want to either make a really big AAA product pushing the hardware. Or the polar opposite, building a really small indie project where performance is important.
I don't recommend custom engines for basically all mid-sized projects. Anything from large indie to small AA studio is best off just using a generic engine.
Making your own engine for a game only makes sense when the game is either too weird or unique to do it in an existing engine or because you want to build an engine.
I promise, if you are an independent developer, making your own engine does not make sense. It only makes sense for educational purposes. The additional effort easily eclipses the performance gains. Recreating this sample scene might have only been 4x effort (for a C++/openGL expert), but adding weapons, enemies, and levels will become exponentially more difficult with the handmade approach.
@@billymonks7771 Would it be? Once you have the shader and material systems created, you can reuse them for all the things in your game, so at some point the amount of effort will be equal between the two engines.
The reason why I am building an engine is because I enjoy the challenge, I wanted to learn more about how engines work, and just to improve myself really and have fun. If you're interested in making a game then you should use a prebuilt engine, if you are looking for a challenge building an engine would actually be a nice pay-off as you know exactly how it works too.
My honest answer would be, if you're making a huge complicated 3d game then you should probably use a prebuilt engine (unless you're like me and enjoy a fun challenge) although everyone forgets that 2D games exist while talking about game engines
2D games in my experience so far aren't too difficult to make while building your own engine. Sure it's still time-consuming, but not as time-consuming as a 3D game.
And just to give an example I started a new 2D project completely from scratch and in 1 day I was able to get sprites and collisions and movement and stuff like that. Sure in a prebuilt you could just drag and drop a sprite in and probably do it in less than 30 minutes, but a day after work for all of that isn't a lot either. In one week I had a nice level laid out.
imagine being that comfortable that you're just like *a few days later* "Okay so I built the thing from scratch for this youtube video" and then doing so.. so much more than the average programming benchmarker
wow, that is actually inspiring.
if it's only 4 times harder to build, but you end up with better control understanding and performance with margins this big(I know that results may differ, I've seen my coding skills).
maybe going full rogue wasn't that much of a bad idea after all.
I bet that it takes him only 4x as long Because he has experience in the field, and lots of experience writing low level graphical renderers. If you want to jump in and do it for your first time, it’s likely going to be 10-100x as long as the math required to truly understand it all is *very* heavy.
@@ducky8075 no shit. It's not like I was coding myself for the past few years and have my profile picture be my first working GUI.
@@dimanarinull9122 Past few years of coding shitty demos using SDL is not scratching the surface of low-level graphical renderers...
@@krele14 yes because ALL I ever coded with was SDL and I definitely started only 4 years ago and never had ANY other experience with multiple OS and wanted a simple and mostly easy interface to work with instead of literally making everything from scratch whenever I move from Windows to Mobile to Linux or whatnot.
it's not that I literally tried to search for tools that are easy to teach others and are a simple way to get away from "engine coding" into "real coding".
and it's definitely not that I mostly code demoes and other things that are almost completely different to everything I have made prior and the things on the internet are explicitly from the first few revisions so they are less obfuscated by debugging and other things and can be reverse engineered into better products.
I can show the revised Chess game I made but it's completely different and only uses the inferred logic from the original one.
pretty much anything was exported into a LUT, the scoring system is revised, there are board hashing and multiple levels of optimization.
anyone reading it would either need prior knowledge of the way chess engines work, or would need a lot of time to understand most of the "meaningless" changes that are there literally only for runtime optimization.
it also moved to a fully portable codebase which includes the CLI using calls for system on both windows and linux depending on the system and uses the ANSI way of printing formatted text to the screen.
I know it may seem like some of us are incompetent but for the most part it's something we want the newbies to think so they can believe "I can do this too", it's not for A-holes to lord over you with no knowledge of how writing a manual works.
don't try to gatekeep if you are not even capable of knowing who is this you are gatekeeping.
@@dimanarinull9122 Hey nice essay scrub, makes you look like a hardcore script kiddie indeed.
I fell asleep, 12:01 woke me up. Rewatched this, damn that is nice.
I thought the world was ending outside and jumped, like what the hell?
LOL
I think this question of unity vs hand built is a general problem with all development. For me this is the "the right tool for the job" question. If my game requires a low amount of graphical needs, an adventure game, puzzle game, or whatever then yes unity might be a good option. It has all prebuilt code and based on the needs of your game you will never tax that system. If you are trying to make a fast paced FPS or top down that is using hordes of enemies while your player character is wielding 30 types of weapons at once at 4k resolution... then ya you may have to go hand built for that. The correct solution is always what will get the job done per the requirements in the fastest time possible.
I agree! There's definitely a place for both approaches
12:04 the gun I dream about having in every horror survival game.
Why is the algorithm just barely giving me this, over a year later?
I would have loved to see it when it was fresh.
Also, I agree. I've had more luck writing bare C++ than I have with a pre-made engine.
Phenomenal Nick. This problem is always happening in software development of all kinds. Great capturing the problem, constructing a problem setup, and putting the work in in attempt to reveal something instructive. Also learned what could be accomplished in the hands of an expert. Thanks for your video. I've walked away with a lot.
Thanks for the kind words! :)
I thought it's a clickbait and started watching this video with a bias but man this is very accurate comparison. Thanks for all your efforts (1084 EU (effort units) for unity and 3638 EU for handbuilt :)
I would like to see this updated with the addition of UE4.
UE4 is crap like Unity
@@MrBratkenSolov UE4 over the last couple of years has really stepped their game up.
I wouldn't say they are crap.
Me too, specially since they both use C++. Not sure if the difference would be that great but certainly it'd be interesting.
ruclips.net/video/avFP67EIYvo/видео.html
@@gkato I thought unity used c#
You really convinced me to learn C++ and OpenGL, thanks man 👏🏻👏🏻👏🏻👏🏻👏🏻👏🏻
Also check some interesting you low level languages like Zig, Rust, Nim and maybe even Odin, And do not forget after you learned OpenGL to use libraries like WGPU, BGFX or TheForge for cross platform rendering capabilities so you will have a uniform graphics API that targets all of the devices
** new low level languages , If I edit my comments to fix a typo RUclips removes them for some reason.
Thankyou very much for this effort, after some tweeks and hours I was able to compile your example, I Will make a pull request to extend the instructions for a more fast compilation phase
Oh nice! I chucked it on github in a bit of a rush before I went on my xmas break and looking back I see the instructions are a bit brief. Glad you got it working! I'm more than happy to accept a PR
@@NickCastonNZ I can't launch main.exe, console outputs: bad png sig
All textures used in main.cc are present in /assets/ folder.
Great demonstration and I appreciate you making this video. Another measure I think would be very important is the amount of development cost both demos would require. Something like (Amount of hours * median game dev salary) for both the Unity and handmade engine.
My old manager said it perfectly:
Making optimized quick code saves our customers money.
Making unoptimized slow but working code saves US money.
Thus this metric could argue in favor of using a pre-made engine simply because it's the most economical option. Lack of time and resources are the biggest bottleneck of every software project after all.
It depends on your goal as a business and a company. If your goal is just to use generic solutions for your product, then using pre-made solutions is obviously the way to go. However, if you also focus on other aspects rather than the specific thing a custom solution may be what you need.
Pre-existing engines makes a lot of sense for a lot of game studios who just want to make games. But for studios which want to make innovation, they bet on their own engine because they can have control over the technology. It could also be that you want to be in the business of making your own engine, or technology around it.
16:49 It's interesting that the progression of frame time against bullets is roughly a parabola (O(n²) for Unity and a straight line (O(n)) for handbuilt.
In unity - exponential progression. In my opinion.
This is very interesting. Why does that happen? What is scaling at n^2 in Unity?
I'm quite surprised it only took you ~4x time to do it from scratch. Given how hight level Unity is and complexity of writing shaders and rendering code yourself, I would have assumed different to be at least x50 if not x100. You ml must be really fluent in low level graphical development. For me it would have only taken couple of days reading articles and papers on how to implement basic techniques like shadows and bloom, something we take for granted with high level engines.
You see, that's the problem... People think that building a custom engine for your game is useless simply because IT MUST HAVE the same features! It's like an unwritten rule. "Gee dude, you're building a story driven, linear style FPS? ON A CUSTOM ENGINE? BLASPHEMY! You'll never release your game... you'll also have to code features XYZ that allow you to also create a third person camera open world game, because that's what -insert favorite commercial engine here- does. If you don't code those useless features that you'll never need or use, your engine will suck". The thing is, a large percentage of that commercial engine's features are simply dead code for you.
What many don't understand is that, if you know what you're doing, it doesn't take that much more time to build a custom engine for your specific use case. Your engine might only be able to do FPS games (if those are the only features you insert), but it's gonna do a MUCH BETTER JOB at running your FPS game, with higher flexibility, than Unity or Unreal will ever be able to. True, the "startup" time of the project (aka groundwork) is going to be higher, but once you have all the basic tools, the overall time of the entire project is gonna match the time it would take to build it in a commercial engine.... sometimes it might even be lower. Not to mention the payoff at the end... having access to the entire codebase, being able to apply quick fixes and optimizations, not being tied to some company, being able to support your game for a long time and having a flexible code base etc.
Another benefit is having the possibility to reuse that custom engine / functionality / libraries in the future on another project (no need to rewrite them... simply refine and optimize over time).
Also, these big engines are GENERAL USE engines. Meaning they need to have a predefined framework (that most of the time restricts what you can or can't do inside the engine... which sucks big time) that you must respect. If you're trying to do something innovative / groundbreaking / interesting, the engine is going to make it hard to do anything other than generic/standard things for which it was designed. You might end up having to rewrite big portions of that engine trying to build your custom functionality (if you even get access to the engine code), which pretty much defeats the purpose of these big engines, and you might as well have written a custom one in the first place. Not to mention that this is EXACTLY what companies are going through when building their next game.
P.S: Even if you use Unity, you'll still have to write your own custom shaders.
@@Borgilian I mean some people like to build their own cars so it has everything they specifically want, but most people just prefer buying existing cars because it can get them from point A to point B without them needing to do much work on how it got them there ya know. Their concerns isn't what the car is made up of it's to get them to their destination as soon as possible.
@@Borgilian *laughs in UE4 blueprints*
@@pmoneyish6869 I'll let you ponder more on why your car analogy is completely parallel with the idea of a graphics engine (aka dead wrong).
@@Borgilian Thanks for letting me ponder on that lol. What kind of pretentious response was that dude?
Interesting watch, but I'm left wondering how long it would take an experienced Unity developer to optimize that (intentionally brute-force algorithm to show DOTS strengths) sample further, and how much of a difference in performance that would achieve. Without those data points it's really hard to make any serious conclusions even just limited to this one project. I'd also love to see a face off between 2 people coding the same project - one experienced Unity developer and another experienced in C++/OpenGL - give them both a week and see what the results would be.
Yeah.. This is interesting but in the end it is just a single exceptionally marginal case where you instantiate thousands of objects in a single frame. THe point is.. nobody forces you to do this. If you really want to have this specific case where you shoot thousands of bullets you can easily handle all the bullets in a shot with a single gameobject and have pretty much the same performance of a custom built engine. This is also the perfect example where you are supposed to use object pooling and not create/destroy gameobjects.
@@fededevi1985 Somehow no one of all the hundreds of pro Unity devs here have stepped up and done it. More than a year later.
You still wouldn't be able to lower the Ram usage. If anything, the optimization would require even more ram.
@@BrunodeSouzaLino By lowering the amount of objects you absolutely could. Do not get me wrong you are not touching a custom built engine in terms of ram usage, That being said they're bloated for a reason. Those generic game engines hold Complete non biased Implementations of everything you need. With a custom game engine you can cheat. You can cut corners and make assumptions however these assumptions are not viable for a game engine that wants to support many different types of games.
@@sirdiealot7805 It's totally possible it's just not worth anyones time. Not to mention the results will still work better On a custom game engine for the reasons I outline above.
Not gonna lie, making resource heavy application natively would probably make sense, due to performance benefits, but nowadays multi-platform'ality is kinda a must.
Just use SDL and some of the 1000s of libraries for GUI, ECS, pathfinding, etc. If your platform does not have a c++ compiler and SDL support it's probably not worth supporting.
Though that said I only have experience with pretty small projects. And never done anything for a console.
But another overlooked benefit of your own engine/rendering code is that it all belongs to you and you alone. And it will still work in 30 years when unity might be long dead. (or the effort of making it work will not be insane)
@@TheR971 Wrong, you must update your engine in order to make it work with new quickly changing technologies, now more than ever, using an game engine is a must.
@@androidgameplays4every13 Yeah, his comment doesn't make sense 😂
@@androidgameplays4every13 You will also have to update your game to use these technologies lol
Very thorough video. I love how you didn’t claim anything here, it’s usually “for this specific game”, etc.
This is awesome. I'm positive DOTs will be a nice change, but I'm very impressed by your hand-building! I can't wait to learn to build game engines someday.
You can start now. Learn SDL2 (window manager + sound library and input manager) and OpenGL (learnopengl is a good resource). If you are familiar with C or C++ you can probably build a small first project within a week.
@@joey199412 Thanks! Hadn't heard of SDL before. I don't have any experience with C or C++, but I have spent quite some time in monogame. From what I've read SDL is another step lower than monogame (not sure you'd say it like that). Would be a fun project to learn when I've got time, but I've been planning on learning C++ so that'll have to happen first.
@@tomasbenders922 After you learn OpenGL, It is best for you to move to using open source cross platform rendering abstraction layers like WGPU or BGFX, Also use cross platform audio libraries such as OpenAL or others, Enitity component system libraries like EnTT and physics libraries like PhysX or Bullet and others, And after that you will be in a good shape to make your own engines and engines tailored to specific games and use cases.
@@astroid-ws4py I've heard of all except WGPU and BGFX. Been watching some cherno which is fun. Have since been using c++ and opengl, mainly doing basic graphics stuf so I'm on my way :)
Every game studio i worked at used their own engines primarily. Cater it to what you need, genres, etc and then if you are lucky you have an engine which you can try to sell on or share across studios if you get bought out etc.
Also, no licensing fees :)
True but running your own engine also incurs costs. You need to have engineers to develop it and add new features. And documentation to actually make the engine useable by employees. I worked with the Playstation phyre engine as part of a Uni project and it was one of the worst projects I've worked on. Poor documentation led to frustrating attempts of jerry rigging code together to try and get things to work. Also no 2 engines are equal. One engine might be focused towards FPS whilst another might be focused towards RPG's. Perfect example of when not to use a company made engine is with EA's Anthem. Forcing bioware to use that engine for a game it wasn't suited to, whilst also not having the engineering staff to make proper character creation systems within the engine caused major project issues. Aside from poor management decisions. Unity is great because it's a generic engine, pretty good at everything. Sure it's not the most performant but there's always ways around that. Where as developing your own engine from scratch takes additional time and money, neither of which you might have.
Yeah, its pretty much only AAA studios that make custom engines, and when that is not the case it usually means the game is some simple 2D game, or at least a simple 3D game, without advanced physics, animations, graphic effects and so on.
There are a few examples where it has happened. Like Serious Sam. But its pretty rare an indie studio uses a custom engine for complex games.
I usually prefer to go the hand-built route for my projects, just because it's more fun and I get more experience with things I wouldn't have.. Plus I like having more control over my projects, yes it does mean that there a many more ways you can go wrong, but hey, at least now I know I'm actually gaining a significant amount of performances for my work, so it's quite reassuring!
Btw, Very great video!!! Very love to see finally there is people make performance comparison on game made with raw/pure code with internal api's and compare it to game created using game engine.. im soo interesting to performance optimization topic like this, im sub man.
Interesting, thanks for making this video. Ok so you spent 3-4x the time to make it work from scratch. But then you'll also have a code base to reuse in future games, you basically have a mini game engine you can reuse. So for the next game it will maybe take 2x the time compared to Unity. And then continue to be smaller for each project. I almost always code my stuff from scratch for this reason. You cut away the bloat, you get better performance, and you'll learn more too. But for something simple that doesn't require high performance, Unity is of course the way to go.
And here I just learned how to create a prefab... Awesome video!
When we need to develop for general purpose, we need to balance between trade-offs. When we develop for single purpose, we can focus on single goal. The latter usually have more opportunity of optimizations. Generally, the observations made in this video makes sense, and I'm not surprised. Unless you have multi-person team that includes non-technical members, for small projects, the handbuilt solution seems the better option. Good to know.
And that's the reason that the graphics are improving more slowly. Because games are becoming more demanding due to easy production, using ready-made algorithms, and hardware is also becoming more powerful. This does not greatly benefit end-users, but it becomes easier and more profitable for developers, especially indie developers.
RUclips recommended me this video; it's awesome ! greetings from Argentina !
"It still performs pretty well"
Unleashes bullet hell Armageddon.
Alright, that's literally one of the best video I found on internet. Well done, please keep it up! Also, you're a very skilled game engine developer :)
Thanks for the kind words! I really appreciate it :) I'm glad you liked the video!
carai, vc aqui
Great performance comparison. The mixed version from unity that still uses gameobjects is a fair representation of how most developers will start with ECS.
A note for those who want to benchmark something: closing applications often isn't enough, from my experience even windows downloading an update can take up 30% of CPU. Just pause updates and check that there aren't apps that use much of system resources
He can code low level, what make u think he didn't know that?
It's obvious performance would be a winner in a software made for the hardware.
The main issue is, now clone the lighting, shading system, post processing effects, animation system that allows you to both animate and add scripts to animations, direct Blender and model rigging etc.
In the super long run it's a winner, but unless you're gonna be a huge experienced team with a massive budget project, then it's better to use another engine that gets updated and gives you the tools to start making your game right now.
A good example is WARSHIFT and Overgrowth.
WARSHIFT was made by one guy in Unity for a couple of years and is a marvel in independent development.
Overgrowth is a masterpiece in responsive and great gameplay and was hand crafted work can be from scratch. But even the developer himself admits he did a lot of flaws and wrongs with this approach. As it's taken him many many years to just get a playable campaign to it.
Personally I'd say get experienced in an engine like Godot or Unity, make some games and learn the structure and code design with software and hardware as well as library structure.
Then you can start practicing from scratch as that's a huge difference. Even with open source graphical programs and physics engines.
It would take a lot of time to get to a big triple A level compared to in Unity.
I'd rather make a laggy masterpiece in Unity, then spend my time optimizing it. It also helps with motivation to see your work rather than spending more time making a work station for your project then make a custom map editor before getting started on the actual game.
I wonder if this result scales. In my opinion, it does not. The effort can be 3 times for a small project, but it can be much greater for a more complex / complete game. The other thing that must be taken into consideration is that it is much easier to train someone to be Unity programmer than to be an C++ game programmer. The real effort is the cost of building that and it will be more costly to pay someone to build it from scratch than to use Unity. The last point is that you are cloning a project that was built on Unity. A fair comparison would be using a design document as reference. The good thing about engines is the ability to iterate over ideas, because you have access to a lot of resources and prebuilt components. Doing stuff from scratch with an ambiguous goal is very challenging.
To your first concern, I agree. But for small games (the kind you would make on your own anyway) and for specific genres (not asset heavy/procedural, mechanics focused for example) your own engine can still go a long way. About writing C++, you can very easily hook something like Lua into your own engine if you have more design/gameplay focused programmers in your team that you wouldn't want to be concerned with engine code.
@@Radgerayden-ist On the other hand I'd say it also depends. If you have small team without much game engine related knowledge it's still might be worth to use Game Engine just because nowadays there isn't much difference if a game need 55 or 500... even about 800 MiB of RAM should be ok. It's because it "steals" your focus. It's not something running in the background that uses resources that other application could use.
"So let's just take a look, in my fancy IDE" *Opens notepad* haha
Thanks! Interesting comparison. Sour but needed reality check for state of DOTS.
I'm aware of few optimizations that Unity version could employ (stripping bloat of data from bullet entities and changing how instancing happens to be more memory-friendly) but for sake of performance-vs-productivity comparison this is still a valid sample project to test.
This is why I coded my own 3D engine in C++ from scratch on my RUclips channel. Like you I also get massive performance gains even on low end mobile devices.
Now add the amount of effort it takes to bring a finished game to all platforms to your formula xD
This here is the reason Unity is king 👍
In modern world you can pay money for lack of skills. Ain’t that a good thing?
@@luckylove72 You always paid money for lack of skills or time. It doesn't matter if it is today or was 1000 years ago. Technology changed, professions changed but principle is the same.
So Unity is pointless when you are doing it single platform? Doubt
Zero, if you choose your libraries correctly. I'm writing a game in c++ and (once I got the IDE to work) it compiled just fine on windows (I usually run on linux) and even ARM Linux as well. Of course if you want to go to consoles it will be harder.
Would be interesting to know how this scales going further into the project. Like, does the hand built version count as a lot of groundwork, or does the effort continue to be 4x the unity effort?
Thank you! This was extremely informative. It makes a case for handbuilt games in the indie space, especially in some niche, data-oriented genres like bullet hells. Losing the easy multi-platform support is something to be seriously considered, though.
This would be easy multi-platform as well. OpenGL and window managers like SDL run on basically everything so you would just need to recompile it for every platform and maybe revise resolutions a bit to match handheld devices and it wouldn't be very different.
I agree with your main point and I think small indie projects in particular would benefit the most from hand-made engines. Especially if you want to do something unique. Notch's Minecraft comes to mind which would have been impossible to develop with UE3, Unity or Source Engine at the time it was made.
the subtleties were the first thing i noticed.
incredible performance increase with code optimisation. nice!
Great comparison! However you have to take into account many other factors. Unity is a well known game engine. Working in a team requires everyone to be aware of what they are doing, which is very difficult to achieve for handmade solutions. People are used to certain workflow. Total effort/performance ratio could be way different for a game that has slightly larger scale.
I think for very small games you could go with either handmade or unity (cause unity overhead for small games usually doesn't show up, unless you have really complicated stuff going on)
For middle scale games unity is a way to go.
For large AAA games you have to make your own game engine.
Thanks for the feedback and input!
Originally I had more discussion in the video about this kinda stuff but it got way too long so I decided to cut it down to just background context and raw results with a "this is just one data point" disclaimer. At any rate...
I agree that looking at a project of this size means a lot of factors which are important for larger projects don't get represented. I realize I might come off a bit handbuilt-biased (and maybe I am slightly) but it can't be denied that a huge number of successful projects have been built with Unity (and other engines).
You make a good point about being used to certain workflows. Using a widely-adopted engine definitely has its advantages there. I have a huge selection bias, but I've seen a lot of experienced devs getting frustrated with Unity when they don't have the control they'd like. So it's possible to go both ways.
It's definitely a very nuanced decision, dependent on the project, the team, and the available resources. And hopefully this video helps someone out there, not as a complete answer, but an interesting anecdote.
Nicely explained.
Now I'd like to refer to this as a "rookie" programmer.
As for my skill:
I've never done big projects or anything like this in 3D. I only once made a sample 3D platformer and all you could do was move, jump and collect coins. No cam rotation, no animations. I only make simple 2D projects, currently working on a GeometryDash-like gravity-based platformer, so I'm not good at all :D
But even so I stumbled upon many problems regarding the fps amount. Like- simple 2D UI animations can lag the game a bit for no reason. But the biggest issue I had was with Audio Source. I tested a few options of putting it into the game and, surprisingly, when I put it on a moving player object, my fps dropped from 250 to 30. I tried putting it on static object, resulted in 40-50 fps. Putting it on canvas gave me 70-80 fps with occasional spikes. And the only way not to hurt the fps was putting it on an empy object, which gave me 230-250 stable fps once again.
I find these small issues with Unity interesting and although they are not that big of a deal for me, who does nothing impressive, I can't imagine this issue on a bigger project. I know there must be better optimization and many things I don't know, but still...
To wrap it up- if you look at it from a newbie point of view, the difference between effort needed for Unity and handbuild game is huge. Just consider point of view of someone who literally knows 0 about game dev.
For me, learning to write "OnCollision" is like 10 times faster than learning to make a collision for handbuild games.
To put it this way- I think Unity is great for beginners to get them hooked into this. If they want to improve and move on to something different afterwards, then leaving Unity behind is good.
As for me- I think I will stick to Unity. I'm a lone developer, I know only a little stuff and I don't have great ambitions for this anyways (I'm more of a story writer and teacher than pro developer. My stories brought more attention than game projects themselves...). I'll be glad if I release 1 successful game for now. I have 2 released shitty projects behind me, so it's time to make something better.
Who knows? Maybe you'll some time in the future play my game, guys :D
I think using Unity (or any third-party engine) is a perfectly valid choice in many situations - and it sounds like you've landed on a decision which works well for you! My goal with this video was just to provide some data and leave it up to the viewer to decide how it applies to their situation.
Best of luck with your games!
@@NickCastonNZ Yes, I can see that :) It was kinda eye opening video, to be honest. Thank you for your response.
“So we can see the” DING DING “the character” DING “actually a little” DINGDINGDINGDINGDINGDING
DING DING
DING DING DING
Alright Mr Salamanca, no need to hurt yourself
look like a berserk episode
It's like with using C++: usually most compilers generate good enough machine code for most of the cases, but if it doesn't or you want it to go faster and you have the knowledge you can usually outperform it. Answering the question whether it's worth it is entirely up to you. Setting up your own engine with physics, logic, graphics, animation, sounds and everything else is a massive undertaking and is an order of magnitude harder than using a general-purpose engine like Unity.
The exponential growth in frame time in the Unity version doesn't seem to correlate to any of the other metrics gathered. I wonder what is causing that?
Is it possible, for example, that something like lighting per particle in the Unity version is leading to some material*light complexity? (What happens if particle lighting is disabled?)
It's RAM bandwidth. You can't see it so it's ULTRA hard to find out and prove.
I was thinking it might also be an issue of CPU cache being exhausted at a certain point. Once CPU cache is exceeded for the critical code/data paths, you can really hit a performance wall. So, related to RAM bandwidth in the previous reply, but closer to CPU cores.
You somehow made a 28 min of nearly just text quite interesting and in part entertaining.
this video never gets old
With sure, doing in C++ is very faster to execute, very better performance and we can use too Data-Oriented design in C. The main problem inside Unity is the quantity of layers to abstract from low to high level of programing and the builds to more plataforms with the same code. And the problem with C++ is the time to develop all code. Unity has the advantage too of constant atualizations to new platforms with the same code. I remember not so long time ago, 1 month to do a good water simulation, and now, drag and drop and it is ready, because this game engine as Unity is all. Very good comparisions ! Some especialized applications need to be in C++ yet where performance is more important.
Jim Browning's doing this now huh? For real he sounds really like him
I thought the same thing
My opinion on this (that this video also seems to support) is that pre made high level engines like unity are useful for smaller projects or prototypes, where it's mostly important to get the project working without it taking too much time and effort to make, while making a project from scratch is better for more advanced projects where optimisation is important.
Thanks for the video, it was something I thought about recently (since my project doesn't really use much from the engine itself). I would maybe suggest some followup where you'll try to implement the bullets (and only bullets) in the optimized fashion in the Unity. I somewhat know the UE and the general workflow is to "build it fast" with the Unreal and then optimize away... just implementing "BulletManager" (instead of bullet actors) will be significantly easier than building the whole solution, but It still might not get as far as your fully native implementation. It would be interesting to see this, instead of the naive unity implementation, so to speak.
That being said, would you expect your 3-4x effort ratio to go up, or down if the project would be bigger? I would argue that it might go lower, but I have no real frame of reference for it.
Thanks for the feedback! There's definitely a lot of room for other investigations to be done here.
In terms of the effort ratio, I don't have any experience with large Unity games, so it's just my thoughts. I expect the ratio would go down as the project gets larger. Getting a 3D animated model running around and shooting is like Unity bread and butter, whereas a lot (not all) of the costs for building from scratch are front-loaded. Later on in large projects is where the lack of control in Unity might start to hurt (e.g. if you start running into serious memory problems). This seems to be reflected in industry with large AAA companies more skewed towards custom engine and indies skewed more towards third-party engine - of course there are plenty of exceptions and lots of factors at play, but it seems to be a general trend.
I would argue that depends on what your scope is in this case where it just needs to run on a single system on a single platform it's probably fine. However you do need to keep in mind Many publishers won't take you if you have a custom game engine Because they don't want to have to sit there and port your massive code base to xbox or playstation. Playstation in particular if I remember correctly has their own graphics API. Also it also would depend on how long you've been using the engine and how many engines you've made prior. If this is the 1st game with the engine and you've never made an engine before then trying to create a first person shooter without networking Is going to be a lot more time consuming if you are originally doing a first person shooter with no networking. So I would argue it really depends on what you're trying to do. Not to mention you also have no tooling, Every tool needs to be created by you which can add up But it can also mean that you can streamline your workflow.
If my memory is correct, compiled empty unity project cost about 60MB storage. They still include core things before our project is added to the engine (I am not sure how since compiled game is encrypted)
But in scratch code, we may code more freely without many feature like unity do. But building engine from scratch is so time consuming and needs more than knowing math and it is computer science
I would have liked to see the footage of the c++ version tests
11:44 ?
@@FamastChannel Yeah, but i wanna see the framerate in realtime with it shooting 90 000 bullets per shot
@@leonardomadona recording software would affect the result.
@@DejaimeNeto i didn't mean for him to show it as a proof, just for our viewing pleasure of seeing what that looks like
The best example of this is Crysis. When you build your engine from the ground up with the most important parts being written in Assembly, you can do things other generic engines can only dream of. The price being, you have to worry about compatibility, coss platform and all that fun stuff etc.
You can't make Crysis on your own so go use game engine
Did you tried various performance tricks on unity before the build to sqeeze as much performance as possible same on the handmade build
Apparently, no. He thought that this sample project is the most optimized implementation of shown gameplay that Unity can make.
It's sad to see how many people see this as a good comparison.
This video was exactly what I was looking for. Nice clean explanation, such a good video. Thank you!
do unreal vs handbuilt next
Its not going to be much if any better.
I'm curious about that, too.
@@sacredgeometry I don't know about that. Sure it has a ton of overhead (abstraction, generalization, etc) just like Unity, but the user code is also C++ instead of C#. You might be right, but I certainly would like to see the hard data.
@@cagefury3789 Unity has IL2CPP, also unity is made with C++. Sure you would have performance differences, but that mostly comes from memory management which isn't an issue on this scenario .
@@NikolasMauropoulos Obviously it's made with C++, I specifically said user code.
Been usin unity for 3 years, i must say that using a game engine makes it considerably harder to ubderstand concepts such as rendering and shading. Hoever game engines also make life way easier for the developer as the dev mostly needs to code in the game mechanics.
Great video and really well explained
Thanks for this Nick. I did the same a while back when deciding to write a 2d game that's been in my head for 10+ years. I'm not a coder but know how to code, I'm old school (z80, 6800, Cobol, c, c++ and c#) and as such struggled with Unity structure. That said, I was prepared to learn Unity but wanted to make sure I was making the right decision as I had heard that performance was an issue for Unity. I did what you did but with not as much detail, I just wanted to know about memory usage and fps. I was so surprised by my results that I was sure that I'd made a mistake because the Unity results were so poor. Granted that this was a few versions of Unity ago but I'm glad that I decided to use c++ although writing a UI library sucked but I won't have to write one again. I used DirectX 11 with DirectXTK to aid with maths and audio. I'm not scared by the low-level nature of DirectX but I do understand that this scares a lot of people which is why Unity is great at hiding it all. Unity is great if you're not an experienced programmer or want to prototype something, but if want to write a complicated game, either in graphical or data detail, it may struggle. I'm aware of a few teams that had to almost start again as they couldn't get Unity to perform as desired, even sending their codebase to Unity didn't help.
Really cool to hear about your journey. Thanks for sharing! It's interesting to hear you went down a similar path and reached a similar conclusion. I'm also glad I went down the C++ path for my game, but I do totally understand the case for using an existing engine.
Good luck with your project!
Thas awesome
Unity has bad performance for 2D why didn't you try out 2D game engines
very informative, thank you.
For the difference of effort, I feel like the difference will be more significant if we include the time to learn Unity/OpenGL if you are not an export.
From my personal experience it's a lot harder to learn unity than it is to learn OpenGL. OpenGL feels like just a library of functions. While unity is a sophisticated tool that makes you feel lost in a forest. If you want to start you can just do so with OpenGL and only uncover features as you need them.
With unity though you need to learn how to navigate the entire toolset. How they are used etc which is significantly harder.
@@joey199412 But unity has a huge community and tons of resources. My experience with OpenGL is limited but I had little place to look for help when in my game engine class when we were using it.
It feels like every single day I find a new reason to create my own game engine...
dont we all?
Very interesting videos, and I'm commenting on all of them to improve their metrics based on engagement.. thank you for all your effort, I love these videos!
Vulcan:
hold my beer.
yeah why he not using vulkan it does have lower performance on handbuilt?
@@c0mbine536 because its fucking hard.
@@igorgiuseppe1862 Vulkan is simpler and more fun than OpenGL. But for maximum performance it is just as complex as the dx12. But still Vulcan loves to work with high level C++ and std. OpenGL looks more like "uglest" C.
@@Lord2225 Vulkan is simpler than OpenGL? As far as i peeked, it looked significantly harder. If you have any good sources for learning Vulkan please do share.
@@Navhkrin @Navhkrin I used to learn from source. It wasn't my first graphic lib and all of them usually repeat same pattern so it wasn't so hard to learn for me. For someone that is new in CG learining vulcan from doc could be confiusing. Form my perspective it is more modern, gose with trends and it is intuitive.
At the start of the video, you mentioned that one of the strong points about game engines was the ease of making games for multiple platforms. It would be interesting if you took that into consideration in your comparison, specially in terms of amount of effort. It seems to me that if the comparison was made for a multiplatform project, and not for windows only like it is stated in your github project, the difference in terms of amount of effort would be much greater. Good video, nonetheless!
Did you ever consider comparing unreal engine 4 with c++ to unity and the hand-built? Would be fascinating to see how ue4 compares using c++ as opposed to handmade c++
It isn't the C++ that provides the speedup. Sure there's some overhead it removes from the C# runtime stuff but the real gain in performance is because you remove the overhead of engine features you're not really using but are still being applied behind the scenes.
UE4 while performing better in optimal cases than Unity would still perform significantly worse than a special made engine for a single task.
That one guy who codes his own game engine: "Look it can draw a triangle."
Anyways its a pretty good video and it was awesome to watch.
Nice work, but I don't think the result suggests anything. In programming, making something go fast is only one of the concerns, out of many. More important than that is keeping the code manageable, extendible, portable, modular, and usable by multiple people. That's what Unity solves; that's what any game engine solves: management of complexity. They don't advertise DOT's speed stand alone; anyone can code simple graphics that are fast. They advertised their speed _given that it's running on Unity_ , a full engine.
You might as well say "I've written a for loop in C that outperforms a for loop in Python by 500x!!". Nicely done, but it's not really Python's claim to be faster than C, and it won't compel any Python user to switch.
(That seems a bit harsh, sorry about that, don't mean it this way)
This was a VERY good video! I didn't know much about game engines or how it compares to making things from scratch, but this gives some great insight into it.
One of the best videos! Well done :)
Nick, really interesting video. I can define you approach like an engineereistic approach and I find this the best you could have chosen. Thank you so much!I think i will use the handbuild approach cause even if it's longer , I can learn a lot from it.
I'm gonna have to try writing a game without a game engine soon, seems like an interesting experiment
Definitely! Even if you go back to using third-party engines you'll have still learned a lot in the process. Happy coding!
Great Video,
You did a great job showing some of the Big disadvantages of a game engine vs doing it from scratch. For the people reading this it's important to understand the value of maintainability and the ability for multiple people to work on it at once, as well as the abstraction of ideas. As a sole developer you may be able to get away with understanding every detail, but on a large scale project you would be better off being able to outsource some of the stuff you don't know how to do to either; the engine, or another person.
I really enjoyed watching this though!
Thanks for sharing, very interesting results
Conclusion - use Unity for quick demos and "sketching", whilst building the end product using "hand-built" method.
I don't know why, but this kind of comparison reminds of the story how Crysis was created, where they build the game and the engine to match the quality of the cinematic movie
Thats only viable for AAA studios. For individuals or small teams, making an engine from scratch for every type of game that you make is just not possible. Only make a game engine when you are sure you want to make a specific type of game, and only if the already existing engines don't provide the features or performance you are looking for. Unity /Unreal etc should be enough for 95% of the games that you can dream of
I think this is hugely flawed, given how small it is. You might notice that much of a performance difference with such simple and basic tests, because Unity still has all of that background, abstraction, etc to load. If you look at a game like Kerbal Space Program, I would say the difference in performance of a custom built solution vs Unity is going to be much smaller. And this is coming from someone who always likes to write their own implementations of things.
Also the same applies to developing a larger game in terms of effort as well. For larger projects it works much better.
For a small basic project like this I think you're right. But for a larger project I think things get much closer.
Opposite the larger the scale the better it is to have customized solution.
Having an editor rly helps when youre working w people that arent programmers too
Support for optimized art pipelines
Etc
Man, that was awesome. I never thought that handbuilt game could be SO much better in performance than what unity team achieved with all: ECS, Jobs and Burst compiler. Now, thanks for you, I will think twice on: “should I use existing game engine or try to write game from scratch”?, for my future games.
Why?
Game engines like Unity aren't about providing you with the best performance. They are about providing you with the tools you need to build games. It can take, literally, years to build a game engine and that's before you even start building a game with it. Unless that's what you want to do why waste your time?
Before I discovered Unity, Unreal Engine, Godot etc I was making my own game engine in C++. I'd spend months and all I'd achieve is some playable 2D sprites on the screen. With Unity (or equivalent) I can get a 3D first person shooting game up and running.
@@odo432, I didn't say anything about how easy(or fast) is to create your own game(or game engine). Why did you start to point it out?
Also, what is the meaning behind "wasting" time?
What if I care about the game, but not about the money and time I spent on it?
What if my game involves high computations and it requires better perfmormance?
What about the time and effort you spent learning Unity or other game engines?
Is it really good to depend on someone's engine?
What if you want to make changes to the internal work of the engine?
The answers to all those questions are not exact and depend on people's personalities, experiences, abilities, goals, etc.
@@rasulseidagul As you said. All depends on what you want.
Given that both Unreal Engine and Unity have both been used in AAA games and games requiring lots of computations it really doesn't make any sense to build your own game engine other than for it to be a hobby or learning experience.
Building a game engine is like trying to recreate the wheel. Someone's already done it. You're really not going to achieve much of anything by making your own.
As for "is it really good to depend on someone else's game engine". We are talking about game engines that have had YEARS of development by hundreds/thousands of developers and battle tested by millions of users. I have no issues with trusting them. They are very stable.
@Mat O ok, so what about people who do create their own game engines or write their games from scratch(as, for example, Jonathan Blow do)? Do you think they are recreating the wheel?
And, you know, there is a well-known product: Google Docs, which has been "battle-tested" by billion users but still has annoying and not elaborated control over images in the text. Having a big community means that the most popular cases are covered(at least), but not all of them guaranteed to be solved.
And yeah - it does make sense to write your game from scratch if it requires better performance than Unreal and Unity could provide you with their bloated insights. The video, under which we are talking, has clearly shown that.
@@rasulseidagul Well, yes.
The only reason to create your own custom engine is if it offers you something that an already created game engine does not. And there really isn't much in that regards.
Also, unless you are an exceptionally good programmer, chances are any game engine you create is going to be riddled with a lot more bugs and issues than one that's already been created.
After you spend a significant amount of time creating the tooling required for your game, then the time differential starts to diminish and you would find that at times, the tooling you created would give you a boost in development speed compared to unity, because Unity need to account for a lot of possible scenarios, where your tooling is specific for this single game.
This is why triple A game studios spend a lot of money developing their own internal game engines, and training developers to use it, because it pays off later and you start to spill games like a production line. This is why Assassins Creed games launch every year probably xD
Greate comparison. You had old information about the release date. DOTS was planned to be released on Q1 of 2020 a long time ago, it was pushed back.
I think it is possible to write own rendering solution in DOTS instead one provided and reduce memory usage but it would require the extra effort of course.
That “several days later” is what matters most in this video, I think...
Why? Don't you think it would also take several days to create the game in Unity.
@@boogaloobomber9889 I mean he's really great. I could never do that in several days... It would be years...
@@owendswang Don't be too hard on yourself. I always thought SFML would be hard, yet it took me less than a week to learn the basics.
@@boogaloobomber9889 Thank you.
I think it's important to note that as your game project become more and more complex over time, that 3-4x increased effort becomes very significant
Very good comparison, of course both versions could be optimized better.
I would be interested to see this with an unreal engine build as well
Seeing Godot performance would be cool too. It's seem like it's quite capable and gained some popularity so it could be nice to see how open-source engine perform compared with both Unity and handbuilt.
@@elementiro Godot does allow you to code in C++, doesn't it? Shouldn't that mean that (unless there's some huge rendering overhead or something) you could write efficient C++ and get the same performance as the hand-built version in the video?
@@ThePC007 No, Godot will not perform better because the issue is not C++ vs C# (or any other language that doesn't completely trash performance). Yes, there's a difference between the two but the main bottleneck in this benchmark was memory access, not CPU time. If both solutions were close to the 100% CPU utilization, you could make the argument that C#'s JIT compiler either takes too much time to optimize or not doesn't optimize well enough. But that is not the case.
@@DLCSpider @DLC Spider The memory access bottleneck might stem from the fact that the memory is laid out less efficiently in the Unity version. The video has shown that every bullet needs ~500 bytes of memory for some reason. While we don't know precisely what that memory is used for, it may very well be something that wastes precious cache line space and thus hits the memory access bottleneck sooner than the C++ version. In C++ we have tight control over how memory is laid out, so it's very much possible that Godot + C++ might achieve similar performance as the self-built version.
@@ThePC007 just like DLC Spider said, it shouldn't be the case - the better performace doesn't come from different language (I believe handbuilt C# version should have similar performace as handbuild c++, maybe slightly worse) but because you're omitting extra layers and features that come with ready general-purpose game engine.
that shotgun looks like a dream weapon for people with OCD
This is amazing video. Thanks, it was very interesting to watch.
Awesome comparison video.
You forgot to include the difference between skilled handbuildist vs unity developer. I takes a lot more years and more money to train and hire a skilled handbuildist.
And even if that was not the case, 7 days instead of one day would justify using Unity is the better choice for most games.
1 day vs one weak may not sound like a lot, but if your project takes 1 year to be complete, then it would take 7 years without an engine.
and if you want to make an comercially viable game, you will need to spend time developing it.
(i know we cant extrapolate like that, but it helps put it into perspective)
There are many AAA developers who write their own engines. And I don't believe it takes 7 times more human resources.
I think it would be even more extreme. A simple hardcoded project takes 4x as much time as in Unity. But imagine introducing tons and tons of new features.
@@АртёмСабадырь writing your own engine is an good option if you have tons of employees.
it uses more resources from the company, but the performance pays off at the end, those companies can solve the time difference by puting tons of employees.
(eg: 100 employes to do in 1 year, what 10 employees would waste 10 years to do, its just an example, in pratice its not so simple, most of the time you cant throw 10x more people at an problem and expect it to be solved 10x faster)
writing your own engine work at scale, but for smaller companies it might not have the desired result, quite the contrary.
in any case, if you plan to start your own engine, you probably wont want to reinvent everything.
unreal licenced part of its code to companies who were willing to pay and nowadays its open source for everyone.
many of those other engines were born out of parts of licenced code from thirdy parties. (eg: lumbeyard)
godot is another good option of open source engine.
i recomend contributing back to those projects instead of starting from scratch.
@@nilstrieb i think the main issue is iteration.
i mean, what if the feature that took you ages to implement end up not being fun?
you wasted years to discovery it, and now you will waste more years to code another feature...
an game engine allow you to test new ideas quickly, either for gameplay or for art direction or for anything...
then, when you are satisfied with the results you can decide if you will need to make it on your own code base (due to the performace requirements) or if you gona use the engine.
@@igorgiuseppe1862 that's what I said. The 4x is for simple things. It gets bigger fast
makes sense, unity has to do a lof of extra stuff that you dont need while handmade engine is made specificly for this one project
I'm not sure if this has been discussed already, but default build in windows would be using direct X. There would also be definitely some difference there unless you forced OpenGL on Unity?
It's a lot more difficult making a game engine with a great API. I remember making a 3D Game Engine using OpenGL to target Android, Linux and Windows at the time using Free Pascal.
Most of my time was spent making the API easy to use.. and it was built completely from ground up including math, windowing, input, everything and was modular so someone could add a different input module very easily.
But that took a loooooong time. So patch building a quick engine that won't hold up for future games is easy.. making one that everyone can use in many scenarios and targets and examples.. that's the time consuming part.
Edit: Also worth some discussion is if you used HDR mode, Forward rendering / deferred, and other quality settings like antialiasing. I'm sure you looked into those already.
6:13 world was not ready for this
Your comparison is not correct. It's not pure Unity DOTS thing, it's just the simple example, where half of project is using old Unity Engine techologies: old GameObjects, old physics, etc.
Bottleneck of this Unity sample is old GameObjects using. Old GameObjects are very slow and vast a lot of RAM. So DOTS should solve this trouble.
You can use Boids Demo as example of pure DOTS.
github.com/Unity-Technologies/EntityComponentSystemSamples/tree/master/ECSSamples/Assets/Advanced/Boids
Unity one is just an example and its super unoptimized code, bullets are GameObjects with a MonoBehaviour to control it.
The c++ code is the oposite, bullets are like Transforms: position and rotation only.
To do something similar on unity you would need to use only a list of transforms, doing it yourself the calculations on 4 threads (or even ComputeShaders) and render on a particle shader. No DOTS needed.