26-05-1999 00:35									#1
	* Proposed Process for Clash Project - Team Members, Please Read / Comment * Put an end to popups!

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 :

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

[This message has been edited by Mark_Everson (edited June 20, 1999).]

	26-05-1999 01:21									#2
	Got spare money?

Does Step 3: "Game model is basically done." Mean that the design work for the model is done? or that the programming for the pre-alpha stage is done?

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.

Accomplishing all of step 3.5 in just one month, considering the virtual-team will be ambitious. You'll need to have a *single* module integrator, to put it together and then your team of developers will pound on the integrated thing for a while. Then report the integration bugs and module level bugs. At that point, I think you've got alpha-1 for the first round of "sid"loops.

	26-05-1999 01:38									#3
	Support Apolyton buy from Amazon

You're right, Step 3: "Game model is basically done." is just the design work for the model.

"Step 3.5" Yeah, the First step is a Big one on Step 4. You're right that the first loop will probably take significantly longer than the subsequent 1-month ones. Perhaps 2-3 months. But I do literally mean that all the functionality isn't there at the end of the first loop. As I interpret the 'Sid' philosophy there should be just enough to do a few fun things and check them out. You get a chance to see if it feels Fun. I used this approach in my coding on Clash so far, and was very pleased with the way it worked. That's another coding issue we need to address: how much of my 'Legacy' code can we use?

	26-05-1999 02:43									#4
	Tired of ads?

Bump

	26-05-1999 07:32									#5
	Full PM-box? Change here!

Come on everyone, let me know what you think of the outline and timing. Silence Implies Consent

-Mark

	26-05-1999 12:35									#6
	Support Apolyton, buy Call to Power 2

OK, I agree with these timelines although I'm not sure I will be able to fit in them...
Mark, IMO u forgot an important point : there are the models, some are pretty ready (or will be for the 5/30/99), but I'm not sure we have enough discussed the interface between the models and the player, and in a more genral way, how the player will interact with the game.
My suggestion is every model designer should provide ideas for the interface between his model and the player with his model for the first step.

	26-05-1999 23:52									#7
	Support Apolyton, buy GURPS/ Alpha Centauri

Step 2:
We have a few programmers. When we have the system outlines, I think we need to produce a program system plan about the whole project in outlines. After we can read all the plans and later we can finish with a system plan which is the best or contain the best parts and ideas of the system plans.
STEP 3:
Mark, I know to write the AI system is 100 or 1000 times more difficult than to write the file reader and writer part of the game. So I think we never can be exact syncron each other. Somebody, who is a kind of leader and can write little glue programs between the functions (classes) are very important for the succes of the project. This guy can produce a working alpha version even if some parts are missing, so we can check the system without waiting 2 - 3 weeks or more to get the classes from somebody who late.

I think the deadlines are realistic.

Blade Runner

	28-05-1999 02:41									#8
	Inflate your Upload Space

Personally I can´t promise I´ll finish Step 1 on time in both of the categories I´m working on, but as the timeline for Step 2 is pretty roomy I´m confidant that I can keep up even if I´ll be a bit behind schedule (a week at the most) for Step 1. I have no comments on Steps 3 and 4 as I have no knowledge of programming, thus no idea how long it takes.

	28-05-1999 02:56									#9
	Support Apolyton, buy GURPS/ Alpha Centauri

Thanks for all of your responses.

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

-Mark

	21-06-1999 05:05									#10
	Suffering from ads?

Hi All:

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.

-Mark

	21-06-1999 05:25									#11
	Support Apolyton, buy Civilization III: Complete

We should begin to implement some "serious" graphics early - mainly to make a good impression on people seeing the project for the first time.

So, all programmers, just tell what graphics you need - and I sincerely hope we find some ambitioned graphics artists soon (no way for me doing all that on my own, sorry).

	21-06-1999 08:21									#12
	Remove this text

I'll take a stab at that:

I think, first, we need a 'spash screen' for the loading phase.

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

Third, we need to decide on a graphix format for map tiles. This is crucial, and a brain-breaker, to me. Help!!!

	23-06-1999 03:51									#13
	Full PM-box? Change here!

"F",

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.

NO, I repeat: NO jpg gfx (with the possible exception of large illustrations, filling half of the screen or more), because we need the details in those tiles and units, so we can't afford to use a lossy format. Bitmap with clearly defined pixels is the way to go.

	23-06-1999 05:56									#14
	Get a bigger avatar today!

On the image format issue...

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.

-Mark

	23-06-1999 09:44									#15
	Support Apolyton buy from Amazon

Hi:

[*]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.
[/list]
I hope I'm not being dense, and asking questions everyone else already knows the answer to. I've just never built an interface for a game before.

	23-06-1999 13:38									#16
	Inflate your Upload Space

F:

One source for our map layering discussions is at http://apolyton.net/forums/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 .

This discussion is OT anyway... so the next person to talk about specific map issues or whatever, Please start a new thread .

	30-06-1999 05:41									#17
	Support Apolyton, buy Alpha Centauri

I wrote in another thread some things that also fit into the process, so I will duplicate them here...

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.

In my absence the dukes IMO should also think about a first, relatively simple sub-set of their areas that we can implemented for the first alpha. Once we have those specs and the variable / interface information that goes along with them we can start coding on alpha1.

	24-07-1999 23:36									#18
	Support Apolyton, buy Alpha Centauri

Hi Everyone:

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,

Mark

	29-07-1999 06:52									#19
	Lose 30 kilos (of popups)

Hi Everyone:

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

-Mark
[This message has been edited by Mark_Everson (edited July 28, 1999).]

	30-07-1999 02:02									#20
	Support Apolyton, buy Galactic Civilizations: Deluxe Edition

Sounds like a workable 1st step.

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


sorry for the ancienTV reference.. for those who missed it.. The "A-Team" was a realistic-style (?!) vigilante-outlaw-goodguys show in which opposing forces could stand meters apart, cutting loose with automatic weapons, and NOBODY EVER GOT SHOT.

	05-08-1999 01:53									#21
	Increase Your PM Length

I pity da foo'

	14-08-1999 17:02									#22
	Get a bigger avatar today!

I'm fairly far along with the alpha1 military model coding. I'm trying to figure out a way to distribute to those who aren't java gurus. No luck so far, but as soon as someone who knows what they're doing in terms of deploying java takes it on we'll put something out.

	20-09-2000 23:36									#23
	Support Apolyton buy from Amazon

I have a couple questions regarding the timeline and plans posted here:

What went wrong?
And how will we make sure it doesn't happen again?

	21-09-2000 03:20									#24
	Support Apolyton buy from Amazon

At the risk of upsetting Mark, this is the reason I'm pushing OO design and the 'Extreme Programming' methodology.

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.

So please continue to be patient with me!

	21-09-2000 06:21									#25
	Avatar Enlargement: We've got the solution

I originally posted this in another thread, but this thread is probably a better place for it.

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

What do you think?