Hi,
I have been following Handmade Hero since the start and for some time now I have wanted to make my own 2d game.
My problem is that nearly all the code that Casey has written I could use in my project. So every time I start on my game project I just end up copying the Handmade Hero code bit by bit and after some time I stop and restart the project because I would rather write the code myself in stead of copying it.
I feel that it is hard for me to write the code from scratch knowing that it is already written in Handmade Hero and this stops me from continuing with making the game. Also it is hard not to copy the Handmade Hero code since it does all the things that I need.
Has anyone else had the same problem and are there any good ways to get started and stop copying the Handmade Hero code?
I have been following Handmade Hero since the start and for some time now I have wanted to make my own 2d game.
My problem is that nearly all the code that Casey has written I could use in my project. So every time I start on my game project I just end up copying the Handmade Hero code bit by bit and after some time I stop and restart the project because I would rather write the code myself in stead of copying it.
I feel that it is hard for me to write the code from scratch knowing that it is already written in Handmade Hero and this stops me from continuing with making the game. Also it is hard not to copy the Handmade Hero code since it does all the things that I need.
Has anyone else had the same problem and are there any good ways to get started and stop copying the Handmade Hero code?
There's nothing wrong with copying bits of code. I had to profile something a few months ago and I started with Casey's timed block stuff pretty much verbatim. Over a few weeks, the code diverged as my needs differed, but the core is pretty much unchanged.
It's a lot harder to write something from scratch, especially if you haven't written a particular thing before. If you get stuck, just push through and get something working, knowing it might not be as fast or as elegant as what's in HH. Then when you have something working, go back and look at what casey did, where his approach differed, and where you did the same things.
Maybe this is because HMH is the only comparison point you have. Read other open-source codebases. See how they solve it. Look at the tradeoffs.
https://en.wikipedia.org/wiki/Lis..._games_with_available_source_code
If you are really stuck, just make something more different than HMH. Make a platformer with a tile-map. Add some feature like destructible terrain that HMH lacks. Or start down paths that HMH has yet to cover, add fullscreen mode or hardware acceleration or pathfinding or something like that.
It's a lot harder to write something from scratch, especially if you haven't written a particular thing before. If you get stuck, just push through and get something working, knowing it might not be as fast or as elegant as what's in HH. Then when you have something working, go back and look at what casey did, where his approach differed, and where you did the same things.
Maybe this is because HMH is the only comparison point you have. Read other open-source codebases. See how they solve it. Look at the tradeoffs.
https://en.wikipedia.org/wiki/Lis..._games_with_available_source_code
If you are really stuck, just make something more different than HMH. Make a platformer with a tile-map. Add some feature like destructible terrain that HMH lacks. Or start down paths that HMH has yet to cover, add fullscreen mode or hardware acceleration or pathfinding or something like that.
Edited by Joel Davis
on
The symptoms you describe sound like you are "stuck in the weeds." You are too far down in the details of the project.
Keep the primary goal in mind: complete the game.
The stream downplays the effort involved to put a complete game together but there's no getting around it: thee are a lot of tasks to complete.
If you get stuck on one ask yourself: "Is this good enough to work with for now?"
The stream does this all the time. Notice the constant reference to the platform layer as a "prototype." It's good enough for now and allows us to move on to the next section.
"Don't take counsel from your fears."
This is an old military maxim that applies here. The "fear" is that you will miss something or not do it as well, etc. Well, the truth is, you probably will. Software programs are extremely complex and "There is No Silver Bullet." You will make mistakes and the program will need to be revised, altered, maintained, etc. Skilled programmers plan for this change and strive to write programs that (they) can easily alter. Once the program is working it is far easier to see what and where to change it. What needs to be reworked? What tools are needed? So don't let these fears stop you from moving forward.
You will learn more from your mistakes than from successes.
HTH
- tim
Keep the primary goal in mind: complete the game.
The stream downplays the effort involved to put a complete game together but there's no getting around it: thee are a lot of tasks to complete.
If you get stuck on one ask yourself: "Is this good enough to work with for now?"
The stream does this all the time. Notice the constant reference to the platform layer as a "prototype." It's good enough for now and allows us to move on to the next section.
"Don't take counsel from your fears."
This is an old military maxim that applies here. The "fear" is that you will miss something or not do it as well, etc. Well, the truth is, you probably will. Software programs are extremely complex and "There is No Silver Bullet." You will make mistakes and the program will need to be revised, altered, maintained, etc. Skilled programmers plan for this change and strive to write programs that (they) can easily alter. Once the program is working it is far easier to see what and where to change it. What needs to be reworked? What tools are needed? So don't let these fears stop you from moving forward.
You will learn more from your mistakes than from successes.
HTH
- tim
Don't worry about it so much.
Assuming the game you are trying to make *isn't* Handmade Hero, your code is going to diverge from Casey's pretty quickly. You'll likely end up rewriting various parts of the engine and platform layers, just because of the requirements of your particular game design.
However, you'll find out what needs to change once you're working on the game itself. There's an adage, "build a game, not an engine". That doesn't mean don't write the low-level code, but to write it with some game's design informing your choices. The entire point of a custom engine (other than being fun to make) is that it can be tuned exactly to *your* game, rather than being some overly-generic blob you have to work around.
I just finished a ~6 month game project, and I had similar concerns at the start. The engine I ended up with definitely takes some of its structure from Handmade Hero, but it's also significantly different because I rewrote large chunks of it to support *my* game. (In particular, it uses a GL renderer, an entity-component system, and went through something like 6 different iterations of audio system.) There is an *incredible* amount of stuff to make in a game, and a lot of it will be more or less unique to that game.
(Now, if your concern is simply *understanding* the code before using it, that's different. And my only advice there is: go play with it. Change things, see what breaks, see if you can fix it.)
Assuming the game you are trying to make *isn't* Handmade Hero, your code is going to diverge from Casey's pretty quickly. You'll likely end up rewriting various parts of the engine and platform layers, just because of the requirements of your particular game design.
However, you'll find out what needs to change once you're working on the game itself. There's an adage, "build a game, not an engine". That doesn't mean don't write the low-level code, but to write it with some game's design informing your choices. The entire point of a custom engine (other than being fun to make) is that it can be tuned exactly to *your* game, rather than being some overly-generic blob you have to work around.
I just finished a ~6 month game project, and I had similar concerns at the start. The engine I ended up with definitely takes some of its structure from Handmade Hero, but it's also significantly different because I rewrote large chunks of it to support *my* game. (In particular, it uses a GL renderer, an entity-component system, and went through something like 6 different iterations of audio system.) There is an *incredible* amount of stuff to make in a game, and a lot of it will be more or less unique to that game.
(Now, if your concern is simply *understanding* the code before using it, that's different. And my only advice there is: go play with it. Change things, see what breaks, see if you can fix it.)
Thanks for all the answers.
The funny thing is that I have already made a small prototype in Javascript and when I programmed that I had no fears that I was doing something wrong because I did not have the "right" code to copy from.
I will start the game in C/C++ from scratch again and only copy/look at the Handmade Hero code if absolute necessary and only do the absolute necessary.
The funny thing is that I have already made a small prototype in Javascript and when I programmed that I had no fears that I was doing something wrong because I did not have the "right" code to copy from.
I will start the game in C/C++ from scratch again and only copy/look at the Handmade Hero code if absolute necessary and only do the absolute necessary.