Merged threads: How to proceed with the Object Builder???

[F_Smith]

Rodrigo:

1) I'm sorry if I scared you, what I suggested for an 'Ideology' would duplicate all the info in your previous 'Ideology', so nothing is lost. Only instead of a fixed list of 'SocialClasses' I suggested a collection of SocialClasses. It will work exactly the same, from your perspective. Yet it will allow much more enhancement, later. But it will work exactly as you laid out, for your scenario.

2) I'm confused. I thought a 'Religion' was to hold certian 'Religious Doctrines', for use by the 'Religous Class'? And that they had to be seperate from the 'Majority Cultural Attributes'? If so, then this requires a seperate religion object, doesn't it?

3) I haven't coded any turn controller code at all. I'm just planning ahead.

4) I definitely don't understand how you envision this game working. Not store any population info at the mapsquare level? From what I know, that is impossible. If Clash is going to be a game that will be played square by square, then each square will have to know a lot about itself, including how many people are there and what those people are like.

Besides, I wouldn't worry. In a real world map by far most squares will be empty of pop, and another large % of the world will have a simple class structure, maybe two classes (land owners and serfs, etc). It won't be bad on memory.

Okay, to decist any worries, I'll stop coding. But I think there's some definite issues that are going to have to be resolved soon . . .

[Mark_Everson]

F. Smith:

No. 4 I have the answer to... Essentially there are just too many squares in the game to worry too much about the details of what happens in each individual square. (With the current default map square sizes there are about 10k populated squares out of the 64k squares in the world. The economic model is handled on the provincial level, and most other things are handled at the provincial level and higher. The most significant exception is combat, which still happens on the square level. Anyway, our working assumption is that individual squares should only hold enough detailed information to prevent really bizarre things from happening. So, for instance, we need to keep track of the number of people in each ethnic group in a square (at least approximately) so that if I take a single square of yours, I will have a square of people that are pissed off at me because they have been conquered by ruthless barbarians (me). Unless I elect to forcibly move them, they will still be there, and still be of the original ethnic group if you take that square back from me (at least if you do it fairly soon, before the culture evolves away from your culture because of being in the different environment of my civilization).

But in terms of the government model not really much happens in a map square... and we don't want each square to have its own unique cultural group, that is just too many objects IMO. So although each square will have a collection of ethnic groups, those particular ethnic groups will generally be in many squares associated with that civ. So all we need to do is point to several different EGs, and say how many of each is in the square. Your average multiethnic civ might have something like 10 ethnic groups, even though it might have hundreds of squares, each with something between one and four ethnic groups. This approach makes a lot of sense to me, and Rodrigo agreed with it when I suggested it. If ethnic groups are unique at a square level, it will both cost huge amounts of processing time (evolving lots and lots of cultures), and use large amounts of memory (tens of thousands of ethnic group objects) while giving very little benefit to the player. Sound reasonable?

All:

On the other big issue... here is a quote from the government thread:

quote: Originally posted by roquijad on 07-10-2000 10:27 PMHere I go: The govt model has a great weakness in "expandability". While developing it, I (and I guess Axi too) never thought about the posibility of having an arbitrary number of classes or to add/change/remove classes. After seeing OC3 govt model approach, I realized some people might desire to have lots of classes. In OC3 they're already talking about "large farmers", "small farmers", etc, which for my taste is too much detail, but it doesn't look bad for others. On the coding side, it won't be easy for a scenario developer to create other classes and their behavior, and most of times it would need extensive coding by the scenario designer himself, which is not my mental idea of scenario designing. This happens because in the current govt model classes' behavior is not created straight forward and in the same fashion for all of them. UC and LC behavior is given by a set of cultural characteristics called MCA, while the RC takes values from another set called RCM. Each, MCA and RCM, are computed using very different procedures. Also, the military class uses UC and LC values plus a special mathematical formulation for choosing ideologies. So, almost each class have its own way to compute its behavior, and this not only includes different variables, but also very different procedures. This usage of different modeling for each class makes deeply harder an attempt to create a totally new political environment. Adding a new class can be an imposible task for a model developer, unless it's very similar to one of the already existent classes. On the other side, how the model uses "ideologies" presents another problem. Ideologies have fixed values and they should cover all the relevant regimes the game is expected to have. If a scenario designer chooses to have 10 classes instead of the original setting, the number of ideologies needed for the minimum flavor increases Extensively. Ideologies have yet another problem. For representative regimes, pol.power shares must go according to demographic shares. Since pol.power shares are fixed in ideologies, this means the ideology itself needs to determine demographic shares, so coherency can be obtained. This isn't much of a problem with the current classes we're dealing with (excluding middle class) if we accept demographic shares are given by the values of PP, EP and SP, but if now one imagines adding/changing classes, then the relationship between demographic shares and ideologies can be very complicated. IMO the govt model is simply not expandible. If this characteristic is a must in the team's view, then a radical change is needed in the model. I never thought about expanding classes, so it's my mistake

Rodrigo, I wasn't thinking about the kind of versatility F. Smith is looking into either, so don't feel too bad! But as he brought it up, it seems at least something worth thinking about... And if you decide that it's too difficult to inject that sort of level of customizability into the model, I think we have to go with your opinion. However, let me propose something for you to think about, and then we can discuss whether it's worthwhile or not.

Although there are a number of different ways of getting class behavior in the model, there are usually at most three or four different ways all the classes decide their behavior or inclinations.

So, for instance, classes' behavior is determined from one of the following: MCA, RCM, a weighted ratio of other classes' behavior, and a few others. Would it be possible to simply use a weighted ratio of all these factors to generate an arbitrary classes behavior? I'm not sure it is worth the trip, but it would give the system a large amount of versatility without needing a massive redesign. In this formalism the religious classes behavior would come from 100% RCM, with all the other components being 0%. This would give a fairly substantial toolboxes to any scenario designer who was sufficiently brave to try and rework the government model. IMO if you can propose such a scheme without a huge amount of work, it would probably be worth it. And if you think it's too much, then I think there is not significant harm in using F. Smith's approach of making the object design more general, but hard coding your model into the more general object design. After all, part of the reason for F. Smith is doing this, is so he can demonstrate his ideas about object-oriented design, and what it might do for the rest of our code.

Does that sound like an okay approach to everyone? And we can discuss these issues further after Rodrigo has had a chance to think about it a bit? Anyway, that's my take on the way to proceed....

[F_Smith]

Hi, Mark:

Welcome back.

I'm afraid I'm still confused. I don't know how to arrange the mapsquare info.

In the 'ObjectBuilder', I'll build in something to allow the designer to group mapsquares into a 'province'. But then I really don't understand what I need to include at the mapsquare level.

1) So I should go ahead and have a collection of 'EthnicGroups' in each mapsquare, correct?

2) And each 'EthnicGroup' will have a pop int encapsulated within it, and pointers (references) to Religion, Culture, Tendency Values and one other object, is that correct?
It does seem like those 4 things will have to vary from msq to msq, won't they? Certainly not all Goths will have the same education level, wealth, and that sort of thing? Or will they? If ya'll want, all people of a single ethnic group could have the same religion, Culture, etc, regardless of where in the world they are, but that, to me, seems like one of those bizzare things you were worried about.

P.S. --
I believe pointers/references are 32 bytes, an int is 32 bytes, so 4x32=128, then times 10,000 squares is 1.28 mbytes. I didn't think that was too bad, for pop. Add in a few more kbytes for the actual Religion, Culture, TV and other object, and we still seem to have the entire thing fit in like 2 meg of memory.

It sounds like we certainly need the population int. By encapsulating the 4 objects into one object we can save perhaps 640k of memory, if that helps. But that seems like the absolute minimum. And then all Greeks act alike -- no Sparta and Athens.

The mapsquare will also have to hold terrain info, I should think, and any improvements it has. Am I mistaken?

[alms66]

Ok, correct me if I'm wrong, and I don't mean to offend you or push you away from helping the Clash project, we definately need help , but wasn't it you, F_Smith, that once said something like (not exact words...but something similar to...) "If you use a good OOA, you don't need to make the models first, you can code then worry about the details later."

then Mark said (Something like) " I don't see how we can make the code without knowing what the models need first."

But now, when you are trying to show the "power" of your OOA, you are asking very specific questions about how very specific models work. "I don't understand this...I don't understand that..." How can you say your approach is better?

I think Mark had it right, in that designing the models, then coding is the only way to go. You've demonstated this perfectly with your multitide of questions.

[F_Smith]

T K:

I hope what I'm demonstrating is that by going so deep into the details of the models, the model designers have overlooked a bunch of basic questions that will change all the details they've worked so hard on to this point.

Consider all the charts, spreadsheets, and pages and pages of descriptions about serious details, while there are serious questions yet to be asked about exactly what will absolutely have to be in a mapsquare -- a very basic question that will change all the models depending on it's answer? Mark just said that an 'ethnic groups'' Culture will have to be able to shift seperately from the EG's other attributes on a mapsquare basis, for being taken over and 'assimilated'. This means Culture absolutely must be stored by EG, by mapsquare, I believe (unless I'm missing something entirely). And if so, then that changes a lot of all those details ya'll are so carefully working out. And the concept of varying divisions of Social classes by EG, on a mapsquare by mapsquare basis, hasn't even been addressed. Is there some way around that I don't know of? Or will all mapsquares with the same EG have the same % of each class, regardless of prosperity?

Another, more important example -- ya'll built a govt model without ever firming up a basic division of people on the map. And now that the prospect of many social classes presents itself, ya'll are going to have to either change a lot to achieve that, or throw out a good, flexible idea (and have no Middle class?). Either stifle innovation or change the govt model.

Im my opinion, the OOD process is suppose to be:
1) Get a good idea of what the basic requirements are.

2) Code up a prototype with a solid OOD that can be expanded.

3) Client/Users provide feedback from prototype, coders use this feedback to refine the model.

4) Repeat until you're 'finished'.

* * *
Instead, ya'll are using the old Cobol programmers approach:

1) Write a massive 'Design Document'.

2) Code according to that document.

3) Change the Design Doc to reflect what really got coded.

4) Debug all that code.

5) Change the Design Doc to reflect what really got coded.

6) Give the client/users the final product for the first time. Hope it's what they want.

No feedback, no refinement, no room for when the programmer discovers more efficient ways to do things -- in fact little or no input from the progammer at all, you want the programmers to go away until you've written the bible, then do all that work. That's just not the way to develop software, in my book. It takes a lot longer, you have no 'release early, release often' cycle to maintain momentum, that sort of thing.

And bottom line, many programmers who might like to contribute some time will *hate* the Cathedral approach, and *love* the 'Extreme Programming' approach. For one thing, your approach requires a programmer to spend a week reading and understanding a huge, complex document, just to even get started. The prototyping approach puts the code out there. They can pick any single object, and code up a version of it they think is 'better'. If no on likes it, or it doesn't work, then it is politely declined. And the project moves forward one iteration. In a few weeks I helped design and code a basic prototype scenario designer that can now be built on and fixed up to ya'lls specs, even if I get hit by a bus. And now you seem to be telling me to quit coding.

Do consider what appears to be happening here. A programmer (me) tried to provide feedback on how the program should be built. You are politely rejecting his advice, in effect telling me thank you but go away until you need my services. And the same thing happened when I tried to help with the 'Tech' model.

I do feel bad, because maybe it's just me. I'm really sorry, if I'm different. But I don't know, I think most programmers I know feel the same way. These things I'm suggesting are, I am certain, common programming concepts.

I don't know if this has anything to do with why you have poor programmer support for this project, but it's sending me clear signals. Mark seemed to indicate clearly to Rodrigo that if the more flexible, powerful approach to social classes doesn't work for his Govt design, he'd be willing to kill the innovation. Or did I misunderstand a polite comment?

I don't know. Again, I hope I'm not just being a jerk. If so, forgive me. Or at least try!
[This message has been edited by F_Smith (edited July 13, 2000).]

[F_Smith]

P.S. My wife is going out of town this weekend, so I will have a bunch of time at night to code.

If my skills are needed, I can contribute. If you know of something I can work on that is definite, do let me know.

Otherwise, I think I'm going to play with a simple, servlet-based version of 'Robot Wars' (anyone see that show?). Just for fun.

Or I'll play some more Caesar 3 . . . choices, choices . . .

[Mark_Everson]

TK:

F_Smith is IMO helping to move things along substantially. We're just going through some differences of opinion, aided by some probable miscommunication on all sides . In the future, would you please refrain from sniping comments? All it serves to do is generate flame wars that waste time that could otherwise be used in moving the project forward.

F_Smith:

Well, I had been hoping to hear what Rodrigo thought about the stuff above before I made my next post, but I can't resist the offer of a bunch of hours of coding . First I'll respond to your post with the exclamation mark on it, and then backtrack to the detailed coding issues you bring up in the previous post.

Your accusing us of having overlooked many basic questions on the model is off the mark. We're not completely dim . I'm not going to respond point by point to all the things that we're accused of in the post, since it would just take more time, and many of the issues will hopefully be resolved in the "coding" part of this post below. And anyway, I never touched that sheep . But I will respond to some of the general statements.

Many of the things you are pushing that we didn't "discuss" come down to how much should be done at an individual map square level. As I said above, we have been working with the general design philosophy that not much should be done at an individual map square level. Some members of the project that even wanted to make things more abstract than they are now, and essentially get rid of map squares completely. Again it's my contention, based on primarily memory usage arguments, that we simply Can't model the individual map squares well. An object that uses 100 bytes that each of the 10k map squares has its own version of, uses up a whole megabyte. Remember, there are many models in Clash, and many things that already have to be done in a map square. If you want to see the stuff that's already in there check out the classes BaseMapSquare, MapSquare, and PopSquare in the clash.map package of the code I sent you a couple weeks ago. And there's lots more to go further into those as the game progresses. Now if adding cultures in every square would make the game incredibly better, it would be worth it IMO to go the way you are thinking. But how much attention is the average player going to pay to any single square of his hundred+ square empire? So for both practical reasons, and most team member's impressions of what the average player will want, we kept with the general design philosophy to limit to a minimum what is in a map square.

I would have Loved to have the model design and coding be much more interactive. But we've never had the programmers available to actually do that other than me. Because of the timing of this, you were indeed presented with a somewhat-complete model when you started programming. Things actually seemed to be going pretty well on the interactivity front until post-by-post a little bit ago people started to get more pissed off... Hopefully we can resolve these differences and get things moving again.

I agree with you in the abstract that a more versatile system is a better thing. But I hope you will excuse me if right now I'm just trying to get something that is playable out. I think the current government model works fairly well at most of the things that we're trying to do. That's the reason why I personally would like to see more flexibility if it can be handled more or less within the current model, but am not terribly interested in completely reworking the model for the sole purpose of making it more flexible. For one thing, a truly flexible government model would be Extremely difficult to write any kind of decent AI for. Realistically, the AI has got to be tuned to one particular model. Scenario designers could certainly go beyond that model, but as they get further and further from it the AI quality is going to deteriorate for sure! So those are at least my personal reasons for wanting to "kill the innovation" if Rodrigo couldn't figure a decent way to make the existing model more flexible.

Anyway, please do continue to question our assumptions of how the model should be. But if you could credit us with having put some thought into these things already, I'd appreciate it. and the rest of us, including me, should try to value your inputs more (I'm trying to be balanced...).

Coding issue...
I wanted to give more specifics in response to your post of July 12. However, based on that post, I think we are essentially there. As you say there will be no Spartan Greeks vs. Athenian Greeks at least within a single Greek culture. However, we have discussed, and will continue to discuss whether cultures can fragment. So one way to approach the Spartans vs. Athenians issue would be to split any original Greek culture so that you do have a Spartan Greek and Athenian Greeks culture. We should discuss this further in the government thread.

And something else you mentioned in the exclamation mark post. (Again I should probably put this in the government thread, but I need to close out for the night so I will just put it here)
In terms of a captured group of people having their culture evolving away from the homeland, that was actually need just giving my best guess as to what we wanted to do. I was hoping that Rodrigo would give me his thoughts on this before we got further... But anyway, I think this concept can be implemented without resorting to individual cultures on a map square basis. IF we decide this is the way we want to do that, then I would handle it in the following manner: Suppose I am the Greeks, and I take over and Egyptian square with cultural Egyptians in it. The instant that we have Egyptians under Greek rule we would create a new culture object that represents Egyptians ruled by Greeks. The square would then have its culture pointer changed to indicate Egyptians ruled by Greeks rather than the original Egyptians. If the Egyptians take back the square fairly soon, those people would just revert to normal Egyptians. However, if it stayed in the Greek empire for a very long period of time, it could evolve away from its home culture. If the Greeks take more Egyptians squares, they would just have their pointers for the culture object also switched to the Egyptians ruled by Greeks culture, perhaps with some prorating of characteristics.

Finally, I think you mentioned somewhere that you are going to embed the population into the culture object. If you are still planning on doing this, please mention it, because I don't see how it can work in the context where many map squares "share" the same culture object.

[F_Smith]

You -- sent me code?

Uh oh, last year when I tried to help on the tech model I had another email address -- eden.com. I'm afraid I changed that a while back. I forgot to mention it to ya'll. My eMail address is JFalasch@austin.rr.com (I got a cable modem -- yay!). I never got the source code. I would appreciate a look at it, if you can resend.

* * *

public boolean team_building_mode = true;

Okay, pull-foot-out-of-mouth-time.

I apologize for anything I said that may have been rude.

I'm sorry if I came across as 'accusing' ya'll of not being smart. It isn't that. It isn't ya'll, at all. It's the system you're using. You must understand this -- No one has *ever* been able to make that methodology work.

All this approach *ever* does is alienate the working programmers. It's the nature of the methodology.

* * *

All big design docs end up as merely a nice theory, one which bears only a passing resemblance to the end result. It's exactly like a General trying to design a detailed plan for a campaign up front. All plans go to hell in the face of the enemy, so he better expect to change almost every little detail in the plan. It's the nature of development.

So, from my viewpoint, ya'll are expressly forbidding such a 'growing' process. And as one of the 'troops', I perceive my General is refusing to change his plans in the face of my new information.

* * *

Please forgive me if this is un-cool. I don't want to burn any bridges here. I think ya'll are a great bunch of guys, and even when I wasn't planning on coding here anymore I kept reading the page because of the great exchange of ideas that goes on here. I could live with just going back to reading ya'lls insightful discussions, happily, if it would help to preserve any level of 'friendship' among us. Ya'll are very clever, very educated individuals with a high level of skill and experience in many diverse areas other than systems design.

But that is a big key, here, and the only reason I bring this up even now. You have to realize that you are allowing non-programmers to over-ride experienced programmers on architecture issues. No, not just me, either, at least two other programmers that I know of came here and voiced similar concerns about OOD, and both left, ignored.

I know you didn't mean to. You had good reasons to make the choices you did. And I know you feel this process has been interactive. But from my viewpoint, it has not been.

* * *

For my part, the only reason there have not been sparks (and I hope there aren't sparks now) is because as I (and, perhaps, the other coders that have come and gone) have been ignored at nearly every turn, I (we?) have just chosen to go away.

If this had been a project at work, you would not *believe* the sparks that would have flown. I have fought this battle before. I even had the audacity to write Object-oriented COBOL once, you see.

* * *

I did stop posting here for a few months. But I did (and would, as I said, no matter what) keep reading. Then one day I thought -- hey, what the heck, what if I show them a better model done by using an object design? Surely they'll see it's better, and will save them time? And you did see how much faster it worked. You do seem to think it's a better model. It would allow you to design and tweak the entire thing in a few months. The game data would use very little memory. All the models together coded up in this style would use at *most* 10 meg of memory, which is nothing, you'll have pictures bigger than that.

It would also run much faster. Especially if you use an observer pattern.

So, I hoped, surely they'll see now that object design is the way to go. But now I'm not sure how much help to ya'll I can be.

* * *

I now work for the 'Project Control' office at a major software company. I write tools to analyze and track all our development projects, and see many that still use the design-build-debug-release methodology. And I can share one truth with you -- the 'design' phase, no matter how detailed and exacting, is at best the first 1/5 of the time that project will take.

If you want this out fast, you must change methodologies. Otherwise, it will take forever. Because theory is always much easier than reality. All planning goes to hell in combat.

* * *

As it turns out, I am very certain that the general design philosophy of not doing things at the lowest level is horribly wrong, from a coding standpoint. The object-oriented approach of deconstructing complex systems into small components, if done right, is always smaller and faster than any other way of doing it.

So, for the moment, I will not lump the 4 'EG Attribute' objects ('culture', 'religion', 'TendencyValues' and 'Attributes') into one 'EG_Culture' object just yet. I can easily do so later, if and when performance becomes a problem (I believe it will not). But the game will work exactly as you describe in your model. The code will just be more flexible than that. It'll be like having a 4wd vehicle, even if you never intend to use 4wd. If you don't use it, you'll never know it's there.

* * *

Okay, It's Like This:
I'm an OO programmer. I write OO code -- it's what I do. If you need that, I can contribute.

The Object builder I wrote is a tool. The very best way for me to improve it now is for ya'll to monkey around with it and tell me "more mapsquares" or "this part stinks -- I want that to have this capability with this performance". Then I give that to you. Then you find other things I screwed up on. Then I fix/change that. Then we add 'turn' capability, to test your models. And then we have a finished game *with* scenario editor.

All in about 3 - 6 months, not counting grafix.

This game could be done by Xmas, assuming no major catastrophes in anyone's life. And this includes debugging, since people will have been banging around on the basic engine for 6 months by then.

That's how I build complex systems, anyway. It's what I get paid to do. We do it like you tell a sketch artist to draw a suspect: general, then specific.

"He had a round face. Close-set eyes. Closer. And a sharp nose." Etc.

It's the only way I can.

* * *

What I Need From Ya'll:
I need more specific feedback on that tool. Something like 'Add Provinces'. That was good, and helpful. You don't have to know how to exactly define all things contained in the province yet (Culture and Religion only hold their names, right now) -- in fact, the fastest way we'll find out what has to go in them is by trying to build one.

I will go finish adding Provinces now. For the moment, I am assuming that you create a civ, then 'edit' it's controlled mapsquares to group them into a 'province' under the control of that civ. I will code it that way. If it's wrong, happily tell me so, and I'll happily build something else.

Just don't tell me to stop.

If you want my help, it's the only way I can work. We work together, as a team.


* * *

P.S. -- are we still friends? I really do value that . . .

[Mark_Everson]

F_Smith:

First, and most importantly, IMO we are certainly still friends! You're just arguing strongly for what you think is right for the project, and I value that. Some things you said in the heat of debate were annoying, but just that... I'm sure I annoy you sometimes to

I just have literally a few minutes before I have to go to work, so here's a very limited take on your post.

I don't consider us as under the impression that the game is actually going to play as our initial design documents work. We indeed planned to check everything incrementally to see if it's fun and everything works right. We just haven't been able to keep up with the "release often" part of the mantra. Have you tried demo 4? It's up on the web page.

Anyway, because the coders weren't here at the start, our choices were:
1. Sit twiddling our thumbs and say gee I wish we had coders so we could do evolutionary development of our models.
Or
2. Start the design and wait for the coders to show up.

So we have a lot of models that have had a various amount of work already put into them, and I and many others at least think they are good enough for a first pass... Obviously since you are putting in a good chunk of work, you get votes too on modification of the system. But please let's not have the design discussions degenerate into "I, must do this" followed by "you must not do that, you must do it this way". And as I think we've agreed, if the system is as flexible as you want to make it, it should be able to handle something similar to Rodrigo's model fairly easily by putting in some specifics. And in those cases where you think there is a major flaw in the current system, let's discuss it.

Anyway, I am all for moving forward in the general direction you suggest. If you can send me and email address for I can send a 2 MB file, I will send you a mostly current version of the code ASAP. For now, I think building the government model in isolation, since much of it can be tested in isolation, is a great idea. I will help where I can.

Gotta run,

Mark

[F_Smith]

That's exactly what I'm saying -- it's time to give these models a 'first pass'.

For the 'Scenario Editor' Beast is indeed flexible enough to accomodate ya'lls current plans. Just assign all EGs of a particular name the same 'Religion', 'Culture', 'TV' and 'Attributes' (haven't added this last to the screen yet). Then they'll all share the same values for these, and use only one object of each for all of them. And you'll be able to build a govt that works exactly as ya'll have laid out, with or without a middle class. You can try it both ways, even, and run tests to see how it works out. It'll work exactly as ya'll want -- whatever ya'll want. I will not change any of ya'lls in-game models, just the structure in which the data is stored. For game purposes, things can work almost entirely at the province level, if that is what you prefer. And you don't even have to use my data model for your final game engine. This is just a scenario editor and tester.

But, as I said, there is one thing I absolutely will have to insist on, if I am going to be a part of this team -- constructive feedback of prototypes. I'm sorry, this is the only 'must', for me, but it's a big one.

I put in the ability to add 'territory' (mapsquares) to a Civ, last night. Tonight, I'll finish the 'Build Province' button, allowing you to group 'controlled' mapsquares into a Province. And maybe finish the 'load' button -- for anyone that does not know this, you can back-space over the html filename in the address bar to get the directory listing for the files. Save all those files to your local hard drive, and you can run this locally. It will load scenario files from your drive in this way, when I've finished that. To save what you've built in the Beast, just copy what comes up in the 'save' textarea (when you hit the 'save' button) to a text file.

Once the basic data-structure for the Beast is largely sketched out, (not fully filled in, that can wait), then I can begin to build in some simple turn logic and we can begin to see these ideas in motion, and evolve from there.

[F_Smith]

Lordy:

Actually, that case was almost exactly the same as this one.

I never tried to change ya'lls in-game design, I stuck completely within ya'lls requirements. But I had what I am sure is a better way to store the tech data in the game's data model, an approach that would have allowed for easy and quick implementation into the game world when the time came. Like this data model will be for these game models. The turn code will be amazingly fast and simple to write, just about writing itself, because the data model is simple and flexible.

Correct me if I'm wrong, but the implementation of the tech model has still not been dealt with. What is being coded, I believe, is a 'builder' like the Beast I'm putting together for these models (the one I'm begging ya'll to begin helping me with!!!). A tool for building 'tech' objects. Now actually using those objects to change the details of what goes on in the game's world/data will be the majority of work that goes into that model, I feel.

And that's exactly why I'm pushing the OO approach. It's been what, almost a year now? That sucker should have been built, debugged, improved, and finished by now. But the approach you chose is slow, and happens behind closed doors, away from any team input. The team still hasn't seen the first prototype.

And it's not the programmer's fault -- he didn't have a good OO code design to build from, so he's having to deal with a thousand little problems that he shouldn't have to. I feel that if ya'll had taken my advice, the entire tech system, from builder to implementation, would be finished, debugged and ready to put into a new release of Clash. That's what I'm trying to prove with the Beast.

I can give you a tech builder prototype for the tech objects in about a weekend, if ya'll want one, since that model is not anywhere near as complex as these. Or even likely work tech objects into the Beast (I think -- I'll have to give that some thought).

* * *

Did you get a chance to mess with the Beast at all?

Any requests, comments, flames? I need feedback! Someone, please? Anyone?
[This message has been edited by F_Smith (edited July 14, 2000).]

[Lord God Jinnai]

F_Smith:
-----
Do consider what appears to be happening here. A programmer (me) tried to provide feedback on how the program should be built. You are politely rejecting his advice, in effect telling me thank you but go away until you need my services. And the same thing happened when I tried to help with the 'Tech' model.
-----
Sorry you seemed put off with the tech model, its just that for that 1 model we actually had and still do someone who was willing to code it. Also the appoach we used was decided upon before you showed up and since he, Garth, said he didn't mind programing it like that (can't remember the method we chose instead of OO) and it did what we wanted and OO didn't seem to have any advantages why scrap a person who's already said he'd program for us and scrap something that works just fine already.

See me and rich decided we wanted to make the model user freindly for your average Joe to go make scerios by changing around application techs and things like that, but keep the fundimental engine the same. We had already done that and with just some formula tweeking left its all done. You just were trying to come and help with probably the only model close enough to what the finished product would be like, excepting changes based on the social model.

I mean i remember i asked you for some input on the wonders and acheivements model, though, but i guess it was and still is too early to worry about coding that.

So as far as the tech model goes, for u atleast, won't be OO coded so I don't know if you'll have trouble with that or not. I think one these 3 models get coded along with the new military one and tech model things will be much easier for me atleast in figuring out how the character and wonders and achievements model will work.

BTW, there is progress on coding the tech model, but its slow.

[alms66]

F_Smith

I didn't mean to sound like a jerk either.
The questions you were asking seemed like "model" questions, when in fact, they were "coding" questins. Sorry, my mistake.

[roquijad]

I stop reading for a weekend and see what happens: you all start throwing tomatoes to each other!!

Yes, this is like a battle with a general in the HQ having a "war design" that could go wrong in the field. Yes, feedback from the field commander is excellent and a good general can change plans along the battle.

You see, F_Smith, the same way you're used to work in a "create design AND code at the same time, continiously" fashion, I'm used and I was tought to behave as the general in the HQ. I come from a deeply scientific and mathematical field, where the model and its properties are way more important than the actual implementation. So when you, the field commander, start to change so easily parts of my "beutiful" mathematical creation, you're actually moving the ground where I'm standing on!

I, in general, agree with Mark's viewpoint of having at least a general and somewhat solid model before coding. But, regardless of this and my background in math modeling, I'm willing to make the effort and accept coding taking a greater role as a "design producer".

You go and code whatever you feel is right. I trust you won't go too far from the original model and you'll tell me if you intend to do something dramatically different for whatever reason. So go for it and show us all how your Object Oriented strategy can do whatever is needed for the social and govt models. I only ask you in return a soft and kind hand everytime you move the ground where I'm standing on, so I can dream of this ground as one that's solid enough to at least keep me standing.

Sincerly yours,
The general in the HQ.

[roquijad]

Now to specifics...

"1) I'm sorry if I scared you, what I suggested for an 'Ideology' would duplicate all the info in your previous 'Ideology', so nothing is lost. Only instead of a fixed list of 'SocialClasses' I suggested a collection of SocialClasses. It will work exactly the same, from your perspective. Yet it will allow much more enhancement, later. But it will work exactly as you laid out, for your scenario."

That's not what you said in the other thread. What's the difference between a fix list of social classes and a collection of them? The problem is not the number of classes itself or the staticness of their values, but the number of ideologies needed as a result of a greater number of socialclasses in order to have the minimum flavor for the game. If you change the list of classes for a collection of classes I don't see the problem solved.

Instead, I'm leaning to the idea of ideologies defined even in a more general sense... I still don't have it worked in my head, but if you give me a few days I think I can come up with something more flexible than our current ideologies. In terms of code, however, if you are going to code ideologies and the procedures related to them, I think you should first code them the way I originally planned so we can see at least if that approach works.
----------------

"2) I'm confused. I thought a 'Religion' was to hold certian 'Religious Doctrines', for use by the 'Religous Class'? And that they had to be seperate from the 'Majority Cultural Attributes'? If so, then this requires a seperate religion object, doesn't it?"

Yes, but my intention was to keep the number of independent religion objects low. So in the model there're religions as independent objects, but only for the most important religions (the Great Religions of the World). All the rest, that represent all sort of small cults or primitive religions that eventually will disappear and replaced by GRW were not supposed to be modeled as religion objects as well, because there're simply too many of them and because they don't have a great impact like GRW. If your problem is you don't know from where to read religious attributes to be used by the Religious Class, the answer is you have to read them from the cultural attributes of the ethnic group, because it's assumed in the model that religious attributes for this not modeled (primitive) religions match the cultural values. If your problem, on the other side, is you don't like this cheaper solution and you want ALL religions as independent objects, then, well....
--------------

"4) I definitely don't understand how you envision this game working. Not store any population info at the mapsquare level?"

As I told you, a msq should only have something like:
Roman Population: 150000
Celtic Pop: 400000
etc

The cultural info for each of them should be stored at the civ level, which is the same as saying all romans are equal within the civ, no matter the province or msq. Again, this is a solution to keep the model cheap. In this case not only storage resources, but processing time, because cultural values must evolve and doing so at the msq for each EG is IMO just too much taking into account that this is only one of many models.
-----------

On classes and EGs:
You're insisting in having each EG divided in classes, while my original idea was to have classes at the civ level for majorities. Can I know why you think your approach is better? What will we gain?

[F_Smith]

T_K:

No, not at all, you didn't come across badly. I think mainly we were just having a language barrier.

I tend to speak in 'programmers' terms sometimes, when I should perhaps use plain English.

Ya'll just put up with me, and we'll turn this game out yet!

[F_Smith]

Hi, Rodrigo:

Glad to have you back. I fully understand. The ground underneath you will always be moving from now on, tho, because we're going to be on the attack . . .

For working up the tool to turn your models into game code, (the 'scenario builder'), if you don't mind, let me worry about the clock cycles and memory usage. Ya'll just tell me what it should do, and what it needs to know.

Because, in my experience, the fastest, smallest way to do things is in an object-oriented fashion, storing info in the lowest level component possible.

That is, in fact, one of the greatest strengths of OO
design. All the matter in the known universe can be described in terms of 4 sub-atomic particles and 4 forces. The interactions of eight objects (or more precisely, 4 objects and 4 behaviors). Probably even simpler underneath, once we understand more!

If I'm wrong, it'll be obvious in about two weeks, and we can immediately change the data structure to enhance performance.

1 From a coding standpoint, one of the problems is indeed the number of Social Classes. Later users may want more, or different ones may be needed.

A scalable model has to be able to grow.

You'll never notice the difference. For now, there are only the classes you define, and you'll define the govt that deals with them.

2) The amount of data stored in those 'primitive religion' objects will be low. We can easily store hundreds.

But if you chose to make only one Primitive Religion, then that fits fine.

3) Since that approach doesn't really, in my experience, keep the model 'cheap', can we use one that doesn't force the designer to make all Romans the same (i.e. Pagan or Christian)? This approach would allow a religion to sweep a nation a square at a time (Christianity in the Roman Empire?).

Or, as above, you can only define one 'Roman' Culture, Religion, etc, and stick with that. In the current data model.

The 'Scenario Editor' should explain what I mean.

4) I gain speed and flexibility by storing class info at the lowest level. May I?

Again, as above, you can just chose to set all a given EG type's class info to the same values. If that works for you, no problem.

It will work as you want, I promise.

And, perhaps, better.

If you get a chance, please wander over to the Scenario Designer and see if it's heading in the right direction for your likes . . .

[roquijad]

As I said, code whatever you think is best. If you think computational resources are not a problem, let's take that and just test later. IMO it'd be great to have cultural things at the smallest level because it's more accurate to real life in that way. I chose the approach of "all romans are equal" only to save resources, but if we don't have too save...

As for socialClasses, I know scalability can be appreciated by some players (not me in particular, tho). I'm working on how to make this easier and have classes' behavior in a more general way which will help scalability.

However, my greatest worry at this time is that if you have lots of EG (at msq level) each with a set a classes behaving in their own way, then at some point aggregation of info must be made, for example to compute the outcomes of govt. It's IMO an overcomplicated thing to have hundreds of political actors doing their stuff at the govt, so aggregations are needed. Not only from the mathematical/computational point of view, but also because the player would be overwhelmed by this huge amount of actors and will hardly understand what's going on. If aggregations are needed, then I believe a lot is lost. The interesting behavior of the, FE, Warrior Class of the persian Ethnic Group in the msq X of province Y will be "lost" during aggregation, because it'll disappear when mixed with other agents. Then it's not so clear why to have at all that incredibly detailed level of modeling. Don't you think?

[F_Smith]

Rodrigo:

We can aggregate at any level, for playability. And additional depth of detial will be available. For later.

I think we're getting close to what you want.

[Mark_Everson]

Further questions...

Is it intended to really save game data in the XML format? Or is that just for building up models, and then you would use serialization to save the whole game efficiently when actually running it? If your answer is the former, and we have something like 5MB of game data, then the XML text file might be something like 30MB or so... to which I say Ugh

[F_Smith]

Hi, Mark:

I was assuming actual game saves would be serialized objects and object streams-- pure bytes.

For multiplayer, I was also assuming we wouldn't stream the entire GameData class, either, except when the game is loaded -- I was assuming that we'd stream the relevant collections in the GameData Class whenever they change. Like in the current architecture -- anywhere there's an 'update' called by a data object, replace that call to the local GUI component with a stream to all players of the changed object. It's by far the most efficient way, and the architecture is built to support it.

The XML, in my mind, was just one idea for a scenario design format. I'm familiar with XML, so it was fast to write a parser (not to mention, I need the practice parsing XML for work).

That part can easily be replaced by any other Scripting language ya'll invent/decide upon. Altho I don't see how we can find anything more powerful, or smaller, to be honest.

[Mark_Everson]

Yeah, your approach sounds reasonable. I still thing for multiplayer we are not going to be able to send all the game information over every turn. But since much of it only changes very gradually I think we can find creative ways to get around that.

[F_Smith]

Mark:

I agree with your thinking 100%, we can't send all the info across every turn. The MVC approach actually requires us to send only info that changes and then only when it changes, not necessarily during the processing and sending of all turn-order processing info.

We can even pre-compute a bunch of things, and send the results across before the 'turn' logic is ever run, when people are making their moves and decisions.

In the architecture, each data element fires off a 'notifyObservers(Object arg)' method every time it changes. This, in multiplayer, will fire off the stream of data to the players.

So a minimum is sent, whenever you best can fit it in.

[roquijad]

"We can aggregate at any level, for playability. And additional depth of detial will be available. For later."

yeah, but... what for? If things at the very detailed level will be unimportant for the player, having no real effect on the game, then why to have them at all?

[F_Smith]

rodrigo:

The details have a major impact on gameplay. The game will be played square by square. Everything will be tracked and played square-by-square. When playing the game, you'll make single-square decisions every turn -- should you take these squares, defend those squares, control/exploit that resource, that river, that good port, what-have-you.

But the player doesn't have to worry about any of those details, unless he wants to. He can watch that important port closely, and ignore the vast, lowly-populated highlands to his west. But if, for some reason, that area becomes important later (say, there's gold in them thar hills?), the player may suddenly find a need to pay attention on a much more detailed level.

It's all available.

The detail has to be there.