Why I'm STILL Glad I Didn't Use a Game Engine 

There’s still time

Wait for the rumoured speed improvements and you'll have even more to talk about.

@@Kednems Man, that's a ridicolous question, the thing is that he's glad he didn't use any game engine, if you saw the first video you would notice that. His point is clear, if your goal is to learn programming it's a better choice take the hardest way and try to program many things on your own. If your goal is just to make games, you could use whatever game engine out there. I don't think it's click bait, as it is no click bait every title: "I made a game in 3h"

@@Kednems In my opinion it is not click bait and I’ll tell you why. A click bait title is deceiving you making you think about a sensational content than giving you something different and less exceptional. In our case the video is about why he’s glad eh didn’t use any game engine. Ok, so now let’s try to separate fact from opinions: Python is slow compared to other game engines. Fact. It is not good for game development? I think this is more an opinion and there are many cases to prove this. There are a lot of games made in pygame that no one knows out of the pygame community (see the subreddit or the last easter pygame game jam). There are options better than Python and pygame: fact He’s promoting Python: fact It’s wrong to promote Python: opinion. All his channel is about pygame and game development with Python, he’s very good, I think way above average, and he shares his knowledge, so yes, he sponsors Python and pygame. I don’t see misleading informations, just a talented guy who explain his experience (usino Python and not a game engine had benefits for him). To conclude, he also sponsored other engines such as Godot and also Lua2D (in some coding session) so it is not a “pygame club only” thing. I think, I made my point Peace ✌🏽

@@dicember92 I put Unity in the title originally for 3 reasons: 1: it's shorter than "game engine" 2: it's the engine I *would have* used had I used an engine when I started, so in **my specific case**, I'm glad I didn't stick with Unity. 3: it's better for the YT algorithm (clickbait, but it's true)

KEK

lol

5 years later: "Why I'm Very Very STILL Glad I Didn't Use a Game Engine" (even though I still haven't shipped a single 3D game)

lolol

This

Agreed. Everything is a toolset and being varied is much better than avoiding a specific area. I learned programming first then got into game engines, but I still enjoy general coding stuff, as it's usually much more straightforward. But Unity and Unreal help me do things that I couldn't even dream of without spending 10 years of my life studying about the backend.

It's great to learn design patterns and certain algorithms too.

@@blackcitadel37 this is completely a different subject. We are talking about programming tools. I do agree with you

Let him learn the hard way. He's still a kid yet.

What tutorials did you use to actually learn monogame?

I've been creating and throwing code out since 1980. You learn more by failing than you ever will with something you thing is good. I have done 100's of projects over 40 years that were abandoned. I've also completed several that are still earning me money today. At this moment. So there's that. The trick is to love it enough to never quit. That is all you need to know about any profession in life, including software development - which goes WAY beyond just writing good code. Some of the most profitable stuff I have is also the junkiest internally. There is a reason for that too, but I'll let you figure it out. lol

to be fair, if someone is really young and has all the time in the world and its really really interested in this kind of world of programming art and game dev which is a combo of all, then yes learning how to make a game engine, learn C, learn assembly, learn learn learn, yea duh he'll have an easier time. But the clock is ticking and if you're a guy that's grown after school and you just get into all of this, dude just learn C slowly progress into the other langs learn to use the existing ones based on what u wanna make and in order to save time ofc and thats it. Plot stories are okeish from a point onward they will eventually come to you because through these you express you character as a person but art takes a tremendous part in all of this, otherwise you need money to pay someone else to make the art for you.

I'm sorry if I'm a late,but you can work around the pathfinding problem. You turn on your pathfinder,save the path,extract it, and turn it off so it won't ruin your physics. That's what Dani did and it worked for me.

@@romanian_the_cow171 i found another solution it isnt exactly elegant. The way i did it have the agent look at a target and then add a force forward. I am still working on obstacle detection

@@maindepth8830well I shared the solution Dani used and it works so I guess it was *OUR* solution lmao

@@romanian_the_cow171 communism

@@maindepth8830 yessir

This is the way.

when di you start your internship in cyber security?

im so confused on how these two things relate at all

@@yashz8282 Thats not true at all. I transitioned to web development and coding in a lot of application building architectures and frameworks very easily thanks to things like unity. in other words had it not been for unity I wouldnt have learned how to code or been able to figure out how a lot of the web stuff is built and connected in front a d backend. not to mention a lot of those languages are waaay easier than what a lot of game engines use. also the design patterns in game building are almost never consistent so you always have little to reference when building your backend systems and architecture for how the game will work. anyway my point is all these things can be valuable teaching tools, I think people just like to hate on the game engine craze and slightly lowered barrier of entry; basically guys like this are probably just a bit salty. or at least thats definitely how he is coming off

You're an intern. I think it's a little too early for you to be giving out info and talking about "job-wise" success.

@@InfernityKnight ur probably not a programmer. The skills are highly transferable if you have experience in low level programming which is what the video is saying but ppl in comments don't seem to know anything about programming

From developing a game using a ready, functioning game engine you'll learn a lot about idiomatic ways to structure data and logic within an engine, including hierarchies. I'd say keep at it, and say "I'm a garbage coder" all you want, but do not repeat it so much that you internalize it. Sometimes the garbage is just the mismatch between the language/facilities and the programmer's natural tendencies. I just hate working in some languages while I seem to gel very well with others. It doesn't matter how high the construction quality of your tool is and how robust it is, if the handle makes it impossible to hold.

@@Anriuko That is true, although my problem isn't with the logic itself, but rather not being able to understand the tools that I'm using in the first place. A game engine to me is essentially this magical tool that I have no idea how does it work, but it gets the job done, so I won't complain. My idea is that I can "make" a game, but I can't "program" a game. This can result in problems with work such as sometimes, a game engine has features that work in a way that is very unlikable or uncomfortable for me, but my only option is to set through it and figure it out because I can't really change it nor can I really code my way around it(a good example of this is how dafluffypotato didn't like Godot's tileset tool and thus decided to code up his own) and I end up blindly following up a tutorial which could show what's probably the worst or most inefficient way of using said feature, but I wouldn't even know because I have no idea how it works in the first place. Learning how to program these tools all by myself changed that and opened my eyes to the countless ways you could get around problems and it will certainly help me a lot if I decide to go back to an engine, because now I have an idea of how this magical tool actually does what it does and I can change what I don't like about it if ever need be, while also having known how to become a lot more efficient and effective with my work.

@@ezzygd2521 The hurdle of learning the tools was the reason I started on my own engine. It started as 2d but I found myself going 3d soon after. The pain points are collision detection, event handling, and pathfinding. If you want to go there, you'll have to learn linear algebra and matrices. If you have a mind for math it's not bad (as in difficult to understand), but it's very involving studying the math. Then comes the optimization, especially in collision detection and rendering. Creating and organizing the data structures is its own battle, and you'll want to refactormyourmcodemas soon as you have it doing what you want. You have to have discipline from the get-go to structure everything clearly, separate the interface from implementation, and plan for code re-use. I recommend presentations by Eskil Steenberg which can be found on RU-vid. Very bright fellow.

@@Anriuko I've had a general idea about all this stuff but I was lacking the resources, so thank you for the recommendation!

Your ability to architect well structured, performant software has nothing to do with whether you started using engines or not. Your ability to program is down to you as an individual, and how you are learning. Professionally, as a game developer working for a studio, I can tell you first hand that the game engine has not dictated how well the systems are implemented, it is not the game engines we use that dictate whether we do or don't use standard industry patterns. If you choose to not expose yourself to learning best practices, it's your lack of action that has limited you. Good tradesmen make the tools work for them. If you simply search on RU-vid for "realism in Microsoft paint" you'll find an assortment of videos from incredible artists doing things in paint that should be impossible, but it isn't. Why? Because what is important isn't how expansive, or limited a toolset is, its about how you take your knowledge of a toolset and apply it. I see so many people agreeing with your sentiment, and it's a giant steaming pile of cope. You want to be a GOOD programmer? Read. Read books on all kinds of patterns, architectural design, domain specific algorithms, LEARN. The game engine you choose, or the language you use isn't going to take your hand, gently caress you and say, "aww diddums, let me teach you 🥺", that's on you.

Then research about great open source libs such as BGFX, WGPU, PhysX, EnTT, Learn C++, Rust and maybe Zig and compose it to your own liking, Also there many open source tutorials/examples for let’s say Unity that you can adapt to your own engine, Etc...

literally the thesis is that you are more than allowed to make game engines; he just chose not to for one project so he could tackle the under-the-hood abstract problems that carry better to other coding jobs

But why

@@baaz5642 $😉

is it finished?

but isn't pygame somebody else's library ?

@@codingboy2254 Oh yeah I'm an idiot

Ikr, whenever I make a game I first design the cpu and gpu, just because I'm too lazy to read documentation on a pre-existing instruction set. /j

@@hetsmiecht1029 I’ve done that though (but not make a game on it)

@@hetsmiecht1029 well, python is a very high level language, and also reading the docs for unity is way harder than for pygame, you need a lot more set up for it and its very ram hungry. Plus your learning nothing about CS or actual programming if you do most of your game dev with visual scripting. For people like me, whos main field is ML, making a game without a game engine teaches a lot more than the other way around. And not everyone wants their career as a game dev, i make games but i dont call myself a game dev, i do it because its fun and IT TEACHES ME a lot.

I mean, I think game engines were mostly *made for 3D* since 2D is so easy to natively program. So I think his whole argument is just bad. Of course if you're making a 2D game you can do it by yourself pretty easily, engines are made for 3D most of the time. They have 2D capability but it often gets abandoned or updated less frequently for a reason, I think this is further proven by Godot who's starting to really focus on 3D now. Game Engines were not created for 2D at first, period. Godot was but it's a very new engine in comparison so I don't think that has much weight. Yeah, this whole topic is nonsensical because anyone who's somewhat good at programming would prefer doing 2D all on their own and not use an engine. He even said "Unless it's 3D" in his video which again, is the whole demograph for an engine, people who wanna make 3D stuff.

@@jonteguy I believe you should maybe pay more attention to the dev logs of Godot. Godot 4.0 is getting a lot of new stuff for 2D. Take for instance the new tile manager.

@@jonteguy not the **whole** demographic, I am no programmer, nor do I want to become one, I make little games for fun and they’re all 2D cuz I’m a visual artist so I managed to pick up GD script and godot pretty quickly. There are many people who aren’t interested in becoming a programmer, and game engines spare us the hassle of having to hire one

@GDScript Dude, I don't agree with your last sentence as it defeats the premise of using an engine in first place. Engines and frameworks are there so you don't have to invest time developing them. That's like saying: You shouldn't learn how to drive before you know how to construct your own vehicle.

​@jonteguy I'm using industrial software to write a 2D game, I have at my disposal the default library (essentially just basic geometry, region filling and such plus a script editor that I tend to use 90% of the time) and that's it. No way to import external libraries, none of those even fundamental functions that typically come in a game framework, such as dynamic image drawing, I had to code all of that myself. And even that is by no means low-level since even that native library takes care of the memory allocation (not to mention the script is way more intuitive and straightforward than raw C++) and graphics rendering so no need for me to ever tackle OpenGL. And you know what? This "easy programming" takes me an absolutely ungodly amount of time to get done even the most basic stuff. Last night, I wasted an hour trying to make an array of segments terminate at a slightly higher point on a character's body just because I got so confused with all of those similarly named outputs that I used higher up: "this was a segment then, but now this one is a point array, but if I change this then it throws an error on that other output there..., I bet you know the drill, makes you want to smash your head against a wall. It's not easy, it's _simple._ That's not the same thing. Simple things may be straightforward to comprehend, but often take a lifetime to implement. It's hard to make a living being an indie gamedev even when you churn out five games a year. Try doing that when you add so much more work on your shoulders for each outing. You could say, well, just reuse your own library, but doesn't it kind of defeat the purpose? Building a game from scratch is supposed to give you 100% creative control, but then you effectively constrain yourself by your own previous creation. You want to go for a completely new style, now what? Rewrite the old library to fit the new style? Are you sure you're going to get it working more efficiently than if you were simply to resort to some third party offering? You're seriously going to remember all the crap code and workarounds you implemented the first time around just to cut some corners? I mean hell, I doubt you bothered to write genuine documentation to begin with and the entire community consists of just one person: you, so no StackOverflow assistance to rely on. Now sure, it's absolutely awesome as a learning tool and I will actually try this from scratch approach next time. But not to build a game that anybody would give a shit about, just for my own personal satisfaction. But it's reductive to say that people who use game engines to build 2D games are in some way a lower form of programmers. Putting a game together is never easy, no matter what tools you use.

Linear or nonlinear? And what was your application of simultaneous equations? (I am curious)

@@gilian2587 linear. i had to figure out whether two lines were intersecting for collision. There are probably better ways of doing it, i just thought that using simultaneous equations would be more fun :)

@@burningapparatus5211 That makes sense.

Yeah, i also think that having something not work on a game engine is a lot more frustrating, since many times the problem is out of your control or you have something configured wrong

Try to programm a 3d game....

@@okay1296 I don't want to 👍

You're missing the point, its not about making your own game engine(he never did btw) its about using something whose skills are far more applicable in other fields(that's the main point). Game engines have you interact with their abstraction layers. He even says that there is a very important element of problem solving in game engines, but the problem-solving skills that you obtain when developing with a game engine are far less transferable to other fields. There's still the point that you gain a much more in-depth knowledge of the problems that you are trying to solve with using something like pygame. (Stuff that you usually take for granted in game engines like physics).

@@aprameyanaganur2934 yeah and im still saying thats not fully true(speaking from experience). in web development for example. the idea is that you focus on concepts which is the dame thing u wpuld do in game development. sure game engines may make you not have to worry about all the boiler plate code, but other but other fields are doing this too anyway. look at things like spring boot. hell even python game oriented libraries essentially give you most of what you need. when it comes to software developement. the concept of problem solving is key. you go deeper when you need to go deeper and there is no right or wrong time to do it. all depends on what your trying to do. and problem solving skills are an absolute must in game dev game engine or not as well as coding foundations. this is easily transferable across any software development field. you just need to change and understand the eviroment of your field. which you will need to do no matter whaat when you switch. so yes i still call bullshit on his point.

guess what that's not a better title

What to just in confusion 😂 game engine or not

Conversely... Using a game engine makes one better at architecting a game engine!

1st: The goal of the students (exept for game dev students of course) is not to learn actual game dev but => dev 2nd: In my school in France we have several learning modules including game dev but usualy from scratch or only graphic libraries, in all thoses rich modules i learned a lot on programming but the most of the things I learned is by making engines) 3rd: For most It has never been about publishing an Engine, far from it, it is just for being more specific on the project you work. That's why many big game studio are making their own engines (even some times a new version per game) rather than using a powerfull all-in-one existing Engine such as Unreal or Unity Today I am pretty happy of the game dev experiance im having, by using existing engines in compangnies and my own engine for personal projects. I love doing both but prefer the experience I have on my Own Engine in my Own way with some friends. Because you know even if there is definitivly features I prefer to use on Existing Engines, but I love when I see some thing very hard to do in thoses for no reason and i can just make it easier on my own engine or even create features for specific game types that is missing on unity or unreal.

And finally, pretty sure i spent same amount of time creating my first engine than learning Unreal wich should have taken even much longer without making one first to actually know what an engine is supposed to do and how it works E.C.S for ever

You should have seen the last video on this. They REALLY didn't get it.

I can't believe I wasted my time reading this comment lol. If you didn't understand his message, you should have stayed quiet.

@@johngibson4874 I'm not that type of a person who gets likes on a youtube comment, I wonder why I got so many though! It could be basically just you who don't want to understand my message, which is just a basic english! Do I really have to re-explain it again? No no no never!

He'll have to learn that stuff the hard way, like everyone else who stays in this field.

If you're joining a company. You'll have to work like that, but if game dev is just a hobby and you want to something else like dat science, then a framework is the way to go. this is because it builds your undertsanding of the language you're working in

youre basically repeating what he said in the previous video

lol

Using Pygame to make a game isn't that impressive lmfao

this is so true

I know right, I spent a bit of time on unity but it was slow and just a heavy program overall, also I found working with Unity's abstraction a bit cumbersome. In pygame, I had to manage all the physics myself, which required a lot more work and was a lot more rewarding once i got it right

well you got the point of the video so well done. totally ok if you just want to make a game. i wish you luck out there

I think if you use a C/C++ library/framework you generally will have a better time with porting as console dev kits will likely have bindings for C/C++ already(pretty much every decent/good game engine is written in C++ regardless of what scripting language is used). C#/Monogame seems like a good choice for console porting as well.

I respect your expressions and statements but there are some stuff that I have to state. First of all, I agree python is "slow" in comparison with compiled languages but it doesn't mean that modern days CPU will just screw up and won't run games created by using python and pygame graphics library. So you can make pretty much well polished games and get some good feedbacks on that. Second of all, you are talking about 3D stuff and I ask you can you make AAA games? you could make 3D game by yourself but it won't get so much attention as same as big companies' games get. So if you are an indie developer, then I think it will take so much time to finish that very well made games. There is another point that you can learn and experience if you are only and only wanna work on a big compony. Then you have to learn game engine and stick to that but you can experience some of the graphics libraries such as pygame or SDL2. In any case, you have to think both sides of programming and commercial aspects. Then you will find your way that you gonna be a professional game developer or indie game developer. Note: making 3D games doesn't make you to make more revenue with that game, look at Hollow Knight, Dead Cells, Inmost, they are all 2D games but they polished very well and developed professionally. So they make people to enjoy that game so much and even forget that that game is even 2D.Those and some other games prove that it is up to you to raise a project or make it trash.

There are performance improvements to be gained with the upcoming performance improvements for Python, as well as the potential of compilers such as Nuitka (Do not know how well it would work with PyGame projects).

Yeah but he meant like ALL jobs related to programming not just game dev. Which is why he said if you are looking for a general job and not just game dev then building an engine would be better for all around experience.

You don't need to be a senior engineer, a team, or be well funded to build your own game engine. 2d engines are actually rather trivial. When using a framework the focus shouldn't be on "making the engine." It should be on making the game. The engine comes naturally as you need something. Don't try to build a whole engine before you start your game. That's where failure happens. Systems should be made as you need them. Not way before you might ever need them. When using a framework don't build a level editor for your game, use Tiled or Blender(any other 3d software) to create your world and import it. Monogame and libgdx for instance have built in 3d support. They can also import from various tilemap software IIRC. If you need physics, Don t build your own. grab a physics engine that already exists. Bullet or boxed2d for example. There are others. The real secret is Unity and Unreal also use already made physics engines. Both have Bullet built in.

Yeah you missed the poin

did you actually watch the ducking video?

@@someonehere4380 there's no ducks in the video.

In my case, since I ended up working on embedded software and simulations for rockets, gamedev translated very well. A *lot* of the lower level thought process was applicable.

why do people think his vid is about MAKING game engines instead of not using them?

If you’re “making your own engine” for a 2D game, you’re doing it wrong. You’re supposed to focus on the functionality you actually need for your game. I spend very little time on engine-like functionality.

Maybe they actually prefer to make game engines than games. It's 2 different things.

I get weird vibes from this approach: "There already are 3 engines out there that are pretty advanced and leverage so much work for me already... I should code my own engine and show them how I would do it." Sure, you gain a ton of experience by that, but it also sounds like unnecessarily re-inventing the wheel.

@@christophsiebert1213 like I said, it isn't for everyone. I still use unity as well, I just don't prefer it.

I know its a stupid question but how do you make an engine how do you start ?

@@BlazeZ__ If you have to ask, you may not fully understand what an engine even is. An engine is supposed to lay the groundwork for multi platform communication with a device and prepare higher level access to all sorts of helpful frameworks for usage in your projects. This higher level acces may include any sort of of "easy-to-use" networking, wireless capabilities, controller inputs, sound system, and graphical scenery. Existing engines will give you a way to simply place objects into a scene, while it does all sorts of optimizations to reduce lag and optimize throughput to the hardware. Stuff you would have to do yourself otherwise and which can get pretty nasty.

@@BlazeZ__ places to start learning that I reccomend are the cherno youtube channel, games with gabe, games from scratch, coding train, and javid9x

it's called a framework :)

@@ajiteshkumar Yes, it's called that, but actually I don't see much of a difference other than the GUI

It is just a library that helps you to create a window and gives you access to input etc. A game engine on the other hand is a complete tool chain for creating games. Something like pygame can be a building block of a game engine, but an engine does so much more than that

The difference between an engine/framework and a library is who has control of the main loop (the fancy name for this is called Inversion-Of-Control by Martin Fowler). A library has zero awareness of control flow, It's just a bunch of code you call, it doesn't care where you call it. You have to set up most of your application's flow and then call the library in the places where you need it. A framework is the other way around, it's almost a complete application, minus the actual content and substance. You inject your code into the skeleton to make it a full, breathing application. It's as if your code is the library and the framework creators set up their application and called your code in a few key places to provide content and game logic (except it happened in reverse, the framework creators made a full application first but left a few hooks here and there for you to attach your code to later). Off course Unity is much more than just a framework, but all the extras are just extra, the fundamental difference is who gets to call whom, to put it very bluntly: who is the "main function". A library needs a main to call it, a framework is a main that does almost nothing except going through the motions of being a full applications, it calls your code to be an actual functional application.

The model they force you to use to build your code around is really bizarre. Keeping things organized in that model can sometimes be... difficult. It tends to lead to a highly coupled mess.