Combatting Programmer A.D.D. in large projects.

General Discussions
#1

So, I have a lot to do in my current project. So much in fact, it’s hard to focus on any one thing. I find myself working in one area, and it leads me to work in another, and that spirals into working in another. Eventually I get to the point I can swing back around to what I was working on in the first place and wrap it up but not before I hopped around 40 other areas first.

Really, my work is fairly well organized, I keep track of everything I’m doing and everything that isn’t finished or needs work I have extensive notes on. But, it seems like it’s a natural process for me to work on 14 things at once that are all somewhat related. For example, right now I’m working on my inventory system, the NPCs, sprite animations and just today I finished a method to sort rendering orders so sprites don’t awkwardly “overlap” each other incorrectly.

So, do you guys get programmer A.D.D.? How do you combat it? Do you even bother or just let the programming flow? :wink:

#2

I just let it flow, I’ve been working on path finding, state machine and AI in my game… All while coding a level editor on the side. I posted a similar thread before and got mixed views.

I think it keeps the mind fresh.

#3

Well… ToDo lists and tasks’ priorization.

I write down all the features I can figure out. Then I sort the features in four categories:
MUST - the game is not going to work without this feature
SHOULD - this is needed, but not so time critical, can be implemented later
NICE - a feature that can be dropped if needed to but usually adds some coolness in the game
WON’T - dropped feature, may add it in the future

This kind of sorting is also know as Moscow method

My first goal is a “minimum viable product” and I’ll do it by completing all MUST tasks. Then I have a build I could release if I need to, but it’s usually very rough version
needing a lot of polish. So the next step is to do all SHOULD tasks and then NICE. All tasks can be usually divided to sub-tasks and “Moscowing” them too.

Btw it gives some satisfaction to cross out a task when completed. I mean literally, with a marker. :slight_smile:

I have this kind of overall ToDo list and then a daily list written on the white board.

#4

Thats a good system :wink:

Oddly enough my entire list is “MUST” stuff at the moment. So it’s really a matter of sorting everything by order of most complete to least, trying to knock out stuff thats almost complete first. Problem is, half the time I complete something I end up with 3 more things on my “MUST” list. Alternatively, another problem is I can’t complete something because I need to do something else first. :o

Needless to say, I can’t wait until my game is a game. It’s still a glorified walking simulator after 3 months of development. :smiley:

#5

Those things should go on NICE or SHOULD list because you should define and lock the MUST list at the beginning of the project. Just to prevent feature creep. :wink:
For the minimum viable product, cut off the things. The first version shouldn’t do everything you imagined.

Prioritize tasks, sort them and complete them one by one, starting from the top of the list. Do not skip a task until you have a somewhat working solution. Having something is always better than nothing. You can always come back and improve it later.

#6

You’re doing great. The only requirement on creating games is not giving up on coding them. As long as you are coding it, there isn’t really an issue on what. This is actually the best type of procrastination as your program always wins :slight_smile:

Even for simple things, I get caught up in feature creep. Those things can be erased later on and might end you in a better (or slightly worse) state than last time. This route usually gets me the most happy accidents, in where I got a feature or improvement I didn’t intend for but it works. Sometimes, I get a bug. However, all in all, the game is coming together. For me, that is the most important thing.

So yeah, let it flow… Keep surprising yourself. You never know what you may find. :o

#7

Eh, recently I’ve just learned to chill out about it. I just work on small games instead of working on huge projects that I have to keep up on constantly.

The big turn-off for me when it comes to making games is that I always get worried that I focus on assets more than gameplay/programming, and usually when I run into one of those periods I spend some time working on MERCury or some other engine projects I work on in secrecy. It slightly works out? :-\

It’s something that all of us game developers fight. My creative mind loves to troll me when I’m busy on specific projects.

Oh, you’re making a dungeon crawler? Time to make a space simulator!

^^
This is usually how it goes.

These moments usually come when I’m fixing bugs, and I really think the only real solution is just to never giving up on your projects.

  • Jev
#8

Heh, I guess that’s true. I guess what I mean is, if I complete one MUST thing that’s currently active it opens the door to do 3 others. It’s endless it seems. The closest thing to a SHOULD I’ve added so far is probably the blood splatter mechanics. But even that was more inching into a MUST thing because I planned to make my game a bit over-the-top in the violence department just for kicks. :wink:

Of course, my MUST list would be insanely long if I had one, I think thats the norm for “RPGs” though, because of all the complicated systems you need to add to make it even quality as such a game.

Maybe the problem with the MoSCoW system is my minimum standard is way too high so a lot of features are “MUST” features. :wink:

hahaha, I’m guilty of that too. I usually stay on track with no speed bumps. But even yesterday I was thinking “Man, a tower defense game would be fun to make on the side! I could even use SixtyGig’s graphics as a foundation!”. Although that idea really just sits around as an idea.

I plan to have some mini-games eventually, so I’m hoping those will help with those “lets do a side project” moments. For example, I was going to have arcade machines in the game world you could play that were minigames, like a ripoff of Pacman, Tetris, etc. You’d stick in a credit or two (Game currency is “creds”) and play. They wouldn’t serve much of a purpose, they’d just be gimmicks. But it could help me break away from coding the RPG a while if I need a break but still technically be working on it. :wink:

#9

Divide your work packages into smaller calculable tasks, finish them, commit, go on.
A chaotic unfocused approach is the ideal hatchery for bugs and introducing side effects.

#10

There is this old solution: http://en.wikipedia.org/wiki/Spiral_model

#11

I had that problem; its triggered by the fact that programming is and remains hard; you cannot focus on one thing at a time because sooner or later that one thing is going to depend on other things to exist before you can even test or run it. You can’t test legs without having a torso as it were.

There is but one true solution in my experience: proper code design. If you know the ecosystem up front (and it can be as simple as drawing up a simple high level diagram of all the different components), you can design placeholders/mock implementations so you CAN focus on one specific cog in the machine and still try it out, if necessary by giving it a spin by hand as it were.

#12

You may also want to consider trying some form of iterative development. In a large project theres always a huge number of things that MUST be finished, but maybe you can bunch a couple of these MUSTs together in an iteration. Ideally you want to have a working version after each iteration that has something cool (like colored hats or explosions) for you to look at, enjoy, and be proud of. At least that is what I try, but it depends a bit on the project whether that works well.