It’s crucial that as the game production progresses, you must have a working product. At the end of your coding session, you project must work (at least to some extent without crashing). By always having a working version you know that the in the next session you can continue working on the game, instead of trying to find out what’s wrong. It’s also practical to have a working demo in case you need to show the demo to someone: you’ll always have something to show.
Remember: Have a working version of your game before you stop coding for the session.
I started coding games when I was a small kid with access to Commodore 64.
This very much falls under the same category as “Get at least one objective completed per day”, at least for me anyway. I doubt I could sleep if I left something broken.
Yeah I like this one too, it’s not always possible, esp. if you get interrupted and/or have kids etc. But I like to get even a rudimentary game working so I can show people, then every time you work on it, you are just improving that already working game, and that feels great.
This comes up many times, but sometimes you just can´t do it. This is why they invented TODO/NOTE/etc. – lists. I´v seen cases where the program was broken for weeks. :=)
Anyway, you shouldn´t stress about it, just make sure that you write down the most important things before you quit, it´s better way you know, trying to get working version each night can kill you. ;)
Using test driven developement, I finish a coding session with everything compiling for the exception of a test. That particular test will either not compile or not pass depending how far I am working on that feature. This way, when I come back for my next session, I know exactly where I left off and I’m not starting by losing 30 min to figure out what I should be doing next. The test clearly shows you the intent of what you wanted to do, so you just continue from where you left off.
Good advice. Sometimes though, having a small bug when you start your daily coding will give you something to jump directly into (trying to fix) as long as you have some kind of idea how to fix it. Then you’ll be “on a roll” and ready to move on to other things.
Just some thoughts.
I think it’s important to add that you should back up all your code before each work session. If the worst should happen, you’ll have a working code set than you can revert back to, which ensures that you’re safe and have 100% chance of ending with working code at the end of each session.
That’s what I’ve been doing on my stuff, at least.
I back up my code and keep a log of when it was backed up(date and time).
I keep those code backups on a separate machine too, so it’s safe if my hard drive fails.
I agree 100% with the Test Driven Development comment, made by Shadx. You write the tests for your own modules, so you can set the pass/fail parameters. If the test passes, you can feel safe about integrating the code into the game. At the beginning of a new session you can still test all added modules to make sure that they are continually working based on your parameters. If a module becomes more complex during development, new test cases can be added.
Test Driven Development is a great, great idea.
Test Driven Development sounds good… but I doubt it helps in this situation. Not necessarily. If you have some todo #1 to do… and if you fail to complete the task I think it’s hard to continue from the point where you were the next day. Your mental process gets cut. It’s kind of difficult to explain, but I like to work on those todos one by one… and get them completed & have working demo always.
I’m not saying Test Driven Development is bad, it sounds very efficient. I just doubt if it helps in this situation.
Hostile – yep, backups are must.
I am not sure that I agree that your project should be working at the end of each coding session. What I will agree to is that you should always have a version available that does work and can be demonstrated in the event that you are called on. I cannot count the number of times I have been stumped on a difficult coding problem only to sleep on it and then resolve it in the shower the next day.