oh good, more paperwork to do... seriously though, that''s a good list RandomTask, thanks!

I''m new, what a joy, hi.

I guess the level of effort put into the whole design stuff varies on what you''re doing, a mod, or a whole new game.

If it''s the last, there''s a lot of work to do. I went through the whole mess hmmm 3 years ago. Setting up and mantaining a web based team can be a fulltime job :/
The project died after a year, mainly because the better of us got hired. Secondly, it was becoming clear that the licensed engine we had picked was becoming outdated and unable to handle what we wanted. Although our main coder totally rocked and we even got the source code of the engine it was all BS.

My 0.02 cents:
1. Write everything down, what needs to be coded, modeled, simply EVERYTHING.
2. Make the docs available to the whole team, if they''re not informed and have the feel that the heads know where they''re heading they''ll start to worry and fade off. Implement new discussed ideas etc asap.
2. When recruiting people, try to make a competent appareance, instead of just ''telling'' them what''s fun to play, send them a doc file, that should show organization.
3. I wouldn''t necessarily agree to let everyone do his own monsters and stuff. I''d let them do what their skills level allows, and make they understand it.
4. THe golden rule is to keep everyone motivated all the time, without that, everything else is obsolete.
5. Coders might want a list of engine specs, limitations, rough to-do list etc.
6. After getting someone into the team give him a job ASAP and look to keep everyone always busy.


-I''ve uploaded some stuff that might help (guess i''m bored :/ )
The documents i had transfered to html by the time i left, that was also what was available to everyone on the team, i think we had a lighter version with all the info newcomers would want, mainly with the upper links about design stuff, game type, engine info, some screens and the like.
http://www.planetquake.com/strangefate/docs

Other design text files, the names should tell what they are more or less. We were mainly aiming to complete a publisher''s demo so some docs are limited to that:
http://www.planetquake.com/strangefate/docs/docs/Character Design.txt
http://www.planetquake.com/strangefate/docs/docs/CodersProjects.txt
http://www.planetquake.com/strangefate/docs/docs/Impact Doc.txt
http://www.planetquake.com/strangefate/docs/docs/levels.txt
http://www.planetquake.com/strangefate/docs/docs/Models list.txt
http://www.planetquake.com/strangefate/docs/docs/powerups.txt
http://www.planetquake.com/strangefate/docs/docs/weapons.txt

This is really cool, it''s off the gathering of developers about everything design docs should contain.
http://www.planetquake.com/strangefate/docs/docs/Std design Doc.txt

guess some links will appear broken due the spaces in the filenames.
It was a huge effort to keep all the docs going but the whole structure and stuff really paid out on all ends (as long it lasted).

The more stuff of that kind you can show to someone, the more he''ll see organization and the easier he''ll join.


Mario

Design Documents are definately important. Otherwise, the programmer has to figure out what you want, and try to implement it all him/her self. As a programmer, I am in this situation at the moment, but, since I am also on the design team, this is pretty much Ok. I simply make the engine as generic as possible (this has also been one of the design goals from the start). Then, any cool idea that pops into someone''s head is fairly easy to implement. This is very clsoe to my ideal work environment. If I had a couple of Design docs, i''d be in programmer''s heaven =).

Z.

I think the Techinical Specification should be isolated from the Design Document. Also, my personal opinion is that a programmer should have a large say over the complete design. All to many times have i seen people trying to suggest features that are impractical from a programming point of view.

When I design stuff (it''s not very often), here is the stuff I include a rough pseudo-code version of the entire game. This is everything, including menus, in-game logic, basic AI, input details etc etc. It generally doesn''t take too long to do, and doesn''t need to go too deep into details (things such as "render model X" suffice).

Nurgle

After careful deliberation, I have come to the conclusion that Nazrix is not cool. I am sorry for any inconvienience my previous mistake may have caused. We now return you to the original programming

Isolating the technical side from the creative side makes some sense, but I think there should be some correlation (hyperlinks? corresponding chapter order?) that maps one part to the other, so designers can easily check on the technical details and programmers can see the intended concept. This will become more important when something cannot be done exactly as envisioned, or something new is to be added. By being able to easily see what ''the other side'' is capable of or requires, such allowances can hopefully be provisioned for.

quote: Original post by sunandshadow
- Let the artists design their own characters and monsters and whatever else they're drawing. If they see themselves as just technicians whose job is to turn your crappy sketches into presentable graphics, they will not be happy. But don't give them a completely open field - suggest some elements and guidelines. The goal is to get them to feel that they are being given an "opportunity to show off".

I don't agree with this, by the way. If artists design their own work, then where do you draw the line? Do you let sound people record whatever sound effects they like? Do you let your musicians bring drum'n'bass into your medieval fantasy game? Do you let the programmers program something entirely different to the game you envisioned? This just sounds like a bad idea.

Instead, I'd say: all people on the team have to work from the specified design. That's not as limiting as it sounds, because there is usually room for personal expression within any constraints, and there will nearly always be someone willing to work with whatever your subject matter is anyway. However, tell your whole team that they can be part of the ongoing design process, and get to put their suggestions forward for consideration by the rest of the team. The difference is that any deviations have to be accepted by your team in general, rather than letting people make whatever they like and then give you a headache trying to make it all fit.

Edited by - Kylotan on November 10, 2001 6:19:37 PM

Actually I am letting my composer compose what I want, within limits, but I made sure his style fit the game''s before I recruited him.

It''s the ''within limits'' that are important, so you''ll be fine. They could be strict or they could be lenient, depending on your circumstances, but you were implying that it would be a case of letting everyone do whatever they like, which is just not gonna work.