Flux_Capacitor
Augur
- Joined
- Dec 29, 2006
- Messages
- 372
A design document really isn't meant to the end all, be all of the project. Things inevitably change over the course of the project. Its just a common place where people can go if they have questions. If you believe it should be followed blindly, well thats just foolish.Naked Ninja said:75 page design document? Lol. There are two main types of development. The older method, where you plan out everything in advance and then carefully follow this huge pile of documentation, often called the waterfall method (one step completes and leads into the other in a flowing, linear "step" concept) and rapid or iterative development, where you work out some basics, build them, then iterate and flesh them out as you go along in ever tightening spirals.
Besides, the actual document was really only part of the reason why I asked. I was also interested in:
- Level of commitment - besides a couple models and forum posts, what indication do I really have that he's willing to see this project through? His word? I don't mean to be a pessimist, but I've seen to many projects crash and burn because of this.
- Getting up to speed - I don't know about you, but having an amorphous mass of emails thrown in my direction isn't really going to help me out a whole lot. I haven't seen these emails (I doubt you have, either), so I have absolutely no idea what format they're in, what information is included or not, etc. Having a well-written, well-formatted document will greatly increase the efficiency here. Also, what happens if other people are brought on to the project? Are you really willing to go through the effort of trying to explain all your emails, and filling in all the gaps, every single time?
- Writing ability - I understand that English isn't his native language (although his skills are certainly acceptable). However, if he's going to be doing a significant amount of writing on the project, I'd like to see an example of how he handles such a large piece of work. Anyone can be eloquent for a page or two, but after 30-40, a lot of people start breaking down.
So, you're saying you're the perfect programmer, and haven't ever spent hours and hours on a flawed implementation? Well, my hat's off to you, I suppose. That's certainly impressive.Naked Ninja said:The second method is becoming much more popular because it is easier to get a working prototype up, see what works and what doesn't, discard the crap and change details before you spend hours and hours on a flawed design.
I know that method can work. However, when your team is spread across the globe, its useful to have a single document anyone can go to if they need it. Otherwise, people may be wasting time, waiting for their teammates to get out of bed, or check their emails, or come back from vacation, so they can get their questions answered. Of course, if you're working alone, this isn't a problem.
Well, I could use another programmer on my project. Tell, you what. You can work for me, for free, for about two years, maybe more. I may bail after a year, or perhaps after the project is done. Until that time, though, you'd damn well better do what I tell you to do.Naked Ninja said:Honestly, I can't blame the guy. Personally, this looks like a terrible deal.
Actually, it is a fantastic deal. A dedicated, skilled artist working for free on a project is an incredible boon. Do you have any idea how much a contractual artist charges per item for custom work? Few indies could afford more than a handful of pieces, nevermind the amount of items an RPG requires.
I hate to be cynical, but really, two years (I'm estimating here) is a long time to do something like that. This is only for the first project. *Then* I get to put in a significant amount of control over the project. How do I know you're going to stick around once your project is finished? People want to see a return of investment. People burn out. Working that much for that long on the same thing takes a lot out of people. Its just a very difficult deal to see through to its full completion.