I am a computer engineering student and there is one prof in our university that really had an impact on a lot of us, teaching low level computer architecture and computer systems. He would preach the exact same things, and now, after completing the two courses that he teaches, I feel so confident with C, its like I am a completely different person. He had us write an emulator in native C for a RISC architecture that he designed a few years back. Took the whole term, just submitted the last part today. And oh boy, seeing that thing run assembly (that we also wrote) at millions of instructions per second, interfacing with devices, interrupts, using cache, the whole works, is such an amazing feeling. Try the hard stuff people, its amazing to see it work at the end and know that if someone asked you about that project in an interview or just out in the wild, you could explain to them every tiny detail because you TRULY know it inside and out.
@@tedbendixson I go to Dalhousie university in Canada. Definitely not the greatest university out there, but prof. Larry Hughes (search him up on rate my prof) has made it all worth it.
@@marcosaraque6223 ECED 3401 - Computer systems, and ECED 3403 - computer architecture. He also teaches a fourth year course - Real time systems. Regarding books, we didn't have any. He is an old school prof (he is like 80), and would mainly teach on the whiteboard. We would get long textbook like pdfs that he wrote, and for the computer architecture course we got a one hundred something page ISA, essentially like a data sheet for the architecture that he designed. We based our emulator off of that document.
I started programming back in '78, at the age of 10. I think the better programmers naturally gravitate towards doing these kinds of things. Things you should do at some point, as a programmer: Write a compiler, write an OS, write a 3D renderer, write a text editor. The compiler doesn't have to be great. It doesn't have to be practical. But it should be comprehensive enough that you can demonstrate a lot of the fundamentals of compiler design. In addition, this implicitly requires an understanding of assembly/machine code, which I also think is important. I think the compiler is actually the single best project a programmer can do because every programmer should understand what I compiler is doing. And you don't have a create a full-blown OS with tons of functionality. But again, enough to demonstrate an understanding of the fundamentals. And again, requires a knowledge of assembly and hardware. All of these projects; Compiler, OS, 3D renderer, and text editor, require really stretching yourself as a programmer and delving into areas that mainstream programming doesn't often go into. But there's tons of great techniques and data structures to be learned by delving into these areas. I wrote a basic 3D game engine with some buddies back in the mid 90s. Wrote a pascal compiler in college. Wrote a 6502 OS many years ago and recently started tinkering with the idea of writing a basic 64-bit OS. I haven't done a full-blown text editor, but it's on my to do list. I've done smaller editors that were built into apps that had some basic functionality, and that's what piqued my interest in writing a full-blown editor. Like these other things, it's a whole rabbit hole of data structures and patterns to learn.
Yes! If anything I want to ask people, "don't you want to know? Aren't you curious about how this stuff works?" I am. Learning new things and challenging myself is what it's all about. If I'm not doing that, there's no point programming anything. It makes the process enjoyable in the moment, which is really all we have.
I've tried to make an argument with this same basic lesson to so many people over the years. It rarely sticks, but I am certain it's the truth. Personal growth is everything, and efficiency without growth is nothing.
I'm a fan of what Ryan Fluery has to say about this. He recently wrote an article saying it isn't about a rational argument, it's more of an aesthetic or system of values about what programming should be. I value knowing how things work and reducing complexity, and I won't compromise on that, even if I get a short term win.
While i do agree, because i share the mindset, let me tell you you're making a big mistake in assuming other people even so much as care. X is only relevant to people that care about X. Ie, growth only means something to people interested in growing. Some people just aren't and there's nothing you can do to change it. You'll just become frustrated for trying to fit a square peg into a round hole. As a trainer, one of the things you learn to do real fast is assess your trainees goals and mindset. Some just want to close the knowledge gap at hand, some want to do it AND go deeper into it. Knowing which is which is important so that you know which you can push a little more. And that's just "interest", then you mix in "competency" and things get a LOT trickier. Some people can grep it, some can't...
@@ErazerPT I agree. Handmade is a vibe, a system of values. If you don't have the same values, it's of no use to you. I made the video to assert my values because I felt like there are too many other videos asserting different values which aren't my own.
growth without ever finishing and publishing a project is also nothing, and in fact can lead to severe low confidence and depression - you know so much yet there are no completed/published/profitable projects to show for it.
if i could offer a slight generalization: take time to actually understand how your tools work. this can mean writing things from scratch, contributing to open source projects, or even just studying other people's code in depth. It really is incredible how quickly you can outpace 90% of professional programmers if you work like this. practicing how to learn is a compounding reward. the more you throw yourself in over your head, the faster you'll get at pulling yourself out. eventually, you get to a point where prior experience basically doesn't matter any more because you're so good at learning on the fly. even if you're just looking out for your career, that opens a ton of doors for you.
even more generalization is: don't skip the fundamental courses for anything, not just coding. Learning some skill the hard way is about learning how to get methods to improvise, innovate and getting more technical to know the strength and weaknesses of every path to wisely choose how to get the work done depending on the variable constraints of each project. Sure academic methods are tedious but taking convenient shortcuts doesn't give you a master or engineer level.
This is actually really good advice. And personally i found it more useful to me than the advice in the video. I've always found trying to learn how things work even a little bit was always better for my own growth than trying to go all in on a single subject.
@@weirdo3116 well, the boring studies in technical courses are there for a good reason. For example if you don't know how to recognize different woods and knowing their characteristics you probably shouldn't make any structural woodwork by yourself. Or if you don't understand how pigments and mediums have different proprieties and how superposing layers should be planned carefully, then you will not have any successful painting job. Another example: if you skip algorithmics and how the OS and the processor operate, you'll get a hard time improving your coding skill. And in general, in many skills there are safety precautions to know and apply, even at the lowest level jobs.
@@PainterVierax yeah but your advice is way too generalized. It's basically saying you gotta learn every last thing in your subject before you can even start. Difference between saying you should understand how something works vs you gotta go through ALL the fundamentals before you can do what you want. One is way more interesting and actually helps you to grow personally. The other is just running through a checklist and hoping they/you actually learn anything useful. Here I'll put it like this. I'm the first way i actually feel like I have the power to go and learn how stuff works on my own. In your way i just feel like I'm playing a slot machine for 100hours hoping I get a jackpot.
looks like the algorithm is giving this video the attention it deserves. really tho, knowing the ins and outs of your projects and tools doesn't just force you to learn new skills, most of the time it makes you capable of saving time and avoiding problems in the long run.
Everything you do is based on clicking on UI created by someone else. Get a Unix source code and begin from scratch to the point where when you are succeeded, nobody cares. It's all about choices! And none is wrong.
@@manz5435 > Just clicking a UI instead of making your own GUI from Unix source code > Just calling Unix functions from a library instead of making your own OS. > Just using C to make your OS instead of using Assembly. > Just using Assembly compatible with the system instead of making your own. > Using the existing bios instead of your own, to interface with the hardware. > Using pre-made hardware instead of building the components by yourself. > Using manufactured spare parts instead of designing and making your own. > Using refined metal instead of digging out minerals to make your own. > Using minerals from pre-existing earth instead of evolving into a 7-th dimension Giga-Demon and creating your own universe. That's just pathetic man. Why even try?
I've made my own game engine, learned a lot, and now use Godot. I like this particular position where I'm efficiently using a game engine that's much better than mine while also being able to more deeply understand what it's doing. If I really needed to, because Godot is open source, I could modify it, which is a freedom I wouldn't of had if I didn't know how game engines worked. My higher level of skill also allows me to do simpler things even faster and more efficiently. All of that is really awesome! I think it's good to know how things work, but you don't need to reinvent the wheel. There's a certain point where doing that is no longer beneficial, at least. Like, if I wanted to create a physics system, I'm clearly going to base my work off someone else's, and I don't mean code, I mean physics papers, software papers, Newton's formula. I'm sure if I were to rediscover newton's formula that I'd have a pretty interesting perspective and understanding of physics, but the effort required to do such a feat would be near genius at that point. If also sometimes prevents us for really learning what we want. You mentioned that productivity and time-to-market may be the goal, you mention learning as your goal, and I think it also depends on what you want to learn. If programming is what you are learning, then sure, but if you want to learn game design, then learning how to make a PNG loader sorta distracts from that goal. And there's a lot of distractions along the way. At least, in my experience. That's my two cents, perhaps like many thing in life, balance is the answer.
the source code for godot is very straightfoward, you can just read the main loop function and how it loads nodes one after another. The engine is a fancy text editor, if you open your scene file as a .txt you'll see it's just a series of node insertions and you can code everything using just that file. I agree, I've made simple multiplayer games in SDL and GLAD/GLFW/OpenGL, it's fine to learn but there's no inherent revelation. Undertale was made by someone who can't code and Terraria is a spagetti hodge podge of unstructured code.
That's the same for every technical job. Rare are the decorators or art restoration technician who make their own paint or their own varnish. They just have the knowledge to decide what premade product are the most suited for the constraints and how to select cheapest or innovative products. Same with tile workers, plumbers, carpenters or any artisan job. That's why academic courses and fundamentals are important to not skip when self learning, even if it's the tedious part.
The term “reinventing the wheel” is so cliche and doesn’t even make sense. The wheel was a perfect invention; Unity and Godot and GameMaker are not. If you want a wheel for your specific game, you have to make it from scratch. You’re not reinventing anything.
@@captainfordo1 That's true, but I feel there's aspects of making your own game engine, such as integrating a PNG image loader, that is "reinventing the wheel" because you'll most likely not do anything different in that or other similar cases. There's definitely a point where you can create very spesific systems or overall architecture for your engine that match your spesific game requirements, but I think there's a massive amount of general things that a game needs to do that doesn't need to be remade any better or different for your average individual. I know I didn't, anyway. I didn't benefit other than the knowledge gained, of course. Asset loading, shader processing, audio playback, physics resolving, input handling, and more are each components I'd call wheels that have already been created. A car needs 4 wheels to run, and just because the car is using wheels from another company instead of creating their own doesn't mean they couldn't still create a car that's spesific to their needs around the track or through the mud. You, as the driver, don't even need to make a car of your own, why not just an existing car that solves the problem you have. That car doesn't exist? Why not get a car that's close to what you want, and modify it! Why not re-use existing solutions? A reason I personally like frameworks like raylib is because it offers all of the existing solutions I need, but easily allow me to expand my own systems on top. Where I can focus, basically, on just making the core of the game engine, where I'm most likely to make the biggest difference. I think Godot finds a perfect balance between being a framework and a game engine compared to Unity, imo. Using Godot, I make my own game systems and managers that just run though Godot's main core loop and easily allows me to achieve complex AND spesific behavior with minimal effort. Plus, as aformentioned, it's open source, so nothings really stopping me from changing core behaviors to allows the engine to behave even more specifically as I want, if I truly need. That's my two cents on wheels.
Web dev here. I very much agree and I became "low-level" enthusiast not so long ago. A lot of people say that building projects is a best way to learn and I agree, but if all you do during those projects is using high-level libraries that abstract all the complexity you're not really learning much. Or if you doing same stuff over and over. For job of course you want to use high-level libraries that get quality stuff done fast, but for learning purposes it's a terrible mistake that's gonna make you stagnant.
I agree. Going through so many tutorials they tell u to use all these frameworks or libraries without explaining what they really do or how it works. In the end u end up just regurgitating snippets of code without any understanding about how it works.
Hey Michael, I've been really questioning lately whether I am programmer or a frameworker and I am starting to think I'm going down the path of frameworker. So my question to you is, as person with a Interest in web dev how would I gain a lower level understanding of the field? Any tips would be greatly appreciated!
I think people who are disagreeing are missing the point of the video which is do hard things to get confident and have deeper understanding of the things that you are working on but obviously if you need to ship a product out in the market take the help of tools which can get things done faster.
I think we also tend to assume that the tools will help us ship faster. In my experience, many of the tools I've used just got in the way of solving the problem, Object Oriented Programming being the canonical example of that. If you want to get something out faster, the best thing you can do is cut out needless complexity and features which are not core to your product. If you need to put a prototype in front of people, use crappy low resolution artwork and make a vertical slice of the core thing, knowing you can fill out the skeleton later. Just because you can use a tool doesn't mean it's going to make you more productive. That's just a sales pitch. You don't have to buy that pitch.
@@tedbendixson You have to do OOP for a while before you understand how to use it correctly. Helps knowing multiple paradigms (functional, structural) and design patterns, but that's just the start really. It's not a panacea to knowing how to code efficiently. I've been using a game engine for 3 years for a project, and if you are using an open source one, you are really not losing anything, you can always go deep inside if you want to know how it works. It would have been impossible for me to code a 3d game of the scale (and quality) i have atm otherwise, it does save an insane amount of time, especially when the community creates someting amazing like the (Zyllan's) voxel terrain I am using or . I do use the "best" MIT engine out there however, so, you do need That said, sure, I lack C++ exp to modify that engine easily, but I can't afford to in the lifecycle of my game anyways (entering marketing phase of what you can call an "early access" title). Soon, hopefully. Anyways, end of my rant, Have fun with your project, it does definitely increase the learning curve for "lower level" programming (non game logic stuff like complex character controllers etc).
I'll also just note that I do have over two decades of game making exp of various kinds (mostly small 2D stuff) and enterprise frontend/backend exp, and also a few months of learning OpenGL etc, so, It's not like I am comming into this from a complete "only use Unity/Unreal" and never go low level, I can just skip reinventing some of the wheels BECAUSE i've reinvented so many others in the past 2 decades... So, maybe myself and Ted agree, not back to actually watch the whole video. Do what you love doing kids, even if it's scary, that's the real key to success.
So, watched the video. There is just one thing i "don't agree" about it, which is that "knowing more will secure your job". It won't always. Most companies function according to "last in, first out" rules from my experience. Which means that you will be sometimes managed by people that know and have far less experience than you do. Yes, sure, they are domain experts, considering they spent say, 5 to 8 years in a single company, but for everything else? So, sure, knowing more than the next guy is great, but it's far from the main thing that keeps you in the job, unfortunately, it's really how much your immediate superior likes you vs the other person, and how much he has worked with somebody plays into that too.
@@tedbendixson OOP has it's uses, though. Just take a look at the codebases of ss13 servers and tell me you could make the game nearly as complex without OOP. The short answer is that you couldn't. There are simply too many variations of every object in the game. The long answer is that you could, but you'd lose your mind in the process.
Loved your message. As a person whose only goal in life is to garner as much knowledge as possible, your “time + effort = rewarding knowledge” message is how I’ve lived my entire life. You gained a new subscriber!
Obviously, if you make everything by yourself, you will improve your confidence. The problem I see with doing everything yourself is the time. And at work, where time is precious, I don't think it's productive to start from scratch everything.
The beautiful thing is you only have to start from scratch once ;-). After that, you have code you can reuse for the next thing. I use simple libraries for common data format standards like PNG loading (stbimage) because that's not really an interesting problem and it's just a proprietary data format.
I’m brand new to programming (installed python a few days ago) ran a few tutorials. Found it very intuitive and was having fun. I then saw a video on making a game in pygame. I first said to myself “no you need to finish these beginners courses first” I obviously couldn’t wait and jumped straight into the game tutorial.. I’m loving it and feel like I’m understanding what/why I’m doing. Mostly because the tutor is explaining everything fully. I then saw a comment on the video that went something like “I’ve just printed hallo wurld with python, now ill make this game” obviously being sarcastic. Lots of reply’s to the comment saying that it would be a terrible idea, and that such a person wouldn’t have a clue why they are doing anything.. but I did? I can’t wait to finish this tutorial and challenge myself to edit the code enough to feel like it’s my own game concept. I might not manage it. But it’s what I’m EXCITED to do I guess the point in my comment is; you will ONLY learn the hard way. And failure is the best to learn from. And as long as your tutor is good enough at explaining concepts. You WILL understand the what’s and whys to your work
You're basically describing my adventures learning C. I started out like, "Okay, I have a bunch of programming experience in this kinda BS object oriented languages. I want to make a game because Unity frustrates me. Let's try this Handmade Hero thing." I followed every episode up to the 50th, and I eventually got an understanding of lower level programming. I took the code and slowly ventured out into making my own games this way. I learned a bunch of graphics programming that isn't even in Handmade Hero because I built up the skills to research solutions and work on all my own, without a tutorial. I banged my skull against a bunch of stuff I didn't understand, but that's fine. It's normal. You usually don't understand what you're building until the sixth or seventh time you build it all over again. Just trust the process.
Watching a tutorial is not "the hard way". And saying that the hard way is the best is self contradictory. If you did it the "hard way" - ie without tutorials, you wouldn't adhere to any of the conventions and probably use the language/framework all wrong.
I am in a similar situation. However, it is more that I am jumping from Python (smand Pygame) to learn C++ and SDL. Yesterday I managed to make a window, which I am quite happy with But maybe I should follow a video tutorial and do less googling as I go approach?
The "My job doesnt allow me to learn all these low level things argument" isn't the problem preventing people from learning the low level, its the consequence of avoiding the low level. If you don't know how the low level works then you simply become an user of the software, frameworks and libraries others created. They remains just magic to you, because you don't know what its doing, as such you're less effective at using it. Its like using a calculator without knowing algebra, you learn through brute pain and messing with things until they work, rather than from the underlying logic. Yes, you do eventually learn some stuff through sheer trial and error, and in the case of a calculator, you will eventually learn the patterns of the different arithmetic operations... But in the case of a framework tens of thousands of lines of code and concepts you've never heard of? Hard shit. And plus, if we all just use whatever someone else has already made, without ever learning how it actually works, then what do we do when those developers who made all those wonders of software engineering retire? Whos gonna maintain that? And most importantly: whos gonna fucking improve it? Are we supposed to believe that the technology we have now is the best it will ever be, that there's nothing to improve, therefore no reason to learn it, and resign as mere users? Accessibility is great, but it will never beat fundamentals, not in programming, nor in any other life endeavour.
Humanity has developed new technologies at an insane rate because people wanted to improve, nothing seemed "complete". But now this idea of "nothing is complete" is getting less popular and people are settling for less quality.
Free open source software (FOSS) isn't about helping save people money at the expense of the creator. FOSS is a culture about helping others learn and experiment without fear of legal threats designed to prevent learning. FOSS is the natural conclusion most programmers eventually come to after they build a bridge over a dangerous chasm: they want to help others to cross and maintain the bridge because, God damn, it was hard. Psychopaths are the ones who cross other people's bridges all their lives and then, when they build one themselves, they rig it with legal curses and explosives, then hide the blueprints to prevent others from defusing the deathtrap.
"My job doesn't allow me to learn all these low level things" I don't know about you guys, but when I was learning programming on my own, there was nothing that could keep me from learning whatever I wanted. I was basically thinking about programming all the time and doing it as much as possible, outside of my job as a cashier. If you want to learn it, you can.
@@Ehal256 Exactly that! I started in 1983 with basic by the time I was 13 in 1986 I was doing 6502 assembly because commodore basic was terribly slow and it didn't allow me to make the demos I watched. Oh for the record commodore basic was a microsoft product -- back then they already only created shit.
@@atomgutan8064 I had rows about software quality! The complacency of developers is sickening. I don't care about clean code Uncle Bob crap, or how you indent or naming conventions (I like consistency) but what i care for is robustness and well tested stuff before you send it to the customer. And code these days is so bad it takes you less than 10 minutes to find flaws and bugs. And all because "we want to be fast to market". Well you scare your customers away with crap like that!
Teaching myself how to code and specifically low level code is what allowed me to be a Senior Software Engineer/Architect today. I started with Game Maker at 14 but quickly moved on to C/C++ and thanks to that I gained the confidence that allowed me to take advantage of opportunities that changed my life for the better.
@@xxDeath99Starxx May I suggest Vulkan, "the new thing" in rendering, I suspect it will probably get a lot more attention in the years to come (since it's developed by a consortium of different companies in the industry). It's more low-level, but you can achieve much better performance.
@@theRPGmaster Thanks a bunch for the suggestion, I shall look into Vulkan now, I haven't read much about it yet, if it's indeed more low-level than directX I will probably make the transition following my first directX project completion!
@@xxDeath99Starxx If you didn't know already the real advantage of Vulkan over DirectX is that it is cross-platform as well as being relatively low level to be far more performant than 'OpenGL' ever was. DirectX is for windows platform only but is the standard way to use those APIs which include the graphics API on Windows. On some games Vulkan offered improved performance over DX12 such as a 10% improved framerate on "Red Dead Redemtion II" while rendering the environment with equivaelt fidelity.
I'm a coding noob and I'm glad I found this video at this point in my journey. An analogy that makes sense to me is learning how to do Math (traditional paper and pen style) over learning how to use a calculator. The person who learns Math will be far more efficient and proficient in using the calculator in the longer term. It's shocking how spelling and language skills have deteriorated because of spell checkers and grammar tools which have resulted in many forgoing learning the basics in favour of immediate output. I'm South African, and I get professional emails from respected organisations with spelling errors, (we spell colour with a "U" here for example), because the software you use has US English as a default. If you don't have the right understanding you won't be able to correct and/or compensate for the shortfalls of the tools you use. I need to be able to recognise when my calculator is faulty, which would be impossible if the calculator is all I know.
No, why would they be more efficient with a calculator? You're simply claiming that. Spelling something "correctly" is only good insofar as it makes a text more readable. In particular "correct" is just how the majority spells something. If anything you should be happy for spell checkers cementing the supposed "correct spelling" instead of letting spelling evolve as it usually does.
@@MrCmon113 yes, but you're using language to communicate with others, therefore you want it to be familiar to others. you're not going to spell like an alien if you let spelling evolve, but khigha's point is that through the use of spell checkers, you eventually will be spelling like an alien because the only thing you relied on was a spell checker. mathematicians are also a lot more efficient than a calculator, math isn't just arithmetic, it's way more than just that. every bit of engineering around you is made with mathematics, sometimes more advanced than what a calculator can help you with too.
@@tedbendixson Cheers! Another you’d like is Mike Acton’s CppCon 2014 talk about data oriented design. But if you are a fan of Casey, you’ve probably already seen it :)
@@cellularmitosis2 I wish I had found these programming circles half a decade ago, hah. Only half a year ago I found casey, and it’s been the most valuable thing for moving forward. More people should talk about this! There's too many echo-chambers on the web, and I want philosophies like this to spread to more people like me
I just watched this talk and I feel like I have a long long way to walk through, I did not felt that since I started programming 4 years ago, I'm excited
I'm coding a game engine from scratch myself, been at it for a few years now, and I agree 100%. People just assume I would want to ship asap and get rich quick, when I'm all about getting more knowledgeable by understanding what I do on a fundamental level (I'm a science / engineering nerd at the core). At the end of the day, what matters is that I'm doing what I love, and I don't care too much about what people tell me I should do, even if they can be patronizing at times. Regardless, the idea that reinventing the wheel is a useless endeavor is just plain wrong. It's not like the history of invention is a linear succession of people solely reusing stuff that's already there...
Same here. I am definitely prepared to spend 5 more years on it, or however long it takes. I keep learning useful things in the process. Now working full time as a software developer there's less time for personal projects, but I'm very glad I spent the hours and didn't give up back when I had more time.
even worse, apparently everytime you think of using something or a certain language to create games people will always answer assuming you wanna make a triple A hit all by yourself, which is complete nonsense.
Only problem is youre working years on it already and prob have 5+ more years to go, which by then its likely to be outdated. But I agree with the core concept, learning low level will of course make you a better programmer for sure. So if the invesrment is in yourself its great. If the investment is in a tangible product maybe not so much
@@flipdeezy1218 It's weird that I have to mention this, but I'm not trying to compete with AAA games. I'm doing a retro RPG thing on my free time, it ships when it ships, so the mere notion that it could be outdated feels somewhat irrelevant to me. If I wanted to produce a modern game quickly, I would use an engine and work with a team. I'm an engineer, I kinda did the math already!
This makes a good point. I just got a comment on a video I uploaded a couple years ago showcasing flowfield pathfinding in GameMaker Studio 2, and the comment just reads "code?", he just wants the code so he can use it. How did I write the code? I researched and coded it from scratch. That's how I typically do it. I need to be able to pathfind n-number of units to a location, including group steering behaviors and such, I learn how these things work and code it. I don't dig around and find a premade answer that either does or does not truly fit my needs. I just make it. On top of this, I make it optimal. I programmed it in C++ and exported it as a DLL that can be used by GameMaker, so it's performant as possible. Doing it the hard way makes you significantly more knowledgeable and capable, and gives you a better understanding of complex problems and how to solve them.
I made my previous comment while still watching the video (at the beginning). I just finished watching it. I totally agree with you. It's actually my philosophy in life. I even went farther than that. I am involved with all part of IT processes: * Programming in assembly; * Learned to write basic operating systems just for the sake of learning; * Backend programming; * DevOps; * Data Sciences; * Artificial Intelligence; * Frontend programming * Learned Haskell (because I was told it was difficult to found out that it is the easiest language in the world and my favorite), Elm, Q (sort of APL), Rust, C++, Scala, Java, Dart, Python, JavaScript, PHP, Imba, ReScript, and many more; * Learning various programming paradigms; * UX-UI design - Framer, Figma, Inkscape, and some more; * And even photo editing - Photopshop, Gimp. Initially I am a mathematician, who dealt with programming because it was part of my curriculum from High School till Post Grad. Then I decided to get a Post Grad in computer sciences. But I still stand in my conviction that anyone serious about programming should go through fundamentals starting with Information Theory, Computer Architecture, Operating System theories, etc, up to learning about various programming approaches. Definitely, peering under the hood of a library should be a hobby and sometimes part of one's job. And I still understand why some folks don't want to bother going to far knowing about programming - they are not programmers in the first place, they need a programming language just as an accountant needs spreadsheets. Programming is just an accessory to what they really do. You are definitely giving to some good advices. TWO THUMBS UP!!! 👍👍
So stoked you watched the rest of the video :-). The sense I get from your comment is that many of the so-called "specializations" in software are kind made up for marketing purposes, that if you are involved in the field, you really should explore all of it, and some of it at a deeper level. It makes you so much more effective in what you do.
The issue is, not everyone is a programmer, some of us are just artists who want to make simplistic yet express games, it's the reason things like RPG maker exist, we probably wouldn't have yume nikki, oneshot, omori, fear and hunger, etc, if "the hard way" was the only option, it 100% depends on goals
In that case, you probably went through the hard way with art and thus have a better understanding of the tools you use there. So, yes, it's all goals.
Yes. 100%. Totally depends on your goals and what your interests are. I think a lot of low-level advocates forget, or fail to realize, that a lot of people simply aren't interested in learning how the "bare metal" code or hardware works. It's like a mechanic saying that all people who drive should learn how to rebuild an engine. If someone is really into that, and doesn't mind getting dirty, then sure, but most people just want to get from A to B.
I think the video is more targeted at programmers who have always been told, "use libraries; don't reinvent the wheel; save time; be efficient". If you're not a programmer, then this advice really isn't for you, and without that context it wouldn't make much sense. It's like if artists were always told, as if it were self-evident, "use pre-made graphics; don't draw something if there's an existing picture of it; save time; be efficient". It's really bad advice and now that I think about it really only comes from a drive for economic efficiency over actually making something good.
building computer vision library, writing the most fundamental image transformation algorithms to writing optimized algorithms for local neighborhood algorithms!! this video is a rare gem among the sea of people who claim to do things from scratch and end up using frameworks and libraries!!
It feels really good to have a more granular understanding of everything by building it yourself. Experimenting and wondering how and why things are the way they are.
Here's a reductio absurdum. Why don't you build your own language compiler? Jon Blow is doing this for example. Why should he or should he not? Should you write your own text rendering pipeline? How about building the tools to draw the art? The gist is, where do you draw the line? If your goal is to make a product and while doing it learn a new skill (i.e. an aspect of low level programming), then that's your goal. Learn and build something at the same time. Just know the cost. If your focus is gameplay programming, and game design overall, then it is perfectly reasonable to use an engine and finish 10 games and iterate on various ideas within the amount of time you could finish only one game, and focus on the gameplay only 10% of the time. So it all depends one's goals. There is no fixed answer.
You have to pick the workflow that works for you, your interests, and your goals. I am a programmer. I enjoy it, and I think going one level lower than where I was comfortable is enjoyable and interesting. But some may not want to grow their careers in that way, and that's perfectly fine. You don't have to go down to mining your own silicon, but it's good to get out of your comfort zone and go a level lower than where you're comfortable.
Yeah, it all boils down to goals. Engines allow you to have a general understanding of how many different games can be built, and how people interact with them, very fast. This versatility and experience with different projects can also prove invaluable later on.
The point is that even AAA studios aren't starting from scratch if they already have an engine. Even if your engine is in-house, chances are it's packaged as libraries and the gameplay programmers making a new game "from scratch" are just linking those libraries and calling functions. The engine is a black box - they likely don't even see the code and they certainly don't touch or edit any of it.
This mirrors a lot of my thoughts on my own pursuit, 3D art. An incredible number of things have been 3D modeled already, but It's not about having a certain asset, it's about learning how to make them yourself. I do also happen to enjoy coding, but if I were to create a video game I would almost certainly use a higher level program like unity because that's just not the area I want to specialize in.
I've definitely shared this sentiment recently. Most of my career (10 years) has been with heavyweight/complex languages like Java, Python and Rust. After all that, I find it really satisfying and refreshing to write zero-dependency C code, just solving problems and implementing data structures on my own. Right now I'm working on my own language, close to the semantics of C but with some of my own opinions on syntax and types. My goal is to finish the first compiler in C and then port the compiler to the language itself. After that, I hope to conquer baremetal and build my own kernel and OS. There's a lot to do before that, but I'm confident I can get there with enough time and research. And, it's not about the destination, but the journey 😄
Also, part of my current job is C++ firmware, which does give me several opportunities and a bit of leverage to be able to write my own libraries. That's definitely one of the perks for me
So I just started learning how to program microcontrollers with C as a hobby. I have no programming background, so I'm learning C and Microcontrollers at the same time. It's damn hard. But I love it. While there are many libraries and APIs I could use, I decided to avoid them as much as possible because I want to learn the details myself, create my own libraries and APIs myself. I feel like if I just start using the libraries and such, I'll just come to only rely on them, and I'll never truly understand the code I'm writing. Wish me luck!
As someone who has made a basic Engine (Elafri on github) from scratch and as a result has had to tackle a lot of issues, most notable 3D rendering on the CPU, I really agree with your point about confidence. This engine was my first project when I was new to C and it started as how to display colors in the terminal to getting keyboard and mouse input from the terminal to drawing 2D and then 3D graphics and then I even ported it to SDL too and now am using it for a 2D platformer game (Ive used it for many more programs too). The feeling is comparable to assembling your own car and there's nothing better than watching it run and knowing what you're capable of. When I want a graphical program, I can use my engine and I dont have to go to godot or unity or use some big library to do things. Anyways, I rambled a bit too much but I really do agree with your points
Yes! In the process of making my game, I also built my own gaming PC. It was great to work with the computer in a non-abstracted way. Look over there, it's the actual CPU, and I'm literally putting it on the motherboard with some thermal paste. That over there is the actual memory. Now I'm going to install the GPU where every frame gets drawn. Oh, look over there, that's where the power for this beast comes from.
It's true. If your goal is to learn the right way, do it the hard way. As software developer I say the harder the task is the more there is to learn in the process. However, I also see the other side of the coin. If you can accomplish much bigger goals by using the tools that are already there, the only rational approach to reach said goal is to take the shortcut. So, yes you can argue that the hard way is better if you have certain goals but also the same goals can benefit from taking shortcuts if you're fine with being more knowledgeable when it comes to the existing tools than building the tools themselves.
Yup. I drew the line at making my own compiler. However, I am still open to it. The thing is, I just don't want to do it at this stage of my career. Jonathan Blow made a compiler, but he had two successful games before taking that on.
Everytime I talk about linear algebra or foundation for rendering objects or vectors for the physiques, I often get answered like “what’s the point? I’m more of a high level programmer, I use libraries for this and that”, or “this framework already does this thing you wanted do to, you are wasting time”. Well after me doing these things I started to realize how little things I knew and now how much more I know if I am compared to those very persons. I’ve done some deeper ray marching and I’m very happy of all the foundation I learned. My next goal is to make a very simple render engine in ray tracing now that I understand this enough to try. Thank you for your words
Thank you so much for this video! I've been working on my own little game engine too (with a little scripting language just for it!) in Haskell and C for a few months now, and it's been my favorite project I've ever done. I chose it because I wanted to learn Haskell and I wanted to get better at both functional programming and lower level concepts. And it has taught me SO MUCH!!!!!! I learned SO MUCH from this project, far more than I would have learned if I had just made another Unity game. I've been feeling so discouraged lately though because I saw people in forums saying the same thing you mentioned someone said to you at the start of the video .The whole *"Why bother? It's useless, someone else already made an engine you can use!"* argument had me genuinely considering giving up on this side project entirely out of shame. Your video actually gave me motivation to keep going, so thank you so much!!
That's awesome! Keep at it :-). It's always good to have a specific game in mind that you want to make with your engine. For me, that really increases the motivation factor.
thank you, will try once and for all! the mental struggle that makes one believe it's and almost impossible challenge is what has kept me just using handy tools/frameworks instead of digging deeper into how things work.
You just need to realize that seemingly impossible things will become easy after enough practice. Most people give up too easily, that is really the only roadblock.
My philosophy with this type of thing is that I learn enough to work first then learn the rest. Or in better words: I learn what I am motivated to learn now and hope for more adhd motivation later for more things.
I too started out making games without engines nor frameworks. Some of my first games were made with vanilla Javascript, vanilla Java, vanilla Python and/or the BASIC programming language and I am VERY VERY glad I did it that way!!!! I felt that it was more fun and I learned a lot more. I learned how and why things worked the way they do. So then, when I started using game engines, the game engines made more sense and I learned various game engines a lot faster. Plus, in the vanilla code based approach, I didn't have to deal with the bloatware that comes with game engines. In game engines, there are always a ton of functions, etc. that I don't use. Finally once I built my first game; given that I knew what was in my code and how things worked, I could reuse the code over and over and build my next game, etc. with it fairly quickly. Btw, the same skills could be transferred to web development. I could build websites very quickly by simply doing most of what I did when developing my games. The same skills applied!
This is a great video! This exact logic is why I’ve made quite a few programming languages, and I’m currently working on my first high level one! (I’m pretty close to completing the compiler/interpreter, maybe a few weeks left)
I just found your video, and it sounds a lot like something I wrote a while back, "Programming as Craft". Good to hear that other folks are thinking about this, too. You also touch on the reasons I advise people to build their own tools. Buying-in can seem fast and easy, but there are multiple costs waiting for you.
Not that I haven't had to overcome my share of programming obstacles, too, but your snowboarding story reminds me of something more to the point. Before I got into a programming slash technology career, I worked for a local public works department. I don't remember what job triggered the thought, but I distinctly remember thinking, "Don't they have people to do this?" Then it dawned on me: I _was_ the "people to do this". There's a lot of menial tasks that go into software development as much as in daily life. Without people putting in the groundwork to develop game engines for the rest of us, we'd all have to do it ourselves.
Ooh more story time. There was this one time when I was in the terrain park at Breckenridge, hitting the largest jumps they had. This guy rocks up to me and asks me what the speed was for the jumps. It took me a moment to recognize him as Andreas Wiig, this big time pro I had looked up to for quite some time. Here I was, a nobody, just doing straight airs and warming up, and he was asking *me* for the speed. And then it occurred to me that so far as he is concerned, in that moment, I was the expert. If you are at Breckenridge at the big park at 9:00 A.M. on a Wednesday in January, you are as close to pro as it gets. Whether you acknowledge it or not, you are in that milieu. 🙂
I was solving a problem by not using the in built libraries and got frustrated and turned on yt to chill. I was really looking for someone to reassure that what I am trying to do isn't really futile. Thanks!
I think this is definitely true if you are trying to be a programmer. If you’re trying to make a great game, I believe it would be more worth your time to use an existing engine and focus on the gameplay loop, visuals, etc. Additionally, some of the biggest engines like unreal have features that are simply not feasible for a single programmer or even a small team to implement. If you need something like Nanite for your game, you should just use UE5. No amount of solo development is going to be able to process things as quickly or as well as a game engine that has been battle tested by industry vets. However, if you’re primarily a programmer, this is 100% the route to take. One of the earliest CS classes I took had us write arrays, linked lists, hash maps, etc from scratch. Now in my day job, I never use anything but the built in versions of these same data structures, but I have the knowledge to know exactly which one I should be using. Additionally, I have the confidence (like you mentioned) to know that the structure I picked really is the optimal one for the task. I better understand how C/Python/Java is handling my memory under the hood, and even though I don’t personally need to do anything about that, it helps me write better code.
"If you need something like Nanite for your game, you should just use UE5. No amount of solo development is going to be able to process things as quickly or as well as a game engine that has been battle tested by industry vets." This is not necessarily true whatsoever, engines like Flax or WickedEngine which were almost entirely developed by a single person go against that claim. They are able to render and process things quickly, as well as doing the build process probably even faster than Unity or Unreal in most cases. Yes, a single programmer probably wouldn't want to try recreating Nanite from scratch, but they can make a similar system that accomplishes the same task. Also, Unreal is mostly open source, so if they wanted to learn how to code Nanite, they can just go read through Unreal's source.
Yes! I have plans to do a video covering all of the computer science concepts you will be introduced to in the process of making just one video game from scratch, using an actual game I made, Mooselutions, as a teaching example.
I'm pretty new to programming, I've been learning C# in college for 3 quarters so far. My most recent final involved making a program that can save and load data. We were supposed to use an existing library to do this, but I decided to make my program a game for the Godot engine. It did not want to play nice with the library, so I thought I would use it's existing way to save data. It turns out it was written to save game states. So I ended up instead using a feature where it could save and load individual 8, 16, or 32 bit bytes. And because of that, I had to get a hex editor, and learn a bit about how Unicode is saved, as I needed the player to enter a name, and also figure out how to make it read multiple save entries, as I wanted to store multiple scores. Normally, I'd just tell it to put everything in a list or two, if I were using the library to do this. I also needed to manage hundreds or thousands of bullets, each going on a unique path. I'm still working on that, but it's been giving me a clearer understanding of what OOP is all about. It's particularly making me more familar with inheritance and interfaces, as the bullets all need to be managed from one list, and need different data-driven behaviors that allow them to move on multiple co-ordiante systems. I'm still working on that part. Anyway, I got 100% on that final. I've been thinking about what you said about challenging myself. I'm very interested in how shaders work, and the basic ones in Godot are... well, for one I don't know how to use them, and for another, their equivalents in Unity are very boring. Even Blender's shader nodes are very limiting, even if I combine them with compositing stuff. I've also been thinking about future projects. Some day, I want to make an FPS, and I love the brushes and sectors in Source and Doom's engine. I feel like they make designing levels far easier and more fun than dropping in models. So I kind of want to make an engine that has those features, but without the baggage of GZDoom or source.
All you need to say is that its a matter of priorities. If you want to effectively ship games then using an existing engine is a no brainer. But building your own engine scratches a personal itch. Also is better for your career if you want to pursue technical work in the future. It's not an optimal path to becoming a skilled game designer, but its certainly not an invalid path. We all ultimately take the path that aligns with our preferences
Good advice, applied same in animations aswell, I've animated as a kid for years without watching UA-cam tutorial videos, coming back to it now it's super easy to actually do difficult things more easily
Let's go to the extreme first: Is it useful, to learn how every layer from setting up CPU registers to the highest abstraction works and recreate it? Yes. Do we have time for it? No. So where do we set the line? In my experience, it is one layer below where you usually work. In my dayjob, i do .Net applications with lots of lower level interop. Knowing c/c++ and archaic unmanaged programming ( no smartpointers! ) helps a lot when working with these components from a a managed environment. In my free time working with Unity, i slowly digging one level below the surface. And now when i see systems in the asset store i not longer think "wow, thats magic" but more often "okay, i got an idea how that might work".
I'm actually making my own Game Engine for my commercial game... And it's extremely enjoyable, you're constantly learning something no matter what you do, it's a nice experience.
This was a very inspirational video. Doing things the hard way, many times, is easier in the long run. Started my own simple from scratch animation library project after this video.
@@tedbendixson, agreed, though, I think part of it is, you just are more comfortable with the abstractions, because you have the most experience with them as the library / framework author.
I recently started programming a webserver with nothing besides the Linux API for using sockets. There have been a few points in the process where I stopped and wondered what the point of it was and if I would look back and realize it was a strange waste of my time. However, once I got past a particularly difficult point and had something that would compile and perform a simple task I realized that I could keep going and see how far I could push this and how much could I build without touching a library. Then I found your video and it made me feel encouraged in this resolve. Thank you!
The problem is too many people enter programming with the mindset that they're doing it just to be successful. Those people take shortcuts and don't learn it properly. If you program because you actually enjoy it, then you'll be happy to do it the hard way.
But also, you won't always be happy. Maybe passionate would be a better word. The easy road is what leads to short-term satisfaction, although terrible in the long run.
Everyone needs money, but the pursuit of money alone probably won't give you longterm happiness. This is a lesson many people who become financially independent eventually learn. The day you get a million dollars in your bank account is just another day. You're still you, with all of your joys, frustrations, friends, pursuits, and fears. Money only solves your money problems.
This is so true. In the years that I've been developing games as a hobby, I've always tried to write as much code from scratch as possible. And my friends and people I know tell me I'm crazy for this, that I should just use Unity, use Unreal engine, etc. But then by writing much of my code from scratch, and especially the core logic that powers everything, I develop much more deep understanding of how different parts of the low end than I could get by using an engine that does everything for me. And then they're surprised when they ask me how to do some task that they haven't seen before or don't know how to accomplish, and I reply with an explanation of how the task in question interacts with the environment, and how to solve this task using some innovative solution. Great to see you communicating this message as well! We need more people to think this way.
My personal rule for the use of software I didn't personally develop is this: if I can't see the source code or make modifications to it, it's of little use to me because I can't learn from it. I aim to strike that middle-ground between speed of development and learning when I need to get down into more low level stuff. The Godot Engine has some really cool tools and documentation to get you started in Shaders; pretty dope.
yes!!! this is a great take. We should use tools not just for the sake of using them, but to learn. And opensourcing projects is the best way to keep them alive. Also, I love shaders! I started messing around with shadertoy and webGL shaders a while back, and I've been learning OpenGL recently. I should take a look at godot, thanks for the suggestion! :)
I agree! I've grown so much as a programmer, and can think programming problems through much more thoroughly since I started making games with Rust instead of a full engine
I have started with complex stuff and doing everything from scratch. I completely agree. although I am using premade stuff I have improved a lot and it benefited me a lot to know the low level stuff.
"I believe the question assumes your goal is to get something to market as soon as possible." I think a more reasonable goal would be to make any game at all. Not to call out anyone in particular (Randy), but it seems like a lot of people are spending years programming engines for super simple games. I can't help but think how far they could have gotten if they'd spent all that time actually making a game, you know, the part people play. Though It's a bit of a fools errand since the point isn't really to make a game, the point is to make a game engine. Anyway, I think the main problem with this argument is that it seems to assume 'programming the hard way' is the only way to challenge yourself. In reality you can find the same sort of challenge in the realm of game design, storytelling, art, or even programming in an existing engine. Time is limited and you have to make decisions. I think it's easy to trick yourself into thinking by choosing the hardest option for the immediate task is the best choice, where in reality you could be ignoring even harder and more worthwhile endeavors. And from the whole spectrum of game development, building an engine ends up looking a lot like the easy choice. It's all math and coding, stuff with finite answers and discrete chunks you can feel good about completing. It lets you ignore the far more difficult task of designing a game people will enjoy. It lets you stack one little 'win' on top of the other without ever having to ask what is actually being built (queue Randy talking about trying to figure out the core gameplay loop 5 years into development).
Yes, the caveat for anyone making a game engine, the requirement, is that you must make a game. I made one. tedbendixson.itch.io/mooselutions Now I'm making another. And as a make that new game, my engine will evolve to better support it and whatever future game products I make.
I'm sure many people share the same struggles that I have in learning programming. I have been trying to learn Python off and on for 4 years. I always got bored with it and left it. But I knew that it could be extremely beneficial to know one day. Just recently I decided to buy a programming book and just read from page one to the end. I am now roughly 200 pages through and can finally write useable code! That approach with a solid curriculum was the only one that worked for me.
Python is the only language I feel comfortable with these days. But I’m no web dev or game dev, so this is an example of where people may have disjoint goals. I can parallel process data on the GPU if I need unbeatable speed, and I can rewrite any application from other languages in half as many lines. Python just feels right to me! :) Not to mention the extremely large PyPI.
@@JordanMetroidManiac I agree. Python is very versatile for general purpose programming. I have been using it for TA on the stock market. The libraries that python comes with are incredible too!
This actually applies to everything that involves engineering. People tend to become used to knowing the essential while they could be so much more. I'm glad I learned this when I still was in middle school.
@@MrCmon113 Yes, you're correct to an extent. However, by understanding everything fundamentally, instead of relying on programs and tools, you'll definitely be a better professional. That's what I meant. Furthermore, people should always learn and study more stuff outside their areas and put their souls into their studies/work, that's how science advances. Sorry for any grammar mistakes, English is my third language.
But what if you don't agree with some of the so-called "progress" of others? You intentionally decide to go back to the point where they made the bad decision and build from there. I like to think this is what I'm doing.
I don't feel like I need to build confidence by making things harder for myself, I learned C++ instead of Unity because programming is fun. Like you said, everyone seems to think the goal of game development is to make money, even you seem to fall into this trap talking about how much money confidence is worth. It's an artistic pursuit and the primary reason behind making games should be a passion for game design. I'll be dead before I have a desk job at a major company, no matter the pay.
It's a complex thing in today's attention-driven economy. In so many ways, getting attention is synonymous with making money. So if you want your work to be known, chances are your work will in some way align with the goal of making money at some point, even if it's not right away.
you'd also be dead if the next economical depression hits and you have no money to sustain your apartment do what works for you but don't claim moral highground over which intention for creating games and art is the "correct" one.
@@thomas.thomas This video is about a private side project the guy's making. If you just want a job, you're wasting your time learning games programming in general. Learn webdev or just Unreal, since there's plenty work in those. But if you're making indie projects on your own with no funding or team and you're deliberately making things harder for yourself by programming, you should stop thinking about money because you're wasting your time. The odds of making it big are extremely small. I'm not taking a moral high ground, there's nothing bad about just getting a job helping someone else get their artistic vision fulfilled, working at some big company. But games are art, and how they sell is often directly linked to how much you respect that art. There's a reason entirely profit focused NFT games just won't take off, while something like Hollow Knight and Celeste, did.
I do want to make it clear that my goal is to make games that make money. I doubt my first game will be profitable, but I hope I take away some valuable lessons from the experience and use them to make something more profitable on the next attempt. Making a game studio is like rolling a giant snowball. You slowly build an audience for your games with each product you release. I just do my best to study the market and listen to my audience, trying out a bunch of little experiments and continuing to improve. That's really all you can do while you are alive on this Earth. Games are art, that's true, but it's also true that certain kinds of art are more appealing than others. Beautiful art is *one* of the reasons a recent hit like Blasphemous was such a big success, but it's truly a combination of many factors. They picked a profitable genre (Metroidvania + Souls Like), and they brought in their own cultural heritage in a way that hasn't been seen in other games. It's a uniquely Spanish game, and that uniqueness is why it occupies its own special niche. Their team has escaped competition through authenticity. I'm trying to find my own way to do something similar :-)
It wasn't until I started to make my own game engine that I realized how little I actually knew about coding. Looking back on old incomplete projects I can see how badly they were implemented and written, if I were to return to those projects they would look much different and be better for it. My code has become much less bloated and solutions to problems come much easier now, as I think about them differently. Interestingly enough I started on the make your own game engine journey because no premade engines worked well for the algorithm I was trying to implement without altering the engines source code. Also not having to shell out cash to Unity or Epic games after a certain sales number is reached is pretty nice.
This is the best video I've seen about programming, and even better after i found out i want to become a game programmer and not a web designer and stuff... Can't thank you enough for this, so all i can do is do my best, subscribe, like, and keep following you, thank you... Ted.
I remember having these kind of arguments with my teammates for my college senior project. We decided to make a game, and the team lead decided to have us go with Unity (against my advice, especially since we were making a 2D game). I was one of the only ones there who'd done *any* game development in my spare time and programmed before going to college, and it showed. I kept having to pull everyone aside to explain simple, core ideas and mechanics and they still wouldn't get it, saying "well it's just a school project, and we're using Unity, so we can just drag and drop stuff". What made it worse was that there was one other guy on my team who had worked with Unity before, and he and I butted heads so much. I remember a specific time where I said "we should make the bullets from this gun go through walls to make it distinct from the other weapons in the game" and his response was "that's impossible ". I asked why, and he said the "engine didn't support that" and shut down the idea, instead of thinking of how we could modify or build the physics engine to make that work. But I was used to programming my own physics and planning ahead for this kind of stuff in my own projects. The entire project was a pain and a slog, and I constantly felt like my entire team was against me just because of this basic philosophy. Did we get the game done? Kinda, one guy didn't understand unity at all and none of his stuff worked, but I was able to show off our game in a way to avoid that. Did we get a good grade? Yeah, we impressed our professors for sure. But did *I* like our project at the end of the day? Heck no. I wanted to redo it all without the constraints of Unity (or at least the ones placed by the others' ideologies) the hard way. Thanks for reading.
Man after reading all of that I can still see a bunch of green lines even after blinking 10 times. But anyways, as a former game engine "user", I used to just spam scripts (for litterally evedy object) and write dirty code. I realized that this kind of technology is the reason why mobile games nowadays during 2018-2023 is oversimplified or to put it bluntly, they're trash. Developers think "we can just spam the same concept over and over again and get a lot of money". Making games is so easy now that we can litterally be lazy as much as we want and still profit from games that litterally does not make sense at all or kill the braincells of many children. Whereas developers who programs in OpenGL with pure C++ are "forced" to make the game good because there's no way you implement a lot of stuff like vertex and index buffer objects, mesh classes, dynamic geometry, shaders, batch rendering, MVP, math stuff, collision detection, and etc, when your game idea is not worth the effort. Like why the hell would you torture yourself to make TicTacToe in OpenGL? In comparison, 2000-2010s game would use more shaders and more realistic graphics and games THAT IS ACTUALLY ENTERTAINING while PRESERVING the rational and logical thinking of gamers. Now everything looks the same because of corporate memphis and money-oriented developers in this industry. But hey, I'm not saying game engines are bad, they are good but it depends on how you use them. Saying "so we can just drop and drag" and not programming an entire idea just because of the limitations during the development process is an invalid excuse. While you're in school be wise and learn as much as you can. I hope people realizes the more effort they put, the bigger the reward becomes. Thank you for reading and have a great day.
@@BlueProgamer212 Thank you got reading, and providing a great reply with educated insight. I can definitely see where you're coming from, especially with modern mobile games and stuff. I used to have a lot of fun playing other peoples games and thinking about how they might have programmed this or that, and analyzing how I would maybe do it myself. But it feels like with a lot of games today on the Indy budget, I can't really do that anymore. It's all just so simple and streamlined and repetitive, and you can just tell how much less heart there is put into those games these days. But that also makes the games that do have the heart and hard work put into them stick out even more, in my opinion. Those games will stand the test of time.
i agree that doing things the hard way is good for learning and learning new skills is very important but if you want to get things done you can be a lot faster with tools. they exist for a reason.
It's definitely a nuanced conversation. I don't always do things the hard way and often use tools. I didn't write my own C++ compiler to make my games, and you could make any of the games I've made with an off the shelf engine. For me it comes down to satisfaction with my work. I just have the kind of personality that enjoys knowing how things work and getting them to work reasonably well because I have that knowledge. It's satisfying, like playing real life Powerwash Simulator.
and then you have developers who only know how to work using those tools and since they dont understand how they work under the hood, they write absolutely terrible code that fill the modern software landscape with bugs, inefficient code and antipatterns...
Waoo man! That's actually the right mindset. We can't push or force someone else to work the hard way, but no one has to criticize the way we approach to things. I wanted to do things the easy way and I realized a long time ago that doesn't work. Now I'm working hard and smarter. For me hard work is a long term smart work. I wish I saw this video just right the day you uploaded it. Hopefully you're doing great!
Great Video! These people who are talking to you obviously have never met a "hand tool" woodworker. I've always been pushed at work (Engineer at Manufacturing companies) to make things faster, cheaper, more economical with resources. When I'm working my hobbies (woodworking, programming, leatherworking) its nice to do things the "old" way, the "hard" way the way that actually allows you to master a craft instead of just get the job done to move on to the next one. Through doing things the slower/older/harder way give more understanding of how things work and at that base level, and it allows you to see much more clearly, not only in the thing you are doing but in other things as well. There has to be some journey to life outside of careening from milestone to milestone as fast as possible.
Love the message in this video. Challenging yourself is such an important part of learning and the key to creative fulfillment. That being said, there’s no way I’m ever making my own game engine lmao. I’ve got a lot of respect for it though!
From a career trajectory POV, I think it’s definitely a balance between doing things the hard way, or using some pre-existing software. You don’t want things that are so hard that you’re not a productive teammate, but you also don’t want things so easy that you’re not growing professionally. For personal projects, I think it’s also a balance; but that balance should be based on whatever your goals are. Are you looking to make a game super quickly? Then making your own engine is probably not the way to go. Are you looking to really understand how things work under the hood? Then writing the stuff yourself seems like a good option. From personal experience, though, I agree that the path with the most unknowns generally leads to the most learning and growth
I love this. Jonathan Blow talks about this kind of stuff all the time. I have been working on my own game and engine in C for years and it has been so rewarding.
Learning to make games from scratch taught me all sorts of things about math, computer science, and physics. It even makes using a video game framework trivial.
Well, in the olden days (and current when it comes to in house engines like Nintendo etc.) The programmer would build the engine and tools so the game designers could do high level scripting mostly by themselves. I am grateful for these premade engines like Unity because they allow a game designer with minimum programming knowledge to create something with a reasonable level of efficency in simpler types of games like 2D games.
This is so true. Subbed. I've had to write a couple of simple libraries from scratch, so I understood what was going on in them and so they produced the correct values.
@@tedbendixson If you always stay in your comfort zone it's bad, but if you try and do too much it can be overwhelming. So the best approach is somewhere in the middle. It's called the Yerkes Dodson Law
@@tedbendixson If it's your first day in the gym and you try and bench 225lbs it's stupid, you should start small and gradually build from there. Same thing with programming, that's why I think beginners should start with an easy language like Python instead of a low level language like C. That's just my opinion
Enjoyable and motivating video! Also the game-mechanics look very fun to play and the character looks very nice. Keep up the good work and keep on tangling with those sea-monsters 😃.
I was in agreement before the video started, but after I felt very motivated, as I have postopned coding from scratch, although thats what I really need to do. Thanks for a great explanaition!
Keep it up Ted! Another great talk. New character art and animation looks very cool, waiting to see when the rest of the world is also with new art assets.
I can't agree more that understand how to program in low level / how computer works in low level makes me more confident. Reading some classical textbook is so boring and hopefully here we have you make these videos.
Seeing the footage of the game when it was just solid colored blocks brings me back to when I started learning programming myself. Like you, I decided to make my game engine from scratch. I never finished my game, but I learned so much in the process. I did many things the wrong way. But that’s ok, because I learned from it. Would I do it again? Probably not. Today I would just use Unity or whatever. I’m too aware of my time budget now, but I’m happy I made my own game engine (how bad it ever was). No regrets.
You've gained a new subscriber :D. I think in the same way, I have been working in software development (mostly in the web) and I am starting to loose a bit of joy doing things, no matter if its a startup with a "great product", or even worse if you deal with a legacy project and you provide value and fix things in the middle of it at the same time due to working in software is not always perfect, and it's not going to be always a green field land of projects. I remember when I started writing some npm libraries (they're outdated at this moment and also useless due to there're a lot of them out there and even better), but doing so gave me a lot of confidence and started taking more and serious challenges. I am currently in the process of working with graphics and your video is a great start. Thanks.
I think there's a difference between being familiar with your tools and understanding fundamentals, and refusing to use the tools available to build everything from scratch. I'm all for exploration and learning about lower-level systems, but that doesn't mean you have to finish a full project with it. I had this conversation with my dad who's being programming for a long time. He has a CS degree and grew up working with electronics. He wanted to start making a game and wanted to do it all from scratch. So I asked him if he is going to write it in assembly and or machine code? Are you going to build your own components? Obviously not. There's a lot of value in understanding these lower level concepts, but when making a game, it's unnecessarily limiting to try to "reinvent the wheel." He tried building his own engine and he could of course do it, but it was impractical to do while working full time on other projects. Once he stopped arbitrarily limiting the tools he could use, he actually got a game up and running. Basically, it's always good to improve your knowledge of a subject and understand the fundamentals, but that doesn't mean you have to commit to building from the ground up on any given project. Setting aside time to study and tinker around with some components at a lower level of abstraction is enough. Also I agree with the overall point of the video. The intro just made it seem like using prebuilt engines is some sort of cop-out.
Good points. I've got another video coming that addresses it. If anything, I'm hoping people got the idea that it's good to drop a level or two below where you are comfortable. Sometimes you'll do this for learning purposes and in other cases to get a degree of control you otherwise couldn't. My reason for not using an engine has more to do with longterm business goals. If I plan to be in business for forty more years, I want control over my game's source code so I can remaster games over and over again without having to worry about engine updates. Other folks will have different goals.
Kinda feels somewhat of a common trend, sadly. Every now and then I visit my fellow programmer friend's progress making their own 3D graphics engine from scratch in objective C. I mean I'm not necessarily learning a lot by inspecting that but mostly about what I really want to be learning and what I don't.
Casey Muratori really opened up my eyes to C (and eventually Jai). I had previously spent most of my career on Java, C#, SQL and web dev stuff. I had grown so disengaged because so many dependencies regularly broke for long periods of time for reasons that made no sense, and because the SOLID OOP religion that I had bought into was eating at me. I clearly remember when I first saw Casey make a few lines in a batch file and state that no matter the size of the project, he'd never need more than that to build the project in a few seconds (and even said it could be a lot faster if the compiler was done efficiently). The way he writes code was so simple and easy to understand, yet also extremely powerful. Then I finally knew where I had gone wrong.
I started to work on my game engine because I thought it would be more fun to learn programming stuff that way compared to the Web2.0 hype that was there when I was in college. I mainly developed my engine around hurdles with retro inspired games at the time, namely that the pixels often went horribly misaligned. Currently I'm using the CPU for rendering, which would give me enough sprites for even some lighter bullet hell games, but I'm soon moving it to OpenGL, all while keeping the classic palette-cycling effects my engine is capable of without using shaders (I figured out a way, that would enable me to use a global texture as a palette). I even added some software synthesizers and a basic MIDI sequencer, later on I want to experiment with dynamic soundtrack.
I think learn whatever is relevant to you, and it sounds like low level C was relevant to you and helped you out. That may not be the same for others. With that said, I agree that fear is often ridiculous in its assumptions and holds people back from doing something. I try to tell my friends that art is just as much engineering as programming is, so stop being afraid of it, but thankfully it leads to a less saturated jobs market.
It's so true. I have been learning programming for 3 years now 2 of which were at university and while they teach a lot of really good ideas really well they never really encouraged us to step outside of our comfort zone but I usually do anyway. Right now I'm programming a 3d printing slicer and knew nothing about the math behind(and yes math is important for programming) and I don't think I ever learned how to write good code since if you already don't understand the problem well you have to write your code in a way that it us easy to understand and follow. And yes while programming things far outside my comfort zone does sometimes feel like banging my head against a wall constantly I do feel like it made me a much better programmer than just following tutorials and using already existing tools.
Currently getting into electrical engineering so i can fabricate the parts of the circuits i want to execute my code. Still sideeying both the island of stability and the possibility of a second page of the periodic table via muonium to make my own elemental materials for all of that.
Same, TBH. I'm just taking a slower path to the bottom. I think first I'll do a drive-by of FPGA programming before I create a lithography machine so I can start fabricating chips from raw sand, but creating your own elements kinda requires a nuclear reactor. Which is a bit expensive, unless you make your own steel and concrete, so I guess that's what I'll be spending my 50s to 120s on. Then I can actually start building the thing!
I made 3 puzzle games using SDL. I liked that it was very low level and gave me a basic set of functions to create a window and draw rectangles. And that was all I needed when I made my Tetris clone. The hard work was in designing the data structures to represent the grid and the blocks and detect collisions when moving and rotating them. I felt that satisfaction of knowing I wrote 13 kb of code just on the mechanics of the game and it all worked.
For a simple 2D game without fancy effects, and only on one platform, sure you can use your own game engine. It gets hard when people want to write sophisticated 3D game engines, or even worse for different platforms. At that point it makes no sense to build one yourself, unless you specifically get payed for that.
I think if you can hone down your 3D game concept, you can do 3D reasonably well. It took me about one month to get basic 3D rendering up, and that's supporting both Mac OS and Windows. It's all about focusing and removing distracting extra features. I plan to discuss this in another video some day.
I am a computer engineering student and there is one prof in our university that really had an impact on a lot of us, teaching low level computer architecture and computer systems. He would preach the exact same things, and now, after completing the two courses that he teaches, I feel so confident with C, its like I am a completely different person. He had us write an emulator in native C for a RISC architecture that he designed a few years back. Took the whole term, just submitted the last part today. And oh boy, seeing that thing run assembly (that we also wrote) at millions of instructions per second, interfacing with devices, interrupts, using cache, the whole works, is such an amazing feeling. Try the hard stuff people, its amazing to see it work at the end and know that if someone asked you about that project in an interview or just out in the wild, you could explain to them every tiny detail because you TRULY know it inside and out.
It's great to hear that the Object Oriented Industrial Complex hasn't completely taken over academia yet :-)
what institute are you in?
@@tedbendixson I go to Dalhousie university in Canada. Definitely not the greatest university out there, but prof. Larry Hughes (search him up on rate my prof) has made it all worth it.
What were those courses if you don't mind sharing? Or the textbooks used for reference
@@marcosaraque6223 ECED 3401 - Computer systems, and ECED 3403 - computer architecture. He also teaches a fourth year course - Real time systems.
Regarding books, we didn't have any. He is an old school prof (he is like 80), and would mainly teach on the whiteboard. We would get long textbook like pdfs that he wrote, and for the computer architecture course we got a one hundred something page ISA, essentially like a data sheet for the architecture that he designed. We based our emulator off of that document.
I started programming back in '78, at the age of 10. I think the better programmers naturally gravitate towards doing these kinds of things. Things you should do at some point, as a programmer: Write a compiler, write an OS, write a 3D renderer, write a text editor.
The compiler doesn't have to be great. It doesn't have to be practical. But it should be comprehensive enough that you can demonstrate a lot of the fundamentals of compiler design. In addition, this implicitly requires an understanding of assembly/machine code, which I also think is important. I think the compiler is actually the single best project a programmer can do because every programmer should understand what I compiler is doing.
And you don't have a create a full-blown OS with tons of functionality. But again, enough to demonstrate an understanding of the fundamentals. And again, requires a knowledge of assembly and hardware.
All of these projects; Compiler, OS, 3D renderer, and text editor, require really stretching yourself as a programmer and delving into areas that mainstream programming doesn't often go into. But there's tons of great techniques and data structures to be learned by delving into these areas.
I wrote a basic 3D game engine with some buddies back in the mid 90s. Wrote a pascal compiler in college. Wrote a 6502 OS many years ago and recently started tinkering with the idea of writing a basic 64-bit OS. I haven't done a full-blown text editor, but it's on my to do list. I've done smaller editors that were built into apps that had some basic functionality, and that's what piqued my interest in writing a full-blown editor. Like these other things, it's a whole rabbit hole of data structures and patterns to learn.
Yes! If anything I want to ask people, "don't you want to know? Aren't you curious about how this stuff works?" I am. Learning new things and challenging myself is what it's all about. If I'm not doing that, there's no point programming anything. It makes the process enjoyable in the moment, which is really all we have.
I've tried to make an argument with this same basic lesson to so many people over the years. It rarely sticks, but I am certain it's the truth. Personal growth is everything, and efficiency without growth is nothing.
I'm a fan of what Ryan Fluery has to say about this. He recently wrote an article saying it isn't about a rational argument, it's more of an aesthetic or system of values about what programming should be. I value knowing how things work and reducing complexity, and I won't compromise on that, even if I get a short term win.
@@tedbendixson Sounds like I need to look that up too. That resonates.
While i do agree, because i share the mindset, let me tell you you're making a big mistake in assuming other people even so much as care. X is only relevant to people that care about X. Ie, growth only means something to people interested in growing. Some people just aren't and there's nothing you can do to change it. You'll just become frustrated for trying to fit a square peg into a round hole. As a trainer, one of the things you learn to do real fast is assess your trainees goals and mindset. Some just want to close the knowledge gap at hand, some want to do it AND go deeper into it. Knowing which is which is important so that you know which you can push a little more.
And that's just "interest", then you mix in "competency" and things get a LOT trickier. Some people can grep it, some can't...
@@ErazerPT I agree. Handmade is a vibe, a system of values. If you don't have the same values, it's of no use to you. I made the video to assert my values because I felt like there are too many other videos asserting different values which aren't my own.
growth without ever finishing and publishing a project is also nothing, and in fact can lead to severe low confidence and depression - you know so much yet there are no completed/published/profitable projects to show for it.
if i could offer a slight generalization: take time to actually understand how your tools work. this can mean writing things from scratch, contributing to open source projects, or even just studying other people's code in depth. It really is incredible how quickly you can outpace 90% of professional programmers if you work like this. practicing how to learn is a compounding reward. the more you throw yourself in over your head, the faster you'll get at pulling yourself out. eventually, you get to a point where prior experience basically doesn't matter any more because you're so good at learning on the fly. even if you're just looking out for your career, that opens a ton of doors for you.
even more generalization is: don't skip the fundamental courses for anything, not just coding. Learning some skill the hard way is about learning how to get methods to improvise, innovate and getting more technical to know the strength and weaknesses of every path to wisely choose how to get the work done depending on the variable constraints of each project.
Sure academic methods are tedious but taking convenient shortcuts doesn't give you a master or engineer level.
This is actually really good advice. And personally i found it more useful to me than the advice in the video. I've always found trying to learn how things work even a little bit was always better for my own growth than trying to go all in on a single subject.
@@PainterVieraxokay this is too generalized for me.
@@weirdo3116 well, the boring studies in technical courses are there for a good reason.
For example if you don't know how to recognize different woods and knowing their characteristics you probably shouldn't make any structural woodwork by yourself.
Or if you don't understand how pigments and mediums have different proprieties and how superposing layers should be planned carefully, then you will not have any successful painting job.
Another example: if you skip algorithmics and how the OS and the processor operate, you'll get a hard time improving your coding skill.
And in general, in many skills there are safety precautions to know and apply, even at the lowest level jobs.
@@PainterVierax yeah but your advice is way too generalized. It's basically saying you gotta learn every last thing in your subject before you can even start. Difference between saying you should understand how something works vs you gotta go through ALL the fundamentals before you can do what you want.
One is way more interesting and actually helps you to grow personally. The other is just running through a checklist and hoping they/you actually learn anything useful.
Here I'll put it like this. I'm the first way i actually feel like I have the power to go and learn how stuff works on my own. In your way i just feel like I'm playing a slot machine for 100hours hoping I get a jackpot.
looks like the algorithm is giving this video the attention it deserves.
really tho, knowing the ins and outs of your projects and tools doesn't just force you to learn new skills, most of the time it makes you capable of saving time and avoiding problems in the long run.
If you do it the hard way, you learn how to program. If you do it the easy way, you learn how to click buttons in a user interface
data entry vs hard programming
The gap in difficulty and skill level is huge
Everything you do is based on clicking on UI created by someone else. Get a Unix source code and begin from scratch to the point where when you are succeeded, nobody cares. It's all about choices! And none is wrong.
@@manz5435 not really?
@@manz5435
> Just clicking a UI instead of making your own GUI from Unix source code
> Just calling Unix functions from a library instead of making your own OS.
> Just using C to make your OS instead of using Assembly.
> Just using Assembly compatible with the system instead of making your own.
> Using the existing bios instead of your own, to interface with the hardware.
> Using pre-made hardware instead of building the components by yourself.
> Using manufactured spare parts instead of designing and making your own.
> Using refined metal instead of digging out minerals to make your own.
> Using minerals from pre-existing earth instead of evolving into a 7-th dimension Giga-Demon and creating your own universe.
That's just pathetic man. Why even try?
@@manz5435 Yeah I can just encircle the area why use calculus LOL
Now that's a good talk. Now I'm gonna go write a compiler in css
Make CSS tiring-complete and add it as an interface to a database
May god be with you
No. I think you should write an operating system in scratch
@@jadedengineeringstudent have you seen linux on scratch?
I've made my own game engine, learned a lot, and now use Godot. I like this particular position where I'm efficiently using a game engine that's much better than mine while also being able to more deeply understand what it's doing. If I really needed to, because Godot is open source, I could modify it, which is a freedom I wouldn't of had if I didn't know how game engines worked.
My higher level of skill also allows me to do simpler things even faster and more efficiently. All of that is really awesome!
I think it's good to know how things work, but you don't need to reinvent the wheel. There's a certain point where doing that is no longer beneficial, at least.
Like, if I wanted to create a physics system, I'm clearly going to base my work off someone else's, and I don't mean code, I mean physics papers, software papers, Newton's formula.
I'm sure if I were to rediscover newton's formula that I'd have a pretty interesting perspective and understanding of physics, but the effort required to do such a feat would be near genius at that point. If also sometimes prevents us for really learning what we want. You mentioned that productivity and time-to-market may be the goal, you mention learning as your goal, and I think it also depends on what you want to learn. If programming is what you are learning, then sure, but if you want to learn game design, then learning how to make a PNG loader sorta distracts from that goal. And there's a lot of distractions along the way. At least, in my experience.
That's my two cents, perhaps like many thing in life, balance is the answer.
the source code for godot is very straightfoward, you can just read the main loop function and how it loads nodes one after another. The engine is a fancy text editor, if you open your scene file as a .txt you'll see it's just a series of node insertions and you can code everything using just that file.
I agree, I've made simple multiplayer games in SDL and GLAD/GLFW/OpenGL, it's fine to learn but there's no inherent revelation. Undertale was made by someone who can't code and Terraria is a spagetti hodge podge of unstructured code.
Wise comments
That's the same for every technical job. Rare are the decorators or art restoration technician who make their own paint or their own varnish. They just have the knowledge to decide what premade product are the most suited for the constraints and how to select cheapest or innovative products. Same with tile workers, plumbers, carpenters or any artisan job. That's why academic courses and fundamentals are important to not skip when self learning, even if it's the tedious part.
The term “reinventing the wheel” is so cliche and doesn’t even make sense. The wheel was a perfect invention; Unity and Godot and GameMaker are not. If you want a wheel for your specific game, you have to make it from scratch. You’re not reinventing anything.
@@captainfordo1 That's true, but I feel there's aspects of making your own game engine, such as integrating a PNG image loader, that is "reinventing the wheel" because you'll most likely not do anything different in that or other similar cases. There's definitely a point where you can create very spesific systems or overall architecture for your engine that match your spesific game requirements, but I think there's a massive amount of general things that a game needs to do that doesn't need to be remade any better or different for your average individual.
I know I didn't, anyway.
I didn't benefit other than the knowledge gained, of course.
Asset loading, shader processing, audio playback, physics resolving, input handling, and more are each components I'd call wheels that have already been created. A car needs 4 wheels to run, and just because the car is using wheels from another company instead of creating their own doesn't mean they couldn't still create a car that's spesific to their needs around the track or through the mud.
You, as the driver, don't even need to make a car of your own, why not just an existing car that solves the problem you have.
That car doesn't exist? Why not get a car that's close to what you want, and modify it!
Why not re-use existing solutions?
A reason I personally like frameworks like raylib is because it offers all of the existing solutions I need, but easily allow me to expand my own systems on top. Where I can focus, basically, on just making the core of the game engine, where I'm most likely to make the biggest difference.
I think Godot finds a perfect balance between being a framework and a game engine compared to Unity, imo.
Using Godot, I make my own game systems and managers that just run though Godot's main core loop and easily allows me to achieve complex AND spesific behavior with minimal effort. Plus, as aformentioned, it's open source, so nothings really stopping me from changing core behaviors to allows the engine to behave even more specifically as I want, if I truly need.
That's my two cents on wheels.
Web dev here. I very much agree and I became "low-level" enthusiast not so long ago. A lot of people say that building projects is a best way to learn and I agree, but if all you do during those projects is using high-level libraries that abstract all the complexity you're not really learning much. Or if you doing same stuff over and over. For job of course you want to use high-level libraries that get quality stuff done fast, but for learning purposes it's a terrible mistake that's gonna make you stagnant.
I agree. Going through so many tutorials they tell u to use all these frameworks or libraries without explaining what they really do or how it works. In the end u end up just regurgitating snippets of code without any understanding about how it works.
all about how bad u want it really.. if u want it, get it, and if u don't then ya know... I agree with u@@markcalvelo1909
Hey Michael, I've been really questioning lately whether I am programmer or a frameworker and I am starting to think I'm going down the path of frameworker. So my question to you is, as person with a Interest in web dev how would I gain a lower level understanding of the field? Any tips would be greatly appreciated!
@@UziTekk for example you could start by search how to create your own template engine, how to create your own route system, etc
@UziTekk find a course on operating systems, study the broad concepts then start coding in C using your OS's api. Like win32 for windows
I think people who are disagreeing are missing the point of the video which is do hard things to get confident and have deeper understanding of the things that you are working on but obviously if you need to ship a product out in the market take the help of tools which can get things done faster.
I think we also tend to assume that the tools will help us ship faster. In my experience, many of the tools I've used just got in the way of solving the problem, Object Oriented Programming being the canonical example of that. If you want to get something out faster, the best thing you can do is cut out needless complexity and features which are not core to your product. If you need to put a prototype in front of people, use crappy low resolution artwork and make a vertical slice of the core thing, knowing you can fill out the skeleton later.
Just because you can use a tool doesn't mean it's going to make you more productive. That's just a sales pitch. You don't have to buy that pitch.
@@tedbendixson You have to do OOP for a while before you understand how to use it correctly. Helps knowing multiple paradigms (functional, structural) and design patterns, but that's just the start really. It's not a panacea to knowing how to code efficiently.
I've been using a game engine for 3 years for a project, and if you are using an open source one, you are really not losing anything, you can always go deep inside if you want to know how it works.
It would have been impossible for me to code a 3d game of the scale (and quality) i have atm otherwise, it does save an insane amount of time, especially when the community creates someting amazing like the (Zyllan's) voxel terrain I am using or . I do use the "best" MIT engine out there however, so, you do need
That said, sure, I lack C++ exp to modify that engine easily, but I can't afford to in the lifecycle of my game anyways (entering marketing phase of what you can call an "early access" title). Soon, hopefully.
Anyways, end of my rant, Have fun with your project, it does definitely increase the learning curve for "lower level" programming (non game logic stuff like complex character controllers etc).
I'll also just note that I do have over two decades of game making exp of various kinds (mostly small 2D stuff) and enterprise frontend/backend exp, and also a few months of learning OpenGL etc, so, It's not like I am comming into this from a complete "only use Unity/Unreal" and never go low level, I can just skip reinventing some of the wheels BECAUSE i've reinvented so many others in the past 2 decades...
So, maybe myself and Ted agree, not back to actually watch the whole video. Do what you love doing kids, even if it's scary, that's the real key to success.
So, watched the video. There is just one thing i "don't agree" about it, which is that "knowing more will secure your job". It won't always. Most companies function according to "last in, first out" rules from my experience. Which means that you will be sometimes managed by people that know and have far less experience than you do. Yes, sure, they are domain experts, considering they spent say, 5 to 8 years in a single company, but for everything else? So, sure, knowing more than the next guy is great, but it's far from the main thing that keeps you in the job, unfortunately, it's really how much your immediate superior likes you vs the other person, and how much he has worked with somebody plays into that too.
@@tedbendixson OOP has it's uses, though.
Just take a look at the codebases of ss13 servers and tell me you could make the game nearly as complex without OOP.
The short answer is that you couldn't. There are simply too many variations of every object in the game.
The long answer is that you could, but you'd lose your mind in the process.
Loved your message. As a person whose only goal in life is to garner as much knowledge as possible, your “time + effort = rewarding knowledge” message is how I’ve lived my entire life. You gained a new subscriber!
Obviously, if you make everything by yourself, you will improve your confidence.
The problem I see with doing everything yourself is the time. And at work, where time is precious, I don't think it's productive to start from scratch everything.
The beautiful thing is you only have to start from scratch once ;-). After that, you have code you can reuse for the next thing. I use simple libraries for common data format standards like PNG loading (stbimage) because that's not really an interesting problem and it's just a proprietary data format.
I’m brand new to programming (installed python a few days ago) ran a few tutorials. Found it very intuitive and was having fun. I then saw a video on making a game in pygame. I first said to myself “no you need to finish these beginners courses first”
I obviously couldn’t wait and jumped straight into the game tutorial.. I’m loving it and feel like I’m understanding what/why I’m doing. Mostly because the tutor is explaining everything fully.
I then saw a comment on the video that went something like “I’ve just printed hallo wurld with python, now ill make this game” obviously being sarcastic. Lots of reply’s to the comment saying that it would be a terrible idea, and that such a person wouldn’t have a clue why they are doing anything.. but I did? I can’t wait to finish this tutorial and challenge myself to edit the code enough to feel like it’s my own game concept. I might not manage it. But it’s what I’m EXCITED to do
I guess the point in my comment is; you will ONLY learn the hard way. And failure is the best to learn from. And as long as your tutor is good enough at explaining concepts. You WILL understand the what’s and whys to your work
You're basically describing my adventures learning C. I started out like, "Okay, I have a bunch of programming experience in this kinda BS object oriented languages. I want to make a game because Unity frustrates me. Let's try this Handmade Hero thing."
I followed every episode up to the 50th, and I eventually got an understanding of lower level programming. I took the code and slowly ventured out into making my own games this way. I learned a bunch of graphics programming that isn't even in Handmade Hero because I built up the skills to research solutions and work on all my own, without a tutorial.
I banged my skull against a bunch of stuff I didn't understand, but that's fine. It's normal. You usually don't understand what you're building until the sixth or seventh time you build it all over again. Just trust the process.
What are the tutorials called?
@@karlarios5609they are by a channel called “tech with Tim” he’s got a few on there mostly titles “how to make a game in pygame in…”
Watching a tutorial is not "the hard way".
And saying that the hard way is the best is self contradictory.
If you did it the "hard way" - ie without tutorials, you wouldn't adhere to any of the conventions and probably use the language/framework all wrong.
I am in a similar situation. However, it is more that I am jumping from Python (smand Pygame) to learn C++ and SDL.
Yesterday I managed to make a window, which I am quite happy with
But maybe I should follow a video tutorial and do less googling as I go approach?
The "My job doesnt allow me to learn all these low level things argument" isn't the problem preventing people from learning the low level, its the consequence of avoiding the low level. If you don't know how the low level works then you simply become an user of the software, frameworks and libraries others created. They remains just magic to you, because you don't know what its doing, as such you're less effective at using it. Its like using a calculator without knowing algebra, you learn through brute pain and messing with things until they work, rather than from the underlying logic. Yes, you do eventually learn some stuff through sheer trial and error, and in the case of a calculator, you will eventually learn the patterns of the different arithmetic operations... But in the case of a framework tens of thousands of lines of code and concepts you've never heard of? Hard shit.
And plus, if we all just use whatever someone else has already made, without ever learning how it actually works, then what do we do when those developers who made all those wonders of software engineering retire? Whos gonna maintain that? And most importantly: whos gonna fucking improve it? Are we supposed to believe that the technology we have now is the best it will ever be, that there's nothing to improve, therefore no reason to learn it, and resign as mere users?
Accessibility is great, but it will never beat fundamentals, not in programming, nor in any other life endeavour.
Humanity has developed new technologies at an insane rate because people wanted to improve, nothing seemed "complete". But now this idea of "nothing is complete" is getting less popular and people are settling for less quality.
Free open source software (FOSS) isn't about helping save people money at the expense of the creator. FOSS is a culture about helping others learn and experiment without fear of legal threats designed to prevent learning. FOSS is the natural conclusion most programmers eventually come to after they build a bridge over a dangerous chasm: they want to help others to cross and maintain the bridge because, God damn, it was hard. Psychopaths are the ones who cross other people's bridges all their lives and then, when they build one themselves, they rig it with legal curses and explosives, then hide the blueprints to prevent others from defusing the deathtrap.
"My job doesn't allow me to learn all these low level things"
I don't know about you guys, but when I was learning programming on my own, there was nothing that could keep me from learning whatever I wanted. I was basically thinking about programming all the time and doing it as much as possible, outside of my job as a cashier. If you want to learn it, you can.
@@Ehal256 Exactly that! I started in 1983 with basic by the time I was 13 in 1986 I was doing 6502 assembly because commodore basic was terribly slow and it didn't allow me to make the demos I watched. Oh for the record commodore basic was a microsoft product -- back then they already only created shit.
@@atomgutan8064 I had rows about software quality! The complacency of developers is sickening. I don't care about clean code Uncle Bob crap, or how you indent or naming conventions (I like consistency) but what i care for is robustness and well tested stuff before you send it to the customer. And code these days is so bad it takes you less than 10 minutes to find flaws and bugs. And all because "we want to be fast to market". Well you scare your customers away with crap like that!
Teaching myself how to code and specifically low level code is what allowed me to be a Senior Software Engineer/Architect today. I started with Game Maker at 14 but quickly moved on to C/C++ and thanks to that I gained the confidence that allowed me to take advantage of opportunities that changed my life for the better.
Awesome bro, good job, I'm 25 now but just picked up C++ and directX to further my learning, I hope one day to get to your position :D
@@xxDeath99Starxx May I suggest Vulkan, "the new thing" in rendering, I suspect it will probably get a lot more attention in the years to come (since it's developed by a consortium of different companies in the industry). It's more low-level, but you can achieve much better performance.
Thanks for sharing your story. I've met so many people with a similar career arc
@@theRPGmaster Thanks a bunch for the suggestion, I shall look into Vulkan now, I haven't read much about it yet, if it's indeed more low-level than directX I will probably make the transition following my first directX project completion!
@@xxDeath99Starxx If you didn't know already the real advantage of Vulkan over DirectX is that it is cross-platform as well as being relatively low level to be far more performant than 'OpenGL' ever was. DirectX is for windows platform only but is the standard way to use those APIs which include the graphics API on Windows. On some games Vulkan offered improved performance over DX12 such as a 10% improved framerate on "Red Dead Redemtion II" while rendering the environment with equivaelt fidelity.
I'm a coding noob and I'm glad I found this video at this point in my journey. An analogy that makes sense to me is learning how to do Math (traditional paper and pen style) over learning how to use a calculator. The person who learns Math will be far more efficient and proficient in using the calculator in the longer term.
It's shocking how spelling and language skills have deteriorated because of spell checkers and grammar tools which have resulted in many forgoing learning the basics in favour of immediate output.
I'm South African, and I get professional emails from respected organisations with spelling errors, (we spell colour with a "U" here for example), because the software you use has US English as a default. If you don't have the right understanding you won't be able to correct and/or compensate for the shortfalls of the tools you use. I need to be able to recognise when my calculator is faulty, which would be impossible if the calculator is all I know.
No, why would they be more efficient with a calculator?
You're simply claiming that.
Spelling something "correctly" is only good insofar as it makes a text more readable. In particular "correct" is just how the majority spells something. If anything you should be happy for spell checkers cementing the supposed "correct spelling" instead of letting spelling evolve as it usually does.
@@MrCmon113 yes, but you're using language to communicate with others, therefore you want it to be familiar to others. you're not going to spell like an alien if you let spelling evolve, but khigha's point is that through the use of spell checkers, you eventually will be spelling like an alien because the only thing you relied on was a spell checker.
mathematicians are also a lot more efficient than a calculator, math isn't just arithmetic, it's way more than just that. every bit of engineering around you is made with mathematics, sometimes more advanced than what a calculator can help you with too.
Amen! You might enjoy the talk “Simple made easy” by Rich Hickey
I am enjoying that talk! Thanks so much for recommending it
@@tedbendixson Cheers! Another you’d like is Mike Acton’s CppCon 2014 talk about data oriented design. But if you are a fan of Casey, you’ve probably already seen it :)
@@cellularmitosis2 I wish I had found these programming circles half a decade ago, hah. Only half a year ago I found casey, and it’s been the most valuable thing for moving forward. More people should talk about this! There's too many echo-chambers on the web, and I want philosophies like this to spread to more people like me
I just watched this talk and I feel like I have a long long way to walk through, I did not felt that since I started programming 4 years ago, I'm excited
I'm coding a game engine from scratch myself, been at it for a few years now, and I agree 100%. People just assume I would want to ship asap and get rich quick, when I'm all about getting more knowledgeable by understanding what I do on a fundamental level (I'm a science / engineering nerd at the core). At the end of the day, what matters is that I'm doing what I love, and I don't care too much about what people tell me I should do, even if they can be patronizing at times.
Regardless, the idea that reinventing the wheel is a useless endeavor is just plain wrong. It's not like the history of invention is a linear succession of people solely reusing stuff that's already there...
Same here. I am definitely prepared to spend 5 more years on it, or however long it takes. I keep learning useful things in the process. Now working full time as a software developer there's less time for personal projects, but I'm very glad I spent the hours and didn't give up back when I had more time.
even worse, apparently everytime you think of using something or a certain language to create games people will always answer assuming you wanna make a triple A hit all by yourself, which is complete nonsense.
Only problem is youre working years on it already and prob have 5+ more years to go, which by then its likely to be outdated. But I agree with the core concept, learning low level will of course make you a better programmer for sure. So if the invesrment is in yourself its great. If the investment is in a tangible product maybe not so much
@@flipdeezy1218 It's weird that I have to mention this, but I'm not trying to compete with AAA games. I'm doing a retro RPG thing on my free time, it ships when it ships, so the mere notion that it could be outdated feels somewhat irrelevant to me. If I wanted to produce a modern game quickly, I would use an engine and work with a team. I'm an engineer, I kinda did the math already!
We have to ignore the ppl around us that just don't get it. They waste so much time preventing u from doing what u love.
This makes a good point. I just got a comment on a video I uploaded a couple years ago showcasing flowfield pathfinding in GameMaker Studio 2, and the comment just reads "code?", he just wants the code so he can use it. How did I write the code? I researched and coded it from scratch. That's how I typically do it. I need to be able to pathfind n-number of units to a location, including group steering behaviors and such, I learn how these things work and code it. I don't dig around and find a premade answer that either does or does not truly fit my needs. I just make it. On top of this, I make it optimal. I programmed it in C++ and exported it as a DLL that can be used by GameMaker, so it's performant as possible. Doing it the hard way makes you significantly more knowledgeable and capable, and gives you a better understanding of complex problems and how to solve them.
I made my previous comment while still watching the video (at the beginning). I just finished watching it.
I totally agree with you. It's actually my philosophy in life. I even went farther than that. I am involved with all part of IT processes:
* Programming in assembly;
* Learned to write basic operating systems just for the sake of learning;
* Backend programming;
* DevOps;
* Data Sciences;
* Artificial Intelligence;
* Frontend programming
* Learned Haskell (because I was told it was difficult to found out that it is the easiest language in the world and my favorite), Elm, Q (sort of APL), Rust, C++, Scala, Java, Dart, Python, JavaScript, PHP, Imba, ReScript, and many more;
* Learning various programming paradigms;
* UX-UI design - Framer, Figma, Inkscape, and some more;
* And even photo editing - Photopshop, Gimp.
Initially I am a mathematician, who dealt with programming because it was part of my curriculum from High School till Post Grad. Then I decided to get a Post Grad in computer sciences.
But I still stand in my conviction that anyone serious about programming should go through fundamentals starting with Information Theory, Computer Architecture, Operating System theories, etc, up to learning about various programming approaches. Definitely, peering under the hood of a library should be a hobby and sometimes part of one's job. And I still understand why some folks don't want to bother going to far knowing about programming - they are not programmers in the first place, they need a programming language just as an accountant needs spreadsheets. Programming is just an accessory to what they really do.
You are definitely giving to some good advices.
TWO THUMBS UP!!! 👍👍
So stoked you watched the rest of the video :-).
The sense I get from your comment is that many of the so-called "specializations" in software are kind made up for marketing purposes, that if you are involved in the field, you really should explore all of it, and some of it at a deeper level. It makes you so much more effective in what you do.
Do you recommend following this path too? I liked it a lot!
The issue is, not everyone is a programmer, some of us are just artists who want to make simplistic yet express games, it's the reason things like RPG maker exist, we probably wouldn't have yume nikki, oneshot, omori, fear and hunger, etc, if "the hard way" was the only option, it 100% depends on goals
In that case, you probably went through the hard way with art and thus have a better understanding of the tools you use there.
So, yes, it's all goals.
@@Alche_mist no i meant going through the hardway with coding when ur main focus is art, if ur an artistic hell yeah go through the hardway with art
Yes. 100%. Totally depends on your goals and what your interests are. I think a lot of low-level advocates forget, or fail to realize, that a lot of people simply aren't interested in learning how the "bare metal" code or hardware works. It's like a mechanic saying that all people who drive should learn how to rebuild an engine. If someone is really into that, and doesn't mind getting dirty, then sure, but most people just want to get from A to B.
I think the video is more targeted at programmers who have always been told, "use libraries; don't reinvent the wheel; save time; be efficient". If you're not a programmer, then this advice really isn't for you, and without that context it wouldn't make much sense.
It's like if artists were always told, as if it were self-evident, "use pre-made graphics; don't draw something if there's an existing picture of it; save time; be efficient". It's really bad advice and now that I think about it really only comes from a drive for economic efficiency over actually making something good.
@@excrubulent exactly, i think there should've been a disclaimer about who is this targeted for exactly
building computer vision library, writing the most fundamental image transformation algorithms to writing optimized algorithms for local neighborhood algorithms!! this video is a rare gem among the sea of people who claim to do things from scratch and end up using frameworks and libraries!!
It feels really good to have a more granular understanding of everything by building it yourself. Experimenting and wondering how and why things are the way they are.
Man you don’t have any idea how much I was needing this approach, thanks, pretty wise
Here's a reductio absurdum. Why don't you build your own language compiler? Jon Blow is doing this for example. Why should he or should he not? Should you write your own text rendering pipeline? How about building the tools to draw the art? The gist is, where do you draw the line? If your goal is to make a product and while doing it learn a new skill (i.e. an aspect of low level programming), then that's your goal. Learn and build something at the same time. Just know the cost. If your focus is gameplay programming, and game design overall, then it is perfectly reasonable to use an engine and finish 10 games and iterate on various ideas within the amount of time you could finish only one game, and focus on the gameplay only 10% of the time. So it all depends one's goals. There is no fixed answer.
You have to pick the workflow that works for you, your interests, and your goals. I am a programmer. I enjoy it, and I think going one level lower than where I was comfortable is enjoyable and interesting. But some may not want to grow their careers in that way, and that's perfectly fine. You don't have to go down to mining your own silicon, but it's good to get out of your comfort zone and go a level lower than where you're comfortable.
I mean the funny thing is many of us have done these sorts of things. The first two aren't even that uncommon.
Yeah, it all boils down to goals. Engines allow you to have a general understanding of how many different games can be built, and how people interact with them, very fast. This versatility and experience with different projects can also prove invaluable later on.
The point is that even AAA studios aren't starting from scratch if they already have an engine.
Even if your engine is in-house, chances are it's packaged as libraries and the gameplay programmers making a new game "from scratch" are just linking those libraries and calling functions. The engine is a black box - they likely don't even see the code and they certainly don't touch or edit any of it.
This mirrors a lot of my thoughts on my own pursuit, 3D art. An incredible number of things have been 3D modeled already, but It's not about having a certain asset, it's about learning how to make them yourself. I do also happen to enjoy coding, but if I were to create a video game I would almost certainly use a higher level program like unity because that's just not the area I want to specialize in.
Don't worry, there's an infinite number of things that haven't been 3D modelled yet
@@slugrag That's very true, and none of things I'm going to model are modeled yet! I better get back to it.
What 3d models you made so far?
I definitely agree with this. It's great to have full control over your code and even better to just learn how these things actually work.
Do you know how assembly code actually affects the cpu?
Do you know what currents flow where and why?
I've definitely shared this sentiment recently. Most of my career (10 years) has been with heavyweight/complex languages like Java, Python and Rust. After all that, I find it really satisfying and refreshing to write zero-dependency C code, just solving problems and implementing data structures on my own.
Right now I'm working on my own language, close to the semantics of C but with some of my own opinions on syntax and types. My goal is to finish the first compiler in C and then port the compiler to the language itself.
After that, I hope to conquer baremetal and build my own kernel and OS.
There's a lot to do before that, but I'm confident I can get there with enough time and research. And, it's not about the destination, but the journey 😄
Also, part of my current job is C++ firmware, which does give me several opportunities and a bit of leverage to be able to write my own libraries. That's definitely one of the perks for me
That's fascinating. Good luck!
Mine your own silicon. Smelt your own copper.
@@MrCmon113 Don't tempt me 😄
Came here from ThePrimeTime to smack that Like. Well said! Thank you for the video man! 👍
So I just started learning how to program microcontrollers with C as a hobby. I have no programming background, so I'm learning C and Microcontrollers at the same time. It's damn hard. But I love it. While there are many libraries and APIs I could use, I decided to avoid them as much as possible because I want to learn the details myself, create my own libraries and APIs myself. I feel like if I just start using the libraries and such, I'll just come to only rely on them, and I'll never truly understand the code I'm writing. Wish me luck!
I think libraries are good for people starting out. Then once they gain experience, they can start building their own libraries. My 2 cents.
Watched this video through Primagen’s reaction and dropping a comment here to say your advice kicks ass.
As someone who has made a basic Engine (Elafri on github) from scratch and as a result has had to tackle a lot of issues, most notable 3D rendering on the CPU, I really agree with your point about confidence. This engine was my first project when I was new to C and it started as how to display colors in the terminal to getting keyboard and mouse input from the terminal to drawing 2D and then 3D graphics and then I even ported it to SDL too and now am using it for a 2D platformer game (Ive used it for many more programs too). The feeling is comparable to assembling your own car and there's nothing better than watching it run and knowing what you're capable of. When I want a graphical program, I can use my engine and I dont have to go to godot or unity or use some big library to do things. Anyways, I rambled a bit too much but I really do agree with your points
Yes! In the process of making my game, I also built my own gaming PC. It was great to work with the computer in a non-abstracted way. Look over there, it's the actual CPU, and I'm literally putting it on the motherboard with some thermal paste. That over there is the actual memory. Now I'm going to install the GPU where every frame gets drawn. Oh, look over there, that's where the power for this beast comes from.
Taking on challenging projects provides you with valuable and RARE skills.
#This video is blowing up, congrats
It's true. If your goal is to learn the right way, do it the hard way. As software developer I say the harder the task is the more there is to learn in the process. However, I also see the other side of the coin. If you can accomplish much bigger goals by using the tools that are already there, the only rational approach to reach said goal is to take the shortcut. So, yes you can argue that the hard way is better if you have certain goals but also the same goals can benefit from taking shortcuts if you're fine with being more knowledgeable when it comes to the existing tools than building the tools themselves.
Yup. I drew the line at making my own compiler. However, I am still open to it. The thing is, I just don't want to do it at this stage of my career. Jonathan Blow made a compiler, but he had two successful games before taking that on.
Everytime I talk about linear algebra or foundation for rendering objects or vectors for the physiques, I often get answered like “what’s the point? I’m more of a high level programmer, I use libraries for this and that”, or “this framework already does this thing you wanted do to, you are wasting time”. Well after me doing these things I started to realize how little things I knew and now how much more I know if I am compared to those very persons. I’ve done some deeper ray marching and I’m very happy of all the foundation I learned. My next goal is to make a very simple render engine in ray tracing now that I understand this enough to try.
Thank you for your words
Thank you so much for this video! I've been working on my own little game engine too (with a little scripting language just for it!) in Haskell and C for a few months now, and it's been my favorite project I've ever done. I chose it because I wanted to learn Haskell and I wanted to get better at both functional programming and lower level concepts. And it has taught me SO MUCH!!!!!! I learned SO MUCH from this project, far more than I would have learned if I had just made another Unity game.
I've been feeling so discouraged lately though because I saw people in forums saying the same thing you mentioned someone said to you at the start of the video .The whole *"Why bother? It's useless, someone else already made an engine you can use!"* argument had me genuinely considering giving up on this side project entirely out of shame. Your video actually gave me motivation to keep going, so thank you so much!!
That's awesome! Keep at it :-). It's always good to have a specific game in mind that you want to make with your engine. For me, that really increases the motivation factor.
thank you, will try once and for all! the mental struggle that makes one believe it's and almost impossible challenge is what has kept me just using handy tools/frameworks instead of digging deeper into how things work.
You just need to realize that seemingly impossible things will become easy after enough practice. Most people give up too easily, that is really the only roadblock.
My philosophy with this type of thing is that I learn enough to work first then learn the rest.
Or in better words: I learn what I am motivated to learn now and hope for more adhd motivation later for more things.
I too started out making games without engines nor frameworks. Some of my first games were made with vanilla Javascript, vanilla Java, vanilla Python and/or the BASIC programming language and I am VERY VERY glad I did it that way!!!! I felt that it was more fun and I learned a lot more. I learned how and why things worked the way they do. So then, when I started using game engines, the game engines made more sense and I learned various game engines a lot faster.
Plus, in the vanilla code based approach, I didn't have to deal with the bloatware that comes with game engines. In game engines, there are always a ton of functions, etc. that I don't use.
Finally once I built my first game; given that I knew what was in my code and how things worked, I could reuse the code over and over and build my next game, etc. with it fairly quickly.
Btw, the same skills could be transferred to web development. I could build websites very quickly by simply doing most of what I did when developing my games. The same skills applied!
This is a great video! This exact logic is why I’ve made quite a few programming languages, and I’m currently working on my first high level one! (I’m pretty close to completing the compiler/interpreter, maybe a few weeks left)
I bet you learned a lot, and I bet it makes most salaried programming jobs look like a cake walk to you. :-)
I just found your video, and it sounds a lot like something I wrote a while back, "Programming as Craft". Good to hear that other folks are thinking about this, too. You also touch on the reasons I advise people to build their own tools. Buying-in can seem fast and easy, but there are multiple costs waiting for you.
Not that I haven't had to overcome my share of programming obstacles, too, but your snowboarding story reminds me of something more to the point. Before I got into a programming slash technology career, I worked for a local public works department. I don't remember what job triggered the thought, but I distinctly remember thinking, "Don't they have people to do this?" Then it dawned on me: I _was_ the "people to do this". There's a lot of menial tasks that go into software development as much as in daily life. Without people putting in the groundwork to develop game engines for the rest of us, we'd all have to do it ourselves.
Ooh more story time. There was this one time when I was in the terrain park at Breckenridge, hitting the largest jumps they had.
This guy rocks up to me and asks me what the speed was for the jumps. It took me a moment to recognize him as Andreas Wiig, this big time pro I had looked up to for quite some time.
Here I was, a nobody, just doing straight airs and warming up, and he was asking *me* for the speed.
And then it occurred to me that so far as he is concerned, in that moment, I was the expert. If you are at Breckenridge at the big park at 9:00 A.M. on a Wednesday in January, you are as close to pro as it gets.
Whether you acknowledge it or not, you are in that milieu. 🙂
@@tedbendixson That's a great example, cool story. It's a common form of unconscious impostor syndrome, discounting your own expertise, never do that!
I was solving a problem by not using the in built libraries and got frustrated and turned on yt to chill. I was really looking for someone to reassure that what I am trying to do isn't really futile. Thanks!
I think this is definitely true if you are trying to be a programmer. If you’re trying to make a great game, I believe it would be more worth your time to use an existing engine and focus on the gameplay loop, visuals, etc. Additionally, some of the biggest engines like unreal have features that are simply not feasible for a single programmer or even a small team to implement. If you need something like Nanite for your game, you should just use UE5. No amount of solo development is going to be able to process things as quickly or as well as a game engine that has been battle tested by industry vets.
However, if you’re primarily a programmer, this is 100% the route to take. One of the earliest CS classes I took had us write arrays, linked lists, hash maps, etc from scratch. Now in my day job, I never use anything but the built in versions of these same data structures, but I have the knowledge to know exactly which one I should be using. Additionally, I have the confidence (like you mentioned) to know that the structure I picked really is the optimal one for the task. I better understand how C/Python/Java is handling my memory under the hood, and even though I don’t personally need to do anything about that, it helps me write better code.
"If you need something like Nanite for your game, you should just use UE5. No amount of solo development is going to be able to process things as quickly or as well as a game engine that has been battle tested by industry vets." This is not necessarily true whatsoever, engines like Flax or WickedEngine which were almost entirely developed by a single person go against that claim. They are able to render and process things quickly, as well as doing the build process probably even faster than Unity or Unreal in most cases. Yes, a single programmer probably wouldn't want to try recreating Nanite from scratch, but they can make a similar system that accomplishes the same task. Also, Unreal is mostly open source, so if they wanted to learn how to code Nanite, they can just go read through Unreal's source.
very happy to hear this! can you make a video of “challenging things you should learn to do”
Yes! I have plans to do a video covering all of the computer science concepts you will be introduced to in the process of making just one video game from scratch, using an actual game I made, Mooselutions, as a teaching example.
I'm pretty new to programming, I've been learning C# in college for 3 quarters so far. My most recent final involved making a program that can save and load data. We were supposed to use an existing library to do this, but I decided to make my program a game for the Godot engine. It did not want to play nice with the library, so I thought I would use it's existing way to save data. It turns out it was written to save game states. So I ended up instead using a feature where it could save and load individual 8, 16, or 32 bit bytes. And because of that, I had to get a hex editor, and learn a bit about how Unicode is saved, as I needed the player to enter a name, and also figure out how to make it read multiple save entries, as I wanted to store multiple scores. Normally, I'd just tell it to put everything in a list or two, if I were using the library to do this.
I also needed to manage hundreds or thousands of bullets, each going on a unique path. I'm still working on that, but it's been giving me a clearer understanding of what OOP is all about. It's particularly making me more familar with inheritance and interfaces, as the bullets all need to be managed from one list, and need different data-driven behaviors that allow them to move on multiple co-ordiante systems. I'm still working on that part.
Anyway, I got 100% on that final.
I've been thinking about what you said about challenging myself. I'm very interested in how shaders work, and the basic ones in Godot are... well, for one I don't know how to use them, and for another, their equivalents in Unity are very boring. Even Blender's shader nodes are very limiting, even if I combine them with compositing stuff.
I've also been thinking about future projects. Some day, I want to make an FPS, and I love the brushes and sectors in Source and Doom's engine. I feel like they make designing levels far easier and more fun than dropping in models. So I kind of want to make an engine that has those features, but without the baggage of GZDoom or source.
Stick with it. I love this story.
I used to do this way. I used to do things the hard way, and I learnt a lot from it. Thank you for reminding me of those days. Really inspiring.
All you need to say is that its a matter of priorities. If you want to effectively ship games then using an existing engine is a no brainer. But building your own engine scratches a personal itch. Also is better for your career if you want to pursue technical work in the future. It's not an optimal path to becoming a skilled game designer, but its certainly not an invalid path. We all ultimately take the path that aligns with our preferences
Good advice, applied same in animations aswell, I've animated as a kid for years without watching UA-cam tutorial videos, coming back to it now it's super easy to actually do difficult things more easily
Let's go to the extreme first:
Is it useful, to learn how every layer from setting up CPU registers to the highest abstraction works and recreate it? Yes.
Do we have time for it? No.
So where do we set the line?
In my experience, it is one layer below where you usually work.
In my dayjob, i do .Net applications with lots of lower level interop. Knowing c/c++ and archaic unmanaged programming ( no smartpointers! ) helps a lot when working with these components from a a managed environment.
In my free time working with Unity, i slowly digging one level below the surface. And now when i see systems in the asset store i not longer think "wow, thats magic" but more often "okay, i got an idea how that might work".
There's a reason why instead of using a = a - 1, I use a = a + -1.
Slightly less processor heat. If that extra hyphen doesn't do much. (compilers)
I'm actually making my own Game Engine for my commercial game... And it's extremely enjoyable, you're constantly learning something no matter what you do, it's a nice experience.
Yeah I'm not sure if I stressed it enough, but I really enjoy working this way. It makes every day way more pleasurable, the joy of programming.
This was a very inspirational video. Doing things the hard way, many times, is easier in the long run. Started my own simple from scratch animation library project after this video.
Indeed! I find it simpler to just build from scratch than to fight with someone else's poor abstractions.
@@tedbendixson, agreed, though, I think part of it is, you just are more comfortable with the abstractions, because you have the most experience with them as the library / framework author.
I recently started programming a webserver with nothing besides the Linux API for using sockets. There have been a few points in the process where I stopped and wondered what the point of it was and if I would look back and realize it was a strange waste of my time. However, once I got past a particularly difficult point and had something that would compile and perform a simple task I realized that I could keep going and see how far I could push this and how much could I build without touching a library. Then I found your video and it made me feel encouraged in this resolve. Thank you!
The problem is too many people enter programming with the mindset that they're doing it just to be successful. Those people take shortcuts and don't learn it properly.
If you program because you actually enjoy it, then you'll be happy to do it the hard way.
But also, you won't always be happy. Maybe passionate would be a better word. The easy road is what leads to short-term satisfaction, although terrible in the long run.
Everyone needs money, but the pursuit of money alone probably won't give you longterm happiness. This is a lesson many people who become financially independent eventually learn. The day you get a million dollars in your bank account is just another day. You're still you, with all of your joys, frustrations, friends, pursuits, and fears. Money only solves your money problems.
This is so true. In the years that I've been developing games as a hobby, I've always tried to write as much code from scratch as possible. And my friends and people I know tell me I'm crazy for this, that I should just use Unity, use Unreal engine, etc. But then by writing much of my code from scratch, and especially the core logic that powers everything, I develop much more deep understanding of how different parts of the low end than I could get by using an engine that does everything for me. And then they're surprised when they ask me how to do some task that they haven't seen before or don't know how to accomplish, and I reply with an explanation of how the task in question interacts with the environment, and how to solve this task using some innovative solution. Great to see you communicating this message as well! We need more people to think this way.
My personal rule for the use of software I didn't personally develop is this: if I can't see the source code or make modifications to it, it's of little use to me because I can't learn from it.
I aim to strike that middle-ground between speed of development and learning when I need to get down into more low level stuff. The Godot Engine has some really cool tools and documentation to get you started in Shaders; pretty dope.
yes!!! this is a great take. We should use tools not just for the sake of using them, but to learn. And opensourcing projects is the best way to keep them alive.
Also, I love shaders! I started messing around with shadertoy and webGL shaders a while back, and I've been learning OpenGL recently. I should take a look at godot, thanks for the suggestion! :)
I agree! I've grown so much as a programmer, and can think programming problems through much more thoroughly since I started making games with Rust instead of a full engine
I have started with complex stuff and doing everything from scratch. I completely agree. although I am using premade stuff I have improved a lot and it benefited me a lot to know the low level stuff.
"I believe the question assumes your goal is to get something to market as soon as possible."
I think a more reasonable goal would be to make any game at all. Not to call out anyone in particular (Randy), but it seems like a lot of people are spending years programming engines for super simple games. I can't help but think how far they could have gotten if they'd spent all that time actually making a game, you know, the part people play. Though It's a bit of a fools errand since the point isn't really to make a game, the point is to make a game engine.
Anyway, I think the main problem with this argument is that it seems to assume 'programming the hard way' is the only way to challenge yourself. In reality you can find the same sort of challenge in the realm of game design, storytelling, art, or even programming in an existing engine. Time is limited and you have to make decisions. I think it's easy to trick yourself into thinking by choosing the hardest option for the immediate task is the best choice, where in reality you could be ignoring even harder and more worthwhile endeavors.
And from the whole spectrum of game development, building an engine ends up looking a lot like the easy choice. It's all math and coding, stuff with finite answers and discrete chunks you can feel good about completing. It lets you ignore the far more difficult task of designing a game people will enjoy. It lets you stack one little 'win' on top of the other without ever having to ask what is actually being built (queue Randy talking about trying to figure out the core gameplay loop 5 years into development).
Yes, the caveat for anyone making a game engine, the requirement, is that you must make a game. I made one. tedbendixson.itch.io/mooselutions
Now I'm making another. And as a make that new game, my engine will evolve to better support it and whatever future game products I make.
You should start a podcast (with a slightly better mic quality) and your golden, I loved listening to this!
I'm definitely going to make some more videos. I got a better recording setup so the audio quality will certainly be better.
NO, the real issue here is that the background gameplay is the same boring loop the whole video long
💀
Video 2 from years ago, 90% of the comments are from this week. Good shit, man!
The algorithm bless you and keep you. The algorithm make its face to shine upon you, and give you grace.
I'm sure many people share the same struggles that I have in learning programming. I have been trying to learn Python off and on for 4 years. I always got bored with it and left it. But I knew that it could be extremely beneficial to know one day. Just recently I decided to buy a programming book and just read from page one to the end. I am now roughly 200 pages through and can finally write useable code! That approach with a solid curriculum was the only one that worked for me.
Python is the only language I feel comfortable with these days. But I’m no web dev or game dev, so this is an example of where people may have disjoint goals.
I can parallel process data on the GPU if I need unbeatable speed, and I can rewrite any application from other languages in half as many lines. Python just feels right to me! :) Not to mention the extremely large PyPI.
@@JordanMetroidManiac I agree. Python is very versatile for general purpose programming. I have been using it for TA on the stock market. The libraries that python comes with are incredible too!
Great video with a good point. You can't study science without understanding what it's built of.
This actually applies to everything that involves engineering. People tend to become used to knowing the essential while they could be so much more. I'm glad I learned this when I still was in middle school.
No.
Engineering is about trusting the progress other people have made and building on top of it.
Otherwise we'd still live in mud huts.
@@MrCmon113 Yes, you're correct to an extent. However, by understanding everything fundamentally, instead of relying on programs and tools, you'll definitely be a better professional. That's what I meant. Furthermore, people should always learn and study more stuff outside their areas and put their souls into their studies/work, that's how science advances. Sorry for any grammar mistakes, English is my third language.
But what if you don't agree with some of the so-called "progress" of others? You intentionally decide to go back to the point where they made the bad decision and build from there. I like to think this is what I'm doing.
I don't feel like I need to build confidence by making things harder for myself, I learned C++ instead of Unity because programming is fun. Like you said, everyone seems to think the goal of game development is to make money, even you seem to fall into this trap talking about how much money confidence is worth. It's an artistic pursuit and the primary reason behind making games should be a passion for game design. I'll be dead before I have a desk job at a major company, no matter the pay.
It's a complex thing in today's attention-driven economy. In so many ways, getting attention is synonymous with making money. So if you want your work to be known, chances are your work will in some way align with the goal of making money at some point, even if it's not right away.
you'd also be dead if the next economical depression hits and you have no money to sustain your apartment
do what works for you but don't claim moral highground over which intention for creating games and art is the "correct" one.
@@thomas.thomas This video is about a private side project the guy's making. If you just want a job, you're wasting your time learning games programming in general. Learn webdev or just Unreal, since there's plenty work in those. But if you're making indie projects on your own with no funding or team and you're deliberately making things harder for yourself by programming, you should stop thinking about money because you're wasting your time. The odds of making it big are extremely small.
I'm not taking a moral high ground, there's nothing bad about just getting a job helping someone else get their artistic vision fulfilled, working at some big company. But games are art, and how they sell is often directly linked to how much you respect that art. There's a reason entirely profit focused NFT games just won't take off, while something like Hollow Knight and Celeste, did.
I do want to make it clear that my goal is to make games that make money. I doubt my first game will be profitable, but I hope I take away some valuable lessons from the experience and use them to make something more profitable on the next attempt.
Making a game studio is like rolling a giant snowball. You slowly build an audience for your games with each product you release. I just do my best to study the market and listen to my audience, trying out a bunch of little experiments and continuing to improve. That's really all you can do while you are alive on this Earth.
Games are art, that's true, but it's also true that certain kinds of art are more appealing than others. Beautiful art is *one* of the reasons a recent hit like Blasphemous was such a big success, but it's truly a combination of many factors. They picked a profitable genre (Metroidvania + Souls Like), and they brought in their own cultural heritage in a way that hasn't been seen in other games. It's a uniquely Spanish game, and that uniqueness is why it occupies its own special niche. Their team has escaped competition through authenticity.
I'm trying to find my own way to do something similar :-)
It wasn't until I started to make my own game engine that I realized how little I actually knew about coding. Looking back on old incomplete projects I can see how badly they were implemented and written, if I were to return to those projects they would look much different and be better for it. My code has become much less bloated and solutions to problems come much easier now, as I think about them differently. Interestingly enough I started on the make your own game engine journey because no premade engines worked well for the algorithm I was trying to implement without altering the engines source code. Also not having to shell out cash to Unity or Epic games after a certain sales number is reached is pretty nice.
This is the best video I've seen about programming, and even better after i found out i want to become a game programmer and not a web designer and stuff...
Can't thank you enough for this, so all i can do is do my best, subscribe, like, and keep following you, thank you... Ted.
I remember having these kind of arguments with my teammates for my college senior project. We decided to make a game, and the team lead decided to have us go with Unity (against my advice, especially since we were making a 2D game). I was one of the only ones there who'd done *any* game development in my spare time and programmed before going to college, and it showed. I kept having to pull everyone aside to explain simple, core ideas and mechanics and they still wouldn't get it, saying "well it's just a school project, and we're using Unity, so we can just drag and drop stuff". What made it worse was that there was one other guy on my team who had worked with Unity before, and he and I butted heads so much. I remember a specific time where I said "we should make the bullets from this gun go through walls to make it distinct from the other weapons in the game" and his response was "that's impossible ". I asked why, and he said the "engine didn't support that" and shut down the idea, instead of thinking of how we could modify or build the physics engine to make that work. But I was used to programming my own physics and planning ahead for this kind of stuff in my own projects. The entire project was a pain and a slog, and I constantly felt like my entire team was against me just because of this basic philosophy. Did we get the game done? Kinda, one guy didn't understand unity at all and none of his stuff worked, but I was able to show off our game in a way to avoid that. Did we get a good grade? Yeah, we impressed our professors for sure. But did *I* like our project at the end of the day? Heck no. I wanted to redo it all without the constraints of Unity (or at least the ones placed by the others' ideologies) the hard way. Thanks for reading.
Man after reading all of that I can still see a bunch of green lines even after blinking 10 times. But anyways, as a former game engine "user", I used to just spam scripts (for litterally evedy object) and write dirty code. I realized that this kind of technology is the reason why mobile games nowadays during 2018-2023 is oversimplified or to put it bluntly, they're trash. Developers think "we can just spam the same concept over and over again and get a lot of money". Making games is so easy now that we can litterally be lazy as much as we want and still profit from games that litterally does not make sense at all or kill the braincells of many children.
Whereas developers who programs in OpenGL with pure C++ are "forced" to make the game good because there's no way you implement a lot of stuff like vertex and index buffer objects, mesh classes, dynamic geometry, shaders, batch rendering, MVP, math stuff, collision detection, and etc, when your game idea is not worth the effort. Like why the hell would you torture yourself to make TicTacToe in OpenGL?
In comparison, 2000-2010s game would use more shaders and more realistic graphics and games THAT IS ACTUALLY ENTERTAINING while PRESERVING the rational and logical thinking of gamers. Now everything looks the same because of corporate memphis and money-oriented developers in this industry. But hey, I'm not saying game engines are bad, they are good but it depends on how you use them. Saying "so we can just drop and drag" and not programming an entire idea just because of the limitations during the development process is an invalid excuse. While you're in school be wise and learn as much as you can. I hope people realizes the more effort they put, the bigger the reward becomes. Thank you for reading and have a great day.
@@BlueProgamer212 Thank you got reading, and providing a great reply with educated insight. I can definitely see where you're coming from, especially with modern mobile games and stuff. I used to have a lot of fun playing other peoples games and thinking about how they might have programmed this or that, and analyzing how I would maybe do it myself. But it feels like with a lot of games today on the Indy budget, I can't really do that anymore. It's all just so simple and streamlined and repetitive, and you can just tell how much less heart there is put into those games these days. But that also makes the games that do have the heart and hard work put into them stick out even more, in my opinion. Those games will stand the test of time.
It's about creating timeless work.
@@BrettLane256 I to CAPITALIZE every other WORD while I write a reply to SOMEONE on UA-cam.
Oh, the good old days of me trying to write my own wireframe 3D engine in QuickBasic... It sucked, but it was mine. I remember, how proud I was.
i agree that doing things the hard way is good for learning and learning new skills is very important but if you want to get things done you can be a lot faster with tools. they exist for a reason.
It's definitely a nuanced conversation. I don't always do things the hard way and often use tools. I didn't write my own C++ compiler to make my games, and you could make any of the games I've made with an off the shelf engine. For me it comes down to satisfaction with my work. I just have the kind of personality that enjoys knowing how things work and getting them to work reasonably well because I have that knowledge. It's satisfying, like playing real life Powerwash Simulator.
and then you have developers who only know how to work using those tools and since they dont understand how they work under the hood, they write absolutely terrible code that fill the modern software landscape with bugs, inefficient code and antipatterns...
when the tools do most of the hard stuff for you, you're not actually learning much tbh, and it shows.
Waoo man! That's actually the right mindset. We can't push or force someone else to work the hard way, but no one has to criticize the way we approach to things. I wanted to do things the easy way and I realized a long time ago that doesn't work. Now I'm working hard and smarter. For me hard work is a long term smart work. I wish I saw this video just right the day you uploaded it. Hopefully you're doing great!
Doing really well. Check out the video I uploaded a few days ago, "Why you shouldn't make a game engine."
Couldn't agree more
Good luck with your project!
Great Video! These people who are talking to you obviously have never met a "hand tool" woodworker. I've always been pushed at work (Engineer at Manufacturing companies) to make things faster, cheaper, more economical with resources. When I'm working my hobbies (woodworking, programming, leatherworking) its nice to do things the "old" way, the "hard" way the way that actually allows you to master a craft instead of just get the job done to move on to the next one. Through doing things the slower/older/harder way give more understanding of how things work and at that base level, and it allows you to see much more clearly, not only in the thing you are doing but in other things as well. There has to be some journey to life outside of careening from milestone to milestone as fast as possible.
Love the message in this video. Challenging yourself is such an important part of learning and the key to creative fulfillment. That being said, there’s no way I’m ever making my own game engine lmao. I’ve got a lot of respect for it though!
From a career trajectory POV, I think it’s definitely a balance between doing things the hard way, or using some pre-existing software. You don’t want things that are so hard that you’re not a productive teammate, but you also don’t want things so easy that you’re not growing professionally.
For personal projects, I think it’s also a balance; but that balance should be based on whatever your goals are. Are you looking to make a game super quickly? Then making your own engine is probably not the way to go. Are you looking to really understand how things work under the hood? Then writing the stuff yourself seems like a good option.
From personal experience, though, I agree that the path with the most unknowns generally leads to the most learning and growth
super late to the video but, as someone who learned the hard way too, though not a game dev, i completely agree
I love this. Jonathan Blow talks about this kind of stuff all the time. I have been working on my own game and engine in C for years and it has been so rewarding.
Time to start programing in 1s and 0s
Learning to make games from scratch taught me all sorts of things about math, computer science, and physics. It even makes using a video game framework trivial.
The magic always happened to me when I tried to reinvent the wheel.
You had me at the title of your video. Forty years of rolling my own code. More power to you.
Well, in the olden days (and current when it comes to in house engines like Nintendo etc.) The programmer would build the engine and tools so the game designers could do high level scripting mostly by themselves. I am grateful for these premade engines like Unity because they allow a game designer with minimum programming knowledge to create something with a reasonable level of efficency in simpler types of games like 2D games.
This is so true. Subbed. I've had to write a couple of simple libraries from scratch, so I understood what was going on in them and so they produced the correct values.
I agree to an extent but if you go too far outside of your comfort zone you can get demotivated and give up as well
Do something that scares you at the edge of your abilities. That's my recipe for personal growth.
@@tedbendixson If you always stay in your comfort zone it's bad, but if you try and do too much it can be overwhelming. So the best approach is somewhere in the middle. It's called the Yerkes Dodson Law
@@tedbendixson If it's your first day in the gym and you try and bench 225lbs it's stupid, you should start small and gradually build from there. Same thing with programming, that's why I think beginners should start with an easy language like Python instead of a low level language like C. That's just my opinion
Enjoyable and motivating video! Also the game-mechanics look very fun to play and the character looks very nice. Keep up the good work and keep on tangling with those sea-monsters 😃.
I was in agreement before the video started, but after I felt very motivated, as I have postopned coding from scratch, although thats what I really need to do. Thanks for a great explanaition!
Keep it up Ted! Another great talk. New character art and animation looks very cool, waiting to see when the rest of the world is also with new art assets.
literally a ted talk
I can't agree more that understand how to program in low level / how computer works in low level makes me more confident. Reading some classical textbook is so boring and hopefully here we have you make these videos.
Seeing the footage of the game when it was just solid colored blocks brings me back to when I started learning programming myself. Like you, I decided to make my game engine from scratch.
I never finished my game, but I learned so much in the process. I did many things the wrong way. But that’s ok, because I learned from it.
Would I do it again? Probably not. Today I would just use Unity or whatever. I’m too aware of my time budget now, but I’m happy I made my own game engine (how bad it ever was). No regrets.
You've gained a new subscriber :D.
I think in the same way, I have been working in software development (mostly in the web) and I am starting to loose a bit of joy doing things, no matter if its a startup with a "great product", or even worse if you deal with a legacy project and you provide value and fix things in the middle of it at the same time due to working in software is not always perfect, and it's not going to be always a green field land of projects.
I remember when I started writing some npm libraries (they're outdated at this moment and also useless due to there're a lot of them out there and even better), but doing so gave me a lot of confidence and started taking more and serious challenges.
I am currently in the process of working with graphics and your video is a great start.
Thanks.
I think there's a difference between being familiar with your tools and understanding fundamentals, and refusing to use the tools available to build everything from scratch. I'm all for exploration and learning about lower-level systems, but that doesn't mean you have to finish a full project with it.
I had this conversation with my dad who's being programming for a long time. He has a CS degree and grew up working with electronics. He wanted to start making a game and wanted to do it all from scratch. So I asked him if he is going to write it in assembly and or machine code? Are you going to build your own components? Obviously not. There's a lot of value in understanding these lower level concepts, but when making a game, it's unnecessarily limiting to try to "reinvent the wheel." He tried building his own engine and he could of course do it, but it was impractical to do while working full time on other projects. Once he stopped arbitrarily limiting the tools he could use, he actually got a game up and running.
Basically, it's always good to improve your knowledge of a subject and understand the fundamentals, but that doesn't mean you have to commit to building from the ground up on any given project. Setting aside time to study and tinker around with some components at a lower level of abstraction is enough.
Also I agree with the overall point of the video. The intro just made it seem like using prebuilt engines is some sort of cop-out.
Good points. I've got another video coming that addresses it. If anything, I'm hoping people got the idea that it's good to drop a level or two below where you are comfortable. Sometimes you'll do this for learning purposes and in other cases to get a degree of control you otherwise couldn't.
My reason for not using an engine has more to do with longterm business goals. If I plan to be in business for forty more years, I want control over my game's source code so I can remaster games over and over again without having to worry about engine updates.
Other folks will have different goals.
Kinda feels somewhat of a common trend, sadly.
Every now and then I visit my fellow programmer friend's progress making their own 3D graphics engine from scratch in objective C. I mean I'm not necessarily learning a lot by inspecting that but mostly about what I really want to be learning and what I don't.
Casey Muratori really opened up my eyes to C (and eventually Jai). I had previously spent most of my career on Java, C#, SQL and web dev stuff. I had grown so disengaged because so many dependencies regularly broke for long periods of time for reasons that made no sense, and because the SOLID OOP religion that I had bought into was eating at me. I clearly remember when I first saw Casey make a few lines in a batch file and state that no matter the size of the project, he'd never need more than that to build the project in a few seconds (and even said it could be a lot faster if the compiler was done efficiently). The way he writes code was so simple and easy to understand, yet also extremely powerful. Then I finally knew where I had gone wrong.
I started to work on my game engine because I thought it would be more fun to learn programming stuff that way compared to the Web2.0 hype that was there when I was in college.
I mainly developed my engine around hurdles with retro inspired games at the time, namely that the pixels often went horribly misaligned. Currently I'm using the CPU for rendering, which would give me enough sprites for even some lighter bullet hell games, but I'm soon moving it to OpenGL, all while keeping the classic palette-cycling effects my engine is capable of without using shaders (I figured out a way, that would enable me to use a global texture as a palette). I even added some software synthesizers and a basic MIDI sequencer, later on I want to experiment with dynamic soundtrack.
That was an excellent and inspiring high level talk about how confidence works.
I think learn whatever is relevant to you, and it sounds like low level C was relevant to you and helped you out. That may not be the same for others. With that said, I agree that fear is often ridiculous in its assumptions and holds people back from doing something. I try to tell my friends that art is just as much engineering as programming is, so stop being afraid of it, but thankfully it leads to a less saturated jobs market.
It's so true. I have been learning programming for 3 years now 2 of which were at university and while they teach a lot of really good ideas really well they never really encouraged us to step outside of our comfort zone but I usually do anyway. Right now I'm programming a 3d printing slicer and knew nothing about the math behind(and yes math is important for programming) and I don't think I ever learned how to write good code since if you already don't understand the problem well you have to write your code in a way that it us easy to understand and follow. And yes while programming things far outside my comfort zone does sometimes feel like banging my head against a wall constantly I do feel like it made me a much better programmer than just following tutorials and using already existing tools.
Currently getting into electrical engineering so i can fabricate the parts of the circuits i want to execute my code. Still sideeying both the island of stability and the possibility of a second page of the periodic table via muonium to make my own elemental materials for all of that.
Same, TBH. I'm just taking a slower path to the bottom. I think first I'll do a drive-by of FPGA programming before I create a lithography machine so I can start fabricating chips from raw sand, but creating your own elements kinda requires a nuclear reactor. Which is a bit expensive, unless you make your own steel and concrete, so I guess that's what I'll be spending my 50s to 120s on. Then I can actually start building the thing!
I made 3 puzzle games using SDL. I liked that it was very low level and gave me a basic set of functions to create a window and draw rectangles. And that was all I needed when I made my Tetris clone. The hard work was in designing the data structures to represent the grid and the blocks and detect collisions when moving and rotating them. I felt that satisfaction of knowing I wrote 13 kb of code just on the mechanics of the game and it all worked.
For a simple 2D game without fancy effects, and only on one platform, sure you can use your own game engine. It gets hard when people want to write sophisticated 3D game engines, or even worse for different platforms. At that point it makes no sense to build one yourself, unless you specifically get payed for that.
I think if you can hone down your 3D game concept, you can do 3D reasonably well. It took me about one month to get basic 3D rendering up, and that's supporting both Mac OS and Windows. It's all about focusing and removing distracting extra features. I plan to discuss this in another video some day.