I loved participating in Game in a Day, and I gained a lot from the experience. For one, I have created a game that I can continue to work on until it is a finished product. I added a few more game development blog links to my list. Also, I learned quite a few new things as well as finally understanding things that I already “knew”:
- I still have a lot of C++ to learn.
- I still have a lot of Kyra to learn.
- Nothing helps more than proper planning.
- Hacking is a lot more fun with a good plan.
- I need to remember to
make cleanbefore packaging a project. There is a big difference between 500KB and 2.2MB.
- After a successful build, not checking in the code before attempting to add a feature is just asking for trouble.
- Too much Mountain Dew is bad.
- Not planning for snacks/eating/showering is even worse.
- It is a lot easier to see that death marches can result in a lot of uncommented code, even with the best of intentions.
- Eating your own dog food is great for revising your design since you can find out what doesn’t work quickly.
That last point is in reference to an article by Joel Spolsky. He basically talks about the importance of actually using your software to dig out bugs and usability problems before releasing them to the public. Eating your own dog food. While I was programming, I was testing. One problem I found was the arbitrary restriction of only four directions for movement.
When I created the control scheme, I didn’t want to waste time making four more images for diagonal movement (even though it would have been a few more minutes of copy, paste, edit, and encode to .dat file), so I made the movement restriction match the images in the game. Perfectly fine, right?
After a few iterations, adding a different feature or otherwise working on unrelated code, I found myself getting frustrated. When I built the program and tried to run it, I found that the controls were just plain irritating! At one point I decided to make the simple change so that the player character can move in all 8 directions. It wasn’t huge, but that tiny difference made the game less unbearable.
My ability to create improves every time I use it. All the theory and facts I’ve learned through books and tutorials are nice, but they don’t compare to the experience of actually making use of them. FuseGB may not be a great game, and I’ve definitely made some mistakes developing it, but at the very least it has provided me with a lot of experience to help in future game development. As Gilbert Chesterton says, “If a thing is worth doing, it’s worth doing badly.”