Military Model IV

[LDiCesare]

I know unexpected collisions can happen, and I am comfortable with the idea (I did read the discussions). My question is just about the user interface feed-back. Will not seeing your army "step back" be disturbing? That was the question. We can just wait and see what testers will say.

[Mark_Everson]

Sorry, didn't mean to question your familiarity with the topic. I think player will see whatever the TF bumped into there also (or that a battle happened and we won) and so any jarring effect should be very fleeting.

On a related topic, I also think if there's enough time we should play out the ticks while the turn is being cranked etc over about 5 sec or so. (Somebody suggested it, may even have been you...) I think this will be both entertaining, and help to replace some of the adrenaline rush lost in not seeing immediate results of one's attack.

[LDiCesare]

Here is an xml example of the currently existing units and elements. Its about 110 lines long.
I show it without any extra explanations so that you all see whether you manage to understand it or not.
The main issues I have, along with some explanations, are listed after the xml.

<Root>
<Element>
Warrior null 20 20 2.5
<Attribute name ="Distance" value ="5"/>
<Attribute name ="Armor" value ="2"/>
<Attribute name ="Health" value ="1"/>
<Attribute name ="Morale" value ="8"/>
<Attribute name ="Mobility" value ="4"/>
<Attribute name ="Order" value ="Attack"/>
<Attribute name ="Order" value ="Garrison"/>
<Cost>0 6 1 0.03 1</Cost>
</Element>

<Element>
HeavySpear Warrior 75 20
<Attribute name ="Distance" value ="0"/>
<Attribute name ="Mobility" value ="2"/>
<Attribute name ="Morale" value ="10"/>
<Cost>0 24 1 0.03 4</Cost>
</Element>

<Element>
LightSpear HeavySpear 70
<Attribute name ="Mobility" value ="3"/>
<Attribute name ="Armor" value ="1"/>
<Cost>0 18 1 0.03 3</Cost>
</Element>

<Element>
Skirmisher Warrior 25 30 3.5
<Attribute name ="Mobility" value ="5"/>
<Attribute name ="Distance" value ="30"/>
<Attribute name ="Armor" value ="1"/>
<Attribute name ="Order" value ="Skirmish"/>
<Cost>0 12 1 0.03 2</Cost>
</Element>

<Element>
Charger Warrior 80 20 3.5
<Attribute name ="Distance" value ="20"/>
<Attribute name ="Mobility" value ="6"/>
<Attribute name ="Morale" value ="11"/>
<Cost>4 20 1 0.03 5</Cost>
</Element>

<Element>
CavalrySkirmisher Skirmisher 40 40 5
<Attribute name ="Mobility" value ="7"/>
<Attribute name ="Distance" value ="20"/>
<Attribute name ="Morale" value ="9"/>
<Cost>3 15 1 0.03 4</Cost>
</Element>

<Element>
Trireme
<Attribute name ="Attack" value ="10"/>
<Attribute name ="Defense" value ="10"/>
<Attribute name ="Movement" value ="4"/>
<Attribute name ="Mobility" value ="4"/>
<Attribute name ="Armor" value ="1"/>
<Attribute name ="Health" value ="1"/>
<Attribute name ="Morale" value ="9"/>
<Attribute name ="Ground" value ="false"/>
<Attribute name ="Sea" value ="true"/>
<Attribute name ="BoardSpace" value ="1"/>
<Attribute name ="Orders" value ="Attack"/>
<Attribute name ="Orders" value ="Garrison"/>
<Cost>0 24 1 0.03 4</Cost>
</Element>

<Element>
Chariot Charger 100 30 5
<Attribute name ="Distance" value ="40"/>
<Attribute name ="Armor" value ="1"/>
<Cost>5 25 1 0.03 5.5</Cost>
</Element>

<Element>
Archer Warrior 10
<Attribute name ="Distance" value ="30"/>
<Attribute name ="Armor" value ="1"/>
<Attribute name ="Morale" value ="9"/>
<Attribute name ="Order" value ="Support"/>
<!-- Could raise decay to more than 0.03 since need lots of training ? -->
<Cost>0 12 1 0.03 2.5</Cost>
</Element>

<Element>
Catapult Archer 5 10
<Attribute name ="Mobility" value ="1"/>
<Attribute name ="Distance" value ="90"/>
<Attribute name ="Morale" value ="7"/>
<Cost>0 35 1 0.03 4</Cost>
</Element>

<Unit> WarriorBand Warrior 9 Skirmisher 1 </Unit>

<Unit> Phalanx HeavySpear 5 LightSpear 3 Skirmisher 2 </Unit>

<Unit name = "Light Cavalry"> Charger 3 CavalrySkirmisher 6 </Unit>

<Unit> Horde Warrior 8 CavalrySkirmisher 2 </Unit>

<Unit> Trireme Trireme 10 </Unit>

<Unit> Catapult Catapult 1O </Unit>

<Unit> Archers Archer 8 Skirmisher 2 </Unit>

<Unit> Chariots Chariot 10 </Unit>

</Root>

Explanations:
Units should be straightforward: name, name of element and number. You can put the name in the unit tag if it contains whitespaces.
Elements have a name, prototype (all attributes are valuated to those of the prototype unless overridden - this allows saving around 150 lines in the above example), then attack defense, movement, and a bunch of attributes which should explain themselves.
Cost is the cost of the element. Values are food, production and services, decay rate and last cost of services to increase training by 1.
Root is pretty useless but without it I have a parse error (malformed xml stuff or something) so I put a wrapping tag.

Current code status:
I use a parser (xerces/sax) which interprets correctly the units and a small part of the elements (name, attack, defense, movement). I haven't implemented the attributes tags and cost tag yet but that should be easy.

Issues:

Attack/Defense/Movement:
If you look at the trireme element example, you can see I put attack, defense and movement as attributes. I think this makes it easier to understand the file.
Do you think it should always be that way or should I use the figures following name prototype for other values (attack defense armor for instance)? Otherwise put, do you prefer the trireme or the warrior declaration?

Orders:
By default the only order allowed to elements is sentry. I could probably add garrison. Settlers/Diplomats/Caravans/Software programmer units wouldn't attack so I didn't put attack as a default. Is it better to have a list of orders (one per tag) or one tag with the whole list?

Values:
You can look at the values I put in, (Paul in particular) and see if they make sense. I copied most from the values found above in this thread, but the last elements I made up.

Other tags:
I plan to add other tags, in particular Civ, in order to restrict some civs (e.g. barbarians) from having units, and to allow civs to change their unit values (name in particular).
An attribute for the image associated to the unit could be good here too (the name of the bitmap for instance).

File location:
We should start thinking about where will these resource files go. I suppose Clash will be installed in its own directory, but we must name and share a subdirectory and filenames for the text/xml resource files.

[Mark_Everson]

Hi Laurent:

I prefer the Trireme-style specs, and think order names should be all in one tag. But I am not radically in favor of either alternative in both cases...

[Gary Thomas]

I just saw this thread, My XML format is different, so:

For the example

quote: &ltElement&gt Warrior null 20 20 2.5 &ltAttribute name ="Distance" value ="5"/&gt &ltAttribute name ="Armor" value ="2"/&gt &ltAttribute name ="Health" value ="1"/&gt &ltAttribute name ="Morale" value ="8"/&gt &ltAttribute name ="Mobility" value ="4"/&gt &ltAttribute name ="Order" value ="Attack"/&gt &ltAttribute name ="Order" value ="Garrison"/&gt &ltCost&gt0 6 1 0.03 1&lt/Cost&gt &lt/Element&gt

my version is (assuming "Element" doesn't mean XML element, but means military element):

&ltelement&gt
  &ltname&gtWarrior&lt/name&gt
  &ltdescription&gtbasic low level (unimproved) fighter&lt/description&gt
                                       I would add the above line, too
  ... don't know what these are: null 20 20 2.5 should be explicitly listed
  &ltdistance&gt5&lt/distance&gt
  &ltarmor&gt2&lt/armor&gt             armour?
  &lthealth&gt1&lt/health&gt
  &ltmorale&gt8&lt/morale&gt
  &ltmobility&gt4&lt/mobility&gt
  &ltorder&gtattack&lt/order&gt
  &ltorder&gtgarrison&lt/order&gt
  &ltcost&gt0 6 1 0.03 1&lt/cost&gt   should be split up explicitly,
              if they are different resources, it is probably sufficient
              to name the rsources "cost" being implicit
  alternatively (and preferred, for reasons to do with the way XML
                is developing):
  &ltcost&gt
    &lttype 1&gt0&lt/type 1&gt
    &lttype 2&gt6&lt/type 1&gt
    &lttype 3&gt1&lt/type 1&gt
    &lttype 4&gt0.03&lt/type 1&gt
    &lttype 5&gt1&lt/type 1&gt
  &lt/cost&gt
&lt/element&gt

This format is usually shorter than the equivalent attribute system. It is certainly much simpler.

Use of lower case tags avoids people having to wonder what the capitalization pattern is, or indeed, whether capitalization is used.

Everything should be explicit, otherwise some future coder is going to be uncertain about the order of values: is it "0 6 1 0.03 1" or "0 6 0.03 1 1"? I have spent too many hundreds of hours puzzling over just this sort of thing to relish it.

Defaults are easily incorporated by including as aan XML element.

Using attributes gets into a much trickier aspect of SAX (though, of course it can be done) without any evident advantage. And, generally, it is harder to remember the XML format for attributes than the above simple form.

I also feel that indenting is important, and have incorporated it in my code, so any output XML will be properly indented.

Please understand I am not being critical, just trying to be helpful, and maybe avoid problems down the line.

Laurent: the code I sent you assumes this format. I do have a version that copes with attributes, but I don't really recommend it.

Cheers

[This message has been edited by Gary Thomas (edited April 15, 2001).]
[This message has been edited by Gary Thomas (edited April 15, 2001).]

[Gary Thomas]

Editing XML stuff is no fun, so here is a correction to my last post (rather than editing it and losing all the &lt and &gt)

quote: Defaults are easily incorporated by including as aan XML element.

should be:

Defaults are easily incorporated by including as a &ltdefault&gt XML element.

Cheers

[This message has been edited by Gary Thomas (edited April 15, 2001).]

[LDiCesare]

Thanks for the comments.
I'll do something like what Gary proposes, with a list for orders, so warrior would be:
<Element>
<Name>Warrior</Name>
<Default>null</Default>
<Attack>20</Attack>
<Defense>20</Defense>
<Movement>2.5</Movement>
<Distance>5</Distance>
<Armor>2</Armor>
<Health>1</Health>
<Morale>8</Morale>
<Mobility>4</Mobility>
<Order>Attack,Garrison</Order>
<Cost>
<Food>0</Food>
<Production>6</Production>
<Services>1</Services>
<Decay>0.03</Decay>
<Training>1</Training>
</Cost>
</Element>
(Here default is clearly useless)
As for case, I prefer to have an initial in upper case but that can be a problem. I'd like to make tags case insensitive but I think it costs a lot in lookup of interesting tags unless I implement a case-insensitive hashtable for strings.

[Mark_Everson]

Hi guys:

We need to think about what info about battles the player will typically want to see for demo 5. What limited set of information would be most useful? Currently Laurent has a detailed diagonstic output to a file. That will only work for people running the demo as an application afaik.

I think we need to see at a minimum:

Force composition at beginning, and end.

Who won each of the phases, and by how much.

Who was left in posession of the field.

I'm sure there's more, but this is just meant to get the topic rolling. For a start we could just stick the info in a text window that the player can look at if desired, and ignore if not .

[LDiCesare]

quote: Originally posted by Mark_Everson on 04-16-2001 11:58 AM Currently Laurent has a detailed diagonstic output to a file. That will only work for people running the demo as an application afaik.

Actually, I use an observer pattern so any UI can be put on top of that. I just spat output into a file because it's the easiest thing to browse when you want to scan the output of 1000 fights of 10 units.

I think I can provide 2 levels of detail: the detailed output and a minimal output, which could both be observed (detailed probably only for debugging the model, minimal for useful information).

On "minimal" output:
I can list starting units with total health and final units with their health. I don't think we want element stats to be displayed. I also can say who won (keep control of the square).

BTW I realiwe I don't have geared anything to decide who controls a square. How do you decide a square becomes yours (by military means)? It'd be a different order from "move".

[Gary Thomas]

quote: As for case, I prefer to have an initial in upper case but that can be a problem. I'd like to make tags case insensitive but I think it costs a lot in lookup of interesting tags unless I implement a case-insensitive hashtable for strings.

There are a number of arguments for lower case tags, none overwhelmingly convincing, but they have a cumulative effect:

1. Most tags are ordinary words, and people don't write (at least they don't in English): "What is your Name?"

2. Capitalized tags give messy appearance to the XML. Compare: &ltName&gtWarrior&lt/Name&gt with &ltname&gtWarrior&lt/name&gt

3. Reserving the capitals for the important data (in this case Warrior) makes the substantive data stand out, with the importance it deserves.

4. There are possible confusions about how to capitalize some tags, &ltstartlevel&gt for example.

5. This is a rather subtle point. There are two distinct approaches to XML. Some implementations deliberately incorporate data into the tags. One case I know of is in the book industry, where all the publishers that the firm deals with are tags, so &ltOReilly&gt, &ltSAMS&gt. The reason for this is that it prevents a new or mis-spelled publisher from creeping into the system. This is prefectly valid, and, since these tags are effectively data, rather than field flags, they should be capitalized as required. Again, lower case tags indicate the effective status of the other tags.

Cheers

[This message has been edited by Gary Thomas (edited April 16, 2001).]

[Mark_Everson]

quote: Originally posted by LDiCesare on 04-16-2001 04:31 PM BTW I realiwe I don't have geared anything to decide who controls a square. How do you decide a square becomes yours (by military means)? It'd be a different order from "move".

This can be complicated. But for now I think we can use this simple rule:

I control a square if I did the last turn,
Unless there are enemy troops in that square that are unopposed,
in which case control passes to the enemy.

Does this sound reasonable? Its what I used in demo 4.

In reality, in a 'final' model, before the modern age especially, territory can change hands in big chunks if the local army is beaten. Its not necessary to militarily occupy all the squares... Also if you leave a square, if the people don't like you they may try to seize back local control, or join back with whomever they were a part of before you took over. Hopefully when we get the Riots model going we'll see that behavior exhibited properly.

[Mark_Everson]

Laurent:

One thing I want to set up soon is to have the player be able to move an army or armies into a square with a defender in it, and hit 'f' (for fight) and have the fight run. I think you are most of the way there, if not there already. I just wanted to let you know that's what I'm hoping to do. I haven't looked at the code yet... but it seems I can just use EncounterManager. The only thing I'm worried about is giving the player's forces the correct orders. Would it be sensible to give every moving TF 'attack' orders for now? (since we don't yet have a gui set up for orders?) And the player could also set this 'odds to attack' number like I had in d4. I think you said you implemented that, but I forgot where it is... Alternatively we could just let the player set TF orders using keypresses if you can think of a simple way to do it. What do you think?

[Lord God Jinnai]

quote: Originally posted by Mark_Everson on 04-23-2001 03:05 PM This can be complicated. But for now I think we can use this simple rule: I control a square if I did the last turn, Unless there are enemy troops in that square that are unopposed, in which case control passes to the enemy. Does this sound reasonable? Its what I used in demo 4.

I think i tried posting this before, but this is only good if the player wants to take 1 square per turn and not try and move his units in 3-4 or whatnot if he can.

[LDiCesare]

Mark, the best way is to give Attack orders to all armies. If you don't want them to attack if there are enemies there, you can use Garrison but usually Attack will do it.
The chance to engage I put in and I removes because it didn't fit with Paul's model (until you have scouted the opponent, you cannot know whether or not to flee). I have put it back at home but can't mail it now due to mail problems . You'll get it soon. I use the number of attacks that are given by Krenske's model to compute the ratio, and give 50%chance of managing flight for the attackers, 100% for the defenders. It'd be better if it used the output of the manoeuvre phase. It seems to work correctly (better than comparing att strength/defense strength). It also has the slight good side effect of not taking into account the experience or training of opposing armies, which you won't know until you engage them.
I think the only order you can change the values of is Attack order, which starts at 1.6. Garrison starts at 2.0 for not fleeing, sentry at 1.5. If you need APIs to change any of them, ask.

LGJ, I did it the way Mark explains. I can take control of squares you go through but that can give weird results I think, like if civ1 crosses a square and then civ2, the square will change in one turn from civ0 to civ1 to civ2... Squares with railroads would tend to change owner a lot.
[This message has been edited by LDiCesare (edited May 01, 2001).]

[Mark_Everson]

Hi Laurent:

Actually I was hoping to have you implement this with some background info on where things are that I will send you soon. I have to go out of town this weekend, and won't have time to do much before then, so I'm going to be useless for about a week...

I have sent you the info by email, and if you can do this, great! If not, I'll do it in a week or so.

I'll respond to the other issues posted above when I get a chance...



[This message has been edited by Mark_Everson (edited May 01, 2001).]