Right now econ only handles building of a unit with some predetermined amount of training. In the future we plan to have
1. stockpiling of weapons (and trading of weapons as such)
2. demobilizing of troops (weapons kept maintained, optional training too)
3. purchasing of training for already-built units
I think small modifications of these can allow the player to do virtually anything they want.

Since I think we need to have separate training costs supported anyway, my best guess is that we should build new units at the "stick weapon in guys hands" level. Then you can optionally train them or not. So by that definition the current econ code has too much services cost in the build...
So the player will have 1. Build Legion, 2. train legion (perhaps done automatically unless overridden), 3. optionally invest in more than the usual training.

As to pay, that will have motivational effects, and perhaps quality effects (recruiting better people). But I haven't thought much along these lines, so comments are welcome.

Does what I've said seem adequate for now? If not, let me know where you want things more refined.

Morale/Orders:

I just want to say that giving demoralized or unmotivated troops a "fight to death" order will not have Any significant effect, so that needs to be included in any model changes.

Mercs: Yes we'll have them, and they have been discussed from time to time. Try searching on "mercenaries" maybe. Agree with Paul's basic take on it.

Experience/Training:

The outline you guys are working on sounds good!

How could this be handled???? We have a assault value for naval vessels that can be used but I think it could be used in different ways. You could order your task force to go for the capture or the sinking, The default being the capture until a certain tech application like advanced wooden hull form (allowing Mass gun ports). At this point we swap to a default of sink for naval task forces. A force ordered to sink the enemy that finishes off the enemy at assault ranges will 70% of the time sink the enemy, Due to putting ruddy huge holes in the sides of them. A force ordered to capture would have a 70% capture rate for ships finished off at assault range. Note some ancient navies did not have the necessary manpower to support additional captured vessels and so they set out to sink the opposition.
Also certain weapon types on board could alter these percentages somewhat. If a ship uses Greek Fire then the capture chance should be halved, If the ship has castle construction then the capture has a better chance. As well at time of construction a ship could have a additional marine contingent added for extra assault firepower in capture mode for a cost. How do these ideas sound??

At present though we are looking mainly at land combat.

As to low morale/demoralised troops receiving stand and die orders they can work if you are willing to be sufficiently ruthless. Ie. The commissars are only 100m behind you and have already shot sergi, petr and ivan for doubting you can stop the yankees/germans/french/poles/swedes. The mongols also used chinese assault troops to take chinese cities, how did they guarantee these low morale troops would do the job? They brought their families along behind and simply executed some and said the rest will die unless you take that city, repeat with the new cities population. This is a major reason for the 20% population drop in china over the decade long mongol invasion. Of course international diplomacy and civilian morale should suffer in these situations.

Of course a civilised leader would not use these techniques but could still issue the orders. A 50% bonus to something small is just 50% bigger than small so it will probably have a lower effect then giving the same order to a force with huge morale.

Radical idea, Governemnts with fanatical tendancies could buy morale in a similar way to training through indoctrination techniques etc. A complete fanatical society could buy massive morale over time where as other societies would not start with high morale but their forces could gain morale through wins etc.

quote: Originally posted by Mark_Everson on 04-04-2001 07:27 PM Laurent, there's a thing we need to discuss about the TF Movement code: TF move orders shouldn't actually move the TF... but they should move it in graphics so the player can see what has moved. Do you have a way in mind to handle this? I think something like moving the TF to "targetSquare" in graphics with an arrow that starts at "currentSquare" or whatever would look good and give the player enough info. Sorry I didn't bring this up sooner, but I forgot it was an unresolved issue.

Currently, orders and move are implemented this way:
Unit receives an order to do something in square x (attack, garrison,...).
A MovementManager manages ticks in the turn (probably we have one tick in a turn until we get all tested). Each army then moves to its target square if it is not already there, and complains if it is too far (but goes there anyway for the moment).
I could call army.notifyObservers("NewOrder") when a new order is received. The UI could observe its TFs and then ask them where they want to go and paint them there although they didn't move yet. (Must be methods like getCurrentOrder().getTargetSquare() to do that).

quote: Now when we get a path algorithm and units move by themselves rather than teleport, what will happen? (New turn) Player can move whatever they like, the above visual applies with a perk like getCurrentOrder(). getSquareYouWillHaveReachedAtEndOfTurn()) (I'll find a better method name when I code it). (End turn). Actual move resolves. The unit may just run into another one before completion of the move. That means it may fight in a square between the one it started the turn in and the one it was depicted in. Could this happen? It would be somewhat startling, I'm afraid...

That's not a bug its a Feature . First of all, we have thought of this and discussed it before you came to the project. The land forces combat movement rates are set up so that in a turn you can only go about 2 squares, meaning your plans can only be dirupted a certain amount without a chance to react. (200km per month is about all that can be managed for a combat advance except for extreme cases in the real world.)

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

For the example

quote: <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>

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

code:

---

<element>
  <name>Warrior</name>
  <description>basic low level (unimproved) fighter</description>
                                       I would add the above line, too
  ... don't know what these are: null 20 20 2.5 should be explicitly listed
  <distance>5</distance>
  <armor>2</armor>             armour?
  <health>1</health>
  <morale>8</morale>
  <mobility>4</mobility>
  <order>attack</order>
  <order>garrison</order>
  <cost>0 6 1 0.03 1</cost>   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):
  <cost>
    <type 1>0</type 1>
    <type 2>6</type 1>
    <type 3>1</type 1>
    <type 4>0.03</type 1>
    <type 5>1</type 1>
  </cost>
</element>

---

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

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

should be:

Defaults are easily incorporated by including as a <default> XML element.

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.

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

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: <Name>Warrior</Name> with <name>Warrior</name>

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, <startlevel> 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 <OReilly>, <SAMS>. 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.

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.

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

quote: Originally posted by LDiCesare on 05-09-2001 09:26 AM Yes, it'd be nice to attack from 2 squares. How would you see that from a UI point of view, though?

My thought was to use arrows. At the beginning of the turn there are just TFs on the map. When I move a TF the TF icon moves, but it leaves a light arrow showing where it started, and each step (square) on its plotted move. I think we need something like this at least as an option to remind the player that they are Planning moves, but the moves may never even happen due to circumstances like the army was attacked on route. So if such arrows are used you can show a multi-square attack simply.

quote: To me the easiest is to have all armies move around, then a finish moving button, and here we go 10 fights in a row. That means you have to be careful in case a fight turns out badly since you cannot re-attack in the same turn. Is that acceptable?

Yes that is the basic plan. However reinforcements could show up in later ticks to reivigorate a previously losing fight.

quote: Is there a dusty thread where the UI of the player turn sequence was discussed (I have no access to the search button right now )? It may be what you intended from the beginning, but I read the F as one fight.

thread with UI... no, I don't recall one, we never got that far. Yes I meant the F as one fight, but just for d5. That's because it is not a real game yet. Just a 'fight tester' on the military side. I'll check out what you did when I get the chance. Its probably good enough.

quote: So this sums up to: Do you want to be able to fight and then move in the same turn, in which case you'd hit "fight" 3 or 4 times in a turn before being done, or do you want to say "done moving" and let war happen a little everywhere?

I had meant the former, but the latter is fine if that's the way you did it because that is the way it will really be in the future anyway!

If so, there is plenty of room for opposing armies in the same square who not only don't fight, but don't know the opposition is there.

On this scale, Greece is 4 squares tall by three wide, consisting only of sea and mountains.