Let's talk.

what's up guys my name is zacherno strap yourselves in this is going to be a long one today we're going to be talking about the game engine series we're going to be talking about hazel where it's going in the future direction of this because i've had the last few weeks to kind of reflect on what i'm doing with my life what i'm doing with this series and uh this video is going to be about where we're heading now it's very likely that this video will upset a few people uh i'm sure that this will not fit the ideas that everyone had going into this series but hopefully the reasons i provide will reassure you that i'm not making this decision lightly and overall it's going to be for the best and for those of you who are completely unaware of what's going on i am making a game engine called hazel and i'm also developing a video series called the game engine series in which i show myself writing basically every single line of code that goes into making a game engine and that is coincidentally also called hazel even though the game engine that i'm making along with a team is very different than the video series the game engine series so this particular video is going to be structured in two parts basically there's going to be the explanation and the future and then we're going to dive in and spend the majority of this video actually planning literally like the rest of the series and every single component from a high level that is going to go into this game engine series and you'll see that i have nicely divided this video into chapters so that you can navigate it more easily so to cut a long story short basically the game engine series version of hazel is becoming hazel 2d yes that means that we will not be adding any kind of 3d rendering 3d physics 3d anything really as part of this game engine series my version of hazel that i'm developing along with a team that of course already is 3d and that's accessible by patrons that will remain 3d and it will contain both 2d and 3d functionality as it currently does now and we're going to keep working on that if you're suddenly oh so shocked then stick around because i'm going to explain why i'm making these decisions and what the motivation is behind them so first of all when i say no 3d in hazel 2d in this game engine series version of hazel i'm not referring to the fact that it will not have any concept of 3d space what i'm talking about is that it's not going to have a 3d renderer that will render meshes 3d models and it will not have like a 3d physics engine or anything like that currently at the moment this game engine series version of hazel that is on github that actually does support the concept of 3d space because of course you can create like an entity and it's got an x y and a z coordinate it doesn't just have an x and a y coordinate like you would see if it was truly 2d it is in fact still in 3d space we also have perspective projection and we have an editor camera that does in fact exist in 3d space and you can control it as if you were flying through 3d space so all of that is in fact there that will remain there but we're not going to be officially at least taking it into more of like a 3d game engine sense basically my idea is to take hazel 2d the game engine series version of hazel from now on i'm going to call hazel 2d the game engine series version of hazel so just remember that and if i say hazel from now on i'm specifically referring to like the full version of hazel the patreon version of hazel my version of hazel not the game engine series my goal with hazel 2d is to make it an absolutely brilliant 2d game engine that means that we will be focusing on implementing pretty much every system imaginable that you can think of that you would like to have in a 2d game engine this series after all is called the game engine series not the how to write a 3d renderer that is goodbye 2021 standards series and it's just becoming far too apparent with the work that i've been doing on hazel the real hazel just how much time it would take to actually teach and record videos on every single line of code that goes into something like that and the thing is at the end of the day not everyone is interested in 3d rendering i think the game engine series is a bit misleading if 90 of it would be 3d rendering and then all the other systems fit in at some point then not to mention it's going to keep going for literally the rest of my life which it looks like it probably will anyway so my point is the scope is just far too large and i would rather focus on the engine in a more holistic approach rather than focusing on this kind of massive part of it now that being said and i have mentioned this before like the scope of the 2d rendering and the 2d games that we're making you know i'm not i'm not picturing 80s space invaders or something like that over the last few weeks i've been playing two games on my nintendo switch celeste and hollow knight now these are both 2d games so to speak for those of you who haven't played these games by the way i highly recommend them they are both excellent now celeste on one hand is a little bit more simple in the way that it renders everything hollow knight on the other hand is very much a a great example of a 2d game in 3d space because the whole thing is made up of so many different layers there's so much parallaxing going on the art in that game is just it's almost overwhelming for me to look at realizing how much work has gone into that it's also a great example of combining 2d art with engine generated things such as like particle effects lighting and other things i think that hollow knight is absolutely a great benchmark a great goal to work towards as to the kinds of 2d games i want to be able to create with hazel 2d so let's talk about why this change is happening i mean i think that a lot of you probably can already guess that it's a lot of work to try and complete quote unquote a 3d game engine i mean first of all if you look at other engines that are currently out there in the wild they're not completed i mean i would call them completed in the sense that it really depends how you define that like what does completing a 3d game engine mean well i guess to me it means it's at a state where you can ship like actually ship a complete game with it that includes all of the things we have grown accustomed to being in a game so like you know if you don't support audio but you have great graphics i wouldn't really call that a complete game engine because usually games have sound the other problem is that like the term 3d game engine i mean you could argue that what we have in hazel 2d is a 3d game engine because it it is in 3d space so like it really depends if you kind of picture something really simple that's in 3d space or you look at a 3d game such as i don't know call of duty or why is it so hard to come up with 3d games on the spot battlefield ratchet and clank just like 3d games guys my point being that 3d games in 2021 are pretty like complex in both the interaction with the world but then also the actual rendering technology that goes into them that's kind of what we're trying to do with hazel with the real hazel like that's that's hard enough as it is but then to convert that into a video tutorial series is both i think mostly unhelpful for people who are actually trying to do this because i don't think they'd be sitting through videos like that unless it's for entertainment um but also there's just just too much time has to go into that i mean to be blunt there is just a lot there's too much time to go into that time that i would rather spend actually making the game engine because as i mentioned that's a difficult enough task as it is the goal of the game engine series as i mentioned is to make a game engine and to bring it into that kind of production quality state what i mean by that is to get it to the point where i would happily ship a 2d game with it on steam a lot has to happen in order to achieve this a lot of mostly non-rendering related work and we're going to discuss all of that here today so that's the first reason just the fact that the scope is absolutely enormous the second reason is mostly because i don't necessarily consider myself a career academic so first and foremost i see myself as a software engineer i see myself as someone working on hazel working on a game engine i actually want to make the game engine and i want to make games with it and i want to ship them and distribute them and let people play them like a piece of art i'm an engineer making art i mean that's the entire goal of hazel to create a game engine that can make games and not just an engine that i can use to make games but an engine that well everyone can use to make games if they want which you know that's debatable the actual like step-by-step tutorial series aspect of of hazel that's secondary i started the game engine series because i wanted to teach people how to make game engines but i also wanted to make a game engine first and foremost don't get me wrong that doesn't mean that i don't consider the educational aspect of what i'm doing important or that i don't care about it i definitely do but first and foremost there needs to be a game engine that i've made in order to teach how to make game engines and that is my primary goal the other interesting factor with that is the fact that like i mean the amount of complexity that would go into a 3d game engine and just the level of nicheness like i mean this series is already pretty niche but i mean if you consider trying to teach someone how to how to make a complex 3d renderer in the context of a 100 plus episode game engine series like the the amount of people i feel that will actually get to that point and will benefit from that it's just it just gets smaller and smaller and trying to do that on youtube like i definitely don't even think that youtube is a good platform for that this is just way too specific that's why i mentioned in my recent bloom video that i would be creating a general purpose 3d rendering course that won't be on youtube and won't apply specifically to the hazel codebase so those are kind of the two main reasons because i think the scope is just enormous and also because i want to spend more of my time actually making hazel and seeing what that can lead to what that can become rather than focusing on a step-by-step video tutorial series which probably isn't the best way to help people who are at that level anyway at the moment the hazel team that works on proper hazel the patreon version of hazel there's eight of us now these are mostly volunteers although some are on payroll but that should give you a bit of an idea as to the effort that goes into hazel it's definitely not just me patreon is what makes hazel possible in the first place not just hazel but hazel 2d and the entire game engine series and hopefully your support will contribute to converting some more of these volunteers to actually being on payroll so that we can achieve greater things lots of the technology from hazel will make its way back to hazel 2d because of course the entire engine is not all about rendering so not everything we develop in hazel is effectively close source and only accessible by patrons who help support the project okay so hopefully all of that makes sense if you have any questions about any of this please leave a comment below i'll we'll be happy to try and reply to as many of you as possible but let's move on to the planning portion of this video and we will discuss how we're going to make hazel 2d the rest of it okay so this morning i actually sat down and i wrote a list off the top of my head of every single game engine system that i could think of that we are going to be putting into hazel 2d it's right here in front of me as i said strap yourselves in this is going to take a very long time i'll try and be kind of quick this is more of an overview it's i'm not going to be too low level 2 implementation detailing it's just going to be specifically all of like the overview of everything that's going to go into this okay so let's begin with the renderer now the renderer which already exists to some extent right this renderer needs to be able to support 2d rendering now what do we mean by 2d rendering well first and foremost by 2d rendering i'm referring to the ability to basically render triangles or quads i mean most of the stuff that we render in 2d if you consider it as being two-dimensional we usually render it on a quad now as i mentioned hollow knight is kind of an inspiration for where this series is going so i'm going to be using it as an example from time to time this is just a random screenshot i pulled off of the internet so if we look at this frame here there are so many things going on but the main gist of it is that everything that we see here is basically a quad with a texture applied to it if you've been following along with the series you'll obviously understand this i'm not going to spend too much time on this but my point is that like pretty much everything that we see here really is a quad right i mean i don't know to what extent the background is separated from everything else but the other thing with hollow knight is that it is in fact made up of layers right so we have like this kind of main layer which is useless me drawing in 2d but we have this kind of foreground layer there might be some other things in the foreground particles are definitely floating around literally everywhere we have many background layers if you look at this from top down instead of from like the side like this then what you'll see is literally like layers like that right so it is in fact in 3d space this is our z kind of access right so that's what we're seeing over here but again everything is made up of these quads and so when we uh look at our render and we think about what a renderer needs to support in 2d it is just overwhelmingly it needs to be able to render textured quartz that's the most important thing now currently we are batching these together kind of on demand dynamically every frame into a large vertex buffer that is a pretty good way of doing it there are some issues with that we could look into using instance rendering we could you look into using like a geometry shader to generate quads although that's becoming more and more old-fashioned uh as time goes on maybe like the new mesh shader can be used for that uh you know gathering those vertices in compute potentially like there's a lot of different ways to think about rendering quads but for now we basically have this idea of a batch renderer um and that is that's going to get us like 90 of the way there basically and i don't think we'll run into performance issues anytime soon now that's all fine being able to render this stuff but what about being able to manage our textures a little bit better in the form of texture atlases right so a texture atlas or a sprite sheet we also i think have covered those kind of um those are basically ways to uh put more than one texture effectively into like a single texture file well i mean it's nothing to do with files really when you create a texture on the gpu instead of making it like 32 by 32 and then having like six of those you can effectively put that put all of those textures into a larger texture and then you know map them here so a good example actually is for like font rendering but of course you can use it for absolutely anything and if you look at a game like minecraft that's a great example because people have a lot of exposure to like the texture packs in minecraft and what they look like that sprite sheet there is a great example of a texture atlas because our gpu can really usually only deal with 32 texture units or texture slots at once meaning that if we want to render more than that amount of textures we need to split up our draw calls which interferes with that batch render anyway this isn't really a rendering tutorial but the idea is we need to have texture atlases now this isn't just used for like sprites or 2d graphics um another good example in 3d use is for shadow maps if you have like a point light with many different shadow maps like one for basically each each uh each face of your kind of cube map right a very common technique is to pile those into a single texture and in fact you can combine multiple point lights that are in your scene and put all of their depth maps into like a single texture that's also very common so this is definitely not like tech that's only used for 2d stuff but it's going to be very important for 2d rendering now moving on animation right so 2d animation of course um usually that's done by having sprite sheets so you create it in whatever software you want to create it in you could even create an animation of something in like after effects and export it as an image sequence if you want again usually they are in fact combined into sprite sheets to kind of save on that unless they're extremely high resolution um it's also possible to use back at ea i actually created like a sprite animation format that we used for our mobile engine which was for uh you know i guess higher quality kind of animations that spreadsheets would have been annoying to use for and that worked by delta encoding between frames so it's a little bit similar to like video codecs although not that complex and you basically had multiple frames of animation and there was various compression that happened on it but the key thing was uh only recording the pixels that have changed basically and then having like keyframes like you would in a um in like a video codec so that's also an option that's probably better if you have huge textures because that way you don't have to um you know have you can't have sprite sheets of 4k textures but usually you wouldn't really if it's that big you you really need to think of something else um usually these animations are quite small so they fit nicely into like a sprite sheet and everything's fine so i don't think we'll do anything fancy like that uh i think we'll be okay with sprite sheets for the most part for animation but we obviously want tools for that we'll get to like the editor portion of this a bit later as well this is strictly like what the renderer needs to support so yeah animation um the other thing is uh basically the ability to have custom shaders and materials right so in 3d we're obviously used to having a material for pretty much everything for pretty much every object in our game but for 2d since most things are just textures on quads we can kind of get away with not really um i guess using uh this whole wide variety of different materials and possibly even different shaders however you may still want to have custom shaders for things so so an example of the top of my head for a 2d game would be like in celeste um you can go underwater and then everything's kind of wavy you know and i don't i don't know how they did that but i don't think it's you know they made like some kind of character animation of it being all wavy right i don't think that's it's probably just a shader effect uh so doing stuff like that as an example that's something that would more or less require like a custom shader or at least some other maybe built-in engine material that would handle like a special case of rendering or something like that um i guess another example is even like because remember you can have layers and so if you have layers like i'm just i'm just uh picturing like you know frosted glass if you had frosted glass and there was stuff behind it which was obviously in the background kind of like the depth was greater then you'd have the parallaxing effect which means this will move with the camera and so therefore you might want to blur like this this might be like an additional path that goes on top of things that would in fact blur this area you know so stuff like that very kind of desirable if you get into the more advanced effects uh so i definitely want to be able to support that now finally um i hope i haven't missed anything major but basically post processing effects so post effects so what i mean by that is basically things like bloom things like color grading color grading there's many more things that you might want um but the point is you know those there's no reason why those have to not exist in 2d they do exist in a lot of 2d games and uh i guess if you're making like a really nice polish 2d game i mean you can even have like auto exposure for different rooms and stuff like that hdr rendering all that stuff we do that anyway i think we're doing hdr rendering it doesn't really matter it's not not a big change but um you know that kind of stuff is also really important if you are kind of shooting towards like a higher fidelity uh i guess 2d game so that's also necessary that is pretty much where i see the renderer and again i think we've got the first two more or less implemented so it's really more about like you know animation and then this stuff which custom shaders and post processing can come later animation is pretty important um we'll probably focus that sometime soon all right that's the renderer that's part one now the next thing that i want to talk about is scripting because in my opinion this is probably uh one of the most important things um in in actually making a game now first and foremost actually with all this stuff i just want to mention that this is in no particular order and this is not this has nothing to do with the order that we're going to be progressing in this is just everything that needs to be done basically right and i will be organizing this into like a trello board or some kind of online medium so that you can actually look at it and you can also track the progress of this over time and i will probably even start tying it to commits and to branches and stuff as that stuff goes in so scripting now um scripting is a way for us to basically create and define all of the behavior for what our what actually happens in our game during runtime right so um there's a few different ways to do that um the way that i've kind of chosen for hazel is c sharp and there are a few reasons for that so first of all c sharp is an extremely capable programming language it's also very fast right um i mean visual studio is written in c sharp uh frostbite like the frostbite editor frosted that is written in c sharp and it uses the sql space engine uh like c sharp is is a very capable programming language obviously unity uses c-sharp as well for scripting but i'm just talking about the language overall i think it's a really good language i've had a lot of experience with it and i really like it i think it's great and this is my engine so lol however there are there are other languages you could consider um the thing with lua is that like lu is also very popular in the games industry less so these days in the past it used to be more but the thing is like i personally like for something like space invaders or like i don't know snake small kind of arcade games it was totally fine but when you start thinking about a large game that maybe could be worked on by a team for like years i just don't see myself using lower for that so because of that we use um we use c sharp on in real hazel land and i think that it's also going to be perfect to integrate obviously into hazel 2d because why wouldn't it be now visual scripting is also a possibility um i won't talk about that now but that's also obviously a system that can be used it's not bad at all a lot of people are afraid of that i'm an engineer though so it's hard for me to justify using a visual scripting system i feel more comfortable with code i feel like i can get more done i like using the keyboard like it's it's just it's just fits me a little bit better but the thing with c sharp and what actually constitutes behavior and how you define behavior in a game engine like this stuff is mostly tied directly to the ecs the entity component system i'm not even going to be talking about like ecs stuff we've already got that and we're just going to build more and more components for basically everything we need as time goes on it's not something that i think we need to really talk about but the thing with c sharp again is that really what you're doing for the most part is interacting with the ecs when you interact with the game engine right so what i mean by that is i mean think of a think of a c-sharp script right you would uh if you wanted to you know respond to the user input and then move an entity you would retrieve the transform component of the entity uh and you know in the onupdate function if input is keypressed blah blah blah then change that translation of the transform component right that's how you move stuff or maybe if you have physics you'll apply a linear impulse to something again you get the rigid body component and you apply the impulse so a lot of this stuff i mean you also instantiate entities and prefabs uh delete entities like that kind of stuff so that's all ecs stuff right i mean obviously you can have an entire meta game an entire like program running as part of your c-sharp scripts that manages all these other systems you could write a multi-threaded ai model or something like that that will determine these things like there's a lot of like stuff that gets built on top of that but at the end when you're actually interfacing with the game engine you are mostly not fully but mostly concerned with the ecs so that's the kind of stuff that needs to be able to be readily accessible by c-sharp now um the other thing is reflection so we want to be able to basically um look at the c-sharp code right have our engine read the c-sharp code or whatever system whatever runtime we're using the compile c sharp code and see what has been exposed to the editor so what i'm talking about is basically if we define a public float or i don't know you don't have to do it this way you can have a special attribute for it called like speed um or whatever right that's awful uh then what i would expect to happen there is that whatever entity that script is attached to in like the editor properties for that script you'd see oh look here's a speed variable and it's modifiable uh over here right so the idea behind that is i mean for the longest time obviously there's been a lot of different disciplines that go into making games right you have engineers but then you also have artists designers that kind of stuff so i mean c-sharp i would argue is pretty simple it's not c plus plus right that's why we don't really want to write our code natively not just because it becomes less about data like it's not like a separate module we can load and it's not like part of the game assets the same way if it's actually native code although of course it could be if it's like a dll but anyway we're not going to get into that the point is that c-sharp is pretty accessible by most people it's not that difficult to learn i think at least in a scripting sense of course language can be complex but if you use what's required for scripting i don't think it's that difficult however providing tools for artists and designers to be able to easily manipulate things like again if you have this complex script uh but then you expose certain parameters that could be used by artists or by designers very easily of course it's easier for them to click an entity and then modify something like this i mean it's even easier for engineers let's be honest but like the point is this stuff is really important because without it like it would be way harder to be able to edit things i mean back in the day again if you you've had to get an engineer for everything if you didn't know how to write code right um it's not like you're going to be in c plus plus or c land dealing with memory allocations and like pointers and references and all of that stuff so a reflection system is very important um and it also means that these values can be serialized right and they can be part of your kind of editor data or your scene entity data whatever um means if if you want to change the speed from five to six you don't need to recompile the entire c-sharp dll if you're on windows you can just change the data that gets sent to that variable at runtime so it's pretty powerful and it's definitely very um useful um you know stuff like being able to like manage the life cycle of the c-sharp runtime so being able to unload and reload assemblies so in hazel in proper hazel when you hit play it will reload the dll usually unless you disable that option so if you're kind of compiling you can compile in visual studio then you can just hit play and it will load the latest script on demand now you can see it's pretty quick if you've seen devlogs it doesn't really take any time at all so it is rather fast but being able to kind of i'll just say loading which again might not make um [Music] that much sense but just know that i'm talking about specifically managing that life cycle loading life um and then finally uh as i mentioned like some kind of visual scripting potentially could be on the tables that's a really big stretch goal um so let's move on from scripting now the next thing we have is physics who doesn't love physics so this is also where the 2d nature comes in because basically for physics as you can imagine we're not going to be using like nvidia physx or any kind of 3d physics engine we're going to use something called box 2d which i have mentioned in the past this is a pretty good 2d physics engine now 2d physics engines in general are not the hardest things in the world to write like it's actually quite interesting if you delve into like the mathematics behind the physics and you'll probably see like physics engines are always scary to people i don't think they're the scariest things in the world unless you know nothing about physics or anything um but obviously using a library like box 2d i think is much is a much smarter play i'm not going to pretend to know how to write an excellent physics library so um that's basically what we'll be uh kind of using and so that will be able to fulfill pretty much all of our physics needs now by physics i'm also referring to collision right so just being able to detect collision even so that's something that box 2d can obviously provide us um it needs to be integrated with scripting meaning like not only can i like retrieve like and and with the ecs so not only can i like retrieve a rigidbody component apply an impulse to it and it will actually shoot like the physics entity somewhere right uh not only that but i also need to be able to actually like receive callbacks when entities or triggers have like collided right so if there is a collision maybe a particular entity wants to know about it so callbacks as well um i guess i'll write that down but that's important um so that's the that's kind of that part of it uh we might also potentially have physics materials it's been a while like box 2d also exists in proper hazel so we have both 2d and 3d physics and videophysx is what we use for 3d physics i don't remember if we support like physics materials for box 2d um but we obviously want parameters to go on to certain entities that are like physics bodies so uh restitution you know bouncing is like stuff like that like how how much something weighs like the mass uh that also needs to be defined somehow so that's kind of editor i guess ecs integration um and then you know joins constraints all of that kind of stuff basically everything that box 2d supports we want to be able to expose and and have people um kind of uh manipulate those parameters to achieve whatever physics stuff they're trying to achieve so next up we have a particle system and also like gravity you know maybe you want to make a game in space and you want stuff to float but again that's that's just that's just a way of exposing kind of box 3d parameters into hazel so particle systems oh man okay so 2d particle systems again slightly easier than 3d particle systems but uh you know the main thing here is probably having some kind of like vfx graph so this is a node-based editor which we can use to define the flow of particles and uh you know what maybe triggers them how they react to things i mean it doesn't have to be like a node based system it can just be a set of parameters but then you lose a bit of like you lose a dimension basically like the whole over time thing but maybe even having if you feel really exciting you could have curve editors so you could have like color over time and you could draw that um you know there's so much stuff to do with like there is so much stuff you could do with particles uh but you know being able to support textures animations all that kind of uh stuff that you would expect to have there um animations you know you could maybe attach lights or things to them which would affect certain shaders uh you know being able to collide with things um so usually collision is done uh i guess separately to like the physics system although it can depend and then finally you can move on to compute so if you're really cool you can um move a lot of your particle kind of simulation uh code onto the gpu and do it kind of asynchronously on the in like in the compute queue in compute shaders which is usually pretty nice but anyway um so particle system again very important if we go back to hollow knight these things floating around here they float they're not static they are all particles right so it can do a lot to kind of increase the fidelity of a game i guess it's not necessarily something that you just need for explosions or like rocket launches or smoke just having particles floating around in your world is huge um it does so much for the ambiance so yeah super important now i have a little section here called editor but the real thing is no um because i'm not going to talk about everything that's going to go into the editor because that's just wild but this is more for some things that you may not have considered such as an undo redo system um the proper hazel doesn't even have this yet right i've had it on my to-do list for ages but i just can't bring myself to do it because it's gonna be a lot of work but basically the editor needs to be very much aware of every change that ever happens to it and in this case how to reverse it right um that's very important and that requires a little bit more um you know thinking about how you write code rather than just writing the bare minimum code to achieve the desired effect right so um that is something that is best done early on we might actually consider doing this pretty soon for the game engine series but basically yeah that whole undo redo thing um super important uh but the i think most of it you you really have to like just look at it as a as a collection of tools right like you know you might in your toolbox you might have a hammer a drill a screwdriver all of that stuff that's what an editor is it's all these different panels that do different things and they manipulate different data they come together into this big tool um called the editor right um or we call it hazelnut so uh that's kind of what it is again even if we go back all the way to um you know what do we start with uh this kind of stuff textual stuff right if you import a texture that's an atlas how do you define the cells right that's the tool um so there's all these different things that that exist um you know as far as the editor goes and it's it's hard to even start talking about all the systems everything that i've mentioned so far that needs a ui well that's going to be that's going to be editor stuff speaking of ui this is a good transition let's go down here user interface also something that we haven't talked about um i actually had this written down a bit later but we'll talk about it now so the main thing with ui is text rendering right so you want to be able to render text this is something we haven't touched at all um text rendering is uh can be fairly simple can be fairly complex you know choose your poison um it depends on how you want to do it we want to do it well so we probably want to use signed distance fields we don't want to just simply rasterize something from free type into a texture atlas and it's good to go that is uh is fine but it's not going to get you the nice crisp text that you probably want so we'll probably look at doing it you know using sdfs there's a few good libraries online that can kind of generate texture atlases even for us that we can then use as part of that um because there's a lot more to ui rendering than text of course uh layouts right so a layout system i'll say this um i haven't really thought about how exactly i want to do this in hazel because there are also libraries that let you like for example define layouts in css and then it will do stuff to it but like a good example is um i mean if we look at hollow knight this ui up here right so let's but that's a good example of ui that's something we call a hud heads-up display that's just overlaid on our game as we play the game there's a few things going on here right there's actually a lot of things going on here first of all the alignment of this we want it to be in the top left corner no matter what resolution we're playing at right so i mean it could be like the screen could be um you know a 4 3 display for some reason it could be an 18 by 9 like ultra wide monitor right and we still want it to be here right we want stuff that we've positioned in the middle to be in the middle that's difficult you guys have done css know how difficult it is to position something in the middle and it's probably easier to do like in c plus plus programmatically but um my point is there's a lot of layout stuff that needs to be considered here um but also it's not just the layout of like what stuff gets aligned to which by the way could be you know set at like 50 pixels or it could be five percent right like you can you should be able to define these things and change them but then um if we look at hollow knight again there's a lot more stuff going on here like this uh kind of soul indicator those of you who have played holiday know what i'm talking about otherwise this might be um not that good you should play the game though it's really i'm still playing it i've just finished crystal peak um it's it's brutal but it's an excellent game and it's just got such a good vibe to it anyway so this is like the soul indicator this kind of moves right so it's animated it's it's also a this level it also depends on how much soul you have at the moment these are basically your lives and these also have to change um they go empty there are blue ones that you can get right like it's it's very much dynamic and it changes this is the amount of geo you have it's like a currency um that also is some text rendering that is positioned in a in a particular location and you need to be able to obviously control that value through your metagame through c sharp so um holo knight is made in unity by the way so uh it's a good example of how to lay things out if you're used to unity um but anyway uh the point is that a lot goes into this little thing but then we're not just talking about like the hud which is what that is uh there's a lot more to ui i mean not just hard elements like that stuff but we also want to obviously support menus and menu screens all right so like the pause menu when the pause menu happens it happens in the middle i don't know i think hollow knight does is i think it it blurs everything out in the background right so we need to be able to have a full screen kind of blur that's usually just a ui kind of overlay that blurs whatever's behind it right because ui is usually rendered last so you know stuff like that um menu screen yeah being able to have a main menu that we can go to options menu with like a slider for like the audio level you know all of that ui has to be there uh being able to transition between screens animations you know ui animations man oh you know there's so much stuff um ui is very very complicated people who think that ui is easy i would vouch that it is almost as complicated as 3d rendering there's so much stuff that goes in it yeah and an um an inventory screen right so being able to have an inventory uh where you can like um you know have different items and go through that like there's a lot of stuff i know when i i don't even want to talk about it's making me upset so moving on um so we touched on the editor before i went into this user interface but also i guess the other important thing is the runtime right so we want to be able to um this is an epic video we want to be able to uh basically hit play to play the game right seems uh simple but this play button is like a lot of a lot of stuff has to happen there and obviously we need to be able to support it so um yeah being able to basically play right but also have a standalone player so play in editor but then also stand-alone right this is very important because if we can't play the game what are we doing um we need to be able to play the game as a standalone thing now realistically like if we do break down what happens there usually it will just load a scene so if you have a menu upload the menu scene if you have a if you just jump straight into the game you load the game scene um and you basically play it by starting up like the physics world and then just running the c script so they have oncreate functions then they have on update functions you just basically run those um and that is your game right so it's not that difficult um in terms of like uh you know what you need to do you just need to hit play on the physics world basically and then hit play um hit call the right c sharp functions obviously there's other engine systems like audio that need to also be potentially initiated and initialized right but that's kind of for the most part what we expect from a runtime now this isn't about distribution we'll get to that later um and about like actually shipping the game um okay a little little blob here which i might actually put here serialization right so now when i say serialization i'm not talking about saving our level this has nothing to do with the editor i'm talking about runtime serialization so what this is is i want to be able to save my game right i don't want the player to lose their progress and start from scratch every time they launch my game that's obviously very weird uh for certain games um i want to be able to have a save game right so that needs to be like the engine usually will provide a way to do that and uh possibly even by using c-sharp's reflection system um and then that will actually serialize something on disk like a file or it'll go up into the cloud right so say games are important but even for something simple like you want to be able to have like a high score right even if you make space invaders i want to be able to um serialize my high score so the next time i launch the game i can see what it is and i can see if i can beat it so uh this can all be done technically speaking this can be done outside of the game engine right if you have um if you're using c sharp c sharp has a library you you can write files there's no reason why you can't so uh that stuff can be done by that but usually an engine will provide its way of doing this and that can be a little bit more kind of standardized i guess so that's serialization pretty quick um the other thing is i don't know if i should even mention this but cinematics right so cut scenes right i want to be able to and obviously nothing to do with 3d but like i want to be able to um you know i've got my player here i want to just take the control away from the player and maybe pan this camera over here to show them something um maybe someone comes there's a bit of dialogue and subtitles and maybe i want this to be like two three five aspect ratio because it's all cinematic but right like there's there's a lot of like to make this stuff happen you need to basically create like a a movie maker or some kind of like after effects style tool like you you want to have you know various layers that are entities you want to have a timeline you want to be able to set keyframes there's a lot of stuff i don't know if we'll do this like we want to i want to but we'll definitely do this for proper hazel but um just another thing to do man just another thing to do uh we've done ui uh let's talk about audio so audio is also immensely important audio is something people forget about but more or less people don't know how complicated audio can be can be very complicated at the very base right we want to be able to play back audio files so playback right i have a wav file probably packaged into like a og or some other kind of file format but we have um we have a wav file for example i want to play it we need to be able to trigger audio events um usually this will be set up and they'll be like events actually set up in your scene or in your project and then you can trigger those and those mapped to assets and those assets which are those wav files they can have a bunch of parameters on them such as how loud they are you know if they've got any filters or effects on them that's the other thing um another thing that happens in celeste as an example is when you do go underwater the sound changes [Music] so as the music is playing and you're under water it just gets all kind of muffled like it's the high frequency just all cut out it's like a low-pass filter um you know that's something that you want to be able to do dynamically right but also stuff like reverb delay you know maybe i don't know about eq and stuff but um you know you can having those kind of effects very i think that i i think it's very important i think sounds very important um you know you could do like mixing um mixing which means basically having different audio channels that you can control the volume of separately uh you could have audio busses where you can send like so you have like a reverb bus and everything lots of stuff you could do um you know being able to stream in those assets so when you're playback you want to be able to stream them in maybe you have a 10 minute ambient sound file you don't want to decode that whole thing and load it into ram at once you might want to just read it off disk buffer it and you know play what you get um yeah i mean you could do a lot of you could do a lot like having a node edit of sound actually our um sound guy on on the hazel team j he has done an amazing job with audio and hazel and he's i mean this is what he's currently working on he's working on this like node editor for hazel's audio system so that's a great uh that's a great look at just how far you can push this stuff you can push all of this extremely far and that's kind of the problem but anyway moving on uh so i'll talk about the asset system a little bit right so an asset system for a game engine like the most important thing of an asset system um we're not going to talk about like um like a virtual file system and other stuff but like honestly it's just to be able to load and unload assets as they're required right so i want to be able to not necessarily like just because i reference an asset or just because i mention an asset i might not want to load the whole thing immediately right because obviously a game can have many different levels especially if you're talking about a game like uh hollow knight or a big 2d game this game's huge right there's so many different areas if and and you have all these textures you have all these like rather high quality textures right these are not things that um you can just keep all in memory or in your gpu memory all the time it's just not gonna work out so you need to have a system to load and unload them as they're being used um you know streaming assets in and memory mapping so what that means is the streaming memory map so what that means is basically um instead of like if you have a a 500 megabyte texture that you want to get onto the gpu hypothetically uh instead of loading in that whole like 500 megabyte texture to cpu ram and then loading it to gpu right gpu cpu you can instead memory map it so you have like a rolling window you roll through it you buffer it and then that way you never use 500 megabytes of cpu ram and you can get into the gpu faster because you don't really need it to stick around in the cpu so memory mapping is very important as well um for like you know something a bit more serious and it will massively cut down load times as well because you don't need to be necessarily loading that whole file again if it is a format that does require the whole file to be loaded that usually would never exist in a runtime for the editor maybe but again i'm more thinking about the runtime here um yeah packaging so like maybe creating a binary blob or blobs we'll talk about packaging a little bit later so binary blob but yeah that also kind of needs to exist um another thing that i wrote down was edit a hot reloading so this is kind of nice very nice system to have very easy to set up basically what that means is that when an asset changes the like a windows file watcher for example will pick that up it'll be aware that hey a file has changed on disk and you can automatically initiate like a reload from that so an example is i'm editing a png file in photoshop i hit control s magically my engine has the updated texture right um because it's got a file washer it's where it's changed and it's re reloaded the asset you might want to be able to turn that off as well but it's uh it's definitely very useful to have and iteration time just go through the roof with that um all right my next step is platform support so with this i'm not just talking about like what we need to do right to have support for like windows mac and linux right i would like to support all of these platforms at a minimum eventually although at the moment we are focusing on windows um that this is all true being able to support all this stuff but um you also need to be able to support different versions of windows so different diff win there are a lot of different versions of windows they have different run times they have different like c plus plus well runtime that's what i'm what i'm talking about you need to be able to support all of this and be sure that the stuff that you're using is widely is as widely available as possible or at least provide alternative paths maybe compile different binaries um for this this falls a little bit into into actual distribution but that's also important right be aware of that but also different hardware so like different gpus so um do you support nvidia uh what about amd what about intel these have these the drivers that kind of you know you use here have a big impact potentially um you know hazel for the longest time didn't like proper hazel didn't run on amd gpus until i set up an amd computer behind me with a 6800 xt where i could actually develop for that right um and that was partially due to me just not like i had some mistakes there that the nvidia driver was happy with um but technically the vulcan specification was like no um but also there were just some things that worked differently that i didn't expect so um this is yeah it's important to actually make sure that you do support different platforms and in this section i've also put things like controllers and game pads right so these are like i guess human interface devices right like heads um these are more like uh actual uh you know hardware that you would use for input but they're also very important like um i i couldn't imagine playing hollow knight on a keyboard i've actually also got the game on steam and i played it with the keyboard a little bit i think i'd probably plug it in controller to play that game because certain games just work really well platform is a great you know there's no need for precise first person shooter aiming with the mouse controllers are great and uh you definitely want to support them especially if you know you want to ship maybe on it on the nintendo switch and it's not just about windows mac and linux so yeah you also need to be kind of aware of that and i've put that in here is anyone tired yet i am um networking networking so networking is an interesting thing because i don't think that we're like we're not going to support multiplayer as part of this series as part of the game engine series um proper hazel has some plans for that but we're not going to support multiplayer as part of this series probably almost overwhelmingly it's just out of scope right this is just too much but um by networking i'm not just referring to like real time or turn-based multiplayer i'm talking about just being able to interface with the network right so being able to download files like right like being able to download assets maybe updating the game even something as simple as having a news screen on the homepage you open the game and then it's like news guess what update 1.4 is out or like you know just being able to communicate with the outside world networking right very important um pulling configuration files off the internet an example is uh back when i worked at ea we showed a game called near for speed no limits which was a mobile game that actually used to pull its tiering settings off of servers that we had so what that means is that basically we could we had like a database of phones like an iphone 6 this was back in the day um and we could set like what you know what shadow resolution should be used for that device what you know what a viewport scale should be used for that device um you know we could set all this stuff kind of remotely and the phone when it connected could download all those configuration settings that way we could tweak stuff after release it's a bit different with mobile i'm not sure what what how how difficult it is like on steam and stuff but you know especially with apple it can take a while to be able to push an update right and so that's why having your own updating system your own way to download assets and configuration files is definitely very important um you know if for nothing else in control of like uh of the content that you're actually displaying in your game you might want to do a special like christmas or halloween update or something right um and you might want to do something special for that basically so that's important um you could also fit in you know if it was mobile maybe ads but also like uh analytics telemetry we're not going to talk about that i don't think i want to put any of that into hazel at least not for the time being but that can be useful as well you can see how many people have crashed their game and why right you can send that back to a server um that's quite useful for diagnosing problems so diagnostics and stuff can be can be used there as well um all right let's talk about optimization briefly we're almost done you guys are enjoying like hopefully now it makes sense maybe while i'm like maybe let's not do 3d because yeah i hope this makes sense um optimization so i like doing this more towards the end because then i know what i'm doing and i'm not going to waste time optimizing stuff that then gets stripped or removed immediately right but uh the biggest change to um the biggest the biggest change and the biggest kind of thing i guess with optimization is multi threading right so making it making the engine multi-threaded at the moment hazel uh [Music] hazel um game engine hazel 2d i was like hey game engine series hazel 2d entirely runs on on a single thread right there is no threads for literally anything i as far as far as i'm aware i don't think so um [Music] this is uh definitely not optimal right because computers don't just have one core uh computers and most devices have a lot more than one core what this means is that we can take advantage of that and we can split our workload along different cores and the thing is i'm not just talking about like you know spinning up a thread uh to do some work temporarily like a job thread right like maybe from c sharp you want to do some ai simulation and you want that to be multi-threaded sure just use the c-sharp api i'm talking about specifically the engine core itself so a very popular model is to have a separate thread for example for rendering right a separate thread for like physics simulation separate thread for audio and that's actually mandatory but like you know spreading out the workloads a little bit so that you don't have to kind of bottleneck yourself by just having uh a single thread so um as i mentioned with the render thread that's a very popular model to do a lot of people think that that doesn't work with opengl for some reason because opengl is single threaded opengl has to be entirely has to entirely exist on one thread but that doesn't have to be the main thread right so you can have your main thread and then that can spin off a render thread whose entire job is just to process opengl commands which still have a considerable cpu cost and you can kind of offload that to a different core that's a very popular architecture for pretty much every game engine so that's an example of what we would do to kind of basically speed up hazel a lot um gpu offloading i also wrote down so gpu offloading again like i mean it depends what it is um a lot of things you can a lot of operations you can potentially move to the gpu uh if you have that it depends if your cpu or gpu bound we're not going to dive into that but that's just a possibility for optimization um the other thing is you do want to be aware of bottlenecks and slowdowns in your engine so you need some kind of profiling now we have some weird rubbish profiler i think in in hazel 2d at the moment hazel the proper hazel uses uh something called optic we'll probably be using that in hazel 2d as well i've actually like the video that i put out recently about diagnosing performance issues in hazel that was using optics if you want to take a look at that and see what it looks like then that's pretty recent video um but yeah so that's also something that um needs to be done for sure i think we've this is it man finally we are at the end and the end is basically packaging and distribution i'm just going to call this distribution uh too tired there we go distribution so how do we ship our game um there's a lot of stuff that potentially has to change for that right um so how do we distribute it that that's that's a question in and of itself um but uh the biggest change probably is the use of custom formats so why would you want custom file formats for all of our assets basically what i'm talking about so custom formats so there's a few reasons for this first of all protection right you don't want to just have all of your assets all of your art assets all of the intellectual property potential that you've built just be copyable right you also potentially don't want it to be changeable like you don't want someone to open your png file in photoshop draw something on it and then play a game that's weird right so protection is is a realist is a real thing that you might want um file size right so certain files can be quite large and you might want to compress them um so that's important as well as just speed right most file formats that we use today png jpeg that kind of stuff um they're not built for game engines so they can take a little bit of time to decode um also you may have known noticed hopefully that we use um you know for the editor side of things for the editor we use uh text-based file formats usually so our scenes are text-based they're in yaml a lot of our kind of files are because they're meant for like development use and you don't want to merge binary files together but for this you need binary files right so switching to binary file formats um and then trying to optimize for these things is very important so speaking of which um in terms of like speed and stuff compression so like things like lz4 you know mel's at ham zed lib i don't remember what else there is um like right there's a few others um uh the this is useful because you can compress files um i don't think i need to tell you that it'll make them smaller um and then based on you know what which which library you use basically you have trade-offs usually between file size and speed um but that's basically um important these are all obviously lossless compression libraries um but also like not just compression with this stuff but also gpu texture formats a lot of people are unaware of this but um gpu texture compression but like um you know the way that we use textures and the way that we've used textures and most people i think who are learning like rendering and stuff use textures is they take their png file or whatever they load it they get all the raw pixels um in rgba right which could be 32 bits each for each channel if it's like in float if it's an hdr or just you know one byte per channel that's four bytes per pixel and then they just just into vram right and there you go now the problem is that um if you've actually tried to ever make something substantial and then think about distributing it you might notice that you very quickly run out of gpu memory like very quickly especially if you're working um maybe on a 3d game that has cube maps and then they have mips and then they might be hdr all right i mean you can easily have textures that are like over half a gigabyte um that's not acceptable uh and again if we look at all of the stuff that we have here there's a lot right there are a lot of these rather large textures now again if you have a whole world of that and you want to keep your not just your file sizes down but vram down right then you need to use a gpu texture compression format um uh such as um i mean what are the big ones like astc um etc dxt5 off the top of my head there's there's others as well pvrtc i think is for power pc or whatever but um there's like these are these are all compression formats which are pretty cool because it means that you can compress your textures into this format and then you take this binary data that is compressed you don't decompress it when loading it you literally put it on into gpu vram compressed and then as it's sampled as it's used it really it like it deals with the format basically so um that stuff is is awesome it is lossy usually um a little bit it depends on which settings you use obviously but um this is very vital i think for this distribution um so uh yeah gpu test compression format is very important um i've written down platforms platform support i guess i covered that but yeah like um oh right what i meant is like you know if you're shipping on mobile you might want to actually support the platform meaning like um push notifications which might use the os api um if you're shipping on steam there's like steamworks and there's like a few steam has its own apis for a lot of things like steam achievements for example you might want to integrate with that so i'll say platform support oh yeah this is a big one that i don't know why i put this into distribution because you should probably be thinking about this before that but localization who doesn't like some localization i don't know if it's spelled with a z usually but i'm australian so localization with an asset is i should have spelt a lot of things within it with an s but i didn't for you so um but anyway localization so um what this means is uh basically supporting other languages right um not just languages but like localization usually refers to supporting other languages so again if you have a main menu instead of having like play um and then all the other kind of options you might want to translate that into japanese or like russian or german or any other language right so you need support for basically like a database of strings right so strings are very important in general for an engine i didn't put this in because that's boring but i didn't didn't put in things like actually a big one in optimization would have been memory meaning be aware of the memory you're allocating maybe have certain like ring buffers or like stack allocators frame allocators that for memory that lasts just one frame has a lifetime of one frame you know there's a lot of stuff that you might want to do with that but anyway localization yeah so you have this entire kind of string database where um you basically instead of having a string ever in your code base you have a key or you have you request some kind of like id of a string and then you get back whichever one you need to based on the language settings so that's important to to have right but um also this can have deeper kind of implications because like i mean not only do you have to make sure that all your fonts support the right glyphs if you are dealing with something like japanese or chinese or i mean even languages like russian and german like you know have german has this like kind of it's double s is what they write a lot of times these days for some reason i don't know i went to school in germany so i know a bit i also speak russian russian has a lot of stuff i mean umlauts and german as well but then you have russian umlauts you have um what's a russian character that doesn't exist anywhere else bear like i know i thought of that one but like there's a lot of different um you know glyphs uh that you might have to have it's not just for like asian languages um uh a lot of languages obviously have that and then also um certain languages like hebrew and arabic you know they read right to left so you need to be sure that your alignment is correct and that you're rendering glyphs in the right order not in this order because you only are aware of the language you speak so there's a lot of stuff that can happen with localization but i think that localization is also i mean i don't think um localization is not just about languages and translations it's also about things like um you know maybe you have uh your latest kind of save games and they have a date associated with them at a date and a time so do you write the date like uh you know day month year right or do you write it in i think only america writes month to year for some reason um but like uh i picked something on ambi i was going to pick a value that was like yeah 15 because then that way you can tell but um you know which how do you write your date based on what region you're in because obviously if you've shipped your game to america and they're like eight eight that's the dumbest example possible the one case in which it works but anyway um you do something like that like hang on a minute it's not even october yet um it's uh well actually no in this case it's august man i'm really failing this but they might look at this and be like dude i did not play this game in october but you're like no you played it on the 10th of august so it doesn't make sense um so that's important 24 hour time i don't know if people uh i don't know if this is like necessarily a localization thing um i just like 24 hour time in general i usually have that on but i remember in school in germany um you know we usually wrote time is 24 hour time but i'm sure that people do use pm there it's not like the date where everyone writes the date in whatever you know region they exist exist in um and then another thing off the top of my head was like currency and like uh you know delimiters i guess for that so like if you have a million dollars right how do you write the separating thing and then you have like um zero cents here right so uh you know we kind of in i think probably most of like well america and like asia i guess as well i'm not 100 sure we write commas here and then a dot here right but then um you know european countries if they were using like euros or whatever um you would write dots for these instead of commas and then you have a comma for this kind of thing and then you'd put like i don't know like the euro symbol which also by the way goes on the end not at the start so there's all these kinds of uh localization things that you have to do um and then finally we have literally like stripping uh stripping like debug symbols so do not ship debug symbols and other kind of things you might want to do make sure you compile with actual full optimization maybe potentially check out a variety of different compilers to see what gives you the fastest code but like you know stripping uh symbols and just in general like production code so what this means and production code so what this means is um uh not just like um specifically debug kind of things that should only exist in debug builds or like you know like logging but um well not logging doesn't just exist in debug builds but i'm not just talking about that i'm talking about like any kind of production code that you might use so for example maybe you have like a cheat menu that you can pop up to like progress to a level to give yourself a million gold because obviously you're testing the game all of that should be stripped um anything there shouldn't be anything to do with the editor most likely right so the editor editor stuff should just not exist physically in the binary um it shouldn't be accessible you shouldn't be calling things that shouldn't be called um it can be a little bit difficult to separate uh you know your kind of production code meaning the code you use during the game's production and then finally what you actually distribute and ship to people so that's important usually code doesn't end up being fully stripped but at least make sure that you don't have debug symbols so that you can't so there's harder to reverse engineer everything um and uh you know stuff like debug menus um cheat menus uh all of that stuff as well as just unnecessary functions even that might be called for verification i mean assess and verify should be removed by this point anyway but you a lot of the time that's why c plus plus is so nice you can just pre-press the pre-process all of that out and even not compile certain files if you're building in distribution anyway how do i zoom out um this is it guys this is uh this is the plan um i i don't think i've missed anything what a long video i hope i hope this is this is fine i hope you guys made it this far um but like this is as far as i can tell this is the complete plan every not every single one of these things but most of these things um we'll have to make it into hazel 2d and into this game engine series project and into proper hazel as well so um yeah uh that is the state of things so anyway i hope you guys enjoy this video i won't keep you any longer um don't forget to leave a like button don't forget to hit the like button below please and um patreon.com best way to help support this it's a lot of work um it's only possible with your support and as i mentioned if you do want to help support the development of proper hazel get access to all that source code um then uh your support would be greatly appreciated it's the only reason why this is possible right um i would uh not be doing this more or less full time if it wasn't for you guys so i'm internally grateful for that and i'm also i'm excited to do all this stuff to be honest and um hopefully you guys are as well please leave your thoughts as well in the comment section below i'm really interested to hear uh what the response is going to be like to this i'm a little nervous but to be honest i feel better after this huge presentation because like it it honestly like to be blunt it honestly doesn't even matter what you guys think like i i can't do this if i'm gonna do this in 3d as well and if somehow magically this series is somehow still going on when all of this is done and we've actually shipped stuff and it's stable then maybe we can look at 3d because i'll run out of things to do with my life which seems unlikely but i hope that you understand at the moment especially for a game engine series not a 3d graphics programming series um this is where i'm at this is what i need to do this is the decision i need to make for myself and and i hope you guys are okay with that thank you all for watching love you all and i'll see you next time goodbye

Channel: The Cherno

Views: 41,057

Rating: 4.8968105 out of 5

Keywords: thecherno, thechernoproject, cherno, c++, programming, gamedev, game development, learn c++, c++ tutorial, game engine, how to make a game engine, game engine series, lets talk, hazel future

Id: 375c091_RN8

Length: 72min 16sec (4336 seconds)

Published: Thu Sep 02 2021