Thanks for watching! ❤ You guys should check out Brilliant FOR FREE for a full 30 days - visit brilliant.org/TheCherno. The first 200 of you will get 20% off Brilliant’s annual premium subscription!
Hi Cherno, I feel like I have to say that I think this video felt like an unnecessarily unfair dunk on the original author. This is potentially awkward and unhelpful when a lot of your audience is quite green and impressionable. I've only looked at the engine briefly but it seems highly likely to me that the template project is what contains the actual game specific project. While the core SpriteEngine project is just the editor alone.
nah you gotta realize this type of advice is great even if it's not code like if I had someone to review my code with this level experience I'd be thrilled for any advice even if he hasn't even ran the project yet
@@pengie_ The issue rather is that it seems to be the same thing people are doing wrong when sending projects to him all the time. I mean having no build system is probably in every project I've seen so far in those reviews. I'm also not sure why people are not looking at existing game engines, when they start developing their own. Like 2000 hours in the game engine and they didn't even have like the basics of game engine architecture in there. They could've easily looked at Unreal Engine and you'd see in a second that you should split the editor and the actual engine from each other. Sure I have years of experience as game dev already but even my first attempt to write a game engine I was looking at other engines to see how things should be done. Even if you don't follow that completely because you want to do your own thing etc., there are just best practices you really should not avoid.
If I remember correctly. This is made by a highschooler. Which makes total sense, because back in high school, I'd always react with "so cool, a custom filebrowser, looks much better than the ugly windows one". Now I'm fully onboard with "if there's a convention, use it. I don't want to have to relearn things I already know how to do.
Certainly, it is the brainchild of an adolescent of scholarly pursuits, whose linguistic articulation in the English tongue presents an ongoing endeavor.
My problem is when there straight up isn't a way to do something simple that I'd expect to be there. This is mainly because either I'm going to use it once and never again, or because I would learn how it works with time either way. Also on Linux people generally configure the file browser to be an exact representation of what they want it to be, both visually and functionally, not using it is kind of a spit in the face.
i dont use a file browser on linux tho, i dont even think i have one set up, it would be better to have your own and fallback to the default one, or even have it as a setting@@iXenox
That's why from the beginning of the Mac product Apple enforced the style guidelines, not to mention that spending time rebuilding what exists means you're not adding the features that makes you stand out against competitors.
I designed my game engine with maximum modularity among its components. The solution consists of several projects. The Renderer is a separate statically linked library that can work independently of the engine altogether. The Engine Core handles only logic processing. The Editor uses both the Engine Core and the Renderer. The engine can be built without the Editor. These are the three main components, but there are others for physics, sound, files, etc. I aimed to make the engine as extensible and decoupled as possible.
Not to be a Jon Blow evangelist but he builds his editor directly into the game and has two successfully published games ie Braid and The Witness. I think it just depends on A. experience of the engineer, B. the complexity of the game. Sometimes a completely separate editor is just added complexity with more overhead of maintaining it when keeping it simple is better, less things to fuss with. People think editors need to be Unreal, when in reality it just needs to be a tool that helps YOU make YOUR specific game, not some generic app that can make ANY game
This! You can totally have an engine, a game and an editor in a single executable (just with compile flags to disable the editor part when you ship the actual game). This is especially useful if you're planning to do very unconventional things (4D, non-euclidian worlds etc). Also, you can really optimize the engine for your game. Game engines are build to be generic, but this can have a great cost. If you know there will never be something in your game, then the game engine doesn't even have to bother trying to check that stuff. When you move on to create another project, just copy things you want from previous games and don't copy the things you don't want!
Beat me to it, was gonna say the same exact same thing. I think it’s totally reasonable to have an engine built for 1 particular game. I’m sure there are plenty of successful games where this is the case
Sure but that's the difference between making a game with a built in editor and making an engine itself. I sure as hell wouldn't go calling braid or the witness an engine project.
@@TheBigWazowski The ID Tech engine is one such example. They just made one game and for the next they removed all game specific code (leaving stuff like rendering, audio, and i/o) and started on the next game, so after a while they just had an engine there from all the generic stuff that got left behind.
To clarify, the engine does not equal the editor. The engine is the code framework that controls the update loop for input, rendering, physics and entities (actors, gameobjects, etc). Separating the engine from game specific code forces you to really practice separation of concerns in your game as well as enabling you to easily branch off to your next game. Every engine basically does this (you can download the engine for Doom 3 BFG and see that they do it for both the engine, the rendering and the game). Whether you include an editor in the engine or have it be a separate application is a different discussion although even then you almost certainly want to split that off into a separate editor framework. Compiling any of these out into their own DLL or into their own executables is again orthogonal to the discussion of separating out engine code from game specific code.
I am not sure about this specific project, however, I would argue that from indie game developer perspective, it makes sense to blur the line between game, editor, engine. Mainly if you are looking to make a game, not so much an "engine" on it's own but still want to do it without existing engines. In indie games when there are low numbers of developers (maybe only one), not designing an engine in the currently popular modular approach reduces the need to design multiple API's which you would in turn only use yourself. When you are ready to ship the game, you just disable the editor (if it should not be the part of the shipped game) and release it that way. I think this is perfectly valid, if you know what you are loosing by doing this. Making a new game doesn't have to be done in a "project browser" way, because you know what parts of the "engine" you need to make the application work. You just copy that code and make it a separate thing.
I think "engine" translates to "unity lookalike thing" in today's parlance, and I really think it shouldn't. The "embedded engine" approach is perfectly valid and that's what I am doing now.
I believe there is also a problem in expecting somebody of both beginner and intermediate levels of programming skill to use a build system. Especially ones with languages such as CMake. CMake is by no means easy to learn, because every library repository uses it differently, and the tutorial is too abstract to be used as a template to "learn by working" with it. It is a very difficult way to learn to build your code meanwhile a vcproj, even though it is technically an "already built repository", just lets you click one button, or enter text in a few boxes to point to your library binaries and libs...and then you have a binary of your program built within seconds, without having to code an extra script to make that happen at all. CMake, in some circumstances especially for learners, speaking from my own failed experiences with it and my inability to use it properly to this day, can waste hundreds of hours just on its own. If education out there for the langauge was better, I wouldn't feel so on the fence about that point of yours. By all means, you are a professional and have taken the time to learn and use that tool, don't feel bad for using it. Just don't expect somebody to spend a hundred hours just to build their hobby project with it.
Beginners maybe, but intermediate no. I would not consider a programmer to be of intermediate skill if they don't have a basic understanding of build systems. Basic CMake is not at all difficult to learn (a minimal hello world is three lines or less) and you just google and extend it as necessary. The real reason people find CMake and similar tools difficult is that they don't actually have a good understanding of the compiler and what it needs in order to preprocess, compile, and link code in the way you expect. Knowing CMake top to bottom won't help if you don't understand what the compiler needs. CMake or a similar tool is more or less a requirement on Linux platforms so this all goes double there. You can write Makefiles by hand if you want but don't come crying to be when they hit 20000 lines haha.
@@ColinBroderickMaths you say that, and yet I have been in university and education for coding in C++ and C# for over 6 years now, and never have I successfully gotten cmake to add a static .lib dependency after around 5 attempts totalling to 30 hours now :/ Like I said, the education out there is terrible. The only time I've ever gotten close to success was when I had to look at some obscure physics library (ReactPhysics3D) which included a cmake tutorial of their own. You know it's badly documented when somebody else has to explain how to use the tool for you. I can use and understand the gui. I have built repos with it just fine. the syntax of the language itself, however, is a problem, especially with method names that don't make sense in context. It's so badly documented that our university has basically refused to teach their lecturers how to teach students in programming CMake at all. They all just teach us visual studio's compiler system. That being said, I am close to understanding the tool. But how much uphill battle I've had to fight to get that close at all is ridiculous, and understandable if an intermediate coder doesn't want to deal with it at all if it's just a hobby project.
I mean unless you are definitely going cross platform much of what a build system does can be done within vstudio directly. All an engine like this really needs is to split the runtime out and have it as a dependent project. Sure automated build system are what you really want, but for a limited release prototype game engine built by a hobbyist I’d recommend they get a cleanish code base before embarking on a fully build system. It just needlessly complicates things in the short to medium term. Id say if you dont know why you need a build system you dont need a build system.
@@ColinBroderickMaths automake and make are way more intuitive than CMake from my limited experience. Anytime a build fails in make or automake it's easy to see what should be changed. With cmake it's like ok what arcane variable or setting do I have to change, how does it interact with all the other settings, and where do I set it.
As someone who has been doing AAA engine development for way too long, I've got a different view on many of these things. * MS VS projects aren't all that bad if your wanting to stick to VS large engines just use VS, albeit with heavily props usage * The one big project I think might be missing the step of creating projects, which is how I would assume the template is designed to work, so it actually splits game and engine and splits them into independent parts * The outlining in the code seems wrong based on my reading of that code, this seems to be an editor not just an engine which isn't all to uncommon with uber-tools, the selecting of a project is to select something before it opens the editor, the project template creates another project specific to the game * I disagree with engine development the primary audience is the players, this leads down the path of "we make games and not engines", which having seen this play out you end up with hacky code bases, no tests, no documentation, bad dev iteration time and all sorts of things. An engine developer and engine team should be building things for game developers, they should be making their life easier to get games out. Nothing tells me in the code that has been shown in the video or the structure says that there is a major amount of inexperience, it's just a different and appropriate approach, the only bad thing I would call out is EngineData state changing from the dialog and implicitly injected into the editor, which is extremely minor.
Looking at the repo further then what is in the video, there are big things to call out such as not committing binaries, unnecessary includes, bloated classes, bad initialization and more. Which do signal at inexperience but the parts highlighted in the video I don't think really highlight that.
This style of game programming reminds me so much of the 1980's, to the extent that I would originally have thought this programmer was in his 50's - or, of course, a younger student today. If you were taken back to the 1980's, particularly for so many famous 'bedroom' programmers, writing games like this was the norm, particularly because both the toolsets and dev environments were extremely basic at that time (particularly for this group of programmers). Extremely simple cross assemblers were being developed though were primarily found in game studios. Today though, things are very, very different, with virtually no limit to toolsets and environments. Crucially, today we have something infinitely more important for programmers that wasn't present in those early days - the internet! With that said, for a different (but similar!) game, all the engine here needs to be fed with is a different data set. Certainly not as difficult to do today as a few years ago.
BTW: he hardcoded the drive in the file dialog selector: (easy to configure when working with it everyday, but unclean for a general audience) this->m_createFileDialoge = s2d::FileDialog("C:\\", ICON_FA_PLUS, "Select where you want to create a project", this->m_createWindowSize, false);
I think a video about build systems would be awesome! I find it to be one of the more complicated and mysterious parts about C++ (and most other languages too actually)
I REALLY want to see more of this. Not only showing better ways to implement things, but also how not too. Thanks a lot to the guy that send this project to share knowledge. Great video, Cherno
One point you missed about splitting the code base into sub-projects (or modules) is dependencies and dependency chains: the editor depends on the engine, but the engine should never ever depend on the editor, otherwise shipping day is nightmare day when you start "emergency" untangling to get rid of the editor. Same way, the game depends on engine and/or editor. But if the engine should ever depend on the game, then you can never reuse the engine. Sub-projects avoid that as most build systems today deny circular dependencies. Or give you an early warning about what you are about to do is very, very bad. Even as a beginner trying your first big project, and a game engine is a big project, you should use multiple sub-projects as a concept. When ever you try to access specific game stuff from the engine part, the compiler, the build system will say "that's not possible".
I have just learned so much about setting up my engine. Glad I saw this before getting too much further into setting up the git. Could you make a video going more in depth on making the core and the editor separate, with Hazel or another more professional engine as an example?
I think there is a reason we get junior coders to make tools - they get the experience of seeing what comes in as raw data into the editor, and prepared efficiently and optimized for the engine. I'm trying to think of the simplest possible example, which might be optimizing triangles of a mesh into triangle fans and strips. The same with texture formats, shaders, etc.
Omg been looking for an engine architecture tutorial/resource since ever. We need more information on that topic, is incredibly difficult to find resources about how to architect a rendering engine. Thanks Cherno!
Interesting. I believe these understandings come from working in a team, in a professional environment. What I think I'm seeing in this project is a work of someone who has done this all by himself, without a team, really. Which can be fine, but it's often producing weird design choices, that aren't acceptable in the industry, or are simply inconvenient or unnatural. Still, it's interesting to look into, and I'm hoping this particular project is dissected thoroughly. I'm enjoying every second of this review, tbh
I have been working in the software industry (not games, juat boring business-to-business stuff) and now I am just mucking around on my own as a hobby. And not being on a team and not having to be professional, having scrum meetings and all that crap is SO liberating. It totally reminds me of why I chose this career back in the day. A bad mistake by the way, because doing it as a job totally ruins the fun of it in my experience. To me the target audience is one person: me. And the target platform is one computer: mine. So no need at all to waste lots of time on build systems. Maybe I will do it one sunny day, just for the sake of it.
There is a good message here; the same could be said for using an ORM v raw SQL/procs. Like your C++ reviews, knowing what to use and when is the key, and takes time to learn
You raised an important point just like the last video but I don't think you need to labour it for the whole video at the cost of getting into the code properly. The point about separating applications/engines/games was well made after a couple of minutes. Really hope to see some detail in the next one.
But you can very well consider engine and game to be a monolith build for that specific game. And then codeparts from the "engine" side used in the next projects etc. This is useful when portability, flexibility and reusability is not a priority, but other considerations such as high performance for a very specific game type, or a tight deadline to release.
In the context of this channel "engine" means a generalized application (editor) + runtime (engine) to be used in the development of multiple games by other people. Whereas in my context, the "engine" is inextricably intertwined with my game and wholly non-generic.. i mean of course you can use the code framework to make anything but it's not trying to be "Unity" by any stretch of the imagination. It's a kind of controlled chaos and it lets me do wacky things my own way.
I like this code review and have a gut feeling, that there will be lots and lots of follow-up episodes on that review 😀 Looking forward to the next episode 👍
You not wanting to say that something is right or wrong is something I agree with, and you mentioning art made me think of a possible universe where someone told Pablo Picasso that his way of making art is "wrong", and he listened, and then we wouldn't have them as we know them today, if even at all.
We also developed an n-tier architecture at one of the companies, where we wrote every layer for each program. It made me wonder, if no one is using individual components, why are we separating them into layers? So layering is not always a good approach unless multiple applications or components truly utilize them.
Maybe he can pick up the idea for Hazel of optional double-precision (64) vector positions, to allow large levels at a solar system scale. Or some vector formal that convers global 64 bit precision to local (render) 32 bit float positions, and adjusting the origin on the fly for the rendering.
All I do lately is watch your vids that TH-cam thinks I should watch. I guess I might have to switch from godot to hazel and c++ so your channel can be more relevant to me… I really like your philosophies and style so I’ll definitely keep watching.
While the comments on the engine not being properly partitioned from the “game application”, I’m concerned about the emphasis of an editor. I’d say that 99% of hobbyist “engines” don’t have an editor and have no need of one on purpose. Much better to leverage other tools for common assets and do the rest in code. The runtime “framework” is usually enough on its own for most people to get bogged down with let alone suggesting that they need a editor to be a “real engine” :)
Visual Studio is in this case a frontend for MSBuild, which is a capable build system. So I don't see a problem with his approach using the MS tools. MSBuild is even capable of cross compile for multiple platforms.
I dont understand your statement, If I create a variable that refer to an element of my vector that is a pointer to a Sprite, this hold the address of this Sprite, If the vector reallocate some pointer, it just change where this pointer is in memory not the object that it points to, so it cannot invalidate the Sprite itself right ? Now lest say I do like Cherno says and hold the actual Sprite inside the vector, If I create a pointer to an element of my vector, this can definitly gets invalidate if the vector reallocate memory after that.
I agree @15:10! File open/save dialogs like the custom one shown here and the ones presented mostly on Linux / Mac, with no way to even copy / paste a path from / to the clipboard are ridiculous. They are such a pain in the butt. We were able to paste paths from clipboard and drag'ndrop into these file dialogs 30 years ago on AmigaOS already e.g.. I'm sure this is not the only OS which was handling this basic concept correctly back then. It's kind of sad that progress is reverted in so many aspects of "modern" software and applications.
hello Cherno, I want to ask whether making a game engine by making 2D and 3D animation software is the same as the steps to make it, meaning programming ?
If you have no need at the moment for cross-platform development, or maybe you are only supporting like 2 platforms... then honestly spending time on a build system may not be worth the effort. Getting a VS solution up and running is simple and then you dont worry about it. For most home engines/projects this will work great 99% of the time.
Wheres the code review? You say you don't like to say things are wrong but then you are criticizing design decisions that are perfectly valid. 1. Randomly switching compilers and dependencies isn't something you do in a project, specially when the whole team is using one specific compiler and library. I think wanting to make merge conflicts easier to handle and adding the ability to comment why you had to make that build setting are far better reasons to choose something like cmake or premake, even though you're only building for a specific version of msvc. 2. It also looks like the engine is designed to work more like pico8, love2d, any emulator. Ie where you launch the engine and then load the game, so your whole "this doesn't work like hazel/unity/unreal/godot" point is kinda moot.
I’ve been wanting to make my own engine for programming(something akin to the processing framework in Java) with a more modern graphics library for the use of more modern features like hardware raytracing, compute shaders, and mesh shaders, but I have no clue how to abstract a graphics API, namely, what is the shared functionality?
you might want to check out travis vroman's game engine series for that. He has only written the vulkan backend but it is written to allow other backends to be added and is a good indication of what you need to abstract
I've struggled with this (defining the library boundaries) a lot in the past, but I can only recommend to start as non-generic as you can get away with. Trying to be as generic as possible from the start when you don't know what exactly to go for only leads to over-engineered results that very likely turn out not to be ideal for your project in the end. Starting with something simple saves a lot of time, and after working on and using it for a while the ideal boundaries become more clear. Don't abstract too much from the start.
CMake is everywhere because CMake is just fine. It's good to use CMake and the haters 1) apparently haven't experienced life before it 2) are mostly just nitpicking and are too lazy to learn even something as simple as CMake. If you're scripting the hell out of it then you're doing something wrong.
Ok, i mean these are good advices, but not everyone wants to make the next Unity. The game "engine" can just be the core of your singular game that you are making without the overhead of having a fully packaged modularized engine.
First - is it a good a idea to see some news saying EU congressmen used git when they launch the himars and then to know about it, because all of it some interactive game. If you tried to mod a game with yours cars, that might be why it's not correct to have one project or this project does not have modularity and testing team work so everybody does not mess everybody work. You have that modding self learning + everything your university taught and imagined it creating the websites with this folder structure.
Stuff like that file open dialog is one of my biggest pet peeves in programs, where they just implement their own that's prettymuch always wildly inferior and annoying. One of the biggest reasons why the first major libraries I'm learning is win32 stuff.
A great example of this is the file dialog of Paint Tool SAI, where it somehow feels the need to cache every observable particle in the universe every time you open it and is unresponsive for almost a minute, and then also doesn't support any of the simple stuff you'd expect like typing into the file list to jump to a file matching the character(s) you type, among other things. Just why...
This is art, but don't wish me to do perfect animations, make me create spaceships. Goal here is - we are afraid to lose this little game industry we have. Don't ask me to do it if it's not days, but months or years. If you don't shine together with me in graphics maybe you can do some python machine learning - you'd be still in the gaming don't you. You know it's not production in this .env file, because I don't need it now.
very bad code review. You are talking about useless points. Why a build system is important, why the runtime and editor should be separate applications, and then some useless story. Seems to me, that you dont really wanna get into the code, and just yap about how much more you know, when that's not the case at all. You have some memories of how things used to be at EA, and then used 20 different libraries to stitch together a very bad "engine" yourself.
It's hardly constructive, it's just pushing some project structuring ideology while failing to take into consideration the project's scope and purpose. The brief moments he had code up it seemed well implemented.
So you merge everything in the same project? I mean it is probably ok for some project but for a game engine which produce games, it's way better You can easily source control each projects and have many versions The engine will probably evolve And you don't want to break any of your old games by updating the engine for instance
make it working, before going into any deep end, with the options, ie k.i.s.s. before trying to go pro, why would you ever recommend going pro or trying to be a bpro
if you have per pixel 4x4x6 or 64x64x6 cubemap reflection caches, whatever fits in gpu/system ram, then you can instanced render all primitives to multiple buffers side by side very fast, making the scatter light reflection maps on the side, no memory fetch lag because of the instanced rendering, if you render multiple instances on the main, you render those to the reflection on/off screen pixel reflection cache buffers too, real time scatter lighting
well, you can put triangles inside sphere bvh octree, then shoot the rays to the top bvh sphere cells first (if hardcore ray tracing/casting in an acceleration structure), to see if it even hits that container, if any children have to be processed under it
if you think apps need to be broken to things to be perfectly working, then I cant help you, God only gives perfect stuff, not your lacking not-so-perfect stuff
I can't stand cmake. It wants to do things for me. No. I want to choose the commands to run and what options. make sucks, but at least it provides the basics
If he creates games with it and he sells them, and they run just fine, I don't see the problem with his architecture. Steam has their own file menu, and inteliJ, pycharm. But I am also a noob and know nothing about game engines :D
Thanks for watching! ❤
You guys should check out Brilliant FOR FREE for a full 30 days - visit brilliant.org/TheCherno. The first 200 of you will get 20% off Brilliant’s annual premium subscription!
Hey cherno i watched your opengl series it really helped me in making a game with no game engine in c, so thanks.
Id love to see how to create an editor with C# and then call the C++ engine.
Hi Cherno, I feel like I have to say that I think this video felt like an unnecessarily unfair dunk on the original author. This is potentially awkward and unhelpful when a lot of your audience is quite green and impressionable.
I've only looked at the engine briefly but it seems highly likely to me that the template project is what contains the actual game specific project. While the core SpriteEngine project is just the editor alone.
@@peterino2 yep thats what it is 👍
Don't worry guys, only 6 more videos until we get to some actual code that does stuff
great way to pad with ADs
Lol
Yeah, we'll see some code that does stuff after The Cherno writes his own. Oh wait,,.
nah you gotta realize this type of advice is great even if it's not code like if I had someone to review my code with this level experience I'd be thrilled for any advice even if he hasn't even ran the project yet
@@pengie_ The issue rather is that it seems to be the same thing people are doing wrong when sending projects to him all the time. I mean having no build system is probably in every project I've seen so far in those reviews.
I'm also not sure why people are not looking at existing game engines, when they start developing their own. Like 2000 hours in the game engine and they didn't even have like the basics of game engine architecture in there. They could've easily looked at Unreal Engine and you'd see in a second that you should split the editor and the actual engine from each other. Sure I have years of experience as game dev already but even my first attempt to write a game engine I was looking at other engines to see how things should be done. Even if you don't follow that completely because you want to do your own thing etc., there are just best practices you really should not avoid.
If I remember correctly. This is made by a highschooler. Which makes total sense, because back in high school, I'd always react with "so cool, a custom filebrowser, looks much better than the ugly windows one". Now I'm fully onboard with "if there's a convention, use it. I don't want to have to relearn things I already know how to do.
Certainly, it is the brainchild of an adolescent of scholarly pursuits, whose linguistic articulation in the English tongue presents an ongoing endeavor.
My problem is when there straight up isn't a way to do something simple that I'd expect to be there.
This is mainly because either I'm going to use it once and never again, or because I would learn how it works with time either way.
Also on Linux people generally configure the file browser to be an exact representation of what they want it to be, both visually and functionally, not using it is kind of a spit in the face.
i dont use a file browser on linux tho, i dont even think i have one set up, it would be better to have your own and fallback to the default one, or even have it as a setting@@iXenox
That's why from the beginning of the Mac product Apple enforced the style guidelines, not to mention that spending time rebuilding what exists means you're not adding the features that makes you stand out against competitors.
even in grade 6 i wrote an engine a little better than this
I think this code review will end up taking 2000 hours haha
🤣
that's optimistic! 🤣
youtube 101
it's definitely a progression. Now we managed to check a first file.
I designed my game engine with maximum modularity among its components. The solution consists of several projects. The Renderer is a separate statically linked library that can work independently of the engine altogether. The Engine Core handles only logic processing. The Editor uses both the Engine Core and the Renderer. The engine can be built without the Editor.
These are the three main components, but there are others for physics, sound, files, etc. I aimed to make the engine as extensible and decoupled as possible.
Do you maybe got a link to your repo? I would be very interested to see it
modularity is mental masturbation
Not to be a Jon Blow evangelist but he builds his editor directly into the game and has two successfully published games ie Braid and The Witness. I think it just depends on A. experience of the engineer, B. the complexity of the game. Sometimes a completely separate editor is just added complexity with more overhead of maintaining it when keeping it simple is better, less things to fuss with. People think editors need to be Unreal, when in reality it just needs to be a tool that helps YOU make YOUR specific game, not some generic app that can make ANY game
This! You can totally have an engine, a game and an editor in a single executable (just with compile flags to disable the editor part when you ship the actual game).
This is especially useful if you're planning to do very unconventional things (4D, non-euclidian worlds etc).
Also, you can really optimize the engine for your game. Game engines are build to be generic, but this can have a great cost.
If you know there will never be something in your game, then the game engine doesn't even have to bother trying to check that stuff.
When you move on to create another project, just copy things you want from previous games and don't copy the things you don't want!
Beat me to it, was gonna say the same exact same thing. I think it’s totally reasonable to have an engine built for 1 particular game. I’m sure there are plenty of successful games where this is the case
Sure but that's the difference between making a game with a built in editor and making an engine itself. I sure as hell wouldn't go calling braid or the witness an engine project.
@@TheBigWazowski The ID Tech engine is one such example. They just made one game and for the next they removed all game specific code (leaving stuff like rendering, audio, and i/o) and started on the next game, so after a while they just had an engine there from all the generic stuff that got left behind.
To clarify, the engine does not equal the editor. The engine is the code framework that controls the update loop for input, rendering, physics and entities (actors, gameobjects, etc). Separating the engine from game specific code forces you to really practice separation of concerns in your game as well as enabling you to easily branch off to your next game. Every engine basically does this (you can download the engine for Doom 3 BFG and see that they do it for both the engine, the rendering and the game). Whether you include an editor in the engine or have it be a separate application is a different discussion although even then you almost certainly want to split that off into a separate editor framework. Compiling any of these out into their own DLL or into their own executables is again orthogonal to the discussion of separating out engine code from game specific code.
“I’m not going to talk about that too much in this video”
Proceeds to make the entire video about that point.
You literally opened one file Cherno.
Worst code 'review' I've ever seen NGL he just lambasted the author lmao
@@handleneeds3charactersormore Yeah he is getting lazy alright
I am not sure about this specific project, however, I would argue that from indie game developer perspective, it makes sense to blur the line between game, editor, engine. Mainly if you are looking to make a game, not so much an "engine" on it's own but still want to do it without existing engines. In indie games when there are low numbers of developers (maybe only one), not designing an engine in the currently popular modular approach reduces the need to design multiple API's which you would in turn only use yourself.
When you are ready to ship the game, you just disable the editor (if it should not be the part of the shipped game) and release it that way. I think this is perfectly valid, if you know what you are loosing by doing this.
Making a new game doesn't have to be done in a "project browser" way, because you know what parts of the "engine" you need to make the application work. You just copy that code and make it a separate thing.
I think "engine" translates to "unity lookalike thing" in today's parlance, and I really think it shouldn't. The "embedded engine" approach is perfectly valid and that's what I am doing now.
Cherno looked at the code in the code review? Can't believe it. The last one was better.
huh?
The last one sucked coz he didnt look through any code
I believe there is also a problem in expecting somebody of both beginner and intermediate levels of programming skill to use a build system. Especially ones with languages such as CMake. CMake is by no means easy to learn, because every library repository uses it differently, and the tutorial is too abstract to be used as a template to "learn by working" with it. It is a very difficult way to learn to build your code meanwhile a vcproj, even though it is technically an "already built repository", just lets you click one button, or enter text in a few boxes to point to your library binaries and libs...and then you have a binary of your program built within seconds, without having to code an extra script to make that happen at all.
CMake, in some circumstances especially for learners, speaking from my own failed experiences with it and my inability to use it properly to this day, can waste hundreds of hours just on its own. If education out there for the langauge was better, I wouldn't feel so on the fence about that point of yours. By all means, you are a professional and have taken the time to learn and use that tool, don't feel bad for using it. Just don't expect somebody to spend a hundred hours just to build their hobby project with it.
Beginners maybe, but intermediate no. I would not consider a programmer to be of intermediate skill if they don't have a basic understanding of build systems. Basic CMake is not at all difficult to learn (a minimal hello world is three lines or less) and you just google and extend it as necessary. The real reason people find CMake and similar tools difficult is that they don't actually have a good understanding of the compiler and what it needs in order to preprocess, compile, and link code in the way you expect. Knowing CMake top to bottom won't help if you don't understand what the compiler needs.
CMake or a similar tool is more or less a requirement on Linux platforms so this all goes double there. You can write Makefiles by hand if you want but don't come crying to be when they hit 20000 lines haha.
@@ColinBroderickMaths you say that, and yet I have been in university and education for coding in C++ and C# for over 6 years now, and never have I successfully gotten cmake to add a static .lib dependency after around 5 attempts totalling to 30 hours now :/ Like I said, the education out there is terrible. The only time I've ever gotten close to success was when I had to look at some obscure physics library (ReactPhysics3D) which included a cmake tutorial of their own. You know it's badly documented when somebody else has to explain how to use the tool for you.
I can use and understand the gui. I have built repos with it just fine. the syntax of the language itself, however, is a problem, especially with method names that don't make sense in context. It's so badly documented that our university has basically refused to teach their lecturers how to teach students in programming CMake at all. They all just teach us visual studio's compiler system.
That being said, I am close to understanding the tool. But how much uphill battle I've had to fight to get that close at all is ridiculous, and understandable if an intermediate coder doesn't want to deal with it at all if it's just a hobby project.
I mean unless you are definitely going cross platform much of what a build system does can be done within vstudio directly. All an engine like this really needs is to split the runtime out and have it as a dependent project.
Sure automated build system are what you really want, but for a limited release prototype game engine built by a hobbyist I’d recommend they get a cleanish code base before embarking on a fully build system. It just needlessly complicates things in the short to medium term.
Id say if you dont know why you need a build system you dont need a build system.
@@leighrobinson agreed.
@@ColinBroderickMaths automake and make are way more intuitive than CMake from my limited experience. Anytime a build fails in make or automake it's easy to see what should be changed. With cmake it's like ok what arcane variable or setting do I have to change, how does it interact with all the other settings, and where do I set it.
As someone who has been doing AAA engine development for way too long, I've got a different view on many of these things.
* MS VS projects aren't all that bad if your wanting to stick to VS large engines just use VS, albeit with heavily props usage
* The one big project I think might be missing the step of creating projects, which is how I would assume the template is designed to work, so it actually splits game and engine and splits them into independent parts
* The outlining in the code seems wrong based on my reading of that code, this seems to be an editor not just an engine which isn't all to uncommon with uber-tools, the selecting of a project is to select something before it opens the editor, the project template creates another project specific to the game
* I disagree with engine development the primary audience is the players, this leads down the path of "we make games and not engines", which having seen this play out you end up with hacky code bases, no tests, no documentation, bad dev iteration time and all sorts of things. An engine developer and engine team should be building things for game developers, they should be making their life easier to get games out.
Nothing tells me in the code that has been shown in the video or the structure says that there is a major amount of inexperience, it's just a different and appropriate approach, the only bad thing I would call out is EngineData state changing from the dialog and implicitly injected into the editor, which is extremely minor.
Looking at the repo further then what is in the video, there are big things to call out such as not committing binaries, unnecessary includes, bloated classes, bad initialization and more. Which do signal at inexperience but the parts highlighted in the video I don't think really highlight that.
This style of game programming reminds me so much of the 1980's, to the extent that I would originally have thought this programmer was in his 50's - or, of course, a younger student today. If you were taken back to the 1980's, particularly for so many famous 'bedroom' programmers, writing games like this was the norm, particularly because both the toolsets and dev environments were extremely basic at that time (particularly for this group of programmers). Extremely simple cross assemblers were being developed though were primarily found in game studios.
Today though, things are very, very different, with virtually no limit to toolsets and environments. Crucially, today we have something infinitely more important for programmers that wasn't present in those early days - the internet! With that said, for a different (but similar!) game, all the engine here needs to be fed with is a different data set. Certainly not as difficult to do today as a few years ago.
BTW: he hardcoded the drive in the file dialog selector: (easy to configure when working with it everyday, but unclean for a general audience)
this->m_createFileDialoge = s2d::FileDialog("C:\\", ICON_FA_PLUS, "Select where you want to create a project", this->m_createWindowSize, false);
I think a video about build systems would be awesome! I find it to be one of the more complicated and mysterious parts about C++ (and most other languages too actually)
I REALLY want to see more of this. Not only showing better ways to implement things, but also how not too. Thanks a lot to the guy that send this project to share knowledge. Great video, Cherno
Thanks :D
One point you missed about splitting the code base into sub-projects (or modules) is dependencies and dependency chains: the editor depends on the engine, but the engine should never ever depend on the editor, otherwise shipping day is nightmare day when you start "emergency" untangling to get rid of the editor. Same way, the game depends on engine and/or editor. But if the engine should ever depend on the game, then you can never reuse the engine. Sub-projects avoid that as most build systems today deny circular dependencies. Or give you an early warning about what you are about to do is very, very bad. Even as a beginner trying your first big project, and a game engine is a big project, you should use multiple sub-projects as a concept. When ever you try to access specific game stuff from the engine part, the compiler, the build system will say "that's not possible".
I have just learned so much about setting up my engine. Glad I saw this before getting too much further into setting up the git.
Could you make a video going more in depth on making the core and the editor separate, with Hazel or another more professional engine as an example?
I think there is a reason we get junior coders to make tools - they get the experience of seeing what comes in as raw data into the editor, and prepared efficiently and optimized for the engine. I'm trying to think of the simplest possible example, which might be optimizing triangles of a mesh into triangle fans and strips. The same with texture formats, shaders, etc.
Omg been looking for an engine architecture tutorial/resource since ever. We need more information on that topic, is incredibly difficult to find resources about how to architect a rendering engine. Thanks Cherno!
Interesting. I believe these understandings come from working in a team, in a professional environment.
What I think I'm seeing in this project is a work of someone who has done this all by himself, without a team, really. Which can be fine, but it's often producing weird design choices, that aren't acceptable in the industry, or are simply inconvenient or unnatural. Still, it's interesting to look into, and I'm hoping this particular project is dissected thoroughly. I'm enjoying every second of this review, tbh
I have been working in the software industry (not games, juat boring business-to-business stuff) and now I am just mucking around on my own as a hobby. And not being on a team and not having to be professional, having scrum meetings and all that crap is SO liberating. It totally reminds me of why I chose this career back in the day. A bad mistake by the way, because doing it as a job totally ruins the fun of it in my experience.
To me the target audience is one person: me. And the target platform is one computer: mine. So no need at all to waste lots of time on build systems. Maybe I will do it one sunny day, just for the sake of it.
There is a good message here; the same could be said for using an ORM v raw SQL/procs. Like your C++ reviews, knowing what to use and when is the key, and takes time to learn
You raised an important point just like the last video but I don't think you need to labour it for the whole video at the cost of getting into the code properly. The point about separating applications/engines/games was well made after a couple of minutes. Really hope to see some detail in the next one.
I liked the humble speech when you mentioned right and wrong. +1 charisma.
But you can very well consider engine and game to be a monolith build for that specific game. And then codeparts from the "engine" side used in the next projects etc. This is useful when portability, flexibility and reusability is not a priority, but other considerations such as high performance for a very specific game type, or a tight deadline to release.
In the context of this channel "engine" means a generalized application (editor) + runtime (engine) to be used in the development of multiple games by other people. Whereas in my context, the "engine" is inextricably intertwined with my game and wholly non-generic.. i mean of course you can use the code framework to make anything but it's not trying to be "Unity" by any stretch of the imagination. It's a kind of controlled chaos and it lets me do wacky things my own way.
I like this code review and have a gut feeling, that there will be lots and lots of follow-up episodes on that review 😀 Looking forward to the next episode 👍
You not wanting to say that something is right or wrong is something I agree with, and you mentioning art made me think of a possible universe where someone told Pablo Picasso that his way of making art is "wrong", and he listened, and then we wouldn't have them as we know them today, if even at all.
We also developed an n-tier architecture at one of the companies, where we wrote every layer for each program. It made me wonder, if no one is using individual components, why are we separating them into layers? So layering is not always a good approach unless multiple applications or components truly utilize them.
True of any product development: Remember the customer, you're not building for yourself, unless you are of course.
I can't wait to hear your opinion of CIG's Star Engine they just demonstrated.
Maybe he can pick up the idea for Hazel of optional double-precision (64) vector positions, to allow large levels at a solar system scale. Or some vector formal that convers global 64 bit precision to local (render) 32 bit float positions, and adjusting the origin on the fly for the rendering.
Please continue talking about about game engine architecture, please
All I do lately is watch your vids that TH-cam thinks I should watch. I guess I might have to switch from godot to hazel and c++ so your channel can be more relevant to me… I really like your philosophies and style so I’ll definitely keep watching.
I’d love to see Cherno review something Jonathan Blow or Casey Muratori wrote. Just to see the absolute incompatibility of philosophies collide. Lol
While the comments on the engine not being properly partitioned from the “game application”, I’m concerned about the emphasis of an editor.
I’d say that 99% of hobbyist “engines” don’t have an editor and have no need of one on purpose. Much better to leverage other tools for common assets and do the rest in code.
The runtime “framework” is usually enough on its own for most people to get bogged down with let alone suggesting that they need a editor to be a “real engine”
:)
My game editor is a series of python plugins for Blender and it works quite well and is very versatile.
Hey at least we saw some code fellas. We're getting there.
You should check out the Meson build system.
Visual Studio is in this case a frontend for MSBuild, which is a capable build system. So I don't see a problem with his approach using the MS tools. MSBuild is even capable of cross compile for multiple platforms.
Yes. But if you want to actually build on other platforms, you cannot use MSBuild.
Please continue this review! Love it so far
I dont understand your statement, If I create a variable that refer to an element of my vector that is a pointer to a Sprite, this hold the address of this Sprite, If the vector reallocate some pointer, it just change where this pointer is in memory not the object that it points to, so it cannot invalidate the Sprite itself right ? Now lest say I do like Cherno says and hold the actual Sprite inside the vector, If I create a pointer to an element of my vector, this can definitly gets invalidate if the vector reallocate memory after that.
that was a surprisingly short one
Cherno's patience for this project cracked when he struggled halfway through the readme.
I think we need a third episode.
Loving this! I know its challenging to work and look at but really like the insights into coding.
I agree @15:10! File open/save dialogs like the custom one shown here and the ones presented mostly on Linux / Mac, with no way to even copy / paste a path from / to the clipboard are ridiculous. They are such a pain in the butt. We were able to paste paths from clipboard and drag'ndrop into these file dialogs 30 years ago on AmigaOS already e.g.. I'm sure this is not the only OS which was handling this basic concept correctly back then. It's kind of sad that progress is reverted in so many aspects of "modern" software and applications.
Great video, Thanks for your experienced insight!
I love Cherno
hello Cherno, I want to ask whether making a game engine by making 2D and 3D animation software is the same as the steps to make it, meaning programming ?
If you have no need at the moment for cross-platform development, or maybe you are only supporting like 2 platforms... then honestly spending time on a build system may not be worth the effort. Getting a VS solution up and running is simple and then you dont worry about it. For most home engines/projects this will work great 99% of the time.
Wheres the code review? You say you don't like to say things are wrong but then you are criticizing design decisions that are perfectly valid.
1. Randomly switching compilers and dependencies isn't something you do in a project, specially when the whole team is using one specific compiler and library. I think wanting to make merge conflicts easier to handle and adding the ability to comment why you had to make that build setting are far better reasons to choose something like cmake or premake, even though you're only building for a specific version of msvc.
2. It also looks like the engine is designed to work more like pico8, love2d, any emulator. Ie where you launch the engine and then load the game, so your whole "this doesn't work like hazel/unity/unreal/godot" point is kinda moot.
Ah man, this is gonna be great
I’ve been wanting to make my own engine for programming(something akin to the processing framework in Java) with a more modern graphics library for the use of more modern features like hardware raytracing, compute shaders, and mesh shaders, but I have no clue how to abstract a graphics API, namely, what is the shared functionality?
you might want to check out travis vroman's game engine series for that. He has only written the vulkan backend but it is written to allow other backends to be added and is a good indication of what you need to abstract
I've struggled with this (defining the library boundaries) a lot in the past, but I can only recommend to start as non-generic as you can get away with. Trying to be as generic as possible from the start when you don't know what exactly to go for only leads to over-engineered results that very likely turn out not to be ideal for your project in the end.
Starting with something simple saves a lot of time, and after working on and using it for a while the ideal boundaries become more clear. Don't abstract too much from the start.
do you even want to work in game development?
@@anon1963 possibly, mostly I just want a way to visualize what I’m doing
@@anon1963 I enjoy it enough, I just don’t want to be caught up in corporate bullshit like the Unity thing
this could easily be a multi chapter series
CMake is everywhere because CMake is just fine. It's good to use CMake and the haters 1) apparently haven't experienced life before it 2) are mostly just nitpicking and are too lazy to learn even something as simple as CMake. If you're scripting the hell out of it then you're doing something wrong.
meson shits on it
bruh you looked at one file in 16 min 💀
I don't understand why you are complaining about custom file dialogs.
Valve made their own for Steam and I can't see anybody complaining.
I'll be the first. Steam's file browsing is horrendous.
The annoyance was palpable in this one!
But you said you are not capable of roasting him XD
what about shipping a binary of tcc alongside a project so one only has to cd into the project file and execute the built in compiler
Ok, i mean these are good advices, but not everyone wants to make the next Unity. The game "engine" can just be the core of your singular game that you are making without the overhead of having a fully packaged modularized engine.
First - is it a good a idea to see some news saying EU congressmen used git when they launch the himars and then to know about it, because all of it some interactive game. If you tried to mod a game with yours cars, that might be why it's not correct to have one project or this project does not have modularity and testing team work so everybody does not mess everybody work. You have that modding self learning + everything your university taught and imagined it creating the websites with this folder structure.
Please more!
This is NOT a code review, it is a code rotisserie 😂😭
well now I just want to see it because of the build up
let's goo he pressed run
Stuff like that file open dialog is one of my biggest pet peeves in programs, where they just implement their own that's prettymuch always wildly inferior and annoying. One of the biggest reasons why the first major libraries I'm learning is win32 stuff.
A great example of this is the file dialog of Paint Tool SAI, where it somehow feels the need to cache every observable particle in the universe every time you open it and is unresponsive for almost a minute, and then also doesn't support any of the simple stuff you'd expect like typing into the file list to jump to a file matching the character(s) you type, among other things.
Just why...
i know how to use renderer to render gui, and splitter, cursor change, color picker, docker tab system, input text handle
Why are people still talking about cmake, now we have xmake which is insanely better, basically Cargo for C++
This is art, but don't wish me to do perfect animations, make me create spaceships. Goal here is - we are afraid to lose this little game industry we have. Don't ask me to do it if it's not days, but months or years. If you don't shine together with me in graphics maybe you can do some python machine learning - you'd be still in the gaming don't you. You know it's not production in this .env file, because I don't need it now.
very bad code review. You are talking about useless points. Why a build system is important, why the runtime and editor should be separate applications, and then some useless story. Seems to me, that you dont really wanna get into the code, and just yap about how much more you know, when that's not the case at all.
You have some memories of how things used to be at EA, and then used 20 different libraries to stitch together a very bad "engine" yourself.
Hey someone said it!
lol
Poor dude. I know it's constructive but poor dude.
It's hardly constructive, it's just pushing some project structuring ideology while failing to take into consideration the project's scope and purpose. The brief moments he had code up it seemed well implemented.
yo wheres the rest of the video..
Dogmas, dogmas, dogmas...
If you want to be shocked, look at the code X-Ray Engine
6:06 There is nothing wrong with that.
So you merge everything in the same project?
I mean it is probably ok for some project but for a game engine which produce games, it's way better
You can easily source control each projects and have many versions
The engine will probably evolve
And you don't want to break any of your old games by updating the engine for instance
It feels like the whole video was made just for ad. I hope I am wrong tho.
maybe you could take a look at the godot source
Im sure he will take peaks at it anyways when developing features for his own engine. No need to reinvent the wheel everytime.
CMake is great (CMake-gui I haven't tried) and the VS CMake extension is first class with proper intellisense and even CMakeLists debugging.
2000 h to make
And
2000 h to review
😂😂😂
Can you do godot code review?
make it working, before going into any deep end, with the options, ie k.i.s.s. before trying to go pro, why would you ever recommend going pro or trying to be a bpro
if you have per pixel 4x4x6 or 64x64x6 cubemap reflection caches, whatever fits in gpu/system ram, then you can instanced render all primitives to multiple buffers side by side very fast, making the scatter light reflection maps on the side, no memory fetch lag because of the instanced rendering, if you render multiple instances on the main, you render those to the reflection on/off screen pixel reflection cache buffers too, real time scatter lighting
well, you can put triangles inside sphere bvh octree, then shoot the rays to the top bvh sphere cells first (if hardcore ray tracing/casting in an acceleration structure), to see if it even hits that container, if any children have to be processed under it
if you think apps need to be broken to things to be perfectly working, then I cant help you, God only gives perfect stuff, not your lacking not-so-perfect stuff
you only need support for sub-par code, and perfect things are not lacking anything, so which is it, perfect or you get no support.
I can't stand cmake. It wants to do things for me. No. I want to choose the commands to run and what options.
make sucks, but at least it provides the basics
no, not enjoyable
for a beginner
6:41
it could be oke.
for now.
this might be a bit much
Crazy how you posted cinematics, instead of gameplay classic EA shit lmao.
cool I'm early
hello sir...i want to ask how studio remedy made the northlight game engine for alan wake 2?
WWCD
Second?
first???
Id love to see how to create an editor with C# and then call the C++ engine.
맵다 매워 ㅋㅋㅋㅋ
visual studio is the worlds worst IDE
If he creates games with it and he sells them, and they run just fine, I don't see the problem with his architecture. Steam has their own file menu, and inteliJ, pycharm. But I am also a noob and know nothing about game engines :D
Firstest :D
This video could have been 5 minutes.
These are campaign choices - must choose what you want
Hey, will you be looking at the starengine demo and perhaps the starcitizen server meshing stuff? would love to hear your thoughts on that!
Damn man since you started doing this series you said you wanted to make the video about to how to upload to TH-cam and build system, still not here.