Game Engine Architecture 101 // Code Review

📚 CHAPTERS
0:00 - Hello
0:25 - Project structure and why use a build system
5:54 - The foundation fo Game Engine architecture
11:41 - A story from the past
14:55 - Running the engine for the first time
15:13 - This is so annoying

💰 Links to stuff I use:

This video is sponsored by Brilliant.

[Finkelfunk]

Don't worry guys, only 6 more videos until we get to some actual code that does stuff

[thomasblazek]

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.

[dingoDogMan]

I think this code review will end up taking 2000 hours haha

[TopConductor]

it's definitely a progression. Now we managed to check a first file.

[msmeraglia]

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

[perkele]

“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.

[danieljenikovsky]

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.

[nick]

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.

[ferdynandkiepski]

Cherno looked at the code in the code review? Can't believe it. The last one was better.

[Kaleidio]

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.

[HotYaya]

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);

[cthutu]

I am starting to go off these videos. People open up their code/soul and get a very condescending response back. Now, there were some good opinions given by Cherno (particularly using premake to generate solutions and division of projects), but it's surrounded by a less than stellar mentoring attitude.

BTW, if you use premake, you can generate a single solution/project if you want anyway. The code becomes separated by folder instead of project (e.g. a engine folder, an editor folder, a game folder). Premake can assemble it all into a single project. I still wouldn't do that for build speed reasons, but it doesn't hurt. Solutions/projects just become a means to an end (building the game) and don't get committed into the repo.

Instead of show exasperation for the release build not working, you could talk about how important it's to ensure both work at all times, and perhaps bring up CI/CD to help out here. Instead of saying how much you hate custom file dialogs, you could have calmly talked about the advantages of native dialogs, as you did but with no attitude.

[reductor_]

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.

[valentinzacarias]

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!

[moonhowler]

I liked the humble speech when you mentioned right and wrong. +1 charisma.

[Rob......]

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.

[francobarrera]

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 <3

[vesk]

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)

[jonathanhoffstadt]

I’d love to see Cherno review something Jonathan Blow or Casey Muratori wrote. Just to see the absolute incompatibility of philosophies collide. Lol

[rmt]

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?