So since Unity fucked up.. Hey I'm ready for my own Engine

Totally agree with you but I'm like two years deep in building a 2D game engine and your point of "you know the code and don't have to lockup documentation" has turned into "why did I do that again and why is there no documentation" 😂

The world needs more engine programming videos, please turn this into a series.

for me the biggest advantage I get from building my own engine is that script reloading times take around 2ms to reload a 10 000 line csharp assembly at runtime. worth 12 months spent on the engine.

I'm making a game with my own engine, mostly doing it because it's more enjoyable. I don't love all the cruft that comes with the big engines and usually don't need it for most of my games. It's really nice to compile the whole game in like five seconds and just run it.

As someone who has built their own game engine (Look up Rank: Warmaster if you care), here is my take away from it: 1. It took many years (read 5) to develop a full 3D engine that handles space flight, RTS, 4X, etc. That means networking/multiplayer, planetary rendering, movement and collision w/ damage model, audio, configurable inputs (including HOTAS, but mouse and keyboard of course), IAUS AI system, VTFS (Volume Tiled Forward Shading), Cascade shadow maps, PBR, Bloom, UI system (ie. windowing, buttons, etc.), 3 scripting engines (one for frame by frame animations, one for campaigns, and one for generic use), etc. Just writing code for importing files/meshes and save/load games is it's own thing. The list goes on, which is more the point I'm trying to make. There is a LOT to be done. Admittedly the game I am building was built along side it, but this was full time. So best to understand your scope and how much time you can spend as well as how good are you really to do it? So if you have that kind of time and money to put those years in, and feel you can, go for it. Otherwise, it can be best to learn an existing engine. 2. C vs C++: Keep in mind that processors aren't getting any faster realistically, however they are adding MANY processors. Because of generally how C++ handles data versus how C handles data, from personal experience, taking your C source and multi-threading it is FAR FAR easier to get full use of the other threads than C++ is able to. ie. DOP vs OOP basically. I went from a single thread loading textures taking 70 second to 16 seconds on a quad core as an example (other things were happening during load, that liked the texture decoding not to be on the main thread). Terrain code bogging down the main thread? Throw it to a different CPU, etc. Movement and weapons fire slowing things down? Throw it on another thread, and it only takes a day to do it. So for me, the performance difference matters. But YMMV. If you can do it, great! More power to you! If you are just starting out, your life will move on and you'll likely never finish it. You'll learn a lot though. If you are a veteran coder and want your next big challenge, a game engine would certainly qualify. So my 2 cents on the matter. I hope I didn't hijack anything.

It was really nice to see a video that didn't just conclude with "Don't make your own engine". I think that for some people; it's just more fun to build something from the ground up and it made me sad that people who might get a real kick out of it were just being told "Don't"-before they even really tried. Good stuff :)

Just wanted to learn about game engines a bit and I have to say the quality of your video is top notch. It's not just the video production itself but I can't tell how many times people don't put chapters, timestamps or links in the description and people have to use the comments to fill the gaps. Not only that but you constantly put in easily screenshotable slides for further research and/or reading and I want to say I really appreciate that.

Great video, I agree with everything you said (also working on a custom engine). It's crazy how monstrous Unreal and Unity became and how long it takes to startup, compile scripts etc even for the simplest projects.

This video was so nice, straight to the point, informative and fun, I hope this is going to turn into a series

I've dabbled in engine programming since 2019, when I had my first experience with idTech 4, a.k.a. the Doom 3 engine. Yeah, I'm one of those weird types who avoid Unity and Unreal. I recall making this large terrain mesh in Blender, right? I put it in my level which was otherwise just one huge empty box (the engine is designed for indoor levels!), and since I compiled the engine in debug mode, it was tripping a certain assert in the physics code. "Ray length was greater than 4096" or something. I copied the message, Ctrl+F'ed it in Visual Studio, and it took me right to the engine's raycasting code, used by its built-in physics engine as well as places in the game code and other things. It was only then that I realised I was effectively reading something that's considered part of the engine code. It felt kind of surreal to be there, since I was used to the engine being nothing but a black box. Apparently, whoever designed the engine did not really expect areas to be wider than 4096 units. It was a rather arbitrary limitation, so I just removed it! Anyway, in very late 2019 I started to mess with simple post-processing shaders, later adding a shader to blend 3 different materials on a terrain mesh according to vertex colours, and overall learning a lot about how the engine kinda worked on the inside. In 2020 I made another little game, now with my slightly modified idTech 4. Then I decided to go down to idTech 3, because idTech 4 is from 2004 and I wanted a real 90s game engine to make a proper retro FPS. And there I learned. A LOT. I made several changes to the renderer, rolled my own particle system, a basic vegetation system, modified the animation system, added a dynamic music system (though nowadays this'd be a game feature in my book vs. an engine feature), and such. In late 2021, I decided to try writing one from scratch mainly because of the fact idTech is GPL-licenced, and I'd like something a tad more permissive. It went well for a year until I found myself experimenting with Godot in December 2022. Wonderful little engine, but still not my kinda idTech-style workflow. Nah nah. I'm still at it, but Godot's a great source of inspiration and excellent for some quick prototyping. So... what was the point of all I just wrote? I guess I just wanna say it's perfectly fine to go for a custom game engine if you have a good reason for it. Personally I was never ever happy with mainstream engines, because I'm just simply used to my idTech-style workflow and I see in it what other people don't. I'm just looking for a solution that fits my needs. And I mean it. I've tried Unigine, CryEngine, Unreal Engine, NeoAxis, Flax Engine and a few others, and I really just cannot get used to them.

I am extremely interested in seeing you create more engine-based videos or series. I would watch them all (probably multiple times)

The youtube channel Called The Cherno is focused almost entirely around building game engines.

nice vid!! motivated me to actually go through with making an engine. Id LOVE it if you were to make more vids about this topic

This video cured my depression

My idea is instead of one building an entire game engine, one should consider building a framework FROM a game that one has already made. In that way, code could still be customized and fixed to ones liking; its easier and it is actually: feeding two birds with one piece of bread ( that is, I said this analogy, instead of the violent saying/analogy of "it kills two birds with one stone"). Thus, in building a framework, one could build their game and have reusable code that could be adjusted and used over and over again for each game that one builds. Now, this is the way that I used to make my games back when I learned vanilla Java and JavaScript, because I enjoyed the coding process, the learning process, the bragging rights and other things mentioned in this video.

Finally, a fair video on this subject. My second job after a short one of game dev, was game engine programmer for somewhere around 2-3 years. It was the place where I learned tons of stuff. After that I went back to game dev and I felt like I was never learning at the same level. I had the same experience as you had with Unreal, I felt it was really slow for coding, it was killing my productivity because of big compile times, I was literally taking a break while it was compiling. On the other engine(it was not a small one - had most of the popular game engine functionalities, including fully functional editor), I was always opening the project directly with the debugger attached. Game Engine Programming is amazing, a lot of stuff is challenging, but highly rewarding. You can learn tons of programming and you can get in a lot of depth on a bunch of domains - if you want to learn physics you can do it, if you want to learn AI, you can do that too, if you want to design really big systems, guess what, you will have tons of chances.

I've been building a framework for roguelikes in Lua/love2d, and tbh I think Lua scales pretty damn well. I've had practically no issues with it so far. I agree, though, that it takes over your time. I've been at it for some 5 years, on and off, and it's still far from ready, and I've burned myself out several times, and... the games I originally wanted to make, well, they're still just prototypes, because they ended up becoming just guinea pigs for testing my framework's features -- which by the way are constantly changing drastically because I keep experimenting different ideas of how to do things to satisfy my personal demands, which further delays the ETA. That said, it's been quite a ride, and I've been enjoying it. It started, by the way, not because I wanted to make a framework, but because I wanted my own rendering code, and to abstract quite some boilerplate. But then I kept adding to it.

This was hugely helpful, would love a series of those

The most comprehensive videos that point you in the right direction I have seen!

I will be glad to see new videos on this topic!

You had more to say than I've grown to expect from these kinds of videos. You're a standout - subbed. I will be watching. :o

I think this is one of the best and most easily-digestible videos on game engines out there. Very cool! Definitely agree with a lot of points here like game engines taking a ton of time, but on the same token, damn is it fun and cool when something you've made actually works. And wins you brownie points with other devs too ;) Thanks for the video!

Pls make more videos about game engine! Making a game engine is something I never imagined I will have to do but it seems to be a good idea if I want to learn about making games.

I loved this video! Straight to the point and great tips for starting out! When I started out a few years back I tried lwjgl and made everything based off of the fact that I thought I knew enough java and linear algebra. I was kinda wrong, but it was a great foundation, later I tried again with lwjgl but followed learnopengl as an example, and kinda documented my process, which helped. But as some might say, third time's the charm, and the best implementation with a complete documentation and ecs implemented was done in C++. I'm still bummed out by the fact that how much you have to implement yourself when doing things like this, but it's mainly the process what's fun for me. Also, knowing the ins and outs of a basic rendering pipeline allowed me to be much more efficient at using Unity for example, making smaller projects getting done pretty fast. What I would've liked if you also included in the video that the things you talked about were only about rendering. Networking, physics, UI, etc. are a whole another topic, and (unless you use premade things like dear imgui and bullet) they're pretty hard to do! Dropped a sub for sure!

great video, earned a sub for sure. the topics you want to cover are exactly what id like to see, managing of large projects is something id very much like to know how to do :D

You can do most C89 code in C++, but as you move into C99, C11 and C17 things becomes more interesting.

I subbed so I can catch when you start the engine video series, so... kinda have to do it now 😁 Really, though, this was a very informative video and would totally eat up more information on the topic.

This was crisp! Keep it up man!

I've got a 2D engine I built over years expanding and improving all the while. I made it cause I didn't like any other engine I tried and I wanted the experience of making my own. At this point it supports open world 2D tile based games and 2D tile based level based games.

As someone who has been working on an open source game engine for >10 years I have to say this whole video is spot on. It wonderfully sums up everything I would personally convey to someone about game engine development.

I absolutely adored all the images. Outstanding video and content!

Nice work PJ, was a very entertaining and informative video :)

would love to see follow up videos on this topic!

Good to mention as well is WebGPU which is a standard API for graphics. It can run on OpenGL, Vulkan, Metal, etc. depending on the platform

Great video and explanations, thank you!

That thing about trying things differently and then understanding why the reasoning behind the convention hit home.

Honestly, I have been toying with the idea of learning to use LibGDX for java since I had recently had a object oriented programming class myself which really helped me get started with java.

Another great set of knowledge that will be essential for a task like creating a game engine from scratch would be learning OO Design Patterns. If you don't know what these are, I recommend reading Gang Of Four Design Patterns. Took a software subsystems class in college, and it's been the most useful course so far.

This is a good video. Only thing that I'd like to add is absolutely do not underestimate the time it takes to develop a game engine. Chances are, if the game you want to make is not a simple 2d platformer or a simple rpg with a tilemap or something, the most likely outcome is that your project will fail. The only case I heard where someone could deliver a 3d game with a custom engine was a guy who spent 3 years of his college course studying that + 5 years working only on that subject, until he made a simple simulation game. And still, it was little more than something that displayed Blender 3d models after they were converted to his custom format. Currently I am doing an editor for fractal flames, much simpler than a game engine, and in the start it was complete hell. It was like fighting a hydra, every head cut created three more to kill. It took a long time to get used to C++ features like template metaprogramming, and I had to write some small libraries for XML serialization and OpenCL execution. Setting up the build and dependencies and getting the IDE to correctly index all the code to get intellisense was no easy task either. After lots of rewrites, I could implement something that read a fractal from the file and rendered it offscreen to an image with the quality of available apps in less than 2000 lines of code, and I felt really proud of myself. Even though it's better now, I expect to change a lot of the code once I implement the UI, and btw only adding the ui library dependency until it built a hello world window took me 4 hours. Absolutely do not underestimate the complexity of this task, it can kill your project!

Thank you for this. Would love to see a series on it. One of the games I was working on(Will wait a LONG TIME before continuing) has a scope that has gotten out of hand. Basically: I need a custom game engine/pseudoOS for running most of it, a custom(unlockable) programming language, and a pseudo-game engine that works with that language. For now, I'm gonna keep focusing on Unity. As all the others(until the ones incorporating this one) only need Unity. But, I'm trying to understand exactly what I would need. Just to keep the gears turning.

poggers engine/build tools/tips&tricks series would be cool

Bro this is awesome!!!

Id definitely love to try and make a game from ground up to have some "fun" with all the technicalities and math, but for now I just really want to put out a few games at least. Generally things are easier learnt from finish to start, so making an engine should be easier done once I've learned how at least one works.

I was thinking about this and I found this video on my recommended, Google’s data collection is insane

So I'm in a school that focuses on programming and two or three times a year we have "projects". They basically give you 30 days to build and present a game on a specific theme. We do that in raw c++. No engines, nothing. Just graphics libraries and thousands of lines of code. The thing is I didn't know it was considered an engine. Good to know

Really good Video 😀. I am also starting to build my own engine. I would really like to see more videos about game engine programming. I would also like to know how you started. Have you watched The Cherno or how did you start game engine programming?

loved this video...there are too many discouraging videos on this topic...i love creating my "simple" game engine, and because of it, i got 2 work opportunities so far, got way more confident as a programmer as well...in general, there wont be many workplaces that will develop something that rivals the complexity of, even if simple, game engine (not counting fang)...you basically insure your future...good luck to everyone, and dont let videos that catastrophize steer you away from your passion!

Thanks a lot, very clear explanation, good job with the video

Thanks for this. Im thinking about using javascript to brush up and get better with the language. This is very helpful. Thinking about using typescript. Would it be ok of i use typescript? Do you have any recommendation. Thanks again for this video.

Great video! Agree with all the things you said. One thing to keep in mind about OpenGL vs Vulkan though (from my understanding at least): The OpenGL standard is no longer being developed, and it has being deprecated by Apple. It is still supported though (even by Apple), and vendor implementations still seem to be updated.

Another option for getting rendering done across multiple platforms is to use a cross platform rendering abstraction APIs something like WGPU or BGFX or Vulkan (there are implementations on top of Metal and DirectX12) so you do not need to rewrite the rendering code for each platform and just let the library delegate the job to the appropriate underlying rendering API.

2:44 with the robot scene cracked me up haha

I've made a lots of small engine to make rpgs and plateformers in pygame mainly. Here's a general guideline to make a 2D game engine if you use a basic game framework (like MonoGame, SDL, etc) * start creating a game_context class where you can store all you basic methods like : * draw stuff on the screen * load images * handle camera * draw text etc.. * create a game_object class that handles tags, properties and erased objects * create a Scene system that contain and update objects : * don't forget to add z_sort property to your objects so the scene render / update them in order (usefull to make multi-layer games) * create general purpose objects such as : * Tilemaps * Level Patterns * Physics Entities * Animated Objects * improve your objects * add more complex features such as : * slopes physics * zoom * shaders (glsl) and there is you engine ;) pls pin me

Cool video. I am making engine in C. I got 2 renderers done using OpenGL ES 3.3. One for 2D and other is pixel renderer that mimics how Atari renders. Goal for engine is to be bunch of single library files (c, no header files) that each file has 1 job to do.

Huge video, thank you so much!

>make my own cpu >make my own language in it >make my own engine with it >make my game with it >die as a 84yo man who made a pingpong video game

Excellent content - I'm actually making an engine in python/openGL - lemme tell ya, the typing thing hit hard at some point, mainly actually, while implementing math. Otherwise, it's a pretty comfortable (and performant) ride thus far.

I'm currently learning the Vulkan API and its really a lot of work to setup and stil no Triangle in sight...

Me: "I would like to try making a game engine once, seems fun!" UKposts: "Well, do I have the perfect video for you."

Great commitment to putting but pics whenever you say but

One point I definitely do not agree on is "to not make an engine if you are building a game". The problem with this is we will be left with engine developers who have no idea what someone developing a game wants out of an engine. Sure, using commercial engines give you the jumpstart on your project and you feel you saved time, but if you are making anything sophisticated, you keep grappling with engine issues later down the line, which completely offsets the time you saved by using an engine (in my experience, this is more frustrating since you are left to the whims of someone else's decision making).

for a game i’d like to make someday i ive considered making a custom engine, tho more likely i’ll just make a bunch of custom stuff for godot and use that. but mostly because of the sheer scale i want to achieve, well past 64 bit float, and a custom physics engine which works with that

I just want to use a modern and nice-to-use language, for that I chose kotlin since its syntax is so mature and has many amazing features, but I would have to use the JVM for that which would make it slower than something made for example in rust, and sadly kotlin multiplatform is still very slow compared to the jvm, for that I also decided to use vulkan since I can do my best to optimize it, quite the roadmap, but I'm sure it's doable with time. great video btw.

A game engine is a program or set of programs which define the laws of physics for a particular space and provides an interface with which one can build, edit and otherwise interact with things within said space in the domain of text and/or graphics and/or audio at the very least whether this be more traditional physical objects physics or physics relative to how card games work.

For Graphics api’s use DX11 for Windows, VK for Linux, Metal for MacOS. There should be a abstraction over this anyways. If you are lazy take a look at sokol shows a pretty unified gfx layer.

been working on a full-on game engine something like unity myself 1 year in development while still lacking features you can make simple 2D games now lol anyway even tho im 1 year in development this video still helped me a little lmao

hey great video. Im not super interested in game developing myself but i do find it fascinating how it works. Is it possible to develop your own graphics api? what advantages could come from doing so?

fwiw, it took me six months to code a 2D engine to handle UI in Open GL in C++. No editor, 3D, physics, audio, networking etc. Not even scalable fonts. The time went into getting all the input events handled and the essential widgets, of which multiline text and editable text were the hardest. If I had to add 3D etc. I'd definitely have to bring others on board (which is what Cherno ended up doing). Bottom line: think long and hard before doing an engine. Even the big studios with tons of resources and sunk costs are giving up. Another advantage to existing popular engines is that you can hire people to work on your game and not have to train them on your engine.

your channel is great education for me

I think a lot of people make a mistake thinking they want to make an engine rather than a game. An engine is an abstraction layer which can take as long to make as a game. A game without an engine is easier because you’re not abstracting for an end user that wants to make generic games. Specified code is easy to write, general code is hard to write.

I would probably create one just for fun and personal achievement

wawawiwa! Great success!(My journey just started...gonna edit any update and if not...bye)

This is great

Thanks Slot. 😁

And if I want to create my own programming code, how do I do it?

With python speed is not a problem. you can use the cython or nuitka compiler. They compile to c/c++ and than to native code.

I at one point built a small engine on top of pygame, nothing fancy and probably really inefficient, but it has stuff i have used on most of my projects since. It’s to the point I am currently building a text editor and have imported a good portion of the engine lol.

I am thinking about learning coding and all, barely looked at any tutorials, I have this fear of never actually learning anything from them and just never being able to become independent from them. (I found a term for that named “Tutorial Hell.”) I also looked a little bit at Harvard CS50, I viewed about an hour or two of one of the lectures on a video, haven’t enrolled in the online course though. I’m thinking about a “engine” for 2D games that could be similar to things from Doom, RPGMaker, and maybe RAGE slightly as I want to make one that isn’t really for level to level 2D platformers like Mario, Sonic, Spelunky, etc… but more like maybe something like Zelda II, Super Adventure Island II, Super Paper Mario, etc… I guess a good way to describe it is that it could feel like a Zelda game but in a 2D Platforming style, or a Story, action RPG as a 2D Platformer. I don’t know where I want to start in full on learning coding though. If Harvards CS50 would be good in learning enough to be able to independently write code yourself

Thanks, this video is very motivating! I want to do something niche, which is why I'm even interested. I want to re-implement and build on an old freeware game called Lunatic Rave 2. It's a clone of the arcade game Beatmania IIDX. There is another one available, but it is built in Java and no longer open source. I want to make one that's fully libre and built on C++ and OpenGL. What's really crazy is that the author of Lunatic Rave 2 has been approached about opening up the source of his old game... but he can't, because he lost the source code!

Personally, I went with a deranged hybrid approach born of my own self-taught nature. I'm writing a text adventure... from scratch. As such, the actual game engine - the stuff that handles all the interactions, the text parsing, the saving and loading, the areas, the NPCs, the rudimentary AI etc... that's all written by me from scratch. But I was under no illusion that I could somehow learn how to deal with UI and graphical elements, even for an almost purely text game, and especially since I ideally wanted to have some nice fades, text formatting and whatnot. So originally, I packaged the whole thing up in a WPF project. Worked pretty damn well, was robust... on windows. But of course, could only ever run on windows. Fast forward to now, and the core engine is still entirely mine, but I'm using Godot for the front-end. Basically, I have a single go-between script that serves as the middleman between the core game and Godot - taking the raw string inputs and keypresses from Godot, and passing them onto the C#, and then passing back instructions for the UI elements. (Oh, and of course technically, it's not C# but Mono... I'm not entirely sure there's a meaningful distinction though at this point - I was able to port the pure C# project into "Mono" without changing anything really). The benefit of this approach is that the two pieces are largely independent of one another; the core game engine doesn't care what engine the UI is using, it's just sending fairly anonymous calls that are picked up by Godot, and receiving similarly generic inputs that could come from anything. So if I need to update the version of Godot I'm using, or switch front-end entirely, I only have to adjust some of those UI calls. In fact, the process of porting the entire existing project from WPF to Godot took only about 1 month, for this reason. And because of all this, I was also able to reach the realisation that I could package my traditional novels... in the same engine as the game. Because it's a glorified text delivery system, with a polished Godot front-end. So I'm currently selling (or trying to sell) traditional novels on Steam. (If anyone's curious, search the Steam store for my name. )

So how Blizzard Maked Diablo on they engine?

Nice ending

You have a really cute cat as your logo. It will bring you much luck!

Ok. So my first couple of 3d game projects I'm trying to aim for a more "classical" way for them in terms of a game engine or two. Been inspired or influenced from old I'd software games and the communities of modding for doom,quake,etc. And I want to see if can make one that can handle a game that graphically looks like a mix of the best games of the 2000s I ps2,xbox,gamecube,wii,etc. Under a consistent 60fps for today's low end pcs from integrated gpus in laptops to even a 2gb video card to run them. Absurd it sounds ,but since I'm not aiming for much modern rendering features and trying to capture certain styles I think with time I can. I also want to make my games have code I can maybe make moddable and whatnot. One day I might make a engine that's like nowadays,but that's not my current focus.

i need to master all of that

Well done

the vision got me tbh

also another big advantage of building your engine is: you're allowed to use any license you want

Bro the on the other hand flipping stock photo got me by the balls 😂😂😂😂

I'd like to see maybe a video on how you made that decal system. Is it based on a tutorial?

Love the editing

I thought about it like a few days ago after the Unity bullshit forcing me away, and I decided not to (too much work.) I’ve been making a library for just over a year in C# and now I am forced to completely detach it from the sinking ship that is Unity right now. Good thing I started C++ a month ago so progress is good, but not exactly fast. I’m missing all the fancy packages I used like Burst. But on the flip side, I get to not depend on a game engine for the functionality of the library because I don’t want to have this sort of thing pulled again and throw a wrench in my progress. I get to start over implementing my features so I can build upon them on a new slab, instead of some of my less-than-ideal design foundations I made a year ago.

i’m making a source-inspired game engine using c# and a sdl2 wrapper, i have a window with working images and audio which i made in 4 hours :)

If you want to develop a game, use an existing game engine. Writing your own game engine is fun, but it's so much work that you'll never have time to develop a game for it as well. The days when you could build a game and a game engine for it at the same time have been over for more than 20 years. For example, the Build game engine (on which Duke Nukem 3D and many other games are based) was developed by one man, but he never did anything other than develop that engine. He never developed a single game with it. This was done by other employees of the same company, who only worked on the games and never on the engine. It's also not worth developing a complex engine and then using it for only one game. Remember: if you have developed a game engine, it is a standalone product. You can sell/license that engine and already earn an income that way. Leave the game development to other people. It's a bit like developing an app: you might be good at writing low-level backend code, but not at creating beautiful user interfaces, or vice versa. Leave the user interfaces to the people who can do them well, and let the backend be developed by people who prefer low-level coding. If you try to do everything yourself, you have to be good at everything at once, and no one is equally good at everything.

Language: Jai or Odin. Or C with function overloading from C++, ideally coupled with some basic meta-programming because C still has some unnecessary failure cases and boiler plate requirements. I'd recommend Handmade Hero for learning how to do an engine the right way, even though the series is almost a decade old by now.

Ahhh, if you want to build an engine with GPU support, start from SDL2 or freeGLUT. SDL2 gives you cross platform access to basic OS functionality plus audio and input with controller support, also it's just a library. Use what you want, compile what you need. Plus, there are other language bindings for it: Rust, Pascal, Lua and Python.

for me, a simple game engine/framework should implement these features: - rendering - physics handling - input handling - and asset loading

thanks 👍

I saw a video of what game engine to use when you have no coding experience. And here, a step further: Make your own game engine! xD One of my ideas for a game is to explain in the game how to use the game engine to make games, simply because, yes, there are resources, but they are not centralized and don't give as much freedom to play with as W3C does with HTML.