Overall Project Issues -- A Proposal for how to Proceed

[roquijad]

I'm with LGJ in the number of options. We should try hard to build a good standard game where options are just small changes with low impact on the general game.


I'm with Mark in what regards implementation. He's made a very good point. F_Smith isn't flexible in this topic and he will in fact code whatever he feels is best. On the other side, he has guranteed all along that in all his implementation, models won't be changed and will do whatever we initially planned for them. He just has added extra potential flexibility if we need it sometime in the future. So let it be. We (the rest) must understand our role (or job like F_Smith says) in the project and just care about design, equations, that sort of thing. Coding is his territory and he's capable and very useful there.

Mark: Don't tell me to relax about major decisions when I feel major decisions are here in the tech/EG/infra topic. Why I feel I'm the only one who sees something really important is in that thread? Am I totally lost about the issue? Is it of no major importance?


I've sent to Chris 3 documents to put in the web site. One for each model (riots, govt, social) with:
Brief Summary
Glossary
Current Status

I'll post them too in the corresponding threads.

[manurein]

Hi all

First of all, let me make things clear about my intervention in this forum.
I am not a part of the Clash Team anymore, because my professional activities dont leave enough time for that. I have a quite active member of the Team for something like 6 months (I developped the first social model, upon which some of the ideas of the actual social model seem to be based), but I'm not involved in this project anymore. I try to follow the forum discussions, but I can not really participate in them.
The fact is, that I really wanted to see Clash ship and play it, and I still want it hardly. What I see for a few weeks, is that IMO Clash takes a very dangerous way, and its shipping seems to me more uncertain from day to day.

This is why I permit myself this intervention, because I think that some of my experience in professional design and development can help here and now.
I must say that I have never worked for the gaming industry, although I know some people how do, here in France. So I quite know how they work.
My experience in design and development is both in the military industry (where projects are way more complex than any gaming project, including Clash), and in the professional software industry.

So on my remarks now :

1. This point adresses Mark's remark about what professial game developpers say about Clash : my opinion is, skilled people in terms of project management are not to be found in the gaming industry. If u follow their design methods, then their point is certainly right. But I can insure you that I have worked on very complex projects, using methods that those people dont use, and I have always finished the job on time. The real problem here, is what method wiil use?

2. On the project complexity : my opinion here, is that Clash is clearly one of the most complex and ambitious game projects ever, if not the most. This complexity is both a blessing (in terms of what the final game will be) and a curse (in terms of project development). Specifficaly, and to answer a point I've seen somewhere else on this forum, IMO Clash is way more complex that SimCity 3000 or Ceasar III. This remark leads to the next one :

3. The most important thing for u now, IMO, is to design the Clash Architecture. Why? Because this Architecture will give you the framework in which every Clash model will have to fit. If this architecture is designed correctly, this will solve many of your problems : it will insure that every model, designed along the guidelines given by the Architecture, will plug correctly in the game. Along with the Architecture, what u have to design now is the interface model. I'm talking about interface model, because this must be a generic interface system. It will tell how models will be able to communicate between them. This a very important point, because the complexity of Clash lies in the interconnections between the models. This is also very important, because if u have a good Architecture and a good Interface Model, u can develop each model as a "Black Box", which means that once the interface of a given model is designed, u are sure that the model will communicate correctly with the other models, and that it will correctly plug in the Architecture. The model designer and coder are completely free to implement the model : the correctness of the model in regard of the Clash Architecture and the Interface Model is not dependant on the implementation. This will give the flexibility u need : first design and code the interface; then plug the model in the Architecture : it works!! U can then implement the fonctionnalities of the model one after the other, refine some, change others ... As long as the interface does not change, u have nothing to do to plug the new version in Clash : it is already plugged, all u have to do is to replace the old code with the new code.

4. There are several steps in a product design process. First of these steps is the specifictaion, which tells what the product will do. The second step is the design, which tells how the product will be built to do what it is supposed to do, as stated in the specification. Next step is the realization, in which u build what u saud u were going to build in the specification, like u said u would build it the design. Step. Subsequent steps are concerning the testing of the product.
It is very important to realize both the importance of such a cycle (sometimes called V-Cycle un the industry), and to realize the importance of each step. It is also very important to realize that each step must be completed before the next step begins. One of the biggest problems u have today IMO (THE Biggest being the lack of an architecture), is that u mix those three steps : while u are coding a model, u are still discussing about what it should do; while u are specifying a model (saying what it will do), u arte speaking about how u will implement it, which is part of the design step. It is very easy to understand why it can not work like this, and this can be seen in the threads of this forum : while u are still in the spec process of a given model, u spend poages and hours discussing the merits of OO design vs procedural design. Do you really think this is productive ? I dont . U can have those discussions (BTW, if u build a good architecture and interface model, this wont be an issue anymore : as black boxes, no mdel depends on how other models are implemented; some can be OO programmed, others can be procedurally programmed ... When I worked for the Aerospace industry, we designed systems comùprising software parts, hardware parts, mechanical parts ... They all worked together perfectly, no point about "is this OO ...") my point here is that specification does not deal about implementation. U can have those discussions, but in the design process. If u really want Clash to ship someday, I very strongly suggest that u stop mixing these steps. U dont have to have all the models at the same step at the same time, but for a given model u really should try to follow this cycle. Once again, I want to emphasize that, if u use a good architecture and build the models as "black boxes", u can easily have an iterative process where u build models part after part, and still follow this cycle.

5. Linked to the last point, u should clerly define the roles of the members of the Clash Team. Speciffically, u should clearly separate the model specifcation role from the model design/code role. Even if the same person has both these roles, he should make a clear difference between them. This to allow for a clear seperation of the steps of the cycle cited in point 4. On the same level, one atomic remark : Mark, u are the project leader, and as u say u have "awesome power" : USE IT!!!

Ok, I think thats all I have in mind now. All these remarks only have one goal : help u SHIP CLASH OF CIVILIZATIONS, because I REALLY WANT TO PLAY THIS GAME!!!!

One last remark, about my last post : I may be wrong, but it seems to me that the actual Social Model is in part inspired by my social model (I'm very proud!!); I thought that, since they are quite near, some of the ideas of my model could inspire u to solve the problems u have now with the actual model. I had no intention to push my model, its not of actuality anymore; I have nor the intention to polemicate about the merits of my model vs yours; all I wanted was u to know that this model existed, and that it could give you some ideas. It's here, use it as u want.

Ok, thats all.
Once again, good luck guys, and KEEP THE PRESSURE : I WANT TO PLAY CLASH!!!

Manu.

[Mark_Everson]

Hi Manu!

I hope things are going great with you. I had this post ready when I saw your new addition to the discussion. Your point about interfaces is good, but I think you should have seen we are already trying to reemphasize that direction. I need to think about what you have said before I respond. Can you give an example of Exactly what you mean by architecture? I have an intuitive feel for it, but my intuitions are very frequently wrong in talking with professionals who have particular worldviews set by their education. So an example would be extremely helpful in figuring out precisely what you mean.

All:

An additional guideline I would like to add to the list...

5. Coding architecture discussions should take place in a different thread from the main model thread. We have had endless amounts of divisive conversations and wasted effort from people, including myself, confusing coding details with model details. For any further conversation in any model on coding details such as architecture or other things, I think we really need to start a thread dedicated to those topics that is different from the model thread.

LGJ:

Your 1. I disagree, I think we should code enough of each model so that we can get a sense whether it's fun or not, and any core pieces that are needed to put together the particular version we are working on. Coding a model in its entirety, if it turns out to be no fun, is a waste of time. I can see where you might disagree, but I've basically bought into the "radical coding" philosophy where you take coding things a bit at a time. Obviously, model development should go on, but refocused as we have discussed above.

Your 2. The options are going to happen... the first thing I personally would cut is your desire for futuristic game Is that an option you are willing to sacrifice in killing the options? We all have different points of view, and some options are the only way to preserve what each of us thinks is most important about clash without really screwing up the core models IMO. Besides, if an option gets more interest than the core model, that is a valuable sign that that model is in trouble.

Rodrigo:

Well, it's possible I'm wrong on the Tech/EG/infra subject, but I view it as a purely coding discussion. I'm not trying to be patronizing, that is just how I read it . The base Tech model will be Exactly as it was before that discussion. This is why I think we should move coding architecture discussions to other threads. They are easily confused with fundamental model discussions, and I've been confused by this distinction at times also. It is because people use hypothetical model examples in talking about the architecture that it sounds like the model has taken a right-angle turn. The sole result of the discussion, as far as I can figure, is that the code architecture will include the possibility for Tech to be stored In the Code in an infrastructure code object. That is it. The idea is that this would facilitate a different set of rules (not those in the core model) in which some technology was routed in infrastructure rather than the people or civ.

[manurein]

Hey Mark, very nice to hear from you!

Ok, lets try to answer ur question :
first, I have seen that you, and particularly F_Smith if I remember correctly, have tried to adress the point about Clash Architecture. Badly, it seems that people reading these posts have not understood the importance of this point, and that F_Smith has not had success in trying to have people work in that.

What do I mean when I speak about Architecture??
Just the same as when u speak about the architecture of an house : u have the functionnalities of the house (electricity, roof, water ...) and u have the architecture, which tells how these functionnalities will be assembled together.
Today u have ur functionnalities of Clash (the models), but u have no way to assemble them because u have no architecture.

So, more practically, what would be an architecture for Clash? It would be a general framework telling HOW the models will be intergated in the project, and HOW the will speak to each other.

More speciffically, you have to answer a few questions :

1. how will the GUI be managed? Will each piece of GUI be managed by the model it relates to? Will there be a central GUI, and in this case, how will it interact with the GI pieces that are speciffically linked to a model? Answering this question will :
- give u a first idea on how u will manage the GUI, and whet is feasible in this area if the game (if fe u decide that every maodel manages its GUI, u will have a very flexible GIU, but there are things that u will not be able to do. In contrary, if u have a centralized GUI u will do what ever u want, but at the price of some complexity in the implementation of the GUI pieces related to a particular model)
- give u a first idea on how models will interact with the general framework of the game (because in both cases, u will need some interaction at the GUI level)

2. How will the model be invoked each gameplay turn : willl each model be executed seperatly, invoked by a central piece of software that we should call the infrastructure of Clash, or will there be a central model capable of using the other models when it needs them? Answering this question IMO is very important and quite delicate, because u will face a problem of scheduling the models : if eco model needs output from social model, but social model also needs output from the eco model, which one will be executed first?
By answering this question, u will have a first idea of how the models will be articulkated, which is an important part of the architecture.

3. How the models are going to talk to each other? Will you have some kind of decentralized messaging system, where each model can ask the others what it needs, or will you have a centralized system where each models puts all the datas it has calculated in a central repository where the models being executed after will be able to take the datas they need? Answering this question is also very important in terms of architecturing Clash, because it is very related to the last point about scheduling the execution of the models.

When u will hacve answered these questions, u will have some ghood ideas of what Clash Architecture will look like. Then u have to design it, which means, considering the answers u gave to the former questions :

1. designing a mechanics to plug the models in Clash. This will allow for the build of "Black Boxes" i was talking about. What u need here is to give a set of functions (an object interface in OO terms) that all models will have to implement and that will be both sufficient and necessary for a model to plug into the general infrastructure of the Clash. This interface should include what is necessary to activate a model (to invoke it) in way that is not dependant on the model itself.

2. design the communication system that will allow the models to talk each other. Here again, this should be an interface ( a set of functions) that will be implemented by each model, and that is not dependant on a particular model, but common to all models.

3. Write the central loop of the game, be it in the infrastructure or in a central model (depending on the answer u gave to question 2); this loop will do a very simple thing, invoking the fucntions of the interfaces defined at point 1 for each model that has been plugged in Clash.

All the interest of such an architecture is this :
Once u have written the main loop, every thing works. U can plug models that have not been implemented, that have only implemented both interfaces (plug and communication); this way, each model can use the other models it needs, with no concern about what is coded and what is not. Further more, each coder is free to implement as he wants, provided that he has implemented both interfaces correctly.
One last intersting point being that the entry code for the interfaces is the same for every model. Write it once, then ditribute it to every model coder.

Ok, I hope this makes things a bit more clear.

If u have more questions, or want me to be more specific about some points, ask me; I have some times for the few days that come, so I'll try to answer.

C ya.

Manu.

[Richard Bruns]

Okay, here is an issue: How do we know if we are talking about game design or code design?

This has been a source of miscommunication. For example, in my recent discussion of Habitats I have talked about what military units, nomads, and fishing fleets should be able to do. I thought I was talking about game design. I thought I was being a model maker and giving my input on how the gameworld should be abstracted.

But then Mark says I've been talking about a code architecture issue! So I have inadvertently been going out of my role and telling how things should be programmed. I never meant to do that at all! I meant to talk about game modeling, not code modeling.

The same thing happened in the tech model discussion, now that I think back on it. I thought I was talking about the game modeling. I was talking about how the tech system had to be modeled in the game world, while F_Smith thought I was telling him how to write the code architecture! Meanwhile, F_Smith was talking about the code architecture and I thought he was insisting on changing the game model. He was talking about behind the scenes code stuff, and I thought he was trying to radically alter the game model we had all agreed on before.

So I thought he was making a game decision and being a game analyst, while he was just talking about the technical code. He thought I was trying to make technical decisions, while I thought I was just being a game designer.

Part of this could come from my programming experience. In BASIC, the game designer has to think about code because the code is so inflexible that if it isn't right, the game model will get messed up. So habit caused me to get into tech issues even though I was only really thinking about the game design. If I didn't have that experience, I probably wouldn't have inadvertently gone out of bounds like that.

But it appears that Java code is so fexible that game designers don't have to worry about it. I still can't comprehend this, but I'm trying. It's hard to believe how many game design habits can be formed by a couple semesters of writing arcade games during boring classes.

My question is this: How can we tell the difference between game design and code design?

[manurein]

Richard : I understand ur question, and I understand it can be confusing.
I have no formal answer rigth now.
I can propose u to look at my social model (u can reach in the social model page of the Clash web site, at the old models topic).
U will see that in no way it talks about HOW the model will be implemented.
To summ it up, u can tell the difference between game design and code design this way :
The game design talks about WHAT will be implemented;
The code design talks about HOW this will be implemented.

The game design should be independant from the code design; the game design should be the input for the code design.

I hope this makes things a bit more clear.

[F_Smith]

Manu:

Hi!

Boy, do I agree. Almost entirely. I'm so glad to have you saying these things.

I would actually suggest that building the program with a 'black box'/'component' approach *is* OO design, so it is true that some of the components can/will be 'procedural' (especially the 'turn handlers'). But that only works if you used an OO design . . .

I would also suggest that 'Extreme Programming' or 'Prototyping' can actually work faster and better than 'design then code', so iterating the design with the development is actually a plus, not a minus. I've done this before, and it seems to have worked here, so I feel confident in the methodology.

---

For my part (assuming the architecture I've adopted will be the demo 5 architecture), here's the answers to the questions you posited -- please feel free to correct anywhere you think my analysis is off:

[*]The Gui -- the program will use the 'Model-View-Controller' architecture. The Gui components will be 'wrappers' for data objects. The data objects will manage/redraw themselves.
[*]'Turn' logic -- the program uses 'TurnHandlers' for each class of object in the game. The 'turnhandler' interface defines one method, at this point -- 'oneYear()'. This will likely be increased later.
[*]GameData -- the models 'talk' to each other thru the central game 'database' (the 'Model' datamodel part of MVC). Each object that needs to communicate with other objects/models will be passed a pointer to the 'GameData' object upon initialization. For now, this 'database' is just an object. But later, we can plug in an actual database to drive the game, for HUGE worlds.[/list=a]

The mechanics to plug the models in already exists, as outlined above ('M-V-C'). The Communications strategy is as outlined above ('GameData' database). The central loop is coded (the 'turn' button instantiates a 'ClashTurnHandler' which takes the 'GameData' object as an argument, then the 'ClashTurnHandler' method 'oneYear' is run. That's where all the specific object turn handlers will go.

Please point out any errors I've made.

It's good to have you back.

[manurein]

Hey F_Smith, long time we have not chatted!!

Actually, u are perfectly right, what I was describing is the essence of OO design (and I mean design, not programming...), without naming it.

It seems to me that few people here are familiar with OO design, and that this clarification was usefull. Moreover, those kind of considerations belong to the design/programming theories, i'm not sure they should have their place in this forum...

Thats why I tried to write things as simple as possible.


About extreme programming : it's not incompatible with what I said; actually, some forms of this method are used in the industry; but this does not prevent from respecting the V-Cycle at each step : u build a prototype using the V-Cycle; then u refine it using the V-Cycle; then u rework it again using the V-Cycle ...

Once again, the complexity of Clash lies in the fact that u have many software pieces (the models) with dense interconnections. This represents about the worst case for a software (or system) designer. This why, IMO, even if u are going to work with several iterations of the project and the models (ala extreme programming), I think u should take extreme care of properly dividing the job between the steps of the V-Cycle (and, incidentally, between the designers of the models and the coders of the models).


About your actual proposition : first, let me make clear that what I am trying to do, is proposing a method for solving ur problems, not the ACTUAL solutions, because I am disconnected from the Clash project for too long a time, and I dont think my points would be very pertinent - at least, I'm sure u are in a better place than me to do that, and I'm sure u will do that greatly.

I think u have a good approach, but once again i dont want to enter in the technical details, because my knowledge of the current state of the project is seriously lacking.

Speciffically :

(Q3) The fact is, that I had taken another approach for the models communications when I was working on the Social Model (namely, a messaging system).

(Q1) This approach is for me the most aesthetic (like many french people, I find "beauty" in every intellectual concept, this is one of our vices ...) and the most graceful; if properly executed it can also be the most powerful. My only point here is, that in my experience, its also the most difficult to design and implement. But u are the coder, u have ur own experience and u know ur oiwn skills, so this may not be a point at all.

(Q2) I see how models will be invoked each turn (I'm saying model, not object; this is voluntary, I think it is important to make a distinction at this point of the discussion - remember, spec vs design ... - A model may be comprised of several objects, and in my description of the architecture, there is one entry point per model, whatever the number of objects a model is comprised of, not one entry point per object. The fact that a model may be an object itself does not belong to this discussion --> spec vs design, again, i'm sorry (lol!!) ) BUT I still dont see the central loop : who will call the OneYear() methods? ---> Sorry, I had not read carefully enough the end of your post ... So the question now is : how will you manage the scheduling of the models? Will u tweak it rigidilly when all the models are coded to make sure every model has the data it needs when it needs it? Will u make some entorse to the realism and let some models use 1 turn-old datas? Or will u try to enginneer a system where each model records its needs and the system takes care of scheduling properly the models to achieve that? (Knowing that this problem may have no solution ... This is actually the biggest problem i had when i was designing the social model. I had found no solution ...)


Once again, take this remarks as they are : only the very own thoughts of a guy that is even not in the Clash team any more.
And u should also know that I, personnaly, am generally in favor of the most modular approach possible when designing a system (my very first social model, which has never been posted on the Clash web site, was only comprised of agents of the same level : it was a strict multi-agent system with every agent having the same responsability level for the working of the model ...) : this is MY taste, and I CAN NOT pretend it is best or worth in the context of a project i dont know precisely (namely, the Clash project).

Ok, now, if u allow, I would like to make a recommandation that is immediaty applicable : redistribute and redefine the roles of every of the members of the Clash project, and the next few steps for the project.

1. Name an architecture designer (F_Smith?) who will be responsible with specifying and designing the architecture and the communication system for the game; this guy should design the software infrastructure and edit some guidelines, that will be used by the model DESIGNERS for designing their model, and a kind of API or SDK that the model CODERS will use to build their model. This is IMHO the MOST CRITICAL and MOST URGENT thing to do now. This guy should do only that until it is accepted and completed. (once again, F_Smith seems to be the most appropriate guy for this task; this is only my opinion...)

2. For each model, clearly differentiate the DESIGNER and the CODER, even if it is he same guy.

3. Clearly define Mark's role : it is very difficult IMO to be both model(s) designer, model(s) coder, models general reviewer and referee, and project leader. I think if you can delegate some of these activities Mark, and restate you as the clash project leader and emphasize that role, it would be very good for the project. I know its very difficult to pass on your coder role because of lack of coders but please, Mark, think about that...

4. Enter in a kind of Extreme programming loop - while still using the V-Cycle explained earlier in each iteration of the loop - , using a strict schedule for the first few iterations of the loop, and defining clearly what the goal of each iteration is. Then make everything that is possible to respect the schedule and the goals.
The first iteration should be to complete the architecture and have it work.
Second step should be to adapt working models to the architecture and test them.
Subsequent iterations should be the implementation and the refining of each models. Once again, u should clearly define for each model what is the goal of a given iteration, and strictly respect this goal.
It is Mark's role, as the leader, to moderate the designers and/or coders that are going to far in repect to a goal.

Ok, thats all, I hope i help you more than i bother u ...

Cya
Manu
[This message has been edited by manurein (edited September 25, 2000).]

[roquijad]

Mark: Ok, I'll take your word on the tech/EG/etc issue. I'll relax...

Manu:
Thanks for coming back with all this experience of yours... just in the right time!

Most of what you say is beyond my understanding. I'm not a computers guy. For sure my role in Clash is model DESIGNER and not coder.

I've three questions.
1) How independent you think model design and model implementation can get to be? Can I as a designer simply forget about coding stuff? Can I simply draw the model without caring about what objects are there in the code or how/where data is stored?

2) Assuming the answer for 1) is mostly "yes, you can forget about coding", what's in your opinion the optimum kind of relationship between coder(s) and designer(s)? I mean, What are the best feedbacks for each direction (coder->designer and designer->coder)? How to optimize this co-work?

3) You said:

quote: Name an architecture designer (F_Smith?) who will be responsible with specifying and designing the architecture and the communication system for the game; this guy should design the software infrastructure and edit some guidelines, that will be used by the model DESIGNERS for designing their model

Aren't we kind of late for the "guideline" part of the quote? I mean, models are already designed in their core at least, so I don't understand well what you mean by setting guidelines for designing. Or am I understanding wrong what you mean by design? Design=what the models will do... correct?


Let me add a very stupid question... What is the "GUI"?

Stay with us in this thread, Manu... your inputs have been great!


PS: Yes, the current social model was inspired greatly in yours. You probably don't remember this, but when I found the Clash Project and started to read the models, I actually mailed you with comments on your model and I explicitly said your social model was the one I liked the most out of all available at that time. It'd be kind of arrogant to say the models I developed (riots, govt, social) are strictly a creation of mine. Not only Axi and Toubabo Koomi were an important part of this process. We as a team also owe you and Hfrankell a lot of good ideas. The bad ideas in them are exclusively mine, of course
[This message has been edited by roquijad (edited September 25, 2000).]

[Beör]

GUI= Graphical User Interface

[Lord God Jinnai]

Mark:

First to point 1....just was saying that with an anlogy to a house its easier to build the final foundation to start with and if it needs many changes, just rebuild it rather than build part of it knowing you want to expand it, but not when or where.

quote: Your 2. The options are going to happen... the first thing I personally would cut is your desire for futuristic game Is that an option you are willing to sacrifice in killing the options? We all have different points of view, and some options are the only way to preserve what each of us thinks is most important about clash without really screwing up the core models IMO. Besides, if an option gets more interest than the core model, that is a valuable sign that that model is in trouble.

You got everything all entirely wrong on this point! Aaaggghhh!!! Not saying its entirely your fault, but still it leaves the wrong impression of what i meant to everyone else.

The example you give about my futuristic techs wouldn't be thrown out in my original #2 statement because it doesn't change the funidmentals of the tech model, it just enhances/changes them in additional ways on manly what you would call a cosmetic level. It still uses basic technologies as they were before (although maybe a few more tier 2 and 3 levels and more applications), same way of calculating RP, etc. There might be faster and more powerful things, but they would all be within the confines of the other models.

What i am against is having as the final shipped producttwo tech systems that have little in common such as a tech tree we had earlier and what we have now as an example. We can test more than one system while developing and i whole heartily support this move, but with a reminder that the other is an alternative system, whether or not its better and which one should be used (if either of them would be...prob more like a combination), then that's what i am saying. From what everyone saying they want just about whatever we use in this testing stage to go into the final product which is what i don't support if it deviates in fundimental ways like my above example.

[Beör]

At one point in this thread Mark asked me as a newcomer about my general impression of the game we're making here.

First I'd like to say that I know that in the end it is going to be a great game, the civ-game of all civ-games, but...

I have a feeling that it might lack 'contrast'. The models are so thorough and many of the players options so indirect that the player can do very little to alter things in a decent timespan. Changes will be lifelike, and therefore very slow. I fear that the player out of sheer boredome will engage in massive military campaigns, since this is the only way to get anywhere fast. For the same reason I also have my doubts about the no-buildings approach.

In the interest of gameplay, I think it would be wise to consider to what extent we can increase the player influence, without enticing micromanagement, and without having too unrealistic results.

IMO the game's to some extent burdened with a tendency to stick by details, and forget about the playability of the thing. It has improved lately I think, where hard-core design-decisions has forced the team into thinking more in game-terms and less in real-world-modelling terms.

Every time you think about adding a new feature you should ask yourself: What will this do to gameplay? How will it be presented in the interface?

And always, always try to remember that Clash is going to be a dynamic environment. Remember conquest, migration, combat and movement of units.

And I love it, I know it is going to be great

[F_Smith]

I'd just like to agree with Beor.

This is the point I was trying to make with all that 'Sim v. Game' discussion a while back.

But I think that I know how to solve this problem. That's why I'm so insistant on having 'optional' systems for everything.

More on this later.

[Lord God Jinnai]

I don't think so though F_Smith and i will fight tooth and nail not too have too many optional models that deviate from the base ones we decide on for the final product. A few things are okay, but i know that people also get turned off with too many options because they don't know what is good/bad for them and then they throw down the game in frustration and don't play it again.

[F_Smith]

Lordy:

Just to be like other games, we'll need at a very least two levels -- two different models -- for each system.

A 'basic' or 'beginner' model, and the model we want to make for us.

I don't think it would be a problem to include up to 5 different levels, to be honest. Look how many optional rules there are in SMAC. The beginning player just leaves them off, and plays the basic game.

But for the player who has played the game a few dozen times, there's added depth so he/she doesn't run out of new challenges.