FYI to readers: if you actually release a game, you won't have that much trouble finding work after as a Plan B if you need it. Speaking as someone in a position of hiring software devs for many years- proven ability to ship a fun or useful product is a #1 consideration that won't be replaced by AI anytime soon.
I remember way back when you made that series on the Handmade platform layer for macOS. Was that the precursor to starting to prototype Mooselutions? I'm always curious how much actual time goes into the prototypes from folks in the "from scratch" / handmade game dev community because there of course has to be some foundation around first to be able to quickly test out gameplay ideas. Even thinking back to Jon Blow's interviews on Braid as one example, it's hard to imagine he that _didn't_ have some simple DirectX rendering code lying around to just use for the initial prototyping (IIRC he says something like the initial rewind prototype took about a week with the simple graphics shown during interviews or Braid anniversary edition). If building those necessary engine pieces is considered part of the initial prototype, what was the timeline from start -> first prototype posting? First prototype -> production release?
Indeed, it took many years. Those first videos were me at the very start, just learning this totally new way of doing software development. I needed to get setup with basic text and sound rendering so I could do simple 2D prototypes. Once I was able to prototype in 2D, I was able to figure out what gameplay goes into Mooselutions. You talk about Jon Blow having something like this when he started Braid, and that is exactly the case. He had some leftover code from previous game prototypes he was building, and he just reused it after taking out all of the gameplay-specific bits. I've done the same thing with my new game. Once you've solved a problem, you get to keep the solution so long as you're alive. So every time you start something new, you're a little further ahead than the last time you started a new project.
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...
Based. I enjoyed this commentary. I had a similar experience, but it was with Brian Will's videos about how OOP is never the correct solution. I later found this article and handmade hero.
I think it was intuitive to call Terraria side scrolling minecraft at one point, since you place blocks. Now, I'd call it a survival metroidvania, where the loot you find and structures you make allow you to navigate more hostile biomes and tackle increasingly difficult bosses. Minecraft, to its detriment, has seemed to chase Terraria's strength of dungeons and bosses instead of focusing on the 3D building sandbox or its cave generation (took YEARS for the cave update, which I think was excellent).
Thank you for a beautiful talk! I kinda wish I had your perspective at your age. I was more like that old lady who cared about you. However as I have gotten older I have realized that some things in life are truly worth doing while young. You never know how old you end up to be and the experiences just would not be the same if you are 20 compared to 40 years old. I do often think about how I can arrange things to avoid choice and get to do both things. Maybe the answer is not to just go the safe route or go the odd job/risky route. Maybe the answer is that we are able to do both and reap their respective benefits. Just a thought. Take care Theodore!
Its funny but I am living the opposite story. I'm here, at the age 28, with a masters degree in software engineering from the hardest university in my area and 4 years of professional experience. I got burned out of doing full stack web development. Quit my job and started aggressive inline skating to make up for the fact that I never had the time to do it while i was young. Been doing that for a year now and have been living off my savings. I used to make mobile games in LibGDX back when i was 17-20, and released 2 of them. I made a Flow clone with randomly generated puzzles with some extra features like multi layer puzzles. And I made a clone of a old LINES game from the DOS area with the board size and rules adjusted to play well on a phone. The games made no money on ads but they were fun to make and great for learning. It's a shame that the university homework projects took so much time that I had no time to continue hobby game dev. I got a job as soon as I graduated but I kept getting more and more responsibilities on that job without getting a pay rise so I just quit. A year has passed and it seems like aggressive inline skating healed my burnout nicely and I now have the motivation to try my luck being a independent game dev again.
I had to stop mowing the lawn and listening to comment that the part about “doing the thing and then be done” is huge. It exemplifies all my frustration with full time software employment so concisely. It’s why I’ve been way more productive as a freelancer ever since.
Yeah, maybe if the game studio thing doesn't work out, I can just focus on fixed price contracts with a definite goal in mind. Hourly billing is insanity.
Another game dev with kids with a lot of fascinating experience (as shared through GDC talks, etc.) is Jason Rohrer! Great video as usual Ted. I'm curious: when you were working full-time and then moonlighting on game dev, how many hours on an average day were you able to / trying to spend on your projects (e.g. Mooselutions)? As someone who also works full-time, supports a family with a kid, and tries to move along with indie game dev, I'm always curious where people draw the line on the number of extra hours they can handle on side projects before it's too much mental load on top of the day job, etc.
Glad you liked the video :-). One of the benefits of doing a game from scratch is how it eventually turns you into a really effective and productive programmer. Because of the skills I learned from doing things this way, my day job slowly transitioned from something that takes a medium amount of effort to basically being a sinecure. Most day job programmers aren't all that ambitious, and they waste their time on the phone or in code reviews trying to look superior by pointing out small aesthetic nitpicky things. So if you just don't do any of that, you can get a lot done. I could usually finish all of my tickets for the sprint a week before it ends. The managers couldn't keep up with me. They couldn't give me enough meaningful work to stay busy, so I would just work on my own stuff when it got dead like that. Most weeks it was about ten hours. On some weeks, I might get as much as twenty hours in. If I felt particularly motivated, I might take Saturday off and work most of a Sunday. We have this silly protestant work ethic here in America. We think we owe our employers our time. I reject that notion. I think we owe our employers a valuable outcome, and it is their responsibility to provide an environment where we can contribute something of high value. If you think along those lines, you can cut down on a lot of bullshit and free up a decent chunk of time.
I use Sean Barret's very small STB libraries to handle PNG file loading. I also use a bunch of Microsoft's Win32 libraries to handle things like showing a window / Windows platform stuff. On Windows I also use DirectX11 for rendering. On Mac OS, I use AppKit for basic Mac OS functionality, and audiotoolbox for low level sound processing. I use Apple's native Metal libraries for rendering on Mac OS.
@@tedbendixsonWhy don't you use things like OpenGL and SDL2 or SFML? Those are pretty low level and to my knowledge they can work on Mac, Windows, and Linux, so you don't have to build a seperate platform layer.
@@dapaulpeng I enjoy learning and wanted to learn how to do a platform layer. I found it easier to work with Metal/DirectX than OpenGL. I tried SDL, but I didn't like the way it takes over a large portion of my programs logic. So here we are. I wish Jai were public. I would probably be using that. So this is the next best thing for me.
@@tedbendixson Have you tried asking for beta access? Feel like someone like you would be able to get access since you've shipped a full game from scratch
Frankly, it's a bad article. The author complains about people who try to force their way of programming on you, and then proceeds to do exactly that. And the argumentation is bad too. We've got this criticism of OOP: "First, you look at the real world problem - say, a payroll system - and you see that it has some plural nouns in it: “employees”, “managers”, etc. So the first thing you need to do is make classes for each of these nouns. (...)" Well... no. The central part of a payroll system are going to be payrolls. If the only relevant piece of information about "employee" or "manager" is the person's name, then you don't need any classes for them, a simple string inside the payroll class will do. So the presented issue (proliferation of classes) is not an inherent flaw of OOP, but rather poor design. Then there's a description of some prototyping and refactoring, really nothing magical about that. It's pretty much impossible to write a bigger chunk of software (OOP or not) any other way. There's nothing wrong with some rudimentary up-front design (which will likely go through multiple phases or refactoring) either. It often helps you to discover dependencies or issues you didn't consider earlier. And "because I enjoy trashing object-oriented programming" just reeks of bias. So yeah, Casey is definitely a smart and capable programmer, but that's just not good criticism. I agree on one thing though: purists are not worth listening to. Now a piece of advice from me: remember, software is a just tool. So the most important thing is that it needs to get the job done. In other words, as long as it meets the requirements, you're golden. It doesn't need to have perfect design, use fancy features, it doesn't need to be OOP, procedural or functional. It only needs to be good enough.
Thanks for the response. I think Casey could be accused of being unfair if there weren't literally hundreds of OOP examples just like the one in his opening paragraph. He's just showing a brief glimpse of what is actually taught in universities, boot camps, and online tutorials. When I first read the article, I got more of a feeling like "that's funny but not funny because it hits too close to home." You may have found work habits that allow you to be productive, even within the constraints of OOP. I have too. It still doesn't make OOP a good choice. With more experience in procedural programming, I've realized I can be much more productive by simply ditching OOP and the whole OOP mindset. It was holding me back. I am as "purist" about not using OOP as you are "purist" about not using horses to get around town. I simply found something better.
taking the john blow route, but the ted way, much respect, im not American tho, but still good seeing you putting on more and more content, leverage that recent waves of views, you could do it man
I found this video really insightful. I am 26, working full time as a web developer, and making games on the side. I consume a decent amount of financial/health/life advice content, but It's nice hearing insight from someone actually in a similar field of work/interests, vs some finance influencer. Thanks for putting the video together!
Great advice! While I cannot comment on taxes or stock market stuff, one thing that I can confirm by experience as a freelancer is: Having some degree of financial "power" is very, very helpful, especially when selecting projects, clients and talking about prices. If you are not desparate for the next project, you can avoid bad projects and getting overworked. I am now in a situation where I just quoted a project half the size for double the price, compared to a different client 3 years ago. At that time I quoted way to low because I was in dire need to acquire more projects.
Very important discussion, been saying something similar for years but I tend to get shouted down by Unity/Unreal enthusiasts that somehow feel that you're attacking them personally when you tell them you want to do it your way. The reason why we do martial arts is not to learn to kick people's heads in, it's to develop a confidence and understanding of the self you don't get in normal life without that dedication to something really hard.
My challenge in life is to make bazillions of money. So much that spending a billion in good causes won't be seen as a big deal. At the end of the day, it's a discussion between people who assume their goals must be the same as everyone else. I highly respect everyone who pursue their goals equally, as they have, despite different, a driven force behind them. Not remaining still and pushing forward in your dreams is what makes life worth living.
41:24 YES YES YES. After you're done actually solving the problem, the torture begins. After a long time of feelign like shit I realised that all I am doing is guessing what a lead developer likes, there's no objective task that I am working towards. It's most often about making Big Important Dev Person look Big and Important so they absoutely have to make everyone rewrite perfectly working code four times and start minimum two metaphysical research papers about meaning of the word 'action' or some shit. Whatever, man.
I honestly don't know. I haven't worked with publishers before. But I would say it all depends on the kind of deal you can get. Definitely reach out to them and see what deals they offer, and then go from there. It's a complicated subject.
Hey. I find your content interesting to watch. However, your microphone is very noisy and it makes it difficult to enjoy your content. Can you please try to setup noise reduction on your OBS. You can click the 3 vertical dots icon next to the microphone volume slider -> go to Filters -> and add a "Noise Suppression" filter. This should reduce the noise. You can also optionally add a "Noise Gate" if you want to make your microphone not pick up anything while you are not talking but this would require some twerking and is a bit more involved.
This just made me feel so much better about how long I'm taking on my own project. Although, after looking at your object model loader I don't think I'll consider you a professional anymore. For starters, you could have used sscanf() to read each line based on the control character, or you could've used strtok() to break up each line and individually process floating point data with atof() or you could've looped using strtod(), and determining whether you've reached the end of a file is a simple matter of `if ( feof( f ) )`, or more ideally you could `do { ... } while ( !feof( f ) );`. I thought I was reinventing the wheel by making yet another programming language, and then I see your "atof" function which reinvents the wheel by making it square. I'm also perplexed why the tiny example you've got took you two months when you could've used RayLib and avoided all of the graphics library differences and even writing a basic 3D demo with a board and a walking character shouldn't take more than a couple of weeks if you devote an hour or two each day to it. I'm sure I've asked before and probably forgotten, but just in case I hadn't already I'm going to ask you now: what is your work experience and educational history?
I'm just a guy doing his best to ship new and interesting games. I don't really care if you call me a professional or not, and I don't need to explain anything to you. I said in the video that my thing is nowhere close to "robust." Thanks for your feedback though. store.steampowered.com/app/2287140/Mooselutions/
@@tedbendixson Need is never a word I'd use when attempting to satisfy my curiosity. Robust is a relative term. Your program may very well be robust, but that doesn't necessarily equate to good. Perhaps now you understand what I meant in my prior post about stopping at the right time. If you'd stopped reading at the first sentence you would've been far happier. At least you've opened my eyes to some things. I shouldn't trust anyone's reputation, whether it be good or bad.
Can you go leave some pedantic comments on someone else's channel, please? Primeagen has a ton of content, much more than I do. There ought to be plenty of small details you can pick apart, and I'm sure it would be a worthy life's pursuit.
@@tedbendixson You're never too old to learn, so I'll start with a tip that comments add to your engagement for your channel. And it's not pedantry, but my attempt to help you learn. Primeagen is a fraud, but there's still some potential in you.
Potential for what, exactly? Being yet another carbon copy of the kind of programmer a textbook education says I should be? What if I'm actually not that interested in programming? What if I just happen to know what I know because my primary interest is game design and product development? You're the kind of person who will pick apart the aesthetics of my code, whether I used this library or that one, as if I actually give a crap when I'm writing it. I don't. Most of the time, I'm just trying to move as quickly as I can, and stopping to think if there's some standard I should be following slows me down. I don't know anything about you. Maybe you'll reveal your identity and show me what you've shipped. Did you do a whole game by yourself? Did it get any reviews? Do you make money from your own products? Seriously, who the hell are you?
Amateur here with an intermediate understanding of programming. When you say "object-oriented programming is trash" (I'm not offended, just inquiring), do you mean software design that depends on inflexible object hierarchies (which I've viewed as one of many of the possible uses of OOP), or do you mean programming that uses features of OOP, like classes, inheritance, polymorphism, access modifiers, no matter how sparing, but still finds solutions that are more flexible and modular than deep hierarchies. I learned C# from the book, "Learning C# by Programming Games" which taught me MonoGame and C# but showed me how to build an extended framework that had a deep object hierarchy. I was productive in making small games with it, but recently, with the assistance of ChatGPT, I learned how to build an architecture that instead uses entities and components. I never felt like I left OOP to do it; I just used it more efficiently. I'm still using objects as data, and that seems inescapable with C#. Am I at the very worst, going down the wrong path, or at the very best on the right track but have a lot more to learn about what's optimal with programming?
When I say OOP is bad, I basically mean it's a bad abstraction and there are better kinds of abstractions which emerge more naturally from the work you do. I learned how to do this by following Handmade Hero for the first 60 days. You can do everything with simple procedural logic, and in my experience, it's much more of a fit to the problems you're trying to solve, especially with games. With OOP, I always felt like I was trying to shoehorn my logic into a system that's fundamentally not designed for it.
@@tedbendixson would escaping those abstractions mean abandoning C# due to how integrated into OOP its features are, or could my use of the language be salvaged despite that with a little changing up how I impliment things with it? (Not unity, it's code-based.)
@@tedbendixson I built a Snake game in C# code with MonoGame that runs at about 43.7MB. Does that sound (un)reasonable for Snake being that it was programmed in a managed environment, with art and music assets included, and an extended class library I built it with? I would love to try C/C++ one day. Juggling art, music, and programming, I'll really have to think about that.
It's all about your goals. Switching to a language where you can manage memory yourself can open you up to a bunch of performance improvements on the CPU side. It also helps you get away from having to share part of your revenues with a company like Unity. It's all about the specific problems you're trying to solve, the game you're trying to make.
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...
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.
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.
Hello again, I just watched this video and I really like it, and I plan to follow the series. However I know that its old and I saw your response to the other comment about using Metal instead of the CPU for rendering. Any other tips you would provide as you today? Thanks.
That's the main one. You can still use CPU rendering for educational purposes, but know it's much much slower than using metal for rendering. I need a better Mac to do more mac-focused streams
It's strange, but I just read that article the other day. I appreciate your perspective, but I don't think this article is as good as you do. I disagree with Casey here regarding the definition of terms, especially with regards to the word refactor because that's precisely what he did to the code mentioned in the article. I also disagree with him claiming that the resultant code isn't object oriented because it definitely is that, if not in a puritanical sense that would rightfully garner hate, he did in fact create an object and orient functions around it. The key takeaway for me is that everything should be in moderation, and if that was all he said then fine, but the part where he all but claims that planning is a bad idea I completely disagree with. Writing a simple outline is how you direct things so that you don't go off the rails in a project. It's also the best way to organize your thoughts in how a project should go. Now admittedly it does take a lot more skill, but if the project you're working on requires optimization, a lack of planning will make that a more difficult refactoring job later on. Anticipating the correct direction to go in a project is a skill that more developers need to develop. Avoiding micromanaging a project is yet another skill that more developers should have. Both are difficult skills to acquire, but all of the best developers that I've known have had those skills.
Amazing. I have been programming, in all kind of languages, since 1974. Long before OOP was a thing. Of course when OOP arrived with the general use of C++ and Java I added that to my toolkit. Soon though I started to feel uncomfortable about it. As the years went by that discomfort became pain. But I could never really put my finger on what I felt the problems were I was experiencing. It's so great to find that someone described eloquently what as nagging me, and such a long time ago already.
IMHO Sokoban games and other tile based movement games are better with an orthographic view. I'd rather use prerendered 2D sprites than embark on all that crazy Metal/DX11 headache. Or just use Unreal and prototype quickly in Blueprint visual scripting.
It just sounds right doesn’t it? However I would love more examples of code compared to really nail it. Do you have more examples besides the one in the post?
@@tedbendixson Oh! I didnt know it had side-by-side examples? Are you sure? I thought it was just the project of writing a game from scratch with lessons learned :D
It doesn't have side by side examples like that, but you will see how Casey's code gets transformed as he discovers what the software architecture should be, or how it should best fit to the problems he's working on.
I've been on a big mental health journey and thinking a lot about systems growing organically and addressing needs of systems and it's very funny how much this organic idea of growth coincides with this compression analogy. This honestly makes very clear to me why I have been so burnt out and frustrated in this industry. I freeze every time I'm trying to create code because I'm so worked up about whether or not it will be written exactly the way that the higher-ups want and the harder I try the worst it seems to get. Thank you for sharing this article and elaborating on it because I feel like this brings together a lot of the things that I've learned over the past 8 years about how I need to not get in my own way and it's nice to feel excited about the idea of programming again. It got bad enough that opening my IDE would caused my heart rate to spike big time
I've been thinking about this in the past days. I've listened to this talk at least 4 times now. I absolutely agree that "semantic compression" makes programming a lot lot more pleasant. Besides that, just like anything in programming, it might be a good idea to partially question it. I came up with a few cases where it might be a good idea to create a function, even if it is only called in one place. - The first thing that came to mind, was a draw function. In simple enough games, where you have just a few entities you want to draw, it might be a good idea to define a draw function on that, and leave it at that. Even if it is only called once in the main drawing phase, I personally like it better not to have that logic in my main function, but define it to the struct that is being drawn. Of course in anything larger, you might want to create an interface/generic function to do that. So in the case of an interface, you have to define the draw function for that struct/class. However, in languages where you have compile-time reflection ( like in ZIG btw :D ) you could define a generic function that draws any struct with let's say a sprite field, position and size. - The second argument I can think of is testing. Let's say you're making a game where only the player can pathfind (by clicking on the screen). In that (extremely specific) case, by the rules of semantic compression, you'd just implement the pathfinding where the mouse input is handled. So in this case, not only the input handling got longer (not necessarily a bad thing), but also you cannot test the pathfinding without also constructing mocking environment for the mouse input. As I said in the beginning, I absolutely agree with this general way of programming. The way I'd put it is: Write the code that is necessary to solve your problem. And when you see repetition, absolve that. After that how many functions, files or even languages you split your project into is personal preference (with advantages and disadvantages). One last thing is that it might be valuable experience to work in a highly complex, OOP environment, or at least not a complete waste waste of time ( or maybe this is my way of coping :D ). I worked in a hyper c++ environment for 2 years, where abstractions were king. In the software we had a way to visualize all the inheritances and connections between all the objects (it might as well could have been a spider-web generator). In the tribe that I worked in (around 30 people) there were around 5 people who could see this whole mess through. Development and fixing bug was pain, I felt really helpless. Every time I could get so far, before getting lost in the forest of abstractions, when I inevitably had to ask for help from 1 of the 5 people who could have helped. That was my first job as a student and luckily I came across videos and articles that challenged OOP, and I tried them for my thesis, and really liked it. Even if that 2 years was pretty bad (the job itself, the people were amazing), I learned why over-abstracting might not be as good as it might seem (for me at least), and I know a few pitfalls to avoid.
I had one thought about automated testing. Essentially at the moment you realize you need automated testing, the spec changes, and a different place now needs access to the same logic which was previously in your main loop or simply a part of some other function body. So I think that case is consistent with semantic compression as Casey discusses it, meaning it makes complete sense to extract it to a function so the automated tests can access it separate from everything else.
Hi, have you considered making the game's "rounds" more long-term? For example, it could be more like in the later stages after you were playing in the same round for hours and hours, you would have a whole sort of world built with many interacting things.
I'm definitely driving towards that. I have a plan for more advanced turrets and enemies, plus production buildings that help you power up. I want the deck to have a hard exterior with a soft productive core, much like a good nation.
I don’t think it’s necessarily “wrong” to use OOP but I do see your point. One thing I noticed is you never once used the term “functional programming” but isn’t that what this really comes down to? functional programming > OOP. I think that’s your point anyways. Or at least thinking about solving problems in a functional way rather than getting caught up in abstraction
There are many things I like about functional programming, but I shy away from it because it can oftentimes be another form of dogma. I'm okay with raw pointers and straight up state manipulation in memory. I don't believe we need systems which make it difficult to just touch the state. Just like OOP, it adds a different form of friction.
Great video! You touched on many interesting and important points, here is a list of thoughts in random order about what you said: - Chaos vs Order is really interesting and it explains much about human nature, culture and history. Games are a great place to explore that space! - As long-time minecraft-lover, I have been thinking about it quite some time: What is it, that I really like so much about this game? And I think the answer lies very much in this chaos-order tension, where I can try to bring order in the natural-wild-untouched block world. My second favorite all-time game is Rimworld (Factorio somewhere in the top ten). And now after what you mentione it in the video: All three of those games share this feature of "chaos vs order". - Very interesting that you made that direct connection to Peterson's lectures. I think what he describes is often not really exclusive to him or his views, but I find he explains psychology in very interesting and understandable way (I watched a semester or two from his Psychology lectures, I think because Xtra-Credits said that game designers should have some understanding of psychology ;). Also, some things I got from his lectures helped me to understand why many games make use of existing religious/mythological themes and symbols. - The Peterson impression was hilarious and on point. How many times did you have to re-record that part? :D - More people/gamedevs should make content like this, and I hope you will be able to continue making these videos
Yeah. I try to explain this to entry level developers that they don’t have to follow “best practices”, which change from one year to the next. It’s much more important to build an application or a system in a way that makes sense to you. For me, organizing code into files and folders that align with my mental model is one of the most important aspects of software development. Also, keep in mind that just because you “can” doesn’t mean you “should”. In this case, just because your chosen language supports classes and objects, that doesn’t mean that you must use them, or even that you should use them. They are optional. I only use classes and objects when doing so is “easier” than using functions and structs. There are definitely cases where this is true, like, for instance, chess pieces, where the “type” of the piece affects its behavior. In this case, having a base class with a virtual function is easier than a switch case statement with every chess piece type in multiple places. I’ve found that this approach almost always results in code that works the first time you run it, which is pretty rare, in my experience. You really do get to decide how complicated you want your life as a software developer to be.
I use C++ and haven't even touched any of the object oriented parts. No classes. Just structs and functions. I made a full game that way. My current game works that way. You're totally right. There is no need to buy into all of the complexity. You get to choose your hard :-)
Did anyone else have a low key panic attack when he said that he wasn’t born in 2014? All of a sudden, I felt really old for some reason… 😳 It took me a second to realize what he meant. 😏
In Tynan Sylvester's book (creator of rimworld) he writes about how we get emotional responses in games from what have helped us survive in the past. Also in the case of Rimworld the "bad" graphics are intentional because the mind fills in the details making the experience richer. For example if some colonists start fighting and you read that one of them said a joke about a banana, you start imagining the details of the joke, how the different colonists reacted, how their relationship has changed and a picture is formed in your mind. Maybe this has happened before and you think one of them is sensitive or maybe you think this other colonist is being a asshole. It emerges from the simple systems of the world and take place entirely in your head. In reality the fight might have just been a random encounter. If Rimworld had realistic graphics or gave you minor details this would not happen. Very interesting video!
I had a similar experience while working on my engine: Once I could render a vulkan triangle, adding (simple) 3D stuff was not a big deal, you only need to get the matrices and vector math right. However, adding then a glTF parser to load some actual models was way, way more work, even only to load the static mesh content :D
I like how the mathematical description of possibility spaces, and the necessity of interesting choice interaction and state for interesting game design naturally leads to one conclusion: People are turing machines whose algorithms are based on the heuristic of "fun and vibes"
