Solo devs and the trap of the game engine (Karl Zylinski) 

I appreciate that. I'm probably being too hard on myself

......WOW for me.... :( like 12 years of my life. was fun though

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 made this one :-) store.steampowered.com/app/2287140/Mooselutions/

Noted. Thanks for the feedback

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!

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 :-)

Oh good to hear there are workarounds. Always good to avoid tying yourself to a proprietary file format

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.

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.

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 agree with this. I just found that the C level is where I am happiest and most productive when making games

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 :-)

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.

We will never agree, but I respect our disagreement :-)

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

Who are "they," out of curiosity? Rust?

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.

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.

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.

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.