Hello. Sorry if I post this in the wrong spot, but I really wanted to express my appreciation for this video series. I always wanted to learn about low-level programming and how to go about making a game engine. Before, I was always baffled to hear that people could make engines from scratch whereas my school only taught me to do things from the command prompt (which feels totally different in my opinion), but thanks to this, I can finally learn how to do everything.
Now, a few questions and thoughts if you don't mind:
1. Should I buckle down and watch ALL of the videos? Or should i just watch up to the engine creation videos (week 56 I think)? I want to make my own engine, but I want to make my own game with it. (I'm on episode 10 by the way if you're wondering)
2. For anyone that codes in Python, C#, or just straight up C++: How difficult is it to make a game engine from scratch in these languages? I haven't looked too much into it, but I'd assume that C++ wouldn't be too hard (since you can use C code)...
3. I'm going to make a pitch here for my game. I'm a classic type of guy. I like retro games. I love the increased difficulty on NES games like Mega Man 2 and Castlevania. As long as the challenge is at least somewhat fair, I get a real kick out of getting the living daylights out of me. It's enjoyable and something that I really love.
Now, I want to make a game somewhat based on that. In essence, I want to make a platformer with lots of mobility. In short, I want to take the mobility from things like Shovel Knight and Khimera Destroy All Monster Girls and bring it up a notch (like adding verticality) with Ninja Gaiden (NES)-like difficulty (not the unfair parts on the other hand). Essentially, the player plays as a ninja [cyborg too maybe?] that was on his way back to his village; however, the local mafia wants to kill you because they found out that you murdered their boss. Now, you must make it back to the village, cutting down anyone in your way.
I want the art style to aesthetically resemble 16- and 32-bit games. More specifically, I want to take inspiration from games like Megaman X, X2, and 7. What are your thoughts on it? Any questions or feedback about it?
Now, a few questions and thoughts if you don't mind:
1. Should I buckle down and watch ALL of the videos? Or should i just watch up to the engine creation videos (week 56 I think)? I want to make my own engine, but I want to make my own game with it. (I'm on episode 10 by the way if you're wondering)
2. For anyone that codes in Python, C#, or just straight up C++: How difficult is it to make a game engine from scratch in these languages? I haven't looked too much into it, but I'd assume that C++ wouldn't be too hard (since you can use C code)...
3. I'm going to make a pitch here for my game. I'm a classic type of guy. I like retro games. I love the increased difficulty on NES games like Mega Man 2 and Castlevania. As long as the challenge is at least somewhat fair, I get a real kick out of getting the living daylights out of me. It's enjoyable and something that I really love.
Now, I want to make a game somewhat based on that. In essence, I want to make a platformer with lots of mobility. In short, I want to take the mobility from things like Shovel Knight and Khimera Destroy All Monster Girls and bring it up a notch (like adding verticality) with Ninja Gaiden (NES)-like difficulty (not the unfair parts on the other hand). Essentially, the player plays as a ninja [cyborg too maybe?] that was on his way back to his village; however, the local mafia wants to kill you because they found out that you murdered their boss. Now, you must make it back to the village, cutting down anyone in your way.
I want the art style to aesthetically resemble 16- and 32-bit games. More specifically, I want to take inspiration from games like Megaman X, X2, and 7. What are your thoughts on it? Any questions or feedback about it?
no way you'll carry through all the videos without doing anything yourself, those 300+ episodes takes ton of time to go through too. Start watching the videos, see if you like them, if you do carry on.
basing your game idea on high level concepts may be good, i don't know, but they can also make you frustrated over the details, and there are a lot of them when programming. i like to keep broad strokes on things.
My recommendation for you is to watch the videos, and when you feel up to it start programming for yourself.
best of luck,
the 8th mage.
basing your game idea on high level concepts may be good, i don't know, but they can also make you frustrated over the details, and there are a lot of them when programming. i like to keep broad strokes on things.
My recommendation for you is to watch the videos, and when you feel up to it start programming for yourself.
best of luck,
the 8th mage.
Even if you don't strictly follow the code that Casey writes in the series, you will learn a lot about writing your own game engine. A lot of people join the streams and watch the VoDs to learn even though a relatively small number of us are making games.
As for game design, I highly recommend the below YouTube series. In particular, the episode I linked is especially relevant to your ideas. Good luck!
As for game design, I highly recommend the below YouTube series. In particular, the episode I linked is especially relevant to your ideas. Good luck!
Hey thanks for replying to this post.
I'm really enjoying the series and I was planning on diverting when I felt comfortable with going on and doing my own thing. I'm likely going to watch the video series, as it is something fun and interesting to do (plus it's nice to see someone so diligent on making a series like this), but I'll be diverting as soon as I feel comfortable.
I don't really have everything planned out, just a general story and style (and some base mechanics), so I'm still flexible on what I plan to do, but it's still just a general blueprint. As for the video, thanks a lot for showing it to me! I'll keep things like that in mind from now on. I guess, if I get it off of the ground, I'll post again and let everyone know that it's gotten off of the ground.
Thanks for the feedback,
Vincent
I'm really enjoying the series and I was planning on diverting when I felt comfortable with going on and doing my own thing. I'm likely going to watch the video series, as it is something fun and interesting to do (plus it's nice to see someone so diligent on making a series like this), but I'll be diverting as soon as I feel comfortable.
I don't really have everything planned out, just a general story and style (and some base mechanics), so I'm still flexible on what I plan to do, but it's still just a general blueprint. As for the video, thanks a lot for showing it to me! I'll keep things like that in mind from now on. I guess, if I get it off of the ground, I'll post again and let everyone know that it's gotten off of the ground.
Thanks for the feedback,
Vincent
You probably won't need to watch all the videos, but there are a bunch that make for good introductions (and some that are very clear guides on implementing) various programming concepts and systems. The annotated episodes are a great way to learn individual things, but there's value in just listening to episodes more-or-less in order to just pick up on how the project is put together and Casey's wisdom of the subject.
Making an engine from scratch in Python or C# is tricky, since you have to bind to the OS level interfaces yourself. Python has a FFI system which lets you call C from Python with relative ease, and C# (and the rest of .NET) has DllImport, which achieves mostly the same goal. If you'd rather write most of the code yourself, there exist bindings to SDL2 for both Python (PySDL2) and C# (SDL2-CS). However, if you want to get right up to the metal, C/C++ is the way to go. You can still using a layer like SDL2 and get decent results, and it's easier to use from native C than through a wrapper in Python or C#, but you are giving up some control and using someone else's assumptions.
Your premise is fine, but I don't think you're matching your fantasy with your planned gameplay very well. A ninja returning home was successful, right? He must have practiced until he was a master at acrobatics, combat, etc. If he's so good, why is the game hard? Not that the story is particularly important to that kind of game, but as a game designer, you need to identify what your audience wants out of your game and what you can deliver on. It's clear that you want your game to be exciting and fun due to its challenge, but the implementation matters; for example: do you want to feel strong and powerful, "solving" combat situations with improvisational fighting skill? Or do you want to feel accomplished by carefully working out enemy placement and learning how to execute the singular solution to a level?
Not to say that you can't build your game incrementally, only following your preferences at each step, but if you care about cohesiveness in your tone and mechanics (which is generally the aesthetic games aim for) and avoiding wasted design and implementation, it's worth thinking about the balance of things that go into platformers and similar games before you start building stuff. Consider this list I pulled off the top of my head: Castlevania (both original and SotN/Dawn of Sorrow styles) Kirby (Nightmare in Dreamland), Mario, Metroid (Metroid 2, Super Metroid, Fusion, Zero Mission), Super Meat Boy, Shovel Knight, 1001 Spikes, VVVVVV, Spelunky, 140, Risk of Rain, Cave Story, Binding of Isaac, Braid, Bastion, Downwell, Dustforce, Eryi's Action, I wanna be the guy, Mark of the Ninja, Castle Crashers, FEZ, and Rogue Legacy are all games that capture some portion of what you've described. If you broadly group them into some categories: "thinking" (VVVVVV, 1001 Spikes, 140, Braid), "fighting" (Bastion, Cave Story, Binding of Isaac, Downwell, Mark of the Ninja, Castle Crashers), "challenge" (Meat Boy, Eryi's Action, I wanna be the guy, Dustforce, Mario), and "explore" (Metroid, Castlevania, FEZ, Isaac and Risk of Rain to an extent), where do you want your game to sit? Not to scare you into paralysis and overdesigning--there's no way you can have some set-in-stone balance of elements a priori; game design is an art that's implemented iteratively through cycles of playtesting and refinement. A vague feeling of what you like in each area plus what you find easy to implement will probably guide you to a good final design, but it's important that you realize that you are making decisions that impact that with every decision you make: from high-level tonal ones like above, to more concrete ones ("how linear are my levels?", "backtracking?", "weapon/equipment customization?"), your choices end up making the final game.
Lastly, difficulty is very easy to tweak, but the fundamental nature of the game you've built isn't. To make something harder, make the player do more work faster; take Simon (the box with colored buttons on it): it gets harder because you're forced to make process the moves you need to make faster and faster. It's old, fair and challenging--should be the perfect game, right? I think a lot of people would call it boring compared to Megaman or Castlevania because it doesn't deliver on narrative or fantasy, and the nature of those elements are tied to how you build your game out of levels, monsters, weapons, powerups, and everything else. Focus on what you want your players to feel, then tune the difficulty until it becomes exciting.
Recommended media:
Even if you don't like what they make, this short video Apple made for one of their conferences hits on the fundamentals of design: "...requires focus... the first thing we do is ask 'what do we want people to feel'... there are a thousand no's for every yes..." Not sure how much design work you've done before, but this is it in a nutshell. Worth analyzing in relation phones (which is where the joy/convenience, abundance/choice tradeoffs in the beginning make the most sense).
"Intention": https://www.youtube.com/watch?v=nmV3KMniZuQ
Mark Rosewater has worked on Magic: the Gathering for a very long time now. While most of what he discusses are geared towards multiplayer, they're often important to think about in single-player too.
"10 things every game needs": http://magic.wizards.com/en/artic...me-needs-part-1-part-2-2011-12-19
"20 years; 20 lessons": https://www.youtube.com/watch?v=QHHg99hwQGY
I didn't talk about game feel in this, and while I'm not particularly excited about the game he's showing off, so much of what makes an experience exciting is up to the game feel, animation and music.
"Why your death animation sucks": https://www.youtube.com/watch?v=pmSAG51BybY
Extra Credits did an episode on what makes a game hard but fun instead of infuriatingly punishing.
"Extra Credits: Hard v. Punishing" https://www.youtube.com/watch?v=ea6UuRTjkKs
Books:
The Design of Everyday Things
Understanding Comics
Alright... I've been working on this at some stupid hour in the morning; sorry if parts don't make sense. Best of luck with your game.
Making an engine from scratch in Python or C# is tricky, since you have to bind to the OS level interfaces yourself. Python has a FFI system which lets you call C from Python with relative ease, and C# (and the rest of .NET) has DllImport, which achieves mostly the same goal. If you'd rather write most of the code yourself, there exist bindings to SDL2 for both Python (PySDL2) and C# (SDL2-CS). However, if you want to get right up to the metal, C/C++ is the way to go. You can still using a layer like SDL2 and get decent results, and it's easier to use from native C than through a wrapper in Python or C#, but you are giving up some control and using someone else's assumptions.
Your premise is fine, but I don't think you're matching your fantasy with your planned gameplay very well. A ninja returning home was successful, right? He must have practiced until he was a master at acrobatics, combat, etc. If he's so good, why is the game hard? Not that the story is particularly important to that kind of game, but as a game designer, you need to identify what your audience wants out of your game and what you can deliver on. It's clear that you want your game to be exciting and fun due to its challenge, but the implementation matters; for example: do you want to feel strong and powerful, "solving" combat situations with improvisational fighting skill? Or do you want to feel accomplished by carefully working out enemy placement and learning how to execute the singular solution to a level?
Not to say that you can't build your game incrementally, only following your preferences at each step, but if you care about cohesiveness in your tone and mechanics (which is generally the aesthetic games aim for) and avoiding wasted design and implementation, it's worth thinking about the balance of things that go into platformers and similar games before you start building stuff. Consider this list I pulled off the top of my head: Castlevania (both original and SotN/Dawn of Sorrow styles) Kirby (Nightmare in Dreamland), Mario, Metroid (Metroid 2, Super Metroid, Fusion, Zero Mission), Super Meat Boy, Shovel Knight, 1001 Spikes, VVVVVV, Spelunky, 140, Risk of Rain, Cave Story, Binding of Isaac, Braid, Bastion, Downwell, Dustforce, Eryi's Action, I wanna be the guy, Mark of the Ninja, Castle Crashers, FEZ, and Rogue Legacy are all games that capture some portion of what you've described. If you broadly group them into some categories: "thinking" (VVVVVV, 1001 Spikes, 140, Braid), "fighting" (Bastion, Cave Story, Binding of Isaac, Downwell, Mark of the Ninja, Castle Crashers), "challenge" (Meat Boy, Eryi's Action, I wanna be the guy, Dustforce, Mario), and "explore" (Metroid, Castlevania, FEZ, Isaac and Risk of Rain to an extent), where do you want your game to sit? Not to scare you into paralysis and overdesigning--there's no way you can have some set-in-stone balance of elements a priori; game design is an art that's implemented iteratively through cycles of playtesting and refinement. A vague feeling of what you like in each area plus what you find easy to implement will probably guide you to a good final design, but it's important that you realize that you are making decisions that impact that with every decision you make: from high-level tonal ones like above, to more concrete ones ("how linear are my levels?", "backtracking?", "weapon/equipment customization?"), your choices end up making the final game.
Lastly, difficulty is very easy to tweak, but the fundamental nature of the game you've built isn't. To make something harder, make the player do more work faster; take Simon (the box with colored buttons on it): it gets harder because you're forced to make process the moves you need to make faster and faster. It's old, fair and challenging--should be the perfect game, right? I think a lot of people would call it boring compared to Megaman or Castlevania because it doesn't deliver on narrative or fantasy, and the nature of those elements are tied to how you build your game out of levels, monsters, weapons, powerups, and everything else. Focus on what you want your players to feel, then tune the difficulty until it becomes exciting.
Recommended media:
Even if you don't like what they make, this short video Apple made for one of their conferences hits on the fundamentals of design: "...requires focus... the first thing we do is ask 'what do we want people to feel'... there are a thousand no's for every yes..." Not sure how much design work you've done before, but this is it in a nutshell. Worth analyzing in relation phones (which is where the joy/convenience, abundance/choice tradeoffs in the beginning make the most sense).
"Intention": https://www.youtube.com/watch?v=nmV3KMniZuQ
Mark Rosewater has worked on Magic: the Gathering for a very long time now. While most of what he discusses are geared towards multiplayer, they're often important to think about in single-player too.
"10 things every game needs": http://magic.wizards.com/en/artic...me-needs-part-1-part-2-2011-12-19
"20 years; 20 lessons": https://www.youtube.com/watch?v=QHHg99hwQGY
I didn't talk about game feel in this, and while I'm not particularly excited about the game he's showing off, so much of what makes an experience exciting is up to the game feel, animation and music.
"Why your death animation sucks": https://www.youtube.com/watch?v=pmSAG51BybY
Extra Credits did an episode on what makes a game hard but fun instead of infuriatingly punishing.
"Extra Credits: Hard v. Punishing" https://www.youtube.com/watch?v=ea6UuRTjkKs
Books:
The Design of Everyday Things
Understanding Comics
Alright... I've been working on this at some stupid hour in the morning; sorry if parts don't make sense. Best of luck with your game.
William Bundy
Making an engine from scratch in Python or C# is tricky, since you have to bind to the OS level interfaces yourself. Python has a FFI system which lets you call C from Python with relative ease, and C# (and the rest of .NET) has DllImport, which achieves mostly the same goal. If you'd rather write most of the code yourself, there exist bindings to SDL2 for both Python (PySDL2) and C# (SDL2-CS).
It is extremely simple to make an engine from scratch in C#.
It's not going to be the handmade way - but you're not going to get the complete handmade experience in pretty much anything but C, C++ (to some degree) or some other compiled GC-less language. And that is okay!
There absolutely no reason to DllImport anything yourself, there's the OpenTK library which does that for you. It has a thin wrapper for OpenGL (OpenGLES) and OpenAL, Input handling, plus, some basic utility classes like Vector3, Matrix4, Quarterion.
Generally you don't even have to deal with any OS level interfaces AT ALL. And that is a good thing.
.NET framework basically has you covered in a cross-platform way (meaning Win, MacOS, Linux) for pretty much everything you are going to need.
In other words - there's not much of an "engine" - as such - to even write. You can straight up write your game - and that's the beauty of it.
Very little additional glue code is necessary (you'll need to write font rendering code, atlas packer, 3d model loader (if you need one), some IMGUI, some code to order and group together OpenGL draw calls, and some other minor things). Performance on PC is not going to be an issue for a vast majority of indie games.
Go for it.
Edited by pragmatic_hero
on
pragmatic_hero:
I think you've missed the point of the Handmade Way. The Handmade movement is nothing about which programming language you use, nor if you use libraries or not, it about making software great, and becoming a better programmer & teaching other to become better*
You can still make something from scratch in C# the handmade way even using libraries. Hell, you can do things in JS and still follow the handmade philosophy.
- Bill
*everyone has a slightly different take on it.
I think you've missed the point of the Handmade Way. The Handmade movement is nothing about which programming language you use, nor if you use libraries or not, it about making software great, and becoming a better programmer & teaching other to become better*
You can still make something from scratch in C# the handmade way even using libraries. Hell, you can do things in JS and still follow the handmade philosophy.
- Bill
*everyone has a slightly different take on it.
Edited by Ginger Bill
on
gingerBill
The Handmade movement is nothing about which programming language you use, nor if you use libraries or not, it about making software great, and becoming a better programmer & teaching other to become better*
Isn't that what every online programming community is about though?
Could handmade hero be made in javascript and run well and consistently?
I have my doubts about that (except if it's some sort of asm.js implementation maybe).
I've always had the impression the Handmade Way had performance and respecting the hardware as one of it's core tenets.
And as such basically any garbage collected, dynamic or JIT-ed language goes right out of the window (which leaves very few options language wise unfortunately).
Edited by pragmatic_hero
on
Handmade.
It’s not a specific technique or programming language—it’s an idea. The idea that we can build software that works with the computer, not against it, using good craftsmanship. That software can and should be built carefully, with performance and usability in mind, avoiding unnecessary complexity by digging deep into the core of what the program does.
Interpret as you wish.
pragmatic_hero
I've always had the impression the Handmade Way had performance and respecting the hardware as one of it's core tenets.
I agree with this assessment in a certain way. If I were to try to explain the "handmade way" myself, I would say it involves first and foremost trying to understand what is actually going on in your code.
I believe that the community tends towards C and C++ because once you've decided that "understanding how your code actually works" is one of your goals, languages like C and C++ make that easier. If you define an "expert" in a language as someone who understands what the language does for their software production, then having a GC'd language is actually harder to master because understanding the GC is very hard. If you instead have the contrasting philosophy "it doesn't matter what happens at other abstraction levels", then it may well be slightly easier to master a "high level language".
In other words I see the train of reasoning that defines the "handmade way" as something like:
1. Performance is important.
2. Performance is achieved by understanding what is actually happening in software.
3. Powerful tool are helpful but they should never interfere with (2), or performance will suffer.
4. Unless you have mastered the features of another language, C is the best language for achieving (3).
Edited by Allen Webster
on
Reason: clarified wording
The Handmade way as I see it is less a philosophy and more a brass tax process. It's about understanding the actual, measurable problem, and solving exactly that. You often arrive at performant solutions, but that isn't the end goal unless your problem is performance.
It's a very zen style of software development. Solve what's now.
It's a very zen style of software development. Solve what's now.
Edited by Jesse
on
Interesting,
Ask yourself Is this code the most performant given the current restrictions at play? And have I removed most accidental complexities to the best of my knowledge? you'll only get clearer answers if you, as Allen stated: "understand what is actually going on in your code", which may or may not be harder if you're in a higher level language (this will depend if it's purely FP, runs on a VM, and other knowledge-based factors, but an interpreter like Python is straightforward enough to follow). This is indeed why this site came to be; we think some of the present lethargy and absence of caring to understand is curtailing potential.
For a non-handmade example, observe the following Python code I've seen in the wild to send e-mail, and it's a function called frequently to send multiple messages in succession:
I hope the computational waste involved here is clear, and many online communities are fine with copy-pasting some given code of this form as their solution to advance their project. Another extreme example is a somewhat known SDL2 tutorial (I'll avoid linking, I'm not here to attack other websites), where a font resource is opened and closed as you bake some glyphs onto a texture that will get thrown away after rendering, only to repeat the process at a later frame. I won't bother pasting the code.
So you'll notice, even though we care about performance, we care more about people caring about good software, and I suspect this has been lost to some unreasonable degree.
The manifesto is flexible because developers may want to explore the technically-best way to write in some language or platform and go through that difficulty for whatever reason. An example of a beautiful handmade game using the Unity engine is Ori and the Blindforest:
And, perhaps more surprising:
Quotes Source
An example closer to home is the ever popular MotionBox. Yes, it's C++ but people don't know the 3rd-party libraries it leverages such as Qt, which some veteran members could traditionally think of as not-handmade. Even so, MotionBox is as fast as they come. It's worthwhile to study why.
Thoughts welcome.
TLDR; In a slow-performing software world, we'll take improvement wherever we can! I like my environment / layers super thin, but shunning people who don't use low-level languages is, to me, nothing but counterproductive.
Ask yourself Is this code the most performant given the current restrictions at play? And have I removed most accidental complexities to the best of my knowledge? you'll only get clearer answers if you, as Allen stated: "understand what is actually going on in your code", which may or may not be harder if you're in a higher level language (this will depend if it's purely FP, runs on a VM, and other knowledge-based factors, but an interpreter like Python is straightforward enough to follow). This is indeed why this site came to be; we think some of the present lethargy and absence of caring to understand is curtailing potential.
For a non-handmade example, observe the following Python code I've seen in the wild to send e-mail, and it's a function called frequently to send multiple messages in succession:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | def sendemail(from_addr, to_addr_list, cc_addr_list,
subject, message,
login, password,
smtpserver='smtp.gmail.com:587'):
header = 'From: %s\n' % from_addr
header += 'To: %s\n' % ','.join(to_addr_list)
header += 'Cc: %s\n' % ','.join(cc_addr_list)
header += 'Subject: %s\n\n' % subject
message = header + message
server = smtplib.SMTP(smtpserver)
server.starttls()
server.login(login,password)
problems = server.sendmail(from_addr, to_addr_list, message)
server.quit()
return problems
|
I hope the computational waste involved here is clear, and many online communities are fine with copy-pasting some given code of this form as their solution to advance their project. Another extreme example is a somewhat known SDL2 tutorial (I'll avoid linking, I'm not here to attack other websites), where a font resource is opened and closed as you bake some glyphs onto a texture that will get thrown away after rendering, only to repeat the process at a later frame. I won't bother pasting the code.
So you'll notice, even though we care about performance, we care more about people caring about good software, and I suspect this has been lost to some unreasonable degree.
The manifesto is flexible because developers may want to explore the technically-best way to write in some language or platform and go through that difficulty for whatever reason. An example of a beautiful handmade game using the Unity engine is Ori and the Blindforest:
Given the complexity of the game and having to have a continuous solid 60fps experience with no loading screens we actually had to shift to using Unity 5 for Ori, since it is the Unity version that has all the necessary optimisation work for level streaming.
- Moon Studios
And, perhaps more surprising:
We are still hard at work in making Ori the best experience on Xbox One with Unity 5 and the Unity team has been a great help in constantly improving and pushing the boundaries of Unity to be able to reach that quality bar and helping us ship hopefully one of the best looking and highly performing 2D games in the recent years.
-Moon Studios (emphasis mine)
Quotes Source
An example closer to home is the ever popular MotionBox. Yes, it's C++ but people don't know the 3rd-party libraries it leverages such as Qt, which some veteran members could traditionally think of as not-handmade. Even so, MotionBox is as fast as they come. It's worthwhile to study why.
Thoughts welcome.
TLDR; In a slow-performing software world, we'll take improvement wherever we can! I like my environment / layers super thin, but shunning people who don't use low-level languages is, to me, nothing but counterproductive.
Edited by Abner Coimbre
on
Reason: Shorter tldr;
To apply the Handmade way on that Python code, we have to evaluate its exact use contextually. Is it saving time relative to its lifecycle and runtime? If it is, does the savings meet expectations? If it's not, we don't understand, or worse recognize, the problem.
We only have so much time to work on our problems. We cannot solve all our problems with our allocated time. So we must prioritize. Fast code can help free us from waiting (and the friction it causes taking us out of the zone, among other things), but it takes time to develop and requires more skill (which took time to cultivate). So if all your skillful developers are spending all their time speeding up a runtime that is legitimately already fast enough, you're not solving the real problem (which is improper use of time and skill), and have departed from the Handmade way.
So I'm not against performance at all. I'm just not sold on the idea the Handmade way is 'runtime' performance centric. It's more holistic. It's about being performant developers, that by extension, tend to provide performant solutions. Why we call this "Handmade" is because the real problems reveal themselves when you 'do it yourself' instead of just taking someone else's word that 'it's already been solved'.
We only have so much time to work on our problems. We cannot solve all our problems with our allocated time. So we must prioritize. Fast code can help free us from waiting (and the friction it causes taking us out of the zone, among other things), but it takes time to develop and requires more skill (which took time to cultivate). So if all your skillful developers are spending all their time speeding up a runtime that is legitimately already fast enough, you're not solving the real problem (which is improper use of time and skill), and have departed from the Handmade way.
So I'm not against performance at all. I'm just not sold on the idea the Handmade way is 'runtime' performance centric. It's more holistic. It's about being performant developers, that by extension, tend to provide performant solutions. Why we call this "Handmade" is because the real problems reveal themselves when you 'do it yourself' instead of just taking someone else's word that 'it's already been solved'.
Edited by Jesse
on
JesseMeyer
To apply the Handmade way on that Python code, we have to evaluate its exact use contextually.
Recall what I said before I showed the code:
abnercoimbre
it's a function called frequently to send multiple messages in succession
Presuming a single account, the only SMTP server call we'd expect is SERVER.sendmail(...), with the init-close calls extracted out. This problem was a variant of the SDL2 example that followed—it has nothing to do with finely-tuning anything! Opening a font resource outside a recurring procedure, and baking all glyphs onto a texture for use across the program are not formal optimizations. It's actually the obvious way (is it not?) yet there are developers who legitimately do not think beyond having stumbled upon someone's—in this case, inappropriate—tutorial samples. This is a problem of a systemic nature with a history of reacting to complexity in ways that may now need to be balanced back.
JesseMeyer
So I'm not against performance at all. I'm just not sold on the idea the Handmade way is 'runtime' performance centric. It's more holistic. It's about being performant developers, that by extension, tend to provide performant solutions.
My examples with Ori and MotionBox were about highlighting performant developers who just happened to be working towards improving runtime-performance (naturally... Unity was effectively not fast enough for Ori. MotionBox thrives on a smooth UX while using complicated frameworks). I don't know, your handmade way might only see an ease-of-portability axis or some such. But you're concerned about it, and that's huge.
Edited by Abner Coimbre
on
Reason: Formatting.
I think we're on the same page. Fast-food-esque development is as shitty as it sounds. So, right - the fact that it seems to be the norm and therefore a silent standard is the real problem. How we address, assist, or perhaps avoid that culture is of course a great concern for this community. I have some concern that our game-development roots have caused a (often helpful) bias in our priorities. Our chief aim is to make well how we make software. That produces good software, which is fast. But the point isn't to make it fast.
Edited by Jesse
on
Reason: clarity