Kohi #000: Game Engine Architecture and Overview (Vulkan Game Engine Series)

hello everyone and welcome to the new kohi game engine series where we are going to be building the tech that powers games from scratch i'm super excited to get this series started and we're going to do that right now before i begin i would like to give a shout out to the channel's first partner the partner is the highest tier of membership on the channel and that partner is arslia i hope i pronounced that correct thank you very much for supporting the channel i would also like to give a quick thank you to the other supporters of the channel who are up on the screen now thank you very much your support is greatly appreciated if you would like to support the channel you can do so by clicking the join button down below details on memberships are actually available in the video i will post here there will also be a link in the description below so this series is actually going to take the channel back to its roots and by that it is going to be about something i'm passionate about which is making game engines that is what this channel sort of got its start on with the typescript game engine series for any of you guys who have seen that and this is sort of going to be the next logical step in that however this series is going to be a lot longer than that series as it's going to be a much larger engine and cover a larger set of features that we are going to be creating and we're going to jump into that in a few minutes so before we go any further let's answer some of the burning questions that i'm sure you guys are wondering about regarding this series so um first let's go ahead and define what a game engine is so that we can get that out of the way for those of you who are not familiar with it a game engine is a software framework and a suite of tools used to build and create video games so the next question is should you make one well to be quite honest if your primary goal is to make a game very quickly and get it out the door get it shipped then the answer to that is actually no and i know that goes against sort of what this series is all about but i want to be straight with you from the get-go if you're looking to create a game as quickly as possible your fastest option is going to be to use a already existing engine such as unreal or unity this series is for those of you who are looking to understand how some of those things work and want to sort of go through the learning exercise and building your own game engines are very large very complex sets of software and it's something that's going to take us a very long time to sort of finish so this is not going to be a series that's going to wrap up in six months this is going to be a long running series that we're going to be constantly building on top of as we go so with all that said if you're interested in learning about the tech that powers games stick around so first off why the name kohi well kohi is basically the japanese pronunciation for coffee i named it that because i have an absolute love for coffee and i can never get enough of the stuff and it just makes sense to me so kohi is the name of the game engine so the next thing is what are the requirements of the series what should you know before actually jumping into this series well you should have some familiarity with c this is not going to be a tutorial on the language itself in fact i actually have a series that's running in parallel to this uh that is an introduction to c that will serve as a primer for this series so at the moment it's very it's a pretty new series it's not that far along but if you follow that along with this eventually it will all sort of come together and make sense so a link to the first video in that series will be up here and that's pretty much all you need to know to jump into this series i'm going to go over everything else that we'll need to know along the way so what about platform support what platforms are we planning on supporting with this engine well i did a poll on this for those of you who participated thank you very much there was a surprising amount of you asking for linux support now obviously windows was number one i expected as much but with the number of you that answered that you would like to see this on linux as well i am actually going to be supporting windows and linux from the get-go and we are going to do this in such a way where we're going to keep those platform abstractions as as combined or sort of self-contained as we possibly can but we are not going to do the whole we're going to support windows now and then do linux at a later date we are actually going to support both out the gate the way that we're going to handle that is we're first going to do windows and then once we have our setup there we're going to stop and we're going to jump over to linux and implement the exact same features that we need for the engine at the linux level and from that point forward you'll be able to build the project on either platform and be able to follow along now as for mac support there was a little bit of a calling for that but not enough to warrant me actually picking up a mac i don't have a mac right now to actually be able to build that at some future point i may obtain one and you know at that point i'll go ahead and port it to the mac os but at this point there's just not quite enough demand for it and so uh that platform i will be tabling but at some point we we will definitely support this even if that is via you know somebody who has a mac that that can can do that work for us so at this point i'm going to put mac aside but we are supporting windows and linux out the gate okay so what about our tech stack our tech stack is going to be very simple in this everything we're going to do we're going to build in c we are going to use clang as our compiler so that out of the box gives us cross-platform compatibility we are not going to be using visual studio whatsoever nor are we going to be using the visual studio compiler clang i think is the best move here um and i've already done a lot of experimenting with it i've been able to get a sort of sample project running in building on both platforms so i am very confident that clang is the right decision for this so vulcan will be used to make our initial renderer we are going to use vulcan out the gate and then possibly in the future we may use opengl and directx is also a possibility because we may want to port to platforms that require those things that may not support vulkan i'll also be using vs code as my editor but it's not required that you actually do that there are going to be some setup things that just automate some of the build tasks but the build system itself will be independent of whatever editor you you decide to use we will not be supporting visual studio because it has a very specific project solution set up that i just don't want to deal with frankly and so if you want to use visual studio that's going to be up to you to support that out of the gate i'm not going to be supporting visual studio this time around okay so next question is is this engine going to be 2d or 3d and the answer is the engine is going to be fully 3d from the beginning 2d support is trivial to build on top of a 3d engine but the other way around is not necessarily true so i think the better move here is to support 3d out the gate okay so a couple other points this game engine will be fully open source and completely free uh to use uh there will be a license where i should be credited um you know as far as the the engine's use and i think that's fair but that is the only restriction um so basically if you use it to build a game you just have to say that you're using it that's it [Music] it's it's part of again me taking this channel back to its roots and providing this kind of tech for free because i think knowledge should be free so uh with that the repo will actually be created later in this video and from there on you guys will be able to get access to everything that we do in the series for free publicly uh the other thing i want to bring up is this series will not be live coded on on the screen um i've done that a lot in the past and it winds up just taking a lot longer and is not quite as productive um and i'm going to take this this approach initially at least for pacing purposes because it takes a lot to actually get vulcan set up and if i live code the entire thing it's going to take forever and frankly i don't think um any of you guys necessarily want to see me code the entire thing live and and wait for that it just it's a lot of video editing and frankly um i just i'd rather spend that time getting um more tech added to the engine versus uh having to worry about editing all that uh that footage so i will not be coding for the most part on the screen at least initially until we have something up and running that is subject to change in the future uh for anything where i feel it's necessary to do that i'll do it but for the most part i'm not going to be doing that the architecture also will be changing up as we go so i'm not going to over architect things from the very beginning because i feel like that's counterproductive because we are going to spend a whole lot of time on just architecture and not actually building things so some of the things that we're going to build early on we're going to build in such a way where they will have to be refactored but i'd much rather get something up and running sooner that being said i do have an architecture in mind that we're going to get to and i will keep that in mind as i write these things so that it's not a complete you know file new refactor type thing and that is pretty much most of the major points i wanted to cover so with that let's go ahead and jump into a quick discussion about architecture and the way that the engine is actually going to be set up as well as the project itself okay so the first thing that i want to talk about is the project structure and by project structure i mean how are the files physically going to be laid out and i'm going to keep this very high level for now once we get into asset management and things i'll cover that but for now i'm just going to talk about how the software itself is going to be laid out so the very first piece of this is going to be the kohi engine itself and this is actually going to be structured as a dll or an so object for linux which is a shared object this is going to be a library of code that is not executable on its own but is referenced by an application so all of our core logic will be in the uh the kohi engine dll so the next part of this there will be a game application which will be our executable and it will reference the kohi engine dll or sl however that being said our game application executable itself will actually be extremely light and the reason for that is because we want to support hot reloadable game code which will also be in a dll or so and the idea here is that we can have our our lightweight game application executable running and then we can make minor changes to our game code and recompile that and as the game application is running we can reload that hot reloadable game code dll which references the engine and see those updates in real time so that we don't have to shut down the project and recompile everything and and so forth so that is a system we'll be setting up a little bit further down the line in the future but this is sort of the overall flow that we're going to be going for so um at least initially we're actually going to be creating something that i'm calling a test bed executable and this will be similar to the game application except this is going to be built with it in mind to test specific game engine features so the test bed will never be a game by itself we are simply going to use that to test engine features and run the engine directly as we continue versus the the game application which will be a little bit more organized finally we have an editor piece which is also going to be an application or an executable of its own and the editor is going to stand separately from the engine dll so that we are not shipping the uh editor code with the engine when we package up the the game application so we've separated this out in order to keep all the editor logic out of the engine to make the engine as lightweight as possible this will also technically allow us to run the editor and the game at the same time um in which case we can go ahead and make changes to the world for example or a world map and then save those changes and see them immediately within the game application executable so that is our overall project structure [Music] so the next thing i want to move on to is a feature list and this is by no means an exhaustive feature list but it's one that gives us a high level view of some of the things that we're going to be implementing and covering in the series and of course this is going to be growing as time continues but these are some of the basic things that i've already got in mind for the engine so the first thing is a lightweight build system this is going to be cross platform the way that we're going to set that up so that you could basically execute a either a batch or a bash file and that will build it consistently across the board so it's going to be a very lightweight build system i'm not going to use a cmake or anything like that i want to keep it as light as possible and as simple as possible to avoid any complexities or issues along the way the next thing we're going to have is some low level utilities things like dynamic arrays binary trees string handling things like that so those are going to be some of the first things that we're actually going to take care of at least the dynamic arrays and string handling we are also going to have a platform layer which abstracts the windows and linux operating systems for now so any os specific code is actually going to be sort of behind that platform layer that way the rest of the engine does not have to care what os we are actually on um the platform layer handles all that for us so this will include things like windowing input console interaction things of that nature next up we will have a logger implemented which is basically just for basic debugging purposes this will include both writing out to the console and basic file logging initially we'll probably wind up revisiting that a couple of times to make it multi-threaded and performant but at least initially it's going to be quite simple also obviously file i o is something we're going to have to deal with because we're going to be reading in textures and models and our world maps things of that nature so we need a file i o layer to handle that we will have an application layer the application layer is basically what manages things that are super high level like the game loop itself as well as various other items like managing a lot of the sub systems that will be in place things like calling the renderer updating the physics system things of that nature so next will be the renderer i'm including in this the uh api abstraction layer so there'll be a thin layer that sits over top of vulcan opengl directx and so there'll be a sort of front-end back-end renderer system here so the renderer that's going to be a very very large topic and it's probably going to be something that's going to be changing a lot throughout the throughout the series because the renderer is one of the most complicated systems in a game engine we're also going to be covering memory management so things like custom allocators things of that nature we'll also have a scene graph system with an entity component system or ecs we will also have profiling and debugging utilities as well as uh basic quote unquote scripting support via the hot reloading that i discussed before where we can recompile our game code on the fly and see those changes immediately and we'll also have a physics system now like i said this is not a exhaustive list of everything we're going to be supporting but these are some of the features i also want to touch on engine architecture real quick just to give you an idea of how sort of the engine will be architected at least as it stands right now basically the engine initially is going to have these sort of layers that exist and the very first layer is going to be the platform layer so the platform layer contains things like the abstraction for all the windows linux mac apis things like windowing low level file access things of that nature console output can also be platform specific so we are going to handle that as well at the platform layer also um as i sort of alluded to before they'll be low level file i o and memory access that will be in the platform layer as well as some of our renderer api extensions that are platform specific and obviously i'll be covering all these in detail as we go so the next layer of this is sort of our core and our core is probably worth where we are going to be spending a lot of time at least initially and that is going to contain our things like our logger our assertions our data structures so our you know binary search trees our link list things of that nature also our higher level quote unquote memory allocators will be here our math library things like parsers for xml csv json files obj files things of that nature will also be here engine configuration for things such as like display resolution various various options that can be toggled on and off will be supported there that will also include a variable system that we'll get into at some point our profiling tools will be located here as well as asynchronous file i o things like localization services and our string handling library which contains a whole bunch of string utilities that we can use from anywhere so that we don't necessarily have to import the massive string libraries as well as the other random things like a random number generator so again this isn't an exhaustive list but it'll give you some of the idea of some of the things that will be in the core layer so the next layer of this is resource management and resources are basically things like images that are loaded off disk that are used typically for textures our material information that holds various properties about our surfaces in the world our meshes animations world maps things of that nature so that's going to be sort of a layer all on its own we'll also have our renderer which will consist of a front end and a back end so the front end will contain things like the graphical user interface the scene graph the camera management some post effects like hdr things of that nature screen blurring things like that and then we'll also have a renderer back end which includes our renderer api abstractions so that's where our vulkan layer will sit our opengl directx things of that nature it's where we'll handle materials and lighting shaders message meshes textures graphics pipelines all that kind of stuff again this is not an exhaustive list these are just some of the high level items that will be included we'll also have an audio system where we'll have 2d and 3d audio various effects playback management things like that and then we'll have a load of other systems that will be in place like our animation timeline system our ecs our event system collision physics which i actually noticed i have listed in there twice but i guess that is how important it is so i'll leave it as his things like state machines and so so many other things that just will not fit on this screen so as you can see here there are a lot of systems we're going to have to build and this is probably about half of them if i'm completely honest this doesn't even include any of the editor stuff that we're going to have to build so the editor stuff is all going to leverage this technology um after we have built it and get to that point so with all that said uh this is the primary plan for this series so one thing i also want to cover real quick is i want to go ahead and create the project repo okay so i have here my github account and i'm going to go ahead and create a new repository and this is simply going to be called kohi and i'll fill in a little bit more of this stuff later i just want to create it for now i do want to add a license and i'm going to stick with apache 2.0 because it's a pretty permissive license the only thing it really requires is that you say that you're using kohi if you use it to build something otherwise you're free to redistribute it modify it whatever and that should be it so let me go ahead and click create and there we are so you can now get this repository from github.com slash travis roman kohi and this is where all the code for this series will be placed so if you like this video please go ahead and click the like button below go ahead and click the subscribe and hit the little notification bell so that you guys know the next time a video in this series drops i'm also thinking a weekly schedule is probably going to be what i'm going to stick to for this series at least initially until it gets off the ground i may step that up to two videos per week at some point but at least initially i want to keep it to one video a week so thank you guys for watching and i will see you guys in the next video [Music] you

Channel: Travis Vroman

Views: 7,323

Keywords: write a game engine, write your own game engine, make a game engine, how to write a game engine, learn to write a game engine, writing a game engine, make your own game engine, game development, game dev, game engine, game developer, how to, tutorial, programming, gamedev, vulkan game engine, vulkan, game engine series, how to make a game engine, vulkan api, 3d game engine, vulkan engine, vulkan tutorial, 3d graphics, learn vulkan, 3d vulkan, how to vulkan, vulkan renderer

Id: teg23SJlyl8

Length: 23min 13sec (1393 seconds)

Published: Fri Mar 05 2021