I like the fact that albeit having your own lessons about all the topic you talk about in this video, you don't push them until the end, and yet, you are really cautious into saying, this is just the start of a journey, if you want to compete with X or Y, you are probably thinking it wrong. This is really honest from you and quite wholesome actually!
Cara pulei de ponta nesse "rabbit hole" já faz 2 meses e nunca me senti mais motivado pra continuar, muito bom finalmente sentir que encontrei a área que quero trabalhar/estudar. Canal sensacional, parabéns pelo trabalho!
Very cool. One of my biggest mistakes when I tried to create a game engine with c++ in the past (in all 2 or 3 attempts iirc) was the endless "feature creep". I always got stuck implementing more and more systems and overcomplicating things instead of focusing on what was really important and forgetting what the end goal was in first place (make a simple space shooter).
Cool video. I would like to point out that a game engine is actually "the part of a games code that can be shared with other similar games". It is often called the 'Engine' or 'Core' library. This is why certain games from studios will use a particular engine over others - depending on which gameplay aspects and features they are trying to achieve (and other decision making, such as ease of use and capability for streamlined collaboration of its editor). Some studios (who may release different unique type of games) may own and manage more than a single engine. Next up, you will have your game code. This code (project) will extend/implement the core/engine library (which often contains the majority of functionality). It will then extend upon the engine code with features and functionality that will be unique to the particular game. Lastly, you will have the editor. The editor does not need to be written in the same programming language as the engine is. After all, it will be mostly managing asset files. It therefor needs to understand how to create and modify the proper file formats for assets, as the code (engine + game code) will need to read into memory. This program will contain the majority of tool necessary for the creatives (and programmers alike, inc. others) to create and manage project assets, visualize and place items into the scene, and much more. Post lastly, sometimes a studio will create one or more specialized tools for particular tasks. The editor will have many bells and whistles in regard to what it can do and how it does it. Sometimes, a simple tool (could even be created in a webpage) can be used for specific complex tasks.
Nice to see a fellow Brazilian here! In any case, maybe I'm being too honest, but for me the answer to "Should you write a game engine?" is a simple no. There's a very simple way to see this. First, pick any game and try to implement something similar to a very small part of it, like a menu to select the items. Try to implement just that from scratch. You will see that you'll struggle a lot, it will look very bad. Now try the same with an engine and you'll see that it will take you just a couple of days. Now pick the tool you used in the engine and try to implement it. With a few months of work and some knowledge you might be able to do it, but at least this is a problem you can attack. If you succeed then you can wonder if you have enough time in your life to actually implement the rest. In any case, you're right that it teaches a lot of programming concepts, but there are much more efficient ways to understand them...
Great overview Gustavo! So your preference would be 'unmanaged' languages like C/C++/Object Pascal vs 'managed' languages such as Java and C# which have a layer of abstraction.
I have no real preference. Different problems require different tools. I just think that in this case, since the goal is to learn something, most students will benefit from using a language that forces them to think lower-level. Different people might disagree, and that's fine.
Imgino que seja Brasileiro, valeu pelo video é um baita começo, estou escrevendo uma engine em c++ usando sfml e tentando utilizar o ECS na mão.. vamos ver no que dá kkk obrigado pelas dicas abraço!
@@pikuma acabei comprando seu curso por que tinha tudo que precisava, sensacional parabéns por reunir tudo que um iniciante precisava, muito legal mesmo..
Gustavo, apesar de falar um inglês perfeito eu suspeitei de ser compatriota e escrevo esse comentário em português mesmo kkkk. Muito bacana seus videos! +1 inscrito.
@@pikuma kkkkkkkk não sei se ja viu um canal chamado Bisqwit. Zoaram tanto o sotaque norueguês dele que ele decidiu fazer uma aplicação text-to-speech do 0 que fala com sotaque igual o dele
Good question. Most AAA studios use some *tested* library (purchased 3rd party or something they have been working for a long time). The only real reason to write one from scratch is if your "physics problem" is very unique/niche or simple enough that you can get away by writing yourself. But again, most studios use something complex and heavily tested, meaning that they don't really need to understand all the math that goes behind every physics computation, and they can be productive only by using the library and its API as a black-box.
Im 15 and trying to make a 3d runners vs trappers game. Never used unity or unreal just now learning c++. Seems out of my scope to make a game engine. I should probably just use an existing one first.
Oh for sure. Really, if somebody just wants to make games then you most likely don’t have to make an engine. BUT, if you’re interested at all, it will never hurt you to take a swing at it
That's a good question. It's one that many beginners get confused. You'll see many people use SDL to open an operating system window, read mouse, keyboard, etc. But when it comes to rendering 3D content, you still need a graphics API to communicate with the GPU. OpenGL, Vulkan, Direct3D, etc. are these graphics APIs. One interesting thing is that SDL itself will sometimes recognize that you have a graphics card and it will open a window and display graphics using OpenGL or Vulkan behind the scenes. But you still need OpenGL or Direct3D to create a proper hardware-accelerated 3D game. I hope this helps.
First several games I want to make their custom engines more akin between classic Id software engines with a few of modern stuff like the ECS and such.
I think more than ECS, which I agree should not be treated as a one-size-fits-all, is the idea of data-oriented programming and really thinking about data locality and data layout for performance. Lots of fancy words but all these ideas were there back in the day when every CPU cycle counted.
@@pikuma Indeed. The classic engines and the modding and source ports communities done for them fascinate me so much more than most modern engines in honesty.
tldw: engines are hard, use whole of computer science and are build up from important parts. Since you want to make an engine and not an renderer (for example), you should use libraries for pretty much all the parts and "just" wire them together. There are a few libraries mentioned throughout the video, but I'll just add that I would go with BGFX for the rendering (instead of using dx/vulkan directly).
