So... this is my lets see *counts on fingers... 9th big project. The first 5 were flops, then next 2 were 3/4th done, and the final 2 are pretty good. The one I am working on now is pretty... massive. Actually, it isn't a game. It is a project for AI. But since it very heavily borrows from game AI, I usually come here for most of my advice/help that I need. How do you guys deal with projects that are so massive that you start coding, and find yourself kind of lost. I mean, this is the 2nd project(1st being chess engine) where I have a good architecture, but it seems that I always have new ideas, and somehow, the elegance is deteriorating. How do you guys plan your projects so that you get to the end? Are there any tools I should use to plan? Should I be using UML? It seems that there is so much to do, and me being the only one to do it makes it difficult to look up. Thanks for any advice.

Quote:Original post by Sagar_Indurkhya
How do you guys plan your projects so that you get to the end?

Follow your plan. Only allow changes to the plan that don't delay its completion. Keep in mind that you can always go back and make changes after the project is completed.

Programmer: "I've got this great idea for a feature in our game."
Project Lead: "That's a fantastic idea. We'll put that feature in version 2."

Quote:How do you guys deal with projects that are so massive that you start coding, and find yourself kind of lost.

Don't code without a vague idea of a design, or you won't be happy. Develop a nose for code smell. Listen to the nagging voice that laments the loss of elegance, because what is a small, nagging voice eventually blooms into full-fledged code rot.

Look at your failed projects. Why did they fail? What would have done differently?

"Massive" means different things to different people. To me, it means over 50,000 lines of actual source code.

Quote:How do you guys deal with projects that are so massive that you start coding, and find yourself kind of lost.

For the loan developer, one suggestion is to not start crazy-big projects in the first place.

Say you want to write a big game. You could break it down into steps that are each in their own, interesting. If you give up on the final project, you've at least got several working games done. The trick here is to stick to the current step and design and plan and not get ahead of yourself.

Here are some example mini-steps for making an MMORPG through several projects, with the finished, playable games in brackets):

- Make a simple, ugly, top-down tile-based engine.
- Make a nice puzzle game that uses that engine (ugly puzzle game)
- Convert your ugly tile engine into a nice isometric engine (pretty puzzle game).
- Change the puzzle game to an RPG-type game (pretty RPG game)
- Give the isometric engine a free-camera and "wow" graphics (stunning RPG game)
- Move the game logic server side and allow people to log in (small co-op play RPG)
- Make the world perpetual and make players independent rather than a team (real online RPG)
- Add crazy database stuff and networking (a real MMORPG).

Note that at every stage (except the first), you have a fully working game you can be proud of. It just takes a little creativity when you make your plan. Then you just need to follow it (ie: no point in adding crazy network features for your puzzle game).

The same idea can work in other genres too.

Quote:Original post by MaulingMonkey
I'll agree with the follow your plan comment, and raise you a design for reuse. I tend to spend more time working on my code library than I do my "actual project", creating reusable classes. That way, even if I get disinterested with a project, it's not a (total) waste of my time.

I agree. I never wrote a very big program, but on my current one, a raytracer in the spare time, I designed every single class to be as extendable as possible: this way, when new features come to mind I should be able to add them without changing too much the design. Well, I know that this way I lost some performances, but I was able to add coloured shadows and anti-aliasing in no time.

I would say: design the project as separate apis. Design the apis as extendible as possible. Add every feature you want as long as they don't change too much the original design.
Otherwise, spend some days to find a way to implement them in a coherent way that will lead to a good design as well.