Tweet
Here's a crude first step at a timeline for the Clash project.
We need some solid targets to aim for to make sure we are doing the minimum possible of "spinning our wheels". I realize there are some problems in finding a good process for a part-time distributed project like Clash. Also, we are trying to use everone's available time as much as possible. For this reason, IMO, things need to run a bit more "in parallel" than your standard business type project. I've put out a rough suggestion of how I think our process should work in the near future. Please suggest modifications of any parts you feel need it, and then we'll follow the final process we agree upon. I haven't been in a large design/coding project like this professionally. I'm sure I've left several things out. Some of the things I say may be boneheaded or impractical. Just let me know which these are, and propose your modifications. We must, however, have a process at least for the Near future agreed upon basically Now
.
I use words like 'final' in here at some points. Final of course will mean final in the plan. But if the feature as we've designed it Doesn't Work well for the player, then we'll have to reconsider. I also am a big fan of the 'Sid' design philosophy of getting the game 'playable' ASAP to avoid Big mistakes, like game elements that just plain suck
. This contradicts standard Software design dogma as I understand it. I put in a strong vote for this particular 'Sid' philosophy, what do other think? Another bit of complexity, is that doing it the Sid way means trying to implement some things sooner, to encapsulate the 'big' picture, which may take some additional planning and handshaking.
Some other useful thoughts come from F_Smith that I think are very appropriate :
Even though there are names on the Duke (coordinators) list, lets not get separated into chimneys. I'm with 'F' that things can be done by flexible teams in many cases, and that we shouldn't get overly hung up on who's 'officially' doing what.
So the question is, when is the most productive time to have the first meeting 'F' descrbes? Look at the proposal below, and see where you think it best fits. (ICQ would be great. Those of you who don't have it you can get it free at icq.com)
Near-term targets:
STEP 1:
Agreement on high-level mechanics / specs for each game element: Main Interface, Map, Unit, and other Artwork, Military, Economy, Government, Technology, Culture, Customization, AI.
I propose we do this by 6/5/99. That means all Dukes (coordinators) must have high-level proposals done by 5/30/99. [Added Later: As manu suggests these should discuss the interface between the models and the player, and in a more genral way, how the player will interact with the game. So every model designer should provide ideas for the interface between his model and the player with his model for the first step.] Criticism of these proposals should be open to everyone, but if you want to change something radically you must present a solid counter-proposal.
We are short on Dukes. If anyone sees an area they want to take charge of in the thread "Duke (coordinator in charge) and Goals List" let me know. I will do all I can to handle any left-over areas.
Please start looking Now at the major game models that are posted if you haven't already. Criticism will be much more likely to be reflected in the final design if it gets in Before 5/30/99.
Question... Is this timing ok? If we don't push, we run the risk of just talking until the project implodes as Druid2 says...
STEP 2:
Once we have the high-level mechanics / specs document we can take the first real look at the specific interfaces for different game elements, and the coding design spec. Handshaking between the major "functional" groups needs to take place here. In parallel, the Dukes in charge of Military... models will need to, with their teams, put specifics on all the generalities previously in their models. Some of the simpler models may be ready fairly soon and could move on to Step 3 ahead of the general schedule.
[Added 6/20/99: I'm adding one more request for the end of Step 2. I propose that Dukes should try to figure out the shape of a barest first implementation for their area to go into our first alpha version. The things we should strive for are a relatively simple sub-section of each area, possibly without any interconnections to the other game models for those areas where its possible. For example, in the economics area we might do only a basic system with no specials, no merchants, and with the only player control being the overall tax rate. The only things one could buy/build would be development of sites, and production of weapons.]
I propose we finish STEP 2 by 6/30/99. Some parts will be finished before this. Those things that get to the right level of specificity before the deadline will move into early STEP 3 Activity.
STEP 3
Each game model (Military...) is basically done at this point, barring further revisions. One thing the 'game model' designers could do at this point is to help with strategies for the AI to use in their part of the game. Artwork should be getting into full production mode. Interface design for all the game areas should be finalized early in Step 3. Design for Coding at Modules and interfaces between modules level should be completed early in Step 3. [edited 6/10 by me because previous statement made no sense] AI for the specific game models can be planned out here too. Handshaking beteen game design, art design, and both interface and 'guts' coding team needs to be strong here too. For each area, when Step 3 is done the respective teams / sub-teams can go on to Step 4. By the end of Step 3 we will have covered the contents of a solid design doc, and will finalize the doc.
I propose we finish STEP 3 by 7/30/99.
STEP 4
When the early part of step 3 is done IMO we enter a series of loops if we're doing the 'Sid' philosophy mentioned above. When a significant amount of new coding and/or artwork has been done, the package is assembled and we see what its like. Team members at this point give each pre-alpha version a good running through. People not involved in coding or art will be especially valuable for this.
I propose we do a cycle of STEP 4 every month or so... [Added Later: As pointed out by Druid2 finishing the first run thru in a month is unrealistic. The first pass thru will probably be more like 2-3 months. See my next post below.]
I haven't even covered documentation and numerous other things... but I will close it here for now and throw the topic open for discussion. It must, however, be Quick discussion at least on the earlier steps...
BTW I am guessing a reasonable target for a beta for distribution beyond the team will be in 1/2000.
-Mark
[This message has been edited by Mark_Everson (edited June 10, 1999).]
[This message has been edited by Mark_Everson (edited June 20, 1999).]
We need some solid targets to aim for to make sure we are doing the minimum possible of "spinning our wheels". I realize there are some problems in finding a good process for a part-time distributed project like Clash. Also, we are trying to use everone's available time as much as possible. For this reason, IMO, things need to run a bit more "in parallel" than your standard business type project. I've put out a rough suggestion of how I think our process should work in the near future. Please suggest modifications of any parts you feel need it, and then we'll follow the final process we agree upon. I haven't been in a large design/coding project like this professionally. I'm sure I've left several things out. Some of the things I say may be boneheaded or impractical. Just let me know which these are, and propose your modifications. We must, however, have a process at least for the Near future agreed upon basically Now
. I use words like 'final' in here at some points. Final of course will mean final in the plan. But if the feature as we've designed it Doesn't Work well for the player, then we'll have to reconsider. I also am a big fan of the 'Sid' design philosophy of getting the game 'playable' ASAP to avoid Big mistakes, like game elements that just plain suck
. This contradicts standard Software design dogma as I understand it. I put in a strong vote for this particular 'Sid' philosophy, what do other think? Another bit of complexity, is that doing it the Sid way means trying to implement some things sooner, to encapsulate the 'big' picture, which may take some additional planning and handshaking.Some other useful thoughts come from F_Smith that I think are very appropriate :
1) In general I've found a 'team/task force' approach far more effective for writing large code projects.
A team of 3-5 people is far more productive than 3-5 individuals. And far more creative, and just about everything else you can measure. Perhaps it might be best to assemble a 'rules' team, a 'programming' team, and a 'grafix' team, and so on, and have them approach the tasks in their area of responsibility as they feel best fits their skills? If they prefer to work individually on some things and collectively on others, so be it, but leave that up to them?
2) The most imporant bit of business if this project is ever to be completed is an 'Architecture' meeting A.S.A.P.
Any project bigger than 3 people *must* be preceeded with a serious meeting between the 'functionality generating' folks (graphics, rules, etc) and the 'functionality implementing' folks (coders).
The coders must be appraised of a good vision of what the end product will be like -- in detail -- so that they can hammer out a good architecture plan for the final product that they all then choose to stick to. The details are not half as important as the coordination between the programmers. They must be thinking on the same page, period, so that no time is wasted on recoding simple pieces to match.
This plan will not be cast in stone, and will certainly evolve, but a project can truly be cut in half by getting it 90% right up front. Even minor architecture changes late in the game can require many, many hours of B.S. work going thru files you've already thought you'd finished.
We really must consider an online 'meeting' via ICQ or some such as soon as is feasible.
A team of 3-5 people is far more productive than 3-5 individuals. And far more creative, and just about everything else you can measure. Perhaps it might be best to assemble a 'rules' team, a 'programming' team, and a 'grafix' team, and so on, and have them approach the tasks in their area of responsibility as they feel best fits their skills? If they prefer to work individually on some things and collectively on others, so be it, but leave that up to them?
2) The most imporant bit of business if this project is ever to be completed is an 'Architecture' meeting A.S.A.P.
Any project bigger than 3 people *must* be preceeded with a serious meeting between the 'functionality generating' folks (graphics, rules, etc) and the 'functionality implementing' folks (coders).
The coders must be appraised of a good vision of what the end product will be like -- in detail -- so that they can hammer out a good architecture plan for the final product that they all then choose to stick to. The details are not half as important as the coordination between the programmers. They must be thinking on the same page, period, so that no time is wasted on recoding simple pieces to match.
This plan will not be cast in stone, and will certainly evolve, but a project can truly be cut in half by getting it 90% right up front. Even minor architecture changes late in the game can require many, many hours of B.S. work going thru files you've already thought you'd finished.
We really must consider an online 'meeting' via ICQ or some such as soon as is feasible.
So the question is, when is the most productive time to have the first meeting 'F' descrbes? Look at the proposal below, and see where you think it best fits. (ICQ would be great. Those of you who don't have it you can get it free at icq.com)
Near-term targets:
STEP 1:
Agreement on high-level mechanics / specs for each game element: Main Interface, Map, Unit, and other Artwork, Military, Economy, Government, Technology, Culture, Customization, AI.
I propose we do this by 6/5/99. That means all Dukes (coordinators) must have high-level proposals done by 5/30/99. [Added Later: As manu suggests these should discuss the interface between the models and the player, and in a more genral way, how the player will interact with the game. So every model designer should provide ideas for the interface between his model and the player with his model for the first step.] Criticism of these proposals should be open to everyone, but if you want to change something radically you must present a solid counter-proposal.
We are short on Dukes. If anyone sees an area they want to take charge of in the thread "Duke (coordinator in charge) and Goals List" let me know. I will do all I can to handle any left-over areas.
Please start looking Now at the major game models that are posted if you haven't already. Criticism will be much more likely to be reflected in the final design if it gets in Before 5/30/99.
Question... Is this timing ok? If we don't push, we run the risk of just talking until the project implodes as Druid2 says...
STEP 2:
Once we have the high-level mechanics / specs document we can take the first real look at the specific interfaces for different game elements, and the coding design spec. Handshaking between the major "functional" groups needs to take place here. In parallel, the Dukes in charge of Military... models will need to, with their teams, put specifics on all the generalities previously in their models. Some of the simpler models may be ready fairly soon and could move on to Step 3 ahead of the general schedule.
[Added 6/20/99: I'm adding one more request for the end of Step 2. I propose that Dukes should try to figure out the shape of a barest first implementation for their area to go into our first alpha version. The things we should strive for are a relatively simple sub-section of each area, possibly without any interconnections to the other game models for those areas where its possible. For example, in the economics area we might do only a basic system with no specials, no merchants, and with the only player control being the overall tax rate. The only things one could buy/build would be development of sites, and production of weapons.]
I propose we finish STEP 2 by 6/30/99. Some parts will be finished before this. Those things that get to the right level of specificity before the deadline will move into early STEP 3 Activity.
STEP 3
Each game model (Military...) is basically done at this point, barring further revisions. One thing the 'game model' designers could do at this point is to help with strategies for the AI to use in their part of the game. Artwork should be getting into full production mode. Interface design for all the game areas should be finalized early in Step 3. Design for Coding at Modules and interfaces between modules level should be completed early in Step 3. [edited 6/10 by me because previous statement made no sense] AI for the specific game models can be planned out here too. Handshaking beteen game design, art design, and both interface and 'guts' coding team needs to be strong here too. For each area, when Step 3 is done the respective teams / sub-teams can go on to Step 4. By the end of Step 3 we will have covered the contents of a solid design doc, and will finalize the doc.
I propose we finish STEP 3 by 7/30/99.
STEP 4
When the early part of step 3 is done IMO we enter a series of loops if we're doing the 'Sid' philosophy mentioned above. When a significant amount of new coding and/or artwork has been done, the package is assembled and we see what its like. Team members at this point give each pre-alpha version a good running through. People not involved in coding or art will be especially valuable for this.
I propose we do a cycle of STEP 4 every month or so... [Added Later: As pointed out by Druid2 finishing the first run thru in a month is unrealistic. The first pass thru will probably be more like 2-3 months. See my next post below.]
I haven't even covered documentation and numerous other things... but I will close it here for now and throw the topic open for discussion. It must, however, be Quick discussion at least on the earlier steps...
BTW I am guessing a reasonable target for a beta for distribution beyond the team will be in 1/2000.
-Mark
[This message has been edited by Mark_Everson (edited June 10, 1999).]
[This message has been edited by Mark_Everson (edited June 20, 1999).]
Comment