9:06 Many of us spent our 20s in a dark basement playing Call of Duty. You shouldn't feel bad at all for investing your time into a sport you enjoy and getting good at it.
This was great, it was refreshing hearing someone explain why i always write my own engines. There's this insane almost bullying mentality in gamedev that you shouldn't make your own engine anymore, meanwhile a pixelated game running on unreal needs 8gb and a leafblower gpu. I just can't be proud if my 2d game requires a 8040 and I like understanding what I'm doing. Sure my game might fail, or I take forever, but at least i got a deep understanding.
That’s very much a programmer’s view on that subject. If your focus is more on the artistic side you don’t necessarily care as long as most people can run your game
I've got a lot of respect for Karl - he's doing good work I just found you, Theodore, and I like what you are doing! I think some people have the experience of thinking they need to create a general purpose engine first - and that's a bad place to be in Others use it as a strawman argument (probably some ego protection) to call people stupid for not using a 3rd party engine As if almost every game before the 2010s didn't get created from scratch...
Game engines/game engine tools: You can always learn and make your own but theyre just there if you need them. And if you really do need them, you'll be glad that theyre there.
As a swe with a bachelor and master’s degree in CS I can safely say that the only thing that counts is to actually make something and finish it. Technology changes and evolve, we’re always learning something. I do see the value of understanding C and how a computer works internally, but then with that mentality of handcrafting everything you should not even be using C and work with assembly…so the moral is engine or not finish something
This post and your comments in the video deeply resonate with my own experience. Have a CS-background and a good amount of programming experience, tried a bunch of engines over the years and ended up writing my own engine. Which then sparked the motivation to *actually* start making games (i.e. not just prototypes). Regarding programming languages I would say that Nim falls into the same camp that Jai and Odin are, in regards of focus on delivering production software. Regarding the *big mistake* of writing a general purpose engine first: Personally I found it also feasible to write a low-level library-style engine that basically wraps rendering, audio and input. At a slightly higher level than Raylib/SDL. With that I started writing my game but, at the same time, continued taking part in GameJams to ensure that my library actually helps me to get to gameplay-code quickly for other projects as well. Whenever I need something that is generic enough (decent collision detection, audio fading, etc) I will add it to the engine. This slowly grows the engine feature-set but ensures every feature has at least one use case. It leads to a somewhat curious feature set where I e.g. have precise collision detection but no depth-pass for rendering :D (because I needed the former but don't need the later yet). Anyway, cool video, looking forward to listening to the other ones.
great video, loved that you talked about your background and the subject at hand, very relatable great insight for someone working on their first game with C++ and SDL2. Game engines feel very slow and bloated, I think if I was doing 3D game with a bunch of physics stuff and or going for realistic graphics or something then putting up with a game engine would probably be worth it but for 2D stuff I am working on, being able to understand my whole system and just work with code instead of GUIs seems far more worth it and enjoyable.
@@tedbendixson please consider making a video about procedural programming and why it is superior in your view. I would like to hear more from you on the topic!
This was excellent to listen to and ironic that I keep discovering videos like this of other game designers assessing their prior pursuits. I've only completed 1 full game and that was a snake clone in the late 90's with Visual Basic 5 through WIndows GDI DLL calls I picked up from The Black Art Of Visual Basic Game Programming book, but everything else has been experiments or demos. I've also used different game engines like Klik & Play/Clickteam Fusion, GDevelop, and recently started learning Godot but I'm noticing a pattern where at a certain point no matter what I use there's always issues that build frustration while working in other game engines. I'm realizing the problem isn't necessarily me, nor is it the fault of the game engine, rather there's just no ideal or perfect game engine for every situation or project you're trying to do. I'm also turning 41 in a few months and like you said, no matter which game engine or path you take there's going to be hurdles and time investment you'll have to do anyway. So I might as well buckle down, really absorb all the fundamentals, and make the ideal 2D engine that suits my needs. I prefer coding in VB and can incorporate Raylib, Monogame or anything with dotnet bindings, and I'm also open to learning Odin, but I might as well brush up on C++ to follow along with Casey's handmade tutorials. I just hope that modern C++ is not as much of a nightmarish hellscape as it was in dealing with 90's Visual C++ 4.0 and Borland C++.
There's no need to learn modern C++, and Casey Muratori makes a point not to use any of it in Handmade Hero. He does C-flavored C++, which is what I also do. Odin doesn't incorporate any modern C++ ideas into its design either. It aims to be more simple and C-like. It's a solid language choice. Enjoy the process :-)
@@tedbendixson Cool thanks for the heads up. I'll be honest in that I don't quite understand C-flavored C++ yet so I'm excited to learn, but just the little bit that I've experimented with VB's classes I can see some value in it especially for self-allocating and de-allocating objects instead of doing it by hand with large arrays of structures. But when it gets to be russian doll layers deep of child inheritance and polymorphism is where I throw my hands up and go, "why?" lol.
Hey man, this was great. It's weird how we have similar experiences but with different outcomes because I agree with everything in the video, but I ended up a hardcore Unity dev and know it like the back of my hand. I was the same, programmed in c++ with a graphics library (don't remember which) and loved it, and am seriously htinking about going back to that for future projects. I had to use Unity for university, and I learn quickly so it just became second nature. One thing I really dislike about Unity is the GC, but it's not a super big problem for what I work on. Regarding the file format for levels, there are ways around it. For example in my current puzzle game I have my own file format that stores all the necessary pieces, layout etc. and then I load that from a themed Unity template scene, so any puzzle will work with any theme.
Engines are a really big dependency to take on though. You can't easily abandon them when you do get stuck, and that's always been my concern. If I don't know how to wrangle Unity to do something I need to do, then I have to abandon Unity and make a game from scratch anyway. Why not just start from scratch then?
I am a self taught programmer. I would say I master Python the best, but I also know Lua/C and C#. What I dislike about game engines is how they abstract too much and for me, too much abstraction makes things harder... Godot's multiplayer for example is harder for me to understand than using raw sockets. One could argue that I am simply not experienced enough with it. Ok, that's cool. Problem is, for things that weren't built yet, I have to experiment a lot (because Godot's documentation lacks in this regard). Whilst using raw sockets, I can create easily any type of architecture. Wasting time on experimenting with it's capabilities, capabilities which are unknown, makes it a gamble...
Yup. Game engines are serenity now, insanity later. You'll get a guy on the screen today, but tomorrow you'll be suffering with the quirks of the engine trying to get the more advanced systems in your game to work. I prefer to suffer today so I can do great things tomorrow :-)
Should I learn C or C-flavored C++? Also, you might like the game Shredders given your background (which is really cool BTW -- spending your 20s that way is not a waste at all; you can only do those sports at a high level when you're young).
Either will do. Also, try out Odin. They're all of a similar family. I picked C-flavored C++ because it makes a bunch of stuff compatible with libraries like D3D11, metal, and Objective-C on Mac OS, but your mileage may vary.
If you start to write game without using existing engine, it is completely wrong mindset if you start by writing an engine. Write code from the mindset of making a game and "engine" will build itself around the game code.
20:20 godot uses python (okay, it's technically gdscript, but it's really close to the same stuff - python has stuff that gdscript can't do and vice versa --- but they are far more similar than different in most all regards) ... unity uses c#.... UE uses c++.... So, I would disagree... If someone is starting out, having them start in any of those engines using those languages is a great place to learn programming. Not only will they actually get stuff done in a very visual and responsive way, but they will have fun while doing it. If you said JS or something, then yeah much of CS goes out the door and I would agree that you're learning things in a really wonky way (to even render to canvas would be wildly confusing and hard to follow for someone that doesn't really know what they're doing)... but... as much as I personally hate python, godot isn't a bad place to start with using that (very very similar) language... and those skills very much hold over to any other python script you're bound to write...
if goal is money, you can throw all other objectives out of the window. otherwise whatever you have fun with, making a game or game engine or both. whatever style.
I'm not so sure about this. My goal is to have a satisfying, rewarding, meaningful career, doing something creative that I love. Money is a part of that picture, but if I have to sacrifice everything else that I love in service of money, then I might as well go back to my job in corporate America. I made far more money there than I am presently making in games. There is such a thing as having a multi-input function with a number of objectives you're working to meet.
I think the video is reaching for the notion of being 'first principled'... which is slightly different than being stupid... but the confusion isn't unwarranted.
16:14 The unity animation thing is a skill issue. You can literally play an animation using: animator.Play("name of animation"), or if you want to fade it: animator.CrossFade("name of animation", amntOfSecondsOfInterpolationInFloat); I too was not a fan of mechanim when that came out (the thing you're referencing), but before that and even since, playing an animation is literally as simple as it can be in code: play(whatever)... can't get easier than that. I agree though, it gets complicated and screwy if you use mechanim with the state machines... but it's just as convoluted as you want it to be, and it wouldn't be less-so in code. I've REALLY worked at it to try and make it work, and I usually just use that Play() or CrossFade() instead of bothering with the state machines. It's cool in theory that if you're character goes a certain speed, that the animator just automatically makes them play the running animation, or whatever... but getting it set up right is usually not worth the effort... it's barely easier writing your own state machines in code to get roughly the same result. The biggest benefit of unity is 'unifying' the data from all the different programs... instead of writing your own fbx parsers, and obj parsers, et at...--- the promise of unity is you just drag the different types into there and 'it just works'. By and large that's been the case... and for that, I love that so much more than writing said fbx parses (et al) manually... been there and it sucks butts... That said, I'm not super happy with unity these days because their business model is crazy. Might end up making my own engine from scratch with aims of replicating most of the features I actually use and with aim of having an engine to quickly prototype in... but...whose got the time.... BUT in any case: it's actually criminally simple to play an animation in unity... using mechanim is optional (but agreeably it's hard to use and convoluted)...so it's at the end of the day: "both hard to use" (your claim) and "easy to use" (my claim)
16:31 yikes... big skill issue... I've written my own engines, and used 3d engines, and game engines for darn close to three decades... and I know 1000000% what you mean... but it's a skill issue. Unity spent a lot of time figuring out the order of things and when things get called... so that we don't have to worry about race conditions and locking everything up all the time... It seems that they are lowering your ability to react to things, but it's actually really well thought out and something to aspire to in your own engines (or at least I fold that into mine). Specific C# gripes aside (which is a complicated issue all of its own, which would take me writing a books worth of text to properly describe), pretty much anything that needs to happen when a 3d object gets created happens in start()... WITH NO FEAR OF RACE CONDITIONS... you can register to C# events, add and remove stuff from Lists, screw with other 3d objects... pretty much anything is free game. Unity actually gimped their engine to allow for this, and everything is done (by and large- I could write a book on the nuance here) on a single thread, so that you don't have to even worry about screwing stuff up in Start... each thing with start, runs sequentially. Anything worth doing that must happen each frame is done in Update(), ALSO DOESN'T require you to have fear of race conditions or anything else... once again, everything with an update method runs sequentially. There are a bunch of other 'event methods' you can register for, and they have their place (maybe fixedupdate for things you don't want to wait for the rendered frame... or maybe lateupdate if you want to have it run specifically after all other updates() have run)... but they should NOT be a subject of confusion and very specifically spelled out in the manual. Lets say you have something that needs to run in its own thread and whenever-it-darn-well-feels-like ... maybe for instance sockets... well, you queue all the server communications from the socket and wait until update and process them... then again... thread safe and you're good to go. THIS FEELS DIRTY AND CRAPPY if you're not used to it. It did for me 100%. It's just a skill issue though... and once you understand what they are doing, you kind of respect what they actually did as well. Like I said, I usually try and make things sequential when I write stuff without a game engine for just that reason. That is not to say that single threaded applications are the best for game development - there is no doubt that they are not - but... if you get it, you get it... especially for stuff that really doesn't matter that much... so if you feel like you're running into issues with getting things to register for events or other such things, just make sure you're doing it in start() or update() and there is a huge likelihood that would make it actually work as expected...
~27:00 you can read files using c#... you can write a custom parser for a level. in c#.. you can write files using c#... I don't understand your complaint. You aren't limited to the type of files you can read and write to in unity - unity doesn't add anything to files that are read or written to - and whatever parsing you're doing can be done in c# ---
I think for me it's just the surface area of having to look that up vs. just doing the intuitive thing and writing it from scratch. It's actually easier for me to just write it from scratch and own my work than have to go through someone else's api.
Sure, but to get whatever is in your level file to work with Unity, you still need to put things in terms of Unity scenes, which is guaranteed to be bigger and more bloated than it would be if you just define what's in a level.
@@tedbendixson I get what you are saying with preferring the smell of your own code- I'm very much the same in that regard. If it is in actuality faster for you, then that's the right tool for you. I have my doubts, because I find being proficient at both low levels and high levels of abstraction allows me to leverage my knowledge against mocking something up quickly to see gesturally if the mechanic is actually good or not, as well as having prod ready performant, maintainable, and functional code that does exactly what I want it to do and not waiting on bug fixes from a black-boxed existing engine or relying on a company that might go belly up. So I think it's a bit of both, the best tool for the job is the one that gets you to your goal the quickest - my humble advice is to not fret about the time it takes to sharpen the axe, if it allows you to cut down things vastly more efficiently. The level file thing is interesting. The paradigm for unity is: to not to manually create scene files yourself (if that's what you're describing, all that stuff is black boxed, and like you said, assuredly more bloated than need be --- not something worth doing manually). I personally separate my data from my logic (psd vs photoshop, docx vs word, etc) so if you build a level editor, you 'should' (I use that word loosely, it's a preference) pretty much exporting data and not logic (ideally). If your levels really needed logic in them, then using/creating a scripting language that gets parsed along with the level data would be ideal (water is wet, and also, It's not a good idea to unquestioningly compile whatever is given to you at runtime from a data file). All that, generally speaking, is done manually and isn't a built in thing. If that's agreeable, then there is almost no distinction between using unity for writing and parsing the level data, and using the language of your choice at any level of abstraction to do it... the only difference is the level of abstraction when you use the data to place 3d/2d objects in the world... which is as easy as GameObject.Instantiate(modelInYourProject); based on the data. tl;dr - if it's faster to write from scratch, that's perfectly valid; That's not my experience. For level data, you don't need to nor should be manually creating scenes in unity - treat the level data like data and parse it appropriately.
Good video, which I agree with a lot of, but strange take on OO at the end. Like any other language paradigm it has its place. Its popularity stems from the rise of graphical user interfaces during the 80s and for that use it's a good fit. Most GUI code today is still based around OO concepts even when it is written in C (take a look at the Gtk codebase). I would say Java is to blame for the excessive and rigid use of OO and even that has eased up in recent times.
Huh. In my experience, it has been easier to make GUIs with straightforward procedural code. I have more direct control, and there's no need for totally ridiculous things like model-view-controller or model-view-view-model just to figure out what to draw for different screens. Some if statements is enough, and it's much simpler.
I worked as a mobile app developer for more time than I care to admit. Everything is MVC/MVVM. People do it without knowing what the alternatives are. It's just this ritual they carry out. They have no idea they can replace it all with a couple of if statements.
... you can make a game in RPG maker, lots of people have. Some of them are even really good. Don't go blaiming a perfectly fine tool. There is tones of low skilled stuff produced by artist just starting out using Photoshop or Krita, that dose not make those tools bad.
There is no blame here, my friend :-). There is the simple stating of facts. RPG maker can only make RPGs of a certain flavor. If you want to make anything else, you're going to need a different and perhaps deeper skill set.
lmao philosophy is word games. The definition of philosophy is something along the lines of creating pathology the whole things is supposed to be enlightening ppl and making them more aware. But it boils down to just making stuff up and trying to use facts.
For what it's worth, I don't think all philosophy is like that, but it just seemed like if I wanted to survive in academia as a philosopher, I would need to become a word game champion.
@@tedbendixson Well this is the definition of philosophy according to bing. phylosophy is a systematic study of general and fundamental questions concerning topics like existence, reason, knowledge, value, mind, and language. It is a rational and critical inquiry that reflects on its own methods and assumptions. Its kinda exactly what philosophy is meant to be. I just thought it was kinda funny cus, your like, man" philosphy feels like this, and im like hmm, I think it is meant to feel that way actually. lmao
@@tedbendixson but it makes a lot of sense, this is th e problem with putting things that are related to art, or have a art nature in school. Hard to understand why it would have to be paid for if it's something you can just say to people
Over the years I came to appreciate the scientific method much more than what I was seeing in philosophy. In science, you have to observe something out there in the world, and you can't argue a phenomenon into nonexistence. If your theory doesn't agree with your observations, you have to throw out your theory. That's not so in philosophy where you can just change the semantics and now everything agrees and your argument is airtight. Something about that just felt "cheap."
@@tedbendixson Yeah, that makes a lot of sense. I feel like philosophy is meant to be that way though. It had a goal and a purpose but now what we have is just creative ways to make some logic. I enjoy thinking about things philosophically . Its how I write stories, and branch out creative ideas.
I'm not going to finish the vid...cause you just went rambling off...but this came to mind when I read the title...do I have to raise, breed and slaughter cows to process the meat into ground beef...just to make a hamburger...no I don't(that would be ridiculous)...the hamburger I make will still be delicious, even tho I've used ground beef someone else already spent the time to produce...
Over the years, I've just come to accept that there are going to be hordes of people commenting on my stuff with [GENERIC POPULAR ARGUMENT], and I can't do anything about that. You didn't read the article, didn't really pay attention to the points made. Okay!
To stay within your own example, if you're passionate about getting the best possible burger, you enjoy the entire process of going "farm to table", and you have the skills and perseverance to do that, why wouldn't you? It's okay if you're fine with a McDonald's burger, but it's also okay if I want something more refined towards my tastes
@@tedbendixson I read the article, listened to the entire video and read the article again, and I broadly agree with this sentiment. As an absolute beginner, it feels like being gatekept. I know I'm not really the target audience, but if this is what you're telling to people with some experience... it's pretty disheartening. I don't care about any dogma of development; I don't even have a frame of reference for what principles I could dogmatically adhere to. I'm just being told not to use the tools that are exciting to try creating something with and are an accessible introduction to the field.
![Method Writing: The First Four Concepts - Jack Grapes [FULL INTERVIEW]](http://i.ytimg.com/vi/ba9jAVzADY0/mqdefault.jpg)
9:06 Many of us spent our 20s in a dark basement playing Call of Duty. You shouldn't feel bad at all for investing your time into a sport you enjoy and getting good at it.
I appreciate that. I'm probably being too hard on myself
......WOW for me.... :( like 12 years of my life. was fun though
This was great, it was refreshing hearing someone explain why i always write my own engines. There's this insane almost bullying mentality in gamedev that you shouldn't make your own engine anymore, meanwhile a pixelated game running on unreal needs 8gb and a leafblower gpu. I just can't be proud if my 2d game requires a 8040 and I like understanding what I'm doing. Sure my game might fail, or I take forever, but at least i got a deep understanding.
That’s very much a programmer’s view on that subject. If your focus is more on the artistic side you don’t necessarily care as long as most people can run your game
I've got a lot of respect for Karl - he's doing good work
I just found you, Theodore, and I like what you are doing!
I think some people have the experience of thinking they need to create a general purpose engine first - and that's a bad place to be in
Others use it as a strawman argument (probably some ego protection) to call people stupid for not using a 3rd party engine
As if almost every game before the 2010s didn't get created from scratch...
Game engines/game engine tools: You can always learn and make your own but theyre just there if you need them. And if you really do need them, you'll be glad that theyre there.
As a swe with a bachelor and master’s degree in CS I can safely say that the only thing that counts is to actually make something and finish it. Technology changes and evolve, we’re always learning something. I do see the value of understanding C and how a computer works internally, but then with that mentality of handcrafting everything you should not even be using C and work with assembly…so the moral is engine or not finish something
I agree with this. I just found that the C level is where I am happiest and most productive when making games
My friend is like you, he never wants to use any engine or existing tool.
He also never finished any project ever. Not even his minecraft buildings.
I made this one :-)
store.steampowered.com/app/2287140/Mooselutions/
The whole ''Not enough time'' or ''too time consuming'' argument is just pathetic laziness and/or deflated confidence.
This post and your comments in the video deeply resonate with my own experience. Have a CS-background and a good amount of programming experience, tried a bunch of engines over the years and ended up writing my own engine. Which then sparked the motivation to *actually* start making games (i.e. not just prototypes).
Regarding programming languages I would say that Nim falls into the same camp that Jai and Odin are, in regards of focus on delivering production software.
Regarding the *big mistake* of writing a general purpose engine first: Personally I found it also feasible to write a low-level library-style engine that basically wraps rendering, audio and input. At a slightly higher level than Raylib/SDL. With that I started writing my game but, at the same time, continued taking part in GameJams to ensure that my library actually helps me to get to gameplay-code quickly for other projects as well. Whenever I need something that is generic enough (decent collision detection, audio fading, etc) I will add it to the engine. This slowly grows the engine feature-set but ensures every feature has at least one use case. It leads to a somewhat curious feature set where I e.g. have precise collision detection but no depth-pass for rendering :D (because I needed the former but don't need the later yet).
Anyway, cool video, looking forward to listening to the other ones.
Great video! It would be nice if you used a larger font size btw
Noted. Thanks for the feedback
great video, loved that you talked about your background and the subject at hand, very relatable great insight for someone working on their first game with C++ and SDL2. Game engines feel very slow and bloated, I think if I was doing 3D game with a bunch of physics stuff and or going for realistic graphics or something then putting up with a game engine would probably be worth it but for 2D stuff I am working on, being able to understand my whole system and just work with code instead of GUIs seems far more worth it and enjoyable.
damn i thought this was a convo with Karl. But great regardless!
We'll probably do an interview at some point. Glad you liked it :-)
@@tedbendixson please consider making a video about procedural programming and why it is superior in your view. I would like to hear more from you on the topic!
@@reasonium7760 Ok!
This was excellent to listen to and ironic that I keep discovering videos like this of other game designers assessing their prior pursuits. I've only completed 1 full game and that was a snake clone in the late 90's with Visual Basic 5 through WIndows GDI DLL calls I picked up from The Black Art Of Visual Basic Game Programming book, but everything else has been experiments or demos. I've also used different game engines like Klik & Play/Clickteam Fusion, GDevelop, and recently started learning Godot but I'm noticing a pattern where at a certain point no matter what I use there's always issues that build frustration while working in other game engines. I'm realizing the problem isn't necessarily me, nor is it the fault of the game engine, rather there's just no ideal or perfect game engine for every situation or project you're trying to do. I'm also turning 41 in a few months and like you said, no matter which game engine or path you take there's going to be hurdles and time investment you'll have to do anyway. So I might as well buckle down, really absorb all the fundamentals, and make the ideal 2D engine that suits my needs. I prefer coding in VB and can incorporate Raylib, Monogame or anything with dotnet bindings, and I'm also open to learning Odin, but I might as well brush up on C++ to follow along with Casey's handmade tutorials. I just hope that modern C++ is not as much of a nightmarish hellscape as it was in dealing with 90's Visual C++ 4.0 and Borland C++.
There's no need to learn modern C++, and Casey Muratori makes a point not to use any of it in Handmade Hero. He does C-flavored C++, which is what I also do. Odin doesn't incorporate any modern C++ ideas into its design either. It aims to be more simple and C-like. It's a solid language choice. Enjoy the process :-)
@@tedbendixson Cool thanks for the heads up. I'll be honest in that I don't quite understand C-flavored C++ yet so I'm excited to learn, but just the little bit that I've experimented with VB's classes I can see some value in it especially for self-allocating and de-allocating objects instead of doing it by hand with large arrays of structures. But when it gets to be russian doll layers deep of child inheritance and polymorphism is where I throw my hands up and go, "why?" lol.
Exactly. Watch Handmade Hero. Casey will show you all the reasons to go with something far more simple :-)
this has come at a good time when I picked up sdl
Nickelback is better than Radiohead. I will die on this hill.
We will never agree, but I respect our disagreement :-)
Hey man, this was great. It's weird how we have similar experiences but with different outcomes because I agree with everything in the video, but I ended up a hardcore Unity dev and know it like the back of my hand. I was the same, programmed in c++ with a graphics library (don't remember which) and loved it, and am seriously htinking about going back to that for future projects. I had to use Unity for university, and I learn quickly so it just became second nature. One thing I really dislike about Unity is the GC, but it's not a super big problem for what I work on.
Regarding the file format for levels, there are ways around it. For example in my current puzzle game I have my own file format that stores all the necessary pieces, layout etc. and then I load that from a themed Unity template scene, so any puzzle will work with any theme.
Oh good to hear there are workarounds. Always good to avoid tying yourself to a proprietary file format
The problem is not engines the problem is relying on it to the point that if the engine can't do it you get stuck.
Engines are a really big dependency to take on though. You can't easily abandon them when you do get stuck, and that's always been my concern. If I don't know how to wrangle Unity to do something I need to do, then I have to abandon Unity and make a game from scratch anyway. Why not just start from scratch then?
i love reading
I am a self taught programmer. I would say I master Python the best, but I also know Lua/C and C#.
What I dislike about game engines is how they abstract too much and for me, too much abstraction makes things harder...
Godot's multiplayer for example is harder for me to understand than using raw sockets.
One could argue that I am simply not experienced enough with it. Ok, that's cool.
Problem is, for things that weren't built yet, I have to experiment a lot (because Godot's documentation lacks in this regard). Whilst using raw sockets, I can create easily any type of architecture. Wasting time on experimenting with it's capabilities, capabilities which are unknown, makes it a gamble...
Yup. Game engines are serenity now, insanity later. You'll get a guy on the screen today, but tomorrow you'll be suffering with the quirks of the engine trying to get the more advanced systems in your game to work. I prefer to suffer today so I can do great things tomorrow :-)
Should I learn C or C-flavored C++? Also, you might like the game Shredders given your background (which is really cool BTW -- spending your 20s that way is not a waste at all; you can only do those sports at a high level when you're young).
Either will do. Also, try out Odin. They're all of a similar family. I picked C-flavored C++ because it makes a bunch of stuff compatible with libraries like D3D11, metal, and Objective-C on Mac OS, but your mileage may vary.
If you start to write game without using existing engine, it is completely wrong mindset if you start by writing an engine. Write code from the mindset of making a game and "engine" will build itself around the game code.
20:20 godot uses python (okay, it's technically gdscript, but it's really close to the same stuff - python has stuff that gdscript can't do and vice versa --- but they are far more similar than different in most all regards) ... unity uses c#.... UE uses c++.... So, I would disagree... If someone is starting out, having them start in any of those engines using those languages is a great place to learn programming. Not only will they actually get stuff done in a very visual and responsive way, but they will have fun while doing it. If you said JS or something, then yeah much of CS goes out the door and I would agree that you're learning things in a really wonky way (to even render to canvas would be wildly confusing and hard to follow for someone that doesn't really know what they're doing)... but... as much as I personally hate python, godot isn't a bad place to start with using that (very very similar) language... and those skills very much hold over to any other python script you're bound to write...
if goal is money, you can throw all other objectives out of the window. otherwise whatever you have fun with, making a game or game engine or both. whatever style.
I'm not so sure about this. My goal is to have a satisfying, rewarding, meaningful career, doing something creative that I love. Money is a part of that picture, but if I have to sacrifice everything else that I love in service of money, then I might as well go back to my job in corporate America. I made far more money there than I am presently making in games. There is such a thing as having a multi-input function with a number of objectives you're working to meet.
just my view point.@@tedbendixson
How they make money is interesting...but borderline criminality !
Who are "they," out of curiosity? Rust?
11:04 ... I don't even need to pretend :P
I think the video is reaching for the notion of being 'first principled'... which is slightly different than being stupid... but the confusion isn't unwarranted.
16:14 The unity animation thing is a skill issue. You can literally play an animation using: animator.Play("name of animation"), or if you want to fade it: animator.CrossFade("name of animation", amntOfSecondsOfInterpolationInFloat);
I too was not a fan of mechanim when that came out (the thing you're referencing), but before that and even since, playing an animation is literally as simple as it can be in code: play(whatever)... can't get easier than that.
I agree though, it gets complicated and screwy if you use mechanim with the state machines... but it's just as convoluted as you want it to be, and it wouldn't be less-so in code. I've REALLY worked at it to try and make it work, and I usually just use that Play() or CrossFade() instead of bothering with the state machines. It's cool in theory that if you're character goes a certain speed, that the animator just automatically makes them play the running animation, or whatever... but getting it set up right is usually not worth the effort... it's barely easier writing your own state machines in code to get roughly the same result.
The biggest benefit of unity is 'unifying' the data from all the different programs... instead of writing your own fbx parsers, and obj parsers, et at...--- the promise of unity is you just drag the different types into there and 'it just works'. By and large that's been the case... and for that, I love that so much more than writing said fbx parses (et al) manually... been there and it sucks butts...
That said, I'm not super happy with unity these days because their business model is crazy. Might end up making my own engine from scratch with aims of replicating most of the features I actually use and with aim of having an engine to quickly prototype in... but...whose got the time....
BUT in any case: it's actually criminally simple to play an animation in unity... using mechanim is optional (but agreeably it's hard to use and convoluted)...so it's at the end of the day: "both hard to use" (your claim) and "easy to use" (my claim)
16:31 yikes... big skill issue...
I've written my own engines, and used 3d engines, and game engines for darn close to three decades... and I know 1000000% what you mean... but it's a skill issue.
Unity spent a lot of time figuring out the order of things and when things get called... so that we don't have to worry about race conditions and locking everything up all the time... It seems that they are lowering your ability to react to things, but it's actually really well thought out and something to aspire to in your own engines (or at least I fold that into mine).
Specific C# gripes aside (which is a complicated issue all of its own, which would take me writing a books worth of text to properly describe), pretty much anything that needs to happen when a 3d object gets created happens in start()... WITH NO FEAR OF RACE CONDITIONS... you can register to C# events, add and remove stuff from Lists, screw with other 3d objects... pretty much anything is free game. Unity actually gimped their engine to allow for this, and everything is done (by and large- I could write a book on the nuance here) on a single thread, so that you don't have to even worry about screwing stuff up in Start... each thing with start, runs sequentially.
Anything worth doing that must happen each frame is done in Update(), ALSO DOESN'T require you to have fear of race conditions or anything else... once again, everything with an update method runs sequentially.
There are a bunch of other 'event methods' you can register for, and they have their place (maybe fixedupdate for things you don't want to wait for the rendered frame... or maybe lateupdate if you want to have it run specifically after all other updates() have run)... but they should NOT be a subject of confusion and very specifically spelled out in the manual.
Lets say you have something that needs to run in its own thread and whenever-it-darn-well-feels-like ... maybe for instance sockets... well, you queue all the server communications from the socket and wait until update and process them... then again... thread safe and you're good to go.
THIS FEELS DIRTY AND CRAPPY if you're not used to it. It did for me 100%. It's just a skill issue though... and once you understand what they are doing, you kind of respect what they actually did as well. Like I said, I usually try and make things sequential when I write stuff without a game engine for just that reason.
That is not to say that single threaded applications are the best for game development - there is no doubt that they are not - but... if you get it, you get it... especially for stuff that really doesn't matter that much... so if you feel like you're running into issues with getting things to register for events or other such things, just make sure you're doing it in start() or update() and there is a huge likelihood that would make it actually work as expected...
~27:00 you can read files using c#... you can write a custom parser for a level. in c#.. you can write files using c#... I don't understand your complaint. You aren't limited to the type of files you can read and write to in unity - unity doesn't add anything to files that are read or written to - and whatever parsing you're doing can be done in c# ---
I think for me it's just the surface area of having to look that up vs. just doing the intuitive thing and writing it from scratch. It's actually easier for me to just write it from scratch and own my work than have to go through someone else's api.
Sure, but to get whatever is in your level file to work with Unity, you still need to put things in terms of Unity scenes, which is guaranteed to be bigger and more bloated than it would be if you just define what's in a level.
@@tedbendixson I get what you are saying with preferring the smell of your own code- I'm very much the same in that regard. If it is in actuality faster for you, then that's the right tool for you. I have my doubts, because I find being proficient at both low levels and high levels of abstraction allows me to leverage my knowledge against mocking something up quickly to see gesturally if the mechanic is actually good or not, as well as having prod ready performant, maintainable, and functional code that does exactly what I want it to do and not waiting on bug fixes from a black-boxed existing engine or relying on a company that might go belly up. So I think it's a bit of both, the best tool for the job is the one that gets you to your goal the quickest - my humble advice is to not fret about the time it takes to sharpen the axe, if it allows you to cut down things vastly more efficiently.
The level file thing is interesting. The paradigm for unity is: to not to manually create scene files yourself (if that's what you're describing, all that stuff is black boxed, and like you said, assuredly more bloated than need be --- not something worth doing manually). I personally separate my data from my logic (psd vs photoshop, docx vs word, etc) so if you build a level editor, you 'should' (I use that word loosely, it's a preference) pretty much exporting data and not logic (ideally). If your levels really needed logic in them, then using/creating a scripting language that gets parsed along with the level data would be ideal (water is wet, and also, It's not a good idea to unquestioningly compile whatever is given to you at runtime from a data file). All that, generally speaking, is done manually and isn't a built in thing. If that's agreeable, then there is almost no distinction between using unity for writing and parsing the level data, and using the language of your choice at any level of abstraction to do it... the only difference is the level of abstraction when you use the data to place 3d/2d objects in the world... which is as easy as GameObject.Instantiate(modelInYourProject); based on the data.
tl;dr - if it's faster to write from scratch, that's perfectly valid; That's not my experience. For level data, you don't need to nor should be manually creating scenes in unity - treat the level data like data and parse it appropriately.
Good video, which I agree with a lot of, but strange take on OO at the end. Like any other language paradigm it has its place. Its popularity stems from the rise of graphical user interfaces during the 80s and for that use it's a good fit. Most GUI code today is still based around OO concepts even when it is written in C (take a look at the Gtk codebase). I would say Java is to blame for the excessive and rigid use of OO and even that has eased up in recent times.
Huh. In my experience, it has been easier to make GUIs with straightforward procedural code. I have more direct control, and there's no need for totally ridiculous things like model-view-controller or model-view-view-model just to figure out what to draw for different screens. Some if statements is enough, and it's much simpler.
@@tedbendixson I never used MVC for the UI system I made.
I worked as a mobile app developer for more time than I care to admit. Everything is MVC/MVVM. People do it without knowing what the alternatives are. It's just this ritual they carry out. They have no idea they can replace it all with a couple of if statements.
... you can make a game in RPG maker, lots of people have. Some of them are even really good. Don't go blaiming a perfectly fine tool. There is tones of low skilled stuff produced by artist just starting out using Photoshop or Krita, that dose not make those tools bad.
There is no blame here, my friend :-). There is the simple stating of facts. RPG maker can only make RPGs of a certain flavor. If you want to make anything else, you're going to need a different and perhaps deeper skill set.
lmao philosophy is word games. The definition of philosophy is something along the lines of creating pathology the whole things is supposed to be enlightening ppl and making them more aware. But it boils down to just making stuff up and trying to use facts.
For what it's worth, I don't think all philosophy is like that, but it just seemed like if I wanted to survive in academia as a philosopher, I would need to become a word game champion.
@@tedbendixson Well this is the definition of philosophy according to bing. phylosophy is a systematic study of general and fundamental questions concerning topics like existence, reason, knowledge, value, mind, and language. It is a rational and critical inquiry that reflects on its own methods and assumptions. Its kinda exactly what philosophy is meant to be. I just thought it was kinda funny cus, your like, man" philosphy feels like this, and im like hmm, I think it is meant to feel that way actually. lmao
@@tedbendixson but it makes a lot of sense, this is th e problem with putting things that are related to art, or have a art nature in school. Hard to understand why it would have to be paid for if it's something you can just say to people
Over the years I came to appreciate the scientific method much more than what I was seeing in philosophy. In science, you have to observe something out there in the world, and you can't argue a phenomenon into nonexistence. If your theory doesn't agree with your observations, you have to throw out your theory. That's not so in philosophy where you can just change the semantics and now everything agrees and your argument is airtight. Something about that just felt "cheap."
@@tedbendixson Yeah, that makes a lot of sense. I feel like philosophy is meant to be that way though. It had a goal and a purpose but now what we have is just creative ways to make some logic. I enjoy thinking about things philosophically . Its how I write stories, and branch out creative ideas.
I'm not going to finish the vid...cause you just went rambling off...but this came to mind when I read the title...do I have to raise, breed and slaughter cows to process the meat into ground beef...just to make a hamburger...no I don't(that would be ridiculous)...the hamburger I make will still be delicious, even tho I've used ground beef someone else already spent the time to produce...
who asked?
Over the years, I've just come to accept that there are going to be hordes of people commenting on my stuff with [GENERIC POPULAR ARGUMENT], and I can't do anything about that. You didn't read the article, didn't really pay attention to the points made. Okay!
To stay within your own example, if you're passionate about getting the best possible burger, you enjoy the entire process of going "farm to table", and you have the skills and perseverance to do that, why wouldn't you? It's okay if you're fine with a McDonald's burger, but it's also okay if I want something more refined towards my tastes
Someone who read the article!
@@tedbendixson I read the article, listened to the entire video and read the article again, and I broadly agree with this sentiment. As an absolute beginner, it feels like being gatekept. I know I'm not really the target audience, but if this is what you're telling to people with some experience... it's pretty disheartening. I don't care about any dogma of development; I don't even have a frame of reference for what principles I could dogmatically adhere to. I'm just being told not to use the tools that are exciting to try creating something with and are an accessible introduction to the field.