Overall Project Issues -- A Proposal for how to Proceed
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 leadto 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
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
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.
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.
I'll wait for Mark to finish his post before I give my opinion.
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.
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.
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?
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...
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.
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
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
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?
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).
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).]
I agree with the "bureaucratic suggestions."
I'll write up the summaries for the models I'm involved with.
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
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?
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.
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.
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.
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.
Hi Manu!
I hope things are going great with you.
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
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
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.
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?
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.
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.
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).]
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).]
GUI= Graphical User Interface
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.
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
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.
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.
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.
Posting Permissions
Reply With Quote
Bookmarks