Overall Project Issues -- A Proposal for how to Proceed

[Mark_Everson]

A lot of issues have come up recently, and we as a group are having a hard time agreeing on the way to approach them. So I decided to make a proposal for how to settle these issues and move on. Much of the discussion centers around 1) realism/complexity of our models, and 2) programming game models. In general I'm not trying to solve specific issues here, but to get agreement from the group as to how we will resolve different classes of disagreement among the team. I think consensus is important on these general modes of operation of the group since these sorts of issues are going to come up over and over again. Only in the case where there is no consensus, and also no set of relatively cheap compromises where we can "take both approaches" will I attempt to use my awesome power as project lead to force resolution on an issue. Hopefully that won't need to happen.

I will be shocked if everyone agrees to the first draft of this. It's meant to be more of a discussion starter. I will number my proposals to facilitate discussion. If anybody wants to add further clauses to a team 'contract', just start numbering from where I left off... The numbering scheme in no way indicates order of importance, it is more just what comes out of my stream of consciousness. Also, I may post this before it's finished since I think we need to start discussing this stuff ASAP.

When we get something we all agree to, I will get the final version up on the web page.

Additionally, I will occasionally here use specific examples just to illustrate overall project problems. No examples are meant as a specific criticism of anyone, but frankly was mostly because I already had an example handy. In fact, people have already responded to some of my suggestions on some of these issues, and I thank them for it.

Everyone that is currently on the project is working very hard, trying to do the best for Clash. I appreciate the work that all of you have done . Now, on to my points...

1. Realism/Complexity of game models

I have said it before, but I'll say it again. Being more like the "real world" is not a sufficient argument for acceptance of a game model, or programming approach to the game model IMO. So long as the game is internally consistent in its logic that is all that is necessary. I agree that all other things being equal, more realism and complexity has an appeal for me also. But I hope to demonstrate below that all other things are very seldom equal. I realize here that in my initial Clash web page way back when, I emphasized the importance of realism as compared to the ridiculous things that happen in games like civ. I Know we can do Much better than Civ. But I think we have to draw the line on realism at some point for several reasons:
a) Discussing ever-more-realistic models takes time from more critical priorities.
b) Executing more complex models in code takes more system resources.
c) Creating AI to handle more complex models is more difficult, and the AI will generally be worse.
d) Good GUIs become more difficult to make because more complex models generally require more complex GUIs. And if the player can't really interact with a certain complex model, then it is my general opinion that the system resources can be spent better elsewhere.
e) Micromanagement almost of necessity increases as model complexity increases. That micromanagement may be fun for a certain person, but unless the complex model is optional, or the AI is competent in that area, it will end up pissing off all the players that don't think that particular kind of micromanagement is fun.

I don't want to bog things down discussing these points too much. If you even agree with three out of these five reasons, then please think seriously about cooling it on the realism front.

Discussing ever-more-realistic.... I know I personally am guilty of liking to discuss minutae on many issues endlessly. I am trying to change that behavior, and that's one of the reasons you have seen me less on the forum recently. I ask the rest of you to do the same. I propose that if the item under discussion is not in demo 5, or in the basic code architecture that F. Smith is trying to hammer out, that you try and do something to contribute to one of these areas.

And one final perspective, a quote from Paul Crocker, who left the project after doing an awful lot of work on tile art:

quote: BTW: I also opted out of taking on a major role because . . . I felt that people were worrying too much about minor details rather than tackling the basic framework (FE worrying more about adding coral reefs, etc than how the whole thing fits together).

I completely agree with Paul Crocker's statement that people are spending way too much time digging far down into the details of models (or were, some change has been noted already ) and not spending enough time worrying about how the high-level pieces fit together. And whether the thing will be fun. I think some topics in aggregate are more likely to hurt the game than help it, because people coming to the forum see game participants going way overboard IMO into unrealistically complicated models of the world. I expect a fair fraction of them will leave the site chuckling never to return. I may be wrong, but this is just my impression of it based on some early feedback that I got on clash from a few people who design games professionally.

These individuals looked at an early design of Clash, which is not Nearly as complicated as what we have now, and said that it was hopeless to try to create such a complex game. I disagree with them, but when I see the world models getting ever more complicated, I get very concerned. More complicated means it's harder to have the AI do the right things, harder to do the interfaces properly, and harder to tune the behavior of the world when it doesn't come out right. I think F. Smith is right when he says that the object model the game is coded in should allow for this complexity. It will allow us to change direction rapidly if we decide there is one critical thing that needs to be made more complicated. But to actually attempt to utilize most of this potential complexity in the actual game mechanics will IMO kill the project.

So my plea, is for everyone to think about things that are Absolutely Essential for gameplay, and to temporarily put aside everything else. If you can program, or think you can learn how to program in Java, then programming is the most important thing you could be doing. That is because only by actually putting some of the big ideas in the system into code will we start to learn if they are fun and work properly. I am not knocking the spreadsheet models of some areas, they are also valuable. But in truth we can't gauge the feel of the game from a spreadsheet.

If you don't think you are suitable for coding, and are just working at very small details in your area, especially if it is far from being actually programmed, please consider thinking about the interface for some area. We have had very little discussion of the player interfaces for the models in general, and this is a Big issue. Or take of fresh look at a model you are not familiar with and picture yourself playing using that model.

2. Programming issues and the intersection between coding and existing models

When a model lead and the model coder disagree on the approach to use in a model they should try very hard to find a point of agreement on each issue. When this is impossible the programmer can use any approach in code provided it can mimic the model results. The programmer is also free to put in any optional models they see fit, provided that those models only replace the "standard" one when a check box is activated by the player. The programmer should then start a separate thread for discussion of the alternate model. I think we have just today reached agreement on such an issue, and its discussed in the next section.

3. Code Object Design and Pointers

This is meant more for informational purposes than as something that we necessarily need to agree to as a group. But it seems to be coming up in a lot of places, so I thought I would put up an example of what 'pointers' in object models allow one to do in terms of game modeling here. A pointer is a programming term for something that points to another object. For example a Province object will have pointers to all the map squares contained in it. The province should not have the complete map square information contained in it, because the map square object is used by other parts of the program, like Task Forces need pointers to the square they are in, and the map itself is an array of pointers to map squares. Pointers are very flexible. This example is from the technology model.

As I see it, the major thing we've been discussing is the object that holds tech. F_Smith wants tech to be at the EG (ethnic group) level, Richard (and me too) at the civ level, or at most province level. By putting an overall tech object pointer at the EG level we can have Both solutions. For the EG level model this means each EG has its own unique Tech object which does all the complex things F_Smith wants (and Enormous computational and other baggage IMO, but that is another discussion). Simply by having a checkbox that says 'Tech at civ level' you can instead have Every EG in the civ have its tech object pointer point to The Same 'civ' tech object. Then you would sum over what RPs are being produced in the civ could be applied once to the overall 'civ' tech. When that tech object changes all the EGs tech pointers point to the new modified object and things are basically the same as if there only Were one tech object, associated with the civ.

I see no problem with a limited amount of this type of complexity in the model coding, provided the 'standard' system gets coded along with any other options.

4. Demo 5 Code Structure... Old architecture, or switch to Beast

Sorry, I have run out of time. Will fill this in when I can.

-Mark

[Lord God Jinnai]

Another thing I suggest is that we must have standard names and meanings for things. This results in many of the problems also. I suggest either posting it on the model page or someplace that can easily be reached by anyone. I say not in the forum pages itself unless we can get it to stay at the top because this IMO is important and has caused about about 40% of the problems that come up in the models.

[alms66]

I guess this belongs here, but even if it doesn't, since everyone will be checking into this thread, I'll post it here.

First, everything Mark speeks of is true, realism especially. Realism in a GAME (!!!), is nothing more than we perceive it to be. I know I've always voted for realism, but the playability comes first. And to be honest, just having those realistic things (disasters, disease, characters, etc.) in a very abstract way would make Clash more realistic than Civ, which is ultimately my goal.

Second is my concern of the number of options we seem to plan on including in Clash. With so many options, I am almost sure the AI will suck, not to mention the player will probably get bored with choosing the options he wants to play with. So my suggestion is to "give the finger" to options, and focus on the default game. After all, if we have no default game, we can have no options... right?

Mark's #4, I personally accept the idea that population is the basis of everything. So I don't see how the demos work so far without it. I'm not saying we should switch to "the beast" or stay with the demo architecture, I'm neutral on this one, but F_smith's approach to building the final game makes sense, it seems more logical.

[roquijad]

I'll wait for Mark to finish his post before I give my opinion.

[Mark_Everson]

Continued from above...

4. Proposed demo 5 approach

I have been thinking a lot about the direction in which we should head for demo 5. I've bought into F. Smith's compartmentalized approach to how the code should eventually all be written. Anyway, one thing to address here is whether we should shoot to rejigger all the code as a demo 5 target or not. Basically as I see that there are two possible options. Do demo 5 separately from the beast, letting the beast continue to build up, and after demo 5 translate things over. The other option is to bite the bullet now, slowing down demo 5, and have demo 5 be done in the new architecture.

F. Smith and I have agreed that it's probably more sensible to do the realignment now, and have everything on the new uniform architecture. Laurent, our other active coder, is out-of-town for the moment. He has been flexible in the past, and I don't think he would mind us going ahead on this decision without him.

F_Smith said:
My personal preference would be to do what's called 'Refactor' the Clash code from the ground up. We should do that from time to time anyway. 'Refactoring' is typically taking a ground-up look at the program from beginning to end, and see how the pieces fit together. I feel that we can in a matter of weeks build a 'Demo 5' alpha prototype that can serve as the foundation of the game program. We could instantly merge the govt code with the prototype, and include basic combat code. That's about 2 months work, I think. Then each model should take about a month to add. So we can hopefully shoot for a new release once every 2 months, or so.


So everybody, what F. Smith said is my proposal for how we go forward on demo 5. Actually, because of F. Smith's approach the official demo 5 will happen sooner, but have much less content than originally envisioned. We are still working out the details of how to do this.

Comments on the overall approach are welcome here. If you want to make specific proposals about demo 5, please put them in the demo 5 threads for the relevant area. I will probably start and new thread on the overall demo 5 issues tomorrow so we have a place to discuss those things.

Please let me know what you think!

Sorry I haven't responded to some of the points above. I'm beat right now, and will return later to discuss.

[Beör]

re 4

I totally agree. We need to look at the whole structure from the bottom up. It is soooo obvious when comming in from the cold.

[roquijad]

While I agree with most of what Mark says, I feel we need a much more specific agenda to decide upon. Some of the things Mark mentions are to my taste too general and may not help to settle the conflicts.

First, I want to express my opinion on the things I believe Mark is clear about, namely
A) How to code models (points 2 and 3)
I Agree. An accepted model must be coded as the "standard" model. Coders can do that in whatever way they want, with the code being able to do much more than originally planned, as long as the default model works in that structure.
Alternative models can be developed as long as they don't demand changes that are harmful to the (let me bold it again) standard and accepted model.

B)Beast and Demo4
I think it's better to adapt demo4 and join all together as F_Smith proposes. This is just what sounds good to me.... remember I don't know much about coding


Now, I want to focus in what I believe Mark wasn't too clear:

A) Realism and complexity of models

A.1) One of the recognized (?) problems is that we are modeling the world in too much detail. I think no-one ever has started a thread about something (or added a model feature) and at the same time consider it a small detail. It's contradictory. What really happens is that someone or some members of the team start discussing a topic believing it's important and then others come and say "don't you think that's a detail?". What I'm saying is you usually don't realize you're worring about a detail. And more important, what is a detail for someone may not be for you. I believe we won't solve anything in this field if each one of us is let alone to his own criteria to decide what is a detail and what's not. That's what we have now already! To me, we need a way to decide as a team what things we want in models and what are considered too detailed to be modeled. Each model developer will have to live with the team decision.


A.2) Endless discussions. That's other thing seem to bother us all in the sense that it stops the project from moving on. IMO Mark merged in his post this topic with the "detail modeling" problem and they're not necessarily the same thing. The number of social classes and the flexibility regarding this number created one of those loooong discussions, FE. However, I feel, and I believe most of you feel the same way, that this is no detail. Social classes define in the game things like riots, revolutions, changes in govt type and economic system and other very critical aspects of the game. So I think it's reasonable to accept a longer discussion on such topics, but at the same time it's very dangerous to the project that these important decissions never get to an agreement. In particular, the issue about the number of social classes is still unsolved, FE. I feel the current conversation about EG/Techs/Infrastructure lies in this same category.
So, what I think we need is a way to detect when a major decision must be taken and a method to take that decision as a team. Let me say it again: a method. We have to be able to develop a system in which important team decisions can be taken!


B) Models we want
This is something Mark didn't mention and I believe it's important. Two things I've got to say here:

B.1) In A) above I bolded "accepted model" (or "standard model"). When a model becomes "accepted"? Do we like our current models? Have they all "passed" and are "approved"? One thing I feel is related with this is that most of us only know maybe one model in depth, two or three in a general perspective and almost nothing about the rest. I find this very bad. In some of the discussions seen recently F_Smith was kind of shocked to see that Clash probably will not have cities, only provinces. The "no-buildings" strategy seemed also to be not well known by team members. Richard only lately in the discussion understood what I wanted to achieve with the "negotiation procedure" in the govt model, even when this feature was kind of the "core" of the model. We don't know our models, I'm affraid. Mark is maybe the only one who has a good idea about all models, but that's IMO not enough. This is for me of crucial importance in a time when models are starting to be coded. Agreeing as a team that we like this or that model and it should "pass" to the category of "waiting-to-be-coded-soon" is IMO very important. Maybe Mark likes in general all models and that's why he doesn't seem to care much about this decision, but I really would like to see us all in this agreement. Just to encourage you all to meditate: The social model is being coded in the Beast. Why are we coding this model (mine) and not Manurein's model (the very first social model developed for Clash)? How many of you know both models and can be confident that we're coding our best option?


B.2) The list of models seem to be always increasing. When I entered the team there was no ecology model, no disaster model, no wonders model, no population model. I myself added one: The Riots Model. Recently we saw two more appearing: the pirates model and the infrastructure model. From discussing techs and social things we decided we needed a "social techs system" which really means one more model... And I've been less than a year here... How many more we'll have? We could take a position like "read my lips: no more models!", but instead I think we should recognize all the areas we want to cover in Clash, organize them in models and then leave the list of models fix (unless of course some big reason dictate another is needed). This is something we can do now. Otherwise the project will be constantly increasing with every idea people come up with.

In short, I want things more organized here. I want clear team procedures for:

1) How to determine the "allowed" level of detail in models (or standard models, if you will). Not a general "law" or "policy" for what's considered a detail, but to check each model and take a team decision of what is too detailed in it and then ask the model lead to get rid of it.
2) How to take major team decisions. This is of great importance in these days...
3) How to evaluate a model and accept it to become the "standard" model.
4) How to handle the number of models.

I know for some of you these things might sound like bureacratic, but IMO it's the only reasonable way to keep progress in line. To me, those days when the Clash forum was full of ideas coming and going, all with chances of being implemented, are gone. We've got to a point where we need to take decisions in a direct and clean fashion. We need clear methods to take team decisions in a formal way. We have lost team members before and we will lose more if we don't put things in order here.


That's my opinion. Does anybody agree?

[axi]

1. On pointers: Of course these pointers have nothing to do with the pointers used in C, do they? The C pointers are used for low level managment and point to memory slots, don't they? Beyond that, I feel it is a good way to achieve flexibility, though I have no idea of coding either.

2. Following on Rodrigo's comment on model organisation, this is how I percieve the existant models and their submodels. The list of submodels should be expanded. Perhaps we should list all components under each model and submodel too. F.e. the infrastructure submodel has two components: the investment machine and the preferences machine.

General Models

AI
Coding
Interface
Multiplayer
Macro Language

Core Models

Economy
- Production
- Infrastructure
- Govtecon
- Merchants & Trade
- Specials
Social
- Population
- Migration
Government
- Riots
Map
- Map Generator
- Map AI
- Map Graphics
Technology


Standalone Models

Military
Diplomacy

Secondary Models

Characters & Dynasties
Environment
- Disasters
- Disease
- Ecology
Wonders

Secondary Submodels
Piracy
Sounds

3. Based on our final model organisation, we should decide in what order we want each model and submodel added in the alpha structure (our demo 5), using the new architecture and what exactly will be there in the first place. This is my proposal (although after 5 and 6 it becomes more of a wishlist... ). I feel that the econ model should have been completed before the military model was initiated, like others feel that ecology should come before everything else, but we can't do anything about it now...

Demo 5: (alpha1)
Map: all submodels except layered graphics
Economy: the basic accounting plus production and govtecon. No Resources. Primitive AI.
Social: everything except migrations. Simple population model
Government: everything but basic set of SCs, no AI, few special actions, few effects for riots.
Technology: the basic system, reduced set of techs, no tech diffusion.
Military: the battle system only. Military AI alpha1 (tactical AI).
Interface: simple functional windows interface.

Demo 6: (alpha2)
Map as before+basic econ/transp/mil layers. Full Government, Technology and Social models. Govt AI alpha.
Economy: add resources, basic trade and infrastructure. Econ AI alpha.
Military: Regular TF formation and upkeep. Connections with pop model and infra.model. Mil AI alpha2 (a1+strategic/logistic AI)
Technology: The full system. Connections with infra model. Runs on auto.
Interface: 1st attempt to implement final interface. Elaboration of graphic represenation instead of numbers.
Diplomacy: basic system, w/ some of the options. Dip AI alpha.

Demo7: (beta1)
All core + standalone models and submodels are in.
1st attempt at environment model with all submodels.
Pirates, barbarians, nomadic civs added (in whatever form they end up)
Total & partial AIs fully functional and tested.
Full coverage of final interface.
1st attempt at multiplayer.
Includes scenario editor alpha.

Demo8: (beta2)
AI improved
Multiplayer finished.
Map finished.
Interface improved.
Scenario editor improved.
Wonders and Characters included.
1st attempt at sounds.
Final artwork.

Final Game:
All features finished and improved.
First custom artwork, mods and scenarios included.

4. I agree with LGJ that a set of official definitions is a must if we want to understand eachother. We also have to agree in a basic OO architecture (the kind of stuff Beör tries to discuss). And of course, all the decisions that are finalised should be put up someplace. IMO, we need the following organisation pages in the website:

a. Definitions: the person that first comes up with a term should post a definition for it in that page.
b. Architecture: someone should get in the trouble to draw a schematic of the architecture we've agreed upon and to update it regularily. The whole collection of gamedata should also be put up there, alongside the objects they belong to, so that we will be able to complete the data puzzle for each demo.
c. Coding standards: There has been a thread already about this. Standards must be expanded upon and put up in the website.
d. Features status: A page where features will be discriminated as: Set-in-stone, Decided with current model, Optional with current model, Current but under revision, Proposed under examination, Proposed&rejected. In addition, their stage of implementation can be displayed too (demo, code, spreadsheet, model, discussed).

5. IMHO, there is not much more that we can do to force organisation to the project, like Rodrigo wants. Clash is an open-architecture project, so it can be as organised as it's contributors want it to be. All we can do in this thread is agree in small moves (like the ones mentioned above) that will help the situation and listen to the advice of our wise model lead.

As I have mentioned elsewhere, it would be nice if, once in a while, everyone made his self-critique publicly. This would help us avoid arrogance and sniping at eachother, but since it is a quite unpleasant thing to do, i wouldn't force it on anybody.

[Mark_Everson]

Note: I composed this before Axi's post, and it's quite long already, so I will wait until my next posts here to respond to Axi.

LGJ:

Creation of a glossary is a good idea. What do others think? IMO there would be a net time savings from it before too long. If we do it I think it should be primarily organized by model.

TK:

Realism:
I think comparison to Civ is a good baseline. At least at this point in the project we should strive to have Clash be "several times more realistic" than Civ for our basic game. But that going tens or hundreds of times more realistic is premature. What that means to me is that we can have a complicated social model, but that trying to do such a thing at any more than a civ-wide level is pushing it too far. With F. Smith's flexible coding structure we can always push it down further at a later date with relatively little loss in time. We need to figure out first if our basic ideas are fun or not. Making a model that is no fun for the player more realistic is simply wasted time.

Options:
Well, IMO as a practical matter we are kind of stuck with lots of options. F. Smith is frankly more productive than all our other coders combined, including me. He insists, quite reasonably, on being able to include as options his own ideas for how things should work. Even with him doing all this optional stuff, our progress will be much more rapid than would otherwise happen. The AI will be tuned to the standard models only, so the AI won't suck just because of all this optionality. If one of the optional models turns out to be accepted as standard, then I'll tune the AI to match the new standard model.

I agree completely that we Must focus on the default game rules at this point, and discuss the alternate models in alternate threads that people can participate in at their discretion.

Rodrigo:

I agree with a lot of what you say! Generally good points. I need to think about your comments a little more... but here are some thoughts off the top of my head.

A 1) Too much detail... I think peer pressure can do much of this, and great progress has already been made in this area since I started complaining about it. Thanks to everyone for their support . Specifically by peer pressure I mean team members, and even onlookers, should be encouraged to make posts in threads simply saying "item X. seems way too detailed to me". Or that the whole thing seems a little too detailed. Those participating in the thread should try and take a fresh look at what they are doing each time one of these comes in. If you get more than a few people saying things seem too detailed, or even as few as two saying they are certain its way too detailed, then the participants should think about packing it up on that topic. If whoever the people discussing that are still think it's important, they should make a very clear statement in terms of what the game play advantages of the details are, how much fun, and how often, that extra detail adds, etc. I will try to be a stronger lead in shutting off discussions that I think are getting much too detailed. What do people think about this proposal?

A 2 endless discussions... I completely agree that some long discussions are necessary. I think the new demo 5 proposal will help us in force discipline here. Discussions can go on for a long time when they aren't holding up coding. As we are getting closer to each model getting handled in the new architecture, I will set up a series of milestones and time points at which we need to lock in agreement on them. We will then force decisions to abide by that time line. That said, it is important to realize that this is really only the first step of our process. If, after the initial model is coded up, it's found out to be not fun, too cumbersome, or any of the number of other things, we will need to go back to the drawing board. So although we will have agreed to lock in decisions, when game play is poor, we must return to the new modeling and subsequent coding of the new/refined model. I think this is quite reasonable. Does anyone have a problem with this? Also, I suppose a model lead can call for votes of agreement/disagreement by the team on any critical issue they think is vital to lock in before moving on.

OT comment. Since you also have persisted in spreading this groundless rumor that we will not have cities, I feel it important to correct that misapprehension here. You can find out about this by reading the Econ model Although provinces are the basic economic unit of the game, there is still a very crude plan to models cities because of their importance in the overall economy...

B 1 How do models become accepted? Well to my mind, most of the standard models that have been out for quite some time are approved at the level at which they exist. In other words, I personally am basically happy with each model as far as it goes. Some go fairly far beyond what I personally consider ideal, but each of these has a core of at least several people that seem to support that level of complexity/realism. Since we are all in this together I try not to throw my weight around on these things. Gameplay will be the test of whether a model goes too far or not IMO.

One of the most useful things people can do is to look at the core models that will be going into demo 5. Tell the group what you think about them, and give an honest appraisal. (I will try to post a list shortly, in order of which they are likely to be implemented) One point Richard made that is very good, is that we need to consider more what the interface might look like for each model, and what the player will actually Do. Thinking about this will make the connection between the player's fun and the model much more stronger than it is now IMO.

So in short, for all these proposals about what is allowed in a standard model, how detailed it should be, and whether the model should be gone into at all, I think we just have to rely on open discussion, and people forcing themselves to review the core areas of the game, especially as the object analysis for that area is carried out, and as coding commences. I don't think any rigid framework for making these decisions will work. If anyone thinks a model should be killed off, they should post that notion in the relevant thread. I will try to exercise more leadership in this area when I think it's appropriate. Personally I don't think it can get quite as structured as Rodrigo seems to want, what do others think? Then again, I think he is right about the trade-offs in that disorder can actively drive people away from the project.

Beör, since you are relatively new to the project, what are your thoughts on the appeal versus the turn-offs of the current project structure?

F. Smith, according to your extreme programming philosophy, what is the correct approach?

[F_Smith]

Mark:

Not much time, I'll just post this --

One of the fundamentals of XP is to distinguish between the decisions to be made by the business/game analysts and the decisions to be made by the technical people.

In my opinion, our biggest problem here has been one of 'role'. The 'Game Analysts' continually try to insist on making 'technical' decisions. I, as programmer, try to allow the 'Game Analysts' to make the game decisions. A 'Game Analyst' insisting on a certain data storage architecture is the equivilant of a programmer refusing to code up a game model he doesn't like -- which I'd never do.

So in my opinion, people just need to learn what their role is in this project, and do their jobs -- allowing the other people in other roles to do *their* jobs.

P.S. -- a first stab at basic 'alpha' architecture is 90% done. I'm going to vegitate on some football today, but I might be able to finish it up tonight and have some basic (boring) screens to show around (not that there'll be much to look at).

[roquijad]

Well, my bureacratic suggestions seemed to find no acceptance. Ok, then.

The least I can ask regards major/vital decisions. I ask to the team that, when recognizing a topic with possible vast implications, a thread specific for it should be created, hopefully with a "Major Decision: ...." title and encouraging all to participate actively. I feel what's happening today with the infrastructure/tech/EG/who-knows-what-else topic should not happen again in the future. The implications of conversations around that topic seem to be vast. Already people are talking about things like seeing military units as infrastructure and things like that. There's a thread about it initiated by Beör in which he has (and I congratulate him for that) tried to quote all what has been said about it, but discussions about this apparently very important topic are still happening in a number of threads and it's very difficult to follow. Did I understand it wrong or is there something important there we must decide as a team soon? Axi: I ask you specifically to please write a very short summary of what your infrastructure sub-model has triggered in terms of "revolutinary" ideas and if any agreement exists already.


I consider very useful LGJ's idea of a glossary of terms. I'd suggest also that each model should have an "executive summary". A 1 page long document with the very essence of each model. This should help us know all the models and should help outsiders to enter the project more easily. I'm gonna write mine today. Even if you don't like the idea, I strongly recommend you to do it with your models.


About cities, Mark, if I wasn't well informed, it just proves my point. We don't know our models. I have indeed read your econ model. It's just that, like Beör, I considered your comments about cities too vague to be sure cities were going to be included.


F_Smith: I posted something in the Beast thread a while ago and I'm waiting for an answer from you. Excuse me everyone else, but I didn't know where to put this to call F_Smith's attention.
[This message has been edited by roquijad (edited September 24, 2000).]

[Richard Bruns]

I agree with the "bureaucratic suggestions."

I'll write up the summaries for the models I'm involved with.

[Mark_Everson]

Axi:

I basically agree with what you said. Although I think the exact steps that go into each demo are probably best determined only when the previous demo is completed.

"We also have to agree in a basic OO architecture" -- Just read F. Smith's post of 11:55 earlier today. I've come to the conclusion that this is a waste of time for anything that F. Smith is coding. I am not attacking him personally, it is just a statement of fact . We have tried to do this in several areas, and it was basically useless. He is going to code using the architecture he wants and discussion will only get people pissed off, and delay his coding. So unless someone else is a programmer that is actually going to code a particular model (in which case they get to pick the architecture, possibly with input from others) my advice is that discussion of this a waste of our resources.

And the rest of us need to understand that is coding architecture will be flexible enough to allow for accurate coding of our models. If it's not he'll change it so that it can. But otherwise we should just get out of the way on coding architecture IMO.

Rodrigo:

I agree with your "Major Decision" thread idea. The stuff that Beör has written is just brainstorming as far as I can tell. Don't worry, when the major decisions, we will use your idea. Until then you can relax

On not knowing the models... Well, I know them all fairly well... although I admit it is easy to forget fairly big details if you don't think about them for a long time. What's everybody else's excuse?

All:

Ideas for things that should be on each model web page. The idea is to make some changes in the web page is to help reduce confusion and focus discussion. The first two suggestions have previously been discussed.

Summary of what the player gets out of it
glossary of terms
list of open issues in the area (both short-term, for the next demo, and long-term)
list of ideas that have been discussed and rejected for the standard model, and why
common misconceptions about the model?

Will this help a little bit in reducing confusion about the models?

Also, I think those of us in charge of models need to read the other major model pages for demo 5 in something like a two-month rotation. Anything less than we are sure to forget big chunks of what is in the other models. Since many of our models are designed to interact, that promotes confusion. There simply is no substitute for reading over the model pages every few months! But don't bother to read the main military page right now, because it is hopelessly out of date. I will try to do something about that soon.

What do people think?

[Richard Bruns]

All:

I brought up a few of of the points being discussed in the Project Communication Problems thread. My posts here assume that the reader has looked over that thread.

I'll reply to a few things. If I didn't say anything about something, then I agree with it.

roquijad's comments:

A.1) Good point. By the way, until a few weeks ago I thought that the big stuff was done and fixed in place and that it was my job to focus on details.

A.2) Miscommunication is what causes many of those long discussions. FE in the social model discussion it took us several weeks to realize we agreed with each other. I've been trying to standardize and clarify definitions for months, but it never seems to work.

B.1) Don't forget that it is sometimes possible to read everything posted on a model and still be confused about what is going on. That is what happened with the social model. I read all of the stuff but got the wrong impression about the role of negotiations.

B.2) Mea Culpa

I agree with your need for more organization. If I had gotten clear instructions a while ago, I might not have been so unproductive and annoying. Of course, a more clever person would have figured some things out on their own, but I'm pretty dense.

axi's comments:

3. I think it will take more iterations than that to finish the game. IMO we should first complete the ancient game, and then add higher tech "expansions" until we get to about 2050 AD. FE we complete the game with the technology of 4000 BC, and then we add the advances that occured from 4000 BC until 500 BC, and then we add the advances until 1400 AD, and then we add 1400-1600, etc.

That way, we can first have a working game that has very little technological complexity, so we can refine the basic structure. Once that is done, we can build up to the complexity of the modern era.

F_Smith: In procedural programming, it was vital for game analysts to make technical decisions because the code structure and model structure were inseperable. The code was so inflexible that if it wasn't programmed just right, the models wouldn't work right. Old habits are hard to break. I'll try to do better in the future.

[Lord God Jinnai]

1. We should, or rather the coders, should code atleast the core models as much as possible for the base architecture, even if it won't be used for demo5 or demo6 even. Reason why? It'll be IMO easier to do so now rather than later. Besides as far as taking extra time to load, if its not using it, we don't need to worry.

2. Everywhere i look i see something like "We can use that for the standard model, but we have these/this option[s] for scerios, etc." I think we need to cut down here? We don't want to turn the player off with too many options. And yes, that can happen. I remember that did happen with some of the games i liked, other people complained that they didn't know what to choose because there was too much to choose. Not everything should have alternative models. I think very few should infact. I know many people might not think the models we use for whatnot are the best, but every time we deviate with a new model, espially if its fundimentally different like Rich's proposal for military model or F_Smiths proposal for a tech tree (which BTW will not happen...if you want F_Smith i'll explain) we add more complexity to the models which most are complex enough and there interaction can be even more complex!

I do not mind the coding it up for test play, etc., but for almost every model we should have one set possible model.

3. Reality vs. Gameplay
I persoanlly am for reality, in the sence that reality is based on a world that exists with its own laws and those laws cannot be broken. FE a magical world could be 'reality' then. Gameplay is very important, but gameplay is not the end all be all of games, espially these games. We haveto think first who are target audiance is? Is it newbies? or is it people who want quick and easy stuff? or is it people who want tons of detail in differnt areas? It is IMO impossible to please everyone, and extremely hard to please most people so we should target specific group[s], but when possible without making it less thrilling for those groups, make it more appealing to the other non-target groups.

4. Detail vs. Abstractness
Just like anything else, there is a point where one can become too detailed and too abstract. In some ways i think we are too detailed, but in others i think we are too abstract. Right now i will not criticize any model because i know many of my points go to the fundimentals of some of these models which have been assumed for a long time, but i think just as mark and others mentioned we need to be not really detailed (which i agree with) these hasn't been any emphasis on being too abstract.