This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

how to: select, develop, and finish a project: your thoughts

how to: select, develop, and finish a project: your thoughts
by on (#55616)
The topic of how many homebrew projects get completed comes up often around here, but I haven't seen a thread devoted specifically to this topic (I guess Homebrew Complexity is related, though).

I know that in my own case it has been challenging to figure out what I really wanted to do, and also challenging to figure out how to really stick to something. But, I've developed a routine that works for me, so at this point I believe I will finish my project.

Now, what are all your thoughts? If you have finished a project of reasonable size, how did you select it, stick with it and finish it? If not, what are you trying to do to get your project finished?

I was hoping that if this thread does well it could be gleaned for the wiki, thus inspiring newbies who aspire to develop a NES game.

by on (#55617)
Well, I haven't yet finished a huge project yet, but hopefully within this next year, or possibly sooner than that I should be finished with a pretty big project. I have coded so much of it that I can't let it go to waste. Basically all I have left to code is player-enemy interaction. This sounds like it includes everything, but currently I have the entire sound engine completed, the entire drawing engine completed (which includes scrolling, map rendering, displaying and updating valuable information on the status bar, drawing as well as animating objects and their weapons, probably some other stuff), AI is currently being handled and enemies can move around and collide with the background, and the player can move around with all of the physics coded, including colliding with the background as well as swimming in water. I do have a little more physics coding to do with enemies like gravity, but I've basically set everything up to now start focusing on game play.

Anyways, that was a bit of a rant, sorry. But like I said before, once I got to a certain point in my project, I was motivated to stick with it because of how much I'd completed. When something looks that promising, I feel like I can take it seriously and keep working on it. As for how I selected it, I wanted to start with something not too challenging, but definitely something that would allow me to move on to bigger and better projects after completing it. I would recommend that before you start coding, you know what type of game you're making, and how it will be played. You want a vision in mind before you start making something. This time, I had a vague idea of what kind of game I wanted before I started coding, and that was fine when I was just developing the rendering and sound engines, and even the AI handler as well as some of the player's physics. But then I hit a huge road block as I didn't think much about exactly how the player would interact with enemies. I knew that the player was going to be jumping around shooting them, but I didn't know anything beyond that. So then I stopped working on the project for days, not knowing where to go next. And that kind of thing is really not motivational, and could end up in a project being abandoned. So it's really important that you know what your vision is so you know exactly what you need to do in order to get the project done.

Besides that, I don't know. I enjoy working on games, so the enjoyment I get from working on my projects is good for trying to complete them...

by on (#55626)
Quote:
Well, I haven't yet finished a huge project yet, but hopefully within this next year, or possibly sooner than that I should be finished with a pretty big project. I have coded so much of it that I can't let it go to waste

I could say the exact same... Dragon Skill was supposed to be released arround 2007-2008, but it's still not complete.

I have fully completed the game engine LONG ago, altough I made some improvements (like 16-bit object coordinates instead of 8-bit) which needed almost a full rewrite of all routines which had to do with sprites and collision.

I guess it's up to each one having different qualities, but to me developing a game engine, composing sound is not a problem. Graphics is a bit of a problem, but I was able to overcome it. What is really the hard thing to do is enemies and bosses. I have really some trouble to make cool enemies, and even more trouble to decide how they'll act on the field. In fact chances are that 80% of my enemies will just walk randomly on the field because I can't come up with anything else, hopefully nobody will notice.

by on (#55642)
I'm just now barely thinking about what I want to make, but I can already see that art and music are going to be hard to come by.

My solution for art is to make everything in Blender 3D, render it in frames, and scale it down to sprites and metasprites and backgrounds.

My solution for music is to take public-domain music, or music with very permissive licensing, and re-make it for the APU.

by on (#55643)
I guess I was hoping more for discussion involving how you budget your time and maybe techniques involving self-motivation. All of us at some point in our experience have probably dealt with what might be called "coder's block" or have a several months long slump. What I'm interested in is routines of behavior or attitudes that help avoid these large-project-killers (or, if not killers, delayers). I feel as though I've found some techniques that work for me but I wanted to see if anyone else has thought through these issues as well. I didn't want to blather on about my own techniques because I felt it would seem as though I was declaring I've "figured it out," which, until I finish a game, will not really mean much to anyone anyhow =)

by on (#55645)
Quote:
I guess I was hoping more for discussion involving how you budget your time and maybe techniques involving self-motivation.

Simply put I don't budget anything, and yes I loose motivation regularly, and I'm a very lazy guy who always gets bored and annoyed as soon as something become a little repetitive, so if you could share you super idea to be always motivated to advance on the project it might help me.

In fact what I do is that when I'm annoyed on one project I switch to another, so that instead of having a completed game, I have one half-completed game, and a mess of ideas/basic concept for a few other games that I hope I'll eventually make.

by on (#55646)
I don't mean to imply I have found a solution that could work for everyone. All I know is I have struggled quite a bit in the past with motivation, and have numerous failed project attempts. I could share my ideas, but I was hoping that various individuals in our community who have actually finished a game that we've all seen and played could provide their own thoughts.

So, it remains to be seen whether my current plan will actually work but...basically I have five major things in place which I think have helped me a lot.

1) I finally realized making a retro game is what I really wanted to do: modern stuff like XNA just didn't appeal to me. I think a lot of people here at NESDEV have also figured out that it is what they want to do.

2) I make certain that I intentionally space out the time I use to work on my project. I work on my project approximately three times a week, usually wednesdays, saturdays and sundays. This keeps me always looking forward to it and I don't burn out. In the past, I would work every day on something (that I could) and burn out within a few months.

3) I keep what I call a development log. It is like a messy personal blog. When I sit down to work, I may not immediately know what to code or what to work on. I just start blathering stream of consciousness style about what I'd like to work on and how to break it into smaller tasks. I also use it to write pseudo code for tricky algorithms.

4) I use source control. Abstracting the process of keeping track of revisions makes it really easy to try, fail, revert, try, fail, revert (not always necessary, but very useful when trying new things). It is also satisfying to see a log of all your changes, and gives you a sensation of momentum.

*edit*
5) I choose reasonable constraints for a project that I start, and I stick to them no matter what. I feel part of the reason past projects of mine failed was I kept adding new features or revising large parts of them over and over. I decided I'd rather finish something simple, then move on to something more ambitious. (I should add, I observed that Sivak appears to do this, and I felt it was worth emulating).

I guess the reason I believe this will work for me is that every single project I ever tried in the past failed utterly after a few months, but on this one I have been going at an absolutely consistent pace for over a year now, with no breaks (except the short, built in ones).

I was reluctant to share these ideas because I haven't yet finished or released anything. But, maybe they could help others anyway, I dunno. I was hoping that some other members of our community who have released projects could share their ideas also---but maybe for some, finishing projects is an entirely intuitive process and thus they may not be able to share "techniques."

by on (#55647)
I'm going to have to leave soon, but I just wanted to say before I left that I totally have a text document filled with me blabbering about ideas that I have possibly with some pseudocode like you were saying! It's really informal, and doesn't discuss things in an organized manner. I basically spout off ideas and say stuff like, "Well, I guess tommorow I'll start working on handling gravity for enemies. I've got a lot of the physics stuff done, but I really have to get that done before I can start coding other stuff. Or maybe I'll work on player-to-enemy collision" or something like that. It's funny, because I find this to be very helpful, as I can see ideas I had for split seconds that I would have forgotten had I not written them down.

Actually, now that I think about it, I have a main text document that I named "Programmer's Notes" that I fill with this when it's concerning the whole project, and then for each part of the engine like handling animation, sound, or other things, I have other documents filled with ideas for that part in particular. So this definitely helps me too. I'll probably have more to comment on this later, but I've got to get going now, sorry!

by on (#55648)
Oh, cool. This is good, if we find that a lot of our members follow similar techniques, perhaps it could be gleaned for the Wiki to give tips to newbies who not only want to learn to write code for the NES but in general would like to organize how they approach a project. That would make this community very unique (it already is...). I haven't seen all that much discussion out there on this topic, on any programming website. But, it is a valuable topic.

by on (#55649)
Bregalad wrote:
What is really the hard thing to do is enemies and bosses. I have really some trouble to make cool enemies, and even more trouble to decide how they'll act on the field. In fact chances are that 80% of my enemies will just walk randomly on the field because I can't come up with anything else, hopefully nobody will notice.


Ah, I share your pain. This is the biggest roadblock in coding I've hit so far in my project. Coding enemy ai takes forever, a lot of recompiling/testing is required to get it 100% right. Thank god there are emulators! I'll somehow need to simplify the ai system without limiting its features too much.


On topic:
I'm pretty confident I will finish my project, although it might take longer than those of other people. I might not have figured out any strategies to avoid those "large-project-delayers" since there are times when I don't feel like working on it and put it aside, but I keep coming back to it. Maybe because it used to be a childhood dream of mine to make an NES game, maybe because it's so diverse - if I don't want to code I can still work on graphics or music - or maybe because playing god is just too much fun. :)
Watching your world develop, eventually throwing your own creatures into it and seeing how they interact with what's around them - to me, that is one of the most rewarding things about programming a game.

Okay, since you've asked for it, I'll reveal some top secret PRO TIPS (not) that have been handed down in my family for several generations:
- make sure you enjoy your work and the project is relevant enough to you so you want to see it finished by all means
- don't allow your game to become TOO complex, there's only so much a man can do (similar to Gradualore's point 5, are you perhaps a remote relative?)
- close your web browser/irc/whatever if you need to concentrate; better: disconnect from the internet entirely ;)
- put on your favorite music while coding
- if you've got a laptop, change your location from time to time!
- while(not_creative) go_for_a_walk()
- don't forget to shower after your coding sprees, before you take on real-life duties again


Gradualore: By the way, I've been wanting to ask you for a while... Why Domenico Scarlatti as the soundtrack for Nomolos? I think that's great, his sonatas are among my favorite baroque pieces of music. Just asking, because out of all composers I find it surprising that someone would choose Scarlatti for his game soundtrack.

by on (#55650)
off-topic response to miau:
I've always loved baroque music and particularly harpsichord music. Scarlatti is incredibly catchy, and he wrote something that has been dubbed the "cat" fugue, so I thought he'd be a perfect choice for a platformer that stars a cat. He wrote dozens of pieces which would sound so awesome on the NES. Especially if mixed with some nice percussion sounds as well.

by on (#55651)
Well you're probably right about keeping a log. I tried to log down on Dragon Skill webpage the progess I made, but I failed at it miserably (no progess since 2008 - in fact I did some progress since, like converting from 8-bit to 16-bit coordinates and improving the object system, but not things that other people can notice).
So yeah keep a log is a good idea.

Maybe you're right about not working too much on the project. It definitely sounds better to dedicate about 1/3 of your free time to it always than dedicate all your free time to it for a month and nothing for 5 months (which is exactly what I do BTW).
The problem is that once you've forced yourself to stop thinking about the project, I just can't help myself but being obsessed by it. And then after a while I'll just leave it for a long time, etc... I've always been like that, and it'd be hard to change.

And miau you're right about the trick to go for a walk. In fact that may be one reason why I always make a lot of progress in summer, and very few progress in fall/winter/spring.
- I can do some walk/sport/whathever and get inspired
- I am in holidays and my friend is too so we can met and advance in the game
- The weather is nice so I can take all my stuff outside and work on it while being in the feel of nature (I know it's dumb but I just like that)

You're also right about deconnecting from internet too, it really helps. In fact I've hionically made quite some progess when my old computer crashed and when I lost the ability to use the net with it this summer. Now that I have a new laptop which is always connected it can be a problem. I think there is a swithc to mechanically turn the wi-fi off, so I should use it.

About complexity, it's good to decide right from the start what your game engine will do. I've done that, I've decided to go for Final Fantasy Adventure-style fast scrolling, and I stuck to it. I've decided the game would be 6 stages long, and stuck to it. However, I haven't decided details like the 16-bit coordinate thing, and how objects works, which made me go trough a few rewrites of codes, and delayed the project.

Now that I think about it I haven't been THAT unplanified. I've tried to planify my work a few times but always failed. However, I have written down the basics of the game engine in a txt file and I have a folder (real life folder, not on the PC) where I have all doccuments related to the project (mostly hand-drawn maps and enemies, and a few pseudo code, I rarely do that but I think I have one sheet or two with it).

If I can give another advice, which I have done COMPLETELY wrong for my current project but I'll do better for the others (if there is others) : It's not because you've done stage 1 that you're ready to do the whole game.
I still remember the day the stage 1 of my game popped in my head during class - and I was sure all the other elements of the game would pop in my head like that. In fact they didn't.
I coded all the engine and the stage 1 with very few ideas of what will follow. In fact I still don't know how the last stage will look and lack a few bosses and enemies.

by on (#55654)
Bregalad wrote:
In fact what I do is that when I'm annoyed on one project I switch to another, so that instead of having a completed game, I have one half-completed game

Same here, except sometimes it's people on forums who try to switch me from one project to another. But sometimes they're trying to switch me back to a project I had been working on before. I don't have enough time to give my full attention to every single project I've released over the years.

Gradualore wrote:
I choose reasonable constraints for a project that I start

I too follow Sivak's lead on this, which is why you see so many non-scrolling games.

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.

by on (#55658)
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. :wink:

I'm longwinded. End post.

by on (#55663)
I'd just like to go ahead and 2000% agree with Kasumi on documenting your own formats. Seriously. After a while, I honestly start to forget how things work. It's not because it doesn't make sense or it's sloppy, but it's because I simply can't juggle all that information in my head at one time. It's too much to think about.

Kasumi wrote:
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 think it's funny to read how much programmers do things similarly sometimes. I, too, have a rambling document followed by a formal document. I didn't adopt this same habit from learning from another programmer; I just decided it was a good thing to do.

I also try to talk with other people who aren't programmers to get new ideas, but mainly for not so technical purposes. I use them kind of like the average gamer to find out whether or not they like something, or notice something odd in one of my projects. And, don't worry, you're not alone in being satisfied when somebody asks you how your game is coming along! I'm actually pleased to see that the progress I've made is substantial enough for someone who isn't a programmer to say "Wow, you've done a lot of work on this". Usually you can pour hours and hours, possibly days and weeks, into a project and it appears as if you have nothing to show for it.

Kasumi wrote:
Really though, I think the bottom line is, "KEEP ORGANIZED!"


Jackpot! Ding ding ding ding ding ding ding

This, I agree, is probably the most important thing to remember in making a large project. If it becomes a mess, you usually become annoyed, and not motivated at all to work on your projects. Just keep code nice and clean, and develop a nice naming system for routines where you will never use the same name twice. I kind of use a tree-branch method where I use dot notation to name labels. So I'll have something like "Mode0.NMI.PPUUpdates.UpdateNewTileColumn" to name the routine that updates a column of tiles in the NMI routine of "Mode 0" in my game (I have separate "modes" in my project, which refer to being at the title screen, in gameplay, in a cutscene, etc.). This kind of system allows you to name your routines something very specific.

I've also made a couple non-scrolling games, and they're too simple in my opinion. Sivak's looks good for not scrolling; it really does. But I feel like it's necessary for my current project to be scrolling. It's only left and right, but I've made a couple 4-way (or a million ways, since you can scroll in two directions at once) scrolling engines. Of course, I'll be recoding it I'm sure the next time I want to use one.

by on (#55664)
Celius wrote:
I also try to talk with other people who aren't programmers to get new ideas, but mainly for not so technical purposes. I use them kind of like the average gamer to find out whether or not they like something, or notice something odd in one of my projects.

Indeed, I should do more of this.
Celius wrote:
Usually you can pour hours and hours, possibly days and weeks, into a project and it appears as if you have nothing to show for it.

Yep. I hate that about programming. I spent a long time doing nothing but getting my game to scroll, and everyone who's not a programmer says, "That's it?" It's not like a painting, where someone who doesn't paint can still appreciate it.

Celius wrote:
I kind of use a tree-branch method where I use dot notation to name labels. So I'll have something like "Mode0.NMI.PPUUpdates.UpdateNewTileColumn"

WOW! I love this. My current label naming "system" is totally awful. Thanks for this!

by on (#55668)
Interesting topic :)

Someone asked me recently (paraphrased): why, despite you hating trackers*, did you attempt to write one on the NES, of all platforms!?

It's not an easy question to answer. I certainly don't stand to gain from it financially and it's been an utter drain on my spare time. I guess I fancied the challenge because it's something that hadn't been done before. Of course, once the giddiness died down and the rose-tinted glasses were off, the plethora of good-reasons-nobody-has-done-it-before was sobering :)

I guess I'm lucky that (despite a few naysayers) I've been overwhelmed by support, help and ideas for the tracker. I'm sure without that I'd have probably given up. There are pretty excruciating times where I'm at the point of breaking and ones where something works *just right* or better than you expect that make you smile again and renew enthusiasm.

I'm certainly learning A LOT! I've never done anything like this before so I've had to learn quite a bit about areas of the NES that I've never touched.

As for organising, I too have a huge text file (well, several) that I just fill with ideas/bugs as I'm working. Then when I've finished the current task I go back to the list and find something else to do. I never delete the notes though as sometimes it's important to review what you've done previously to stop you redoing something you'd earlier discounted or coding the opposite of something you've already done. I know this from mistakes :)

And I agree 100% about documenting stuff. And commenting your code. There was a period recently that I just had to stop coding and write the manual (despite it now needing a big revision) because I just couldn't remember how a lot of stuff worked in the editor, especially stuff like tokens for commands, which bits did what in parameters. I've also had to rewrite some big chunks of the editor recently and I had to go back over code that I wrote during the beginning. It was all mostly un-commented and I had a hard timing figuring out why I'd done stuff. There are still sections like that but mostly I have enough notes/comments to still understand the trickier bits.

Actually, something I've started doing when embarking on a new bit of code is to write it out in english in comments first, breaking it in to logic flow. Then when it comes to coding, I put the code in between the comment lines. I find it helps visualise the code easier and also you have instantly commented sections.

Finishing is something I have nightmares about. I keep getting really close to a releasable version and then something else crops up. I'd gotten my bug list down to one item the other day (plus I relegated a few features to "Medium Term Goals"). Then I decided to rewrite the player code. Then I decided the Song Arranger needed proper copy and paste features. So my to-do-list just exploded again.

I know I have to finish this project and I'm utterly determined to get it released. I do worry that it's become somewhat of an obsession :)


* I don't and have never *hated* them, I just didn't get them until I started to do some research. SDI on the C64 was probably the catalyst.

by on (#56387)
I would just like to apologize ahead of time if all this seems obvious, but it is important to any project to understand the software development life cycle. http://en.wikipedia.org/wiki/Software_development_process

while this sounds like a no brainer, i have tried to approach a number of ambitious projects with the code first, patch till working method, and it never net decent results.

This sucks bad enough when working on a modern PC, but it gets even worse when working in a limited environment like the NES.

I like to be REAL anal about keeping track of how i plan to use the available RAM.

I also like to have a relationship between the locations of tiles. (EG, moving sprites have a set location for standing still, then have two animation frames for moving in each direction. for instance, '66' is standing, '76' and '86' is walking up, '46' and '56' is walking down, '67' and '68' is walking right, and '64' and '65' is walking left. ) You can make a define for the standing, then the rest are intuitive. if you map it out, you can arrange quite a few of these into a tileset if you stagger them, and you can use the tons of other tiles that have little relationship to one another in the gaps. this will save time wasted on looking at tile maps while programming, but requires preplanning.

the trick when you want to do the work, if you wait until you are programming to start planning, you need to work within the scope of your existing code. if you plan ahead, you can make programming a lot easier, but you need to know what you are doing long before you start doing it.

then again, the only project i ever actually completed was hangman, so take my advice with the weight of a grain of salt.

by on (#56613)
Hey guys,

Long time lurker here. I'm actually coming from the Atari 2600 dev community, but I can identify with a lot of what's been said. Keeping motivation is the hardest part of any project I think. Inevitably you'll have stretches where you do no work, and I think this is where many projects die because it's just too easy to say "I don't want to bother with it right now" when you've been away from it for a while.

What I do to overcome this is to tell myself "well just look at the code, you don't actually have to do any coding today. Just look it over and try to refamiliarize yourself with things." I think this is usually more effective in getting back in the game than telling myself "ok I have to sit down and start coding a solution for XY and Z". Laziness almost always wins when you set your expectations too high. :)

by on (#56615)
Keep a diary.

Do design work if you get burned out from code, so that at least you know what to do. In your design work, break things into individual steps that take no more than fifteen minutes, preferably five to ten.

Times will come where you just can't think of anything. Have a B project for those times.