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 :

quote:

---

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.

---

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).]

The former, I'd assume.

You need a step 3.5 before you start the "Sid" iterations. That is the actual coding of the modules in accordance with the finalized design AND the integration of all the DEBUGGED modules.

I think the deadlines are realistic.

H: Yeah, I may lag on Step 1 a little also, but we need the solid goals to keep us moving .

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 think, first, we need a 'spash screen' for the loading phase.

Second, we need a 'Game selection interface screen' background.

you sure that a splash screen should be important right now? I ask because I think a splash screen should have the same general style as e.g. the interface gfx, which in turn are largely determined by what is recognizable and feasable. So I'm afraid any splash screen done now would be done 100% differently lateron

As for the 'Game selection interface screen' background: For this - as for all other gfx jobs - I need a bit more than the general idea, i.e.:

- what exactly is to be done?
- how large can / must the area be?

The best thing would be if programmers who are in need of some gfx draw a crude sketch of what they would like to see - just the outlines and the different text / icon / button / info areas. The crude layout of all graphical game elements is mainly determined by their function - not before the programmer in charge has stated exactly what the gfx is to show, I (or any other graphics guy - erm... where ARE they???) can start working on it.

The graphics format of the map tiles:
I understand you mean the data format, not the actual size, right? But only you (and the other coders) can give the answer. My answer is clear:

16.7 M color TIF graphics (i.e. 24 bit bitmaps in memory).

Should that be too much for a decent speed, I'd settle with 65 k colors (16 bit bitmaps) and, if even that's too much, with 256-color gfx. Only thing I strongly recommend is to use a viewport of at least 65 k colors, so each tile / unit / icon / whatever gan bring its own palette with it.

I've found an API that looks like it will work for 24-bit tiffs. I have started the new thread "Please, please could someone check to see if this API will handle TIFFs OK in Java?" requesting help in determining once and for all if we can do this, and if so how it times out.

• Was just thinking a splash screen would be the first thing they'd see, and would set the tone for the whole game. Perhaps it is too early. Ya'll tell me, because I've never been down this road before!


• The Game Selection Interface Screen would likely have 3 or 4 choices/buttons/tabs on it -- 'Load Game', 'New Game', 'Build Game' for sure, and maybe one other ('OnLine Game'?). What should that look like? How should we lay it out?


• First, can I assume we're going to build the map out of 'tiles'? And I assume there will be 'Layers'? If so, how many types of tiles will there be? How many singular terrain types? How many combos? How will the combos work, layered or specially drawn? Shoreline tiles? Etc? I think we'll need this info to build map Image objects, and to create code to draw it to the screen very early in the process.

One source for our map layering discussions is at ../../Forum21/HTML/000058.html . I think there is some discussion elsewhere, but since the search for the forums seems to be broken I can't find it the easy way .

We seem to be falling a bit off our planned schedule . I am one of the transgressors. I had an outbreak of work-related activity and a bit of 'designer's block' on the Econ system.

However, I'm really feeling like getting an alpha version out asap. Also, I think that although we are lacking in many details, things as far as they're sketched out seem to fit together reasonably well. So I propose we stick to the original process and dates, and just have things in some areas a little less fleshed out if necessary.

Dukes, could you report in as to where you are? What I need most out of those in charge of game models is the 'simple' version of their area that we will try and code into the first alpha. Try and keep this to the Minimum size that can still give a small flavor of your part of the model. We will build up from the simple models in the succeeding alpha versions. When the simplified versions are posted I will convert them into a crude coding specification so that we can get going on the code itself.

Thanks,

I guess we need to discuss it a bit, but my intention had been to stick with an ancient-world-only alpha-1 just to keep things simple. A lot of the economic and military stuff will be much more complicated as we get into the modern world. I was hoping to avoid that aspect for now. What does everyone think? Any strenuous objections?

All of our coders except me are not going to be available at least for the next few weeks. So my preference would be just to implement what we have in terms of the simple models into my old version of Clash and document the heck out of them. That way we will have something that works after a fashion fairly soon even though I may be the only one actually coding. This would also have the advantage of letting the dukes play with their primitive models very early looking for fundamental problems.

Keep up the good work

[Lighting up my Hannibal Smith cigar]
I love it when a plan comes together.

Sometimes I'm afraid I've been pushing too hard for OO. But do realize, a year and a half ago, when I first came aboard, I ended up leaving for a while because my attempts to push OO were completely rejected. In discussing the tech model, I pointed out all the problems that are now coming up, proposed a solution and offered to code up that solution.

Now a lot of time has been wasted, and nothing has been produced (except that one model I insisted on using OO design on -- the govt model).

I am certain that a failure to adapt this project to modern OO coding and methodology will mean the death of it. I do not want that to happen.

---
I think that it could have been a mistake to concentrate on the military in the first demos. IMO the military cannot reasonably be modeled without doing other stuff first. The game world and code architecture won't be able to support it. My view is that the demo progression should go something like this:

1) Map Generation and Ecology Modeling to define the game world. This will be more of a test case then a playable demo.

2) Add farming, hunting, and the population model. Assume a primitive hunter/gatherer or agrarian civ with no real economy or advancement. Player controls all activity and the player's people are the only people.

3) Add basic economic activity and infrastructure. Now we are assuming early settled civilization. Again, player controls everything.

4) Add basic government, social, and riots models. This allows us to model an early kingdom with proper player interaction. This kingdom is still the only one on the globe.

5) Add basic military actions and diplomacy. This allows modeling of the interactions of multiple nations. At this point, the player/tester controls all civs.

6) Add multiplayer support. Start by turning the #5 interface into a true hotseat game, and then go to other communication types. I think it will be easier to get this done and debugged while the game world is still simple.

7) (Concurrently with 6) Develop the AI. We should develop and test it while the game is still simple. Once we know it is competent, we can tech it how to deal with the additional complexity.

8-?) Add technology growth in small increments. Each time technology allows something new, the other models are concurrently updated and refined. In this way, we slowly build up to the complexity of the modern world.

I think this would be the best way of building up the gameworld. We would be starting with the basic stuff and then adding things that rely on the earlier models. If we made sure that we had a good foundation for the later stuff, it would be easier to add.

I'm not suggesting that we scrap the existing work. I'm just saying that it might be good to put some of it aside until the basics are covered. I think that adding the ecology model after the economy infrastructure is in place would be much harder than doing the reverse. The game world should be built from the bottom up. If the task force and military model codes are the basis of the world, we will have a skewed modeling IMO. It may not be exciting to do the ecology first and watch the world develop, but I think it would make a better game foundation.

Obviously we can't go back to step 1 and follow the timeline I listed. We already have some of the models from later steps coded. But I do think we should develop an ecology only test case after we do demo 5. Then we should add step 2 while developing the final, scalable game architecture. After that, we can start transferring existing code to the new architecture in a logical pattern. This should go quickly because the code will already exist and the models would have already been tested. We just modify it so it fits the new architecture. At the end of this process, we should have a good architecture with all of the working models.