I guess I'll post here. It's a book. Feel free to tl;dr.
My released project (GalaxyNES) took almost no time at all. The first build (containing nothing but joypad reading, and movement that was not velocity based and 1 pixel per frame) was on 8/13/08, and the current release was built on 2/6/09. Even though it lacks music/sound effects, the gameplay is complete. (I plan to add some stuff, but that will probably only take another 15 days when I get around to it) And in fact that only reason it even took THIS long (six months) is because I got stuck/frustrated and didn't work at ALL on it for about three months.
The hiatus was from 8/27/08 (at which point ALL of my difficult enemy logic/collision detection was finished) to 12/18/08. The reason for the hiatus: I got stuck on a stupid problem and didn't ask for help. When about 40 of my green enemies (they dodge bullets) were on screen they started warping around. I know now this is because so many of them acting at once took more than a frame of CPU time, and the NMI at that point didn't store/restore the registers. Had I asked on this forum, I'd have probably finished the game twice as fast.
Tip ZERO!: Ask for help with you need it.
But that was the only pitfall I fell into for this game. Other than that, I pretty much worked straight through. Here are some things I did that kept me motivated. (which are similar to other people, I suppose)
1. I made a source/build backup for every major change.
This is good if you completely break a build. It's also how I know exactly when I started/took a break from/and "finished" the game. Between the first build and release of the game there are 47 source backups with a playable rom. It's actually really cool to start at folder one, and play each one, and watch the game get more and more complex. I did that to remind myself of how much I did whenever I felt burned out.
2. I knew exactly what I was going to do before I did it.
Nothing in the game was really unplanned before I started working on it. Granted this is easier when working on a clone game, but it's true for my current game as well. I knew what I was going to leave out/keep in and how it would behave on NES before I started. The only thing I didn't plan for is how many cycles things would take up (which is killing me now and killed me then with the green enemies). The first thing I did for my current project was write exactly how I want my character to behave. Shortly after that, I wrote a RAM map and a few data formats.
3. I kept/keep a log of what is/was being done, and things to think about, so even if I took/take a long break, I could jump right back into things.
Inside my current "working on.txt" are some headers, each acting like a short of checklist.
"Things to think about:" or things I could consider changing/different ways to write routines that MAY result in optimization. I also keep possible changes to level format and things like that here.
"Things to Optimize:" Things I am SURE will make the program faster, and just haven't gotten around to implementing. The things that go here, usually sit there for a while since they're usually optimization for functions that run only once per frame. When I need to optimize something that's run 12 times a frame I do it immediately instead of sticking something here.
"Currently Working On:" Or whatever I'm in the middle of doing right now. Sometimes multiple things end up there, and sometimes I write (on hold) next to something there, so I know it still need to be done, but it's not as important as what else is in there.
When I complete something, I take it off the list.
4. Document your own formats!
I have a folder called notes that contains all of the info needed to understand my level/metatile/animation data formats. Before I finalize a format.txt document, I write a format planning document in a stream of consciousness style as mentioned before. I basically argue with myself in the document about why everything I think of won't work. When I've run out of ways to make myself look stupid for forgetting things the format needs, it means the format will probably work okay. It's better to get that stuff out of the way in a planning document than it is to code something, and realize you need to change EVERYTHING because you overlooked something. When "dataformat planning.txt" is done arguing with itself, "dataformat.txt" is created so I remember how it works later. I also keep the planning document so I know why I made the choices I made.
I also keep documents in the notes folder about how many cycles various subroutines take up. (so I can know which things I need to focus on when I need to optimize.) I also keep certain things I can never remember there for quick reference (like that #$FF is left slow, #$7F not #$80 is left fast in my velocity handler)
5. I talk with people about my projects sometimes when I get stuck.
Sometimes it's nice to just bounce ideas off someone, even when I decide some of their ideas won't work. In fact some of the ideas for how I might change how my slope data is stored came from someone who is not a programmer. No matter how discouraged and depressed I am with my project, whenever someone asks about it my eyes light up as I talk about how much I've currently done. But that might just be me.
6. I'll end this by mirroring everyone saying you should start small.
I gave up NES programming when I tried to start with my own big RPG project. (That was in '07. I barely got off the ground). Then my brother showed me Geometry Wars, and I couldn't help but wonder if it could work on NES. I think every time I learn to program for a "new" old console I'm gonna make a clone game just to teach myself the nuances of the system. There's less to plan when you make a clone game, and you can focus on just learning to code. (I await the bricks to come falling through my window for suggesting the community should make more clones.)
Really though, I think the bottom line is, "KEEP ORGANIZED!"
Tepples posted while I was write this book.
tepples wrote:
One thing I've had to learn to do is hold my tongue: not release anything to the public until it's ready, so that I don't get people's hopes up on something that I'm not absolutely sure I can deliver. I failed on this with President.
I agree. But this line of thinking of keeping things hidden is also what kept me from asking for help.
tepples wrote:
I too follow Sivak's lead on this, which is why you see so many non-scrolling games.
I started with a nonscrolling game, and am now working on a game that scrolls in all four directions like a Sonic game would. The scrolling and level loading and display is already done, and I found it easier than the physics I'm writing now. After making one nonscrolling game or a few, people should try to move to something more difficult.
I'm longwinded. End post.