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

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