11-01-2001 01:12									#1
	Military OO Design Avatar Enlargement: We've got the solution

This is a first shot at a design for coding the military model. It interfaces with stuff like user interface, AI, and economics-infrastructure for supporting units, tech for efficiency of units... The interfacing part is not detailed at all yet.

Main proposed Classes (or interfaces):
Army
Unit
UnitArchetype
Resource *(not military specific)
UnitBuilder (or something from infrastructure model)
TaskForce
General (links to AI, user interface)
Observable *

* not specific to military, and can be coded otherwise if anyone has better ideas or this rebukes too many people.
UnitOrder
MovementManager
EncounterManager
Strategies (links to AI)

Description:

Army is a class or interface from which Unit and TaskForce derive. It has the civ, movement and combat infos common to both subclasses. It also has current orders and current General info.

Unit is the class describing one unit. It contains data like current health, owner task force, experience, morale, a link to the UnitArchetype that it is a kind of, an identifier (number in civ?), a name (may be used as identifier if fast enough). May also have a base square/city information.

UnitArchetype is a class of units. Examples are trireme, phalanx, tank...
It contains data like name of unit for a given civ, movement points, combat power (attack, defense, ranged attack, scouting?...). Should be created from a resource object. There is probably one UnitArchetype per unit type and per civ. This allows to have civ-specific name and movement/combat strength based on tech computed in one place.

Resource should be an object managing the various figures used in the game.
It can be used to create the appropriate UnitArchetype objects based on a file like in civ2 for instance. Its being a class allows switching file based to hard coded resources easily. The scope of such a class is much broader than military. It has to do with macro language.

UnitBuilder is the link with infrastructure. Somehow it decides what kind of army can be built based on tech, square, existing infrastructure (barracks...) and builds them.

TaskForce is a group of armies. It links them, computes move rate and power.

General is a class in charge of an Army (or several). It gives them their orders. There are two kinds of Generals: one is the player, the other the AI. AI generals probably take their orders from other AIs. This is not discussed here (not yet). The two main subclasses are thus one AI taking orders from another, and one Player, which observes certain events. See Observable below.

Observable: Actually this is rather an event bus: Events are typically emitted thru the user interface, but they can be emitted by the AI too. I probably need a EventBus class somewhere that can emit events based on strings, so General would interpret the events it is interested in. This is based on the Observer/Observable pattern (thus the name of this section), but different from standard java implementation: I'd like to be able to send new events without having to change the code of the observed object. Thus an event bus managing events with string source = "Player"/"AI1"/..., string eventClass = "name of the class" would allow to send events and observe them without coupling military to UI: The PlayerGeneral would say it is interested in "Player"+"ArmyOrder" for instance, and the UI could send these events through the event bus.

UnitOrder is the current orders given to an army. Orders can be attack, garrison, move, maybe also scout, pillage and others... Orders are per TaskForce but a unit inside a TaskForce could have separate orders.

MovementManager manages the movement of the armies, coordinating each civ moves and calling EncounterManager when they meet.

EncounterManager manages the meeting of armies. Might also manage what happens on entering enemy squares or special events, based on strategy. For instance MovementManager moves army X into square Y. X's UnitOrder happens to be pillage so EncounterManager is called and X begins pillaging Y. Probably some observers are needed here.

Strategies are what should be evaluated by the AI. It is a goal like attacking this or that square, which can be modelled as a UnitOrder, but additionnally it includes info on who to send there, who's already there and what payoff can be expected if we do that now. It also includes how much we want to reach this goal, and how far we are from it/what we need to achieve it.

	11-01-2001 05:18									#2
	Help yourself to an AD-FREE life

Hi Laurent:

It looks good in general to me .

I have only a few minor points.

I am not sure if EncounterManager can do the job you envision in the current system. Because movement is simultaneous just because two opposing units end up in a square does not necessarily mean an encounter is valid. That's because the enemy unit that is in a square could be in the process of moving out, so in the real world the units would never have been even close to each other. So after each tick of movement is complete (tell me if you haven't seen about ticks yet) I think we need either to sweep over the units or the map to see if an encounter happens. Perhaps there is a clever way around that by making EncounterManager smarter.

My other point is that you seem to be worrying about optimization already. I don't think Anything a unit or TF does other than AI could possibly be a limit in game speed. That's because there will be relatively few TFs on the board at any time. Maybe a few thousand is the maximum we would expect. They should be compared with many thousands of MapSquares, where lots of things happening each turn in the Economy and other models. So I think, in accord with our new extreme programming philosophy, it is best not to worry about optimization at this point. When the game gets far along we can worry about that where it is demonstrated that optimization is needed.

And finally, Unit, for flexible design, needs to have some objects pertaining to manpower, weapons (quality etc.), and perhaps some other things in it. For instance, it's possible we will want to keep track of the ethnicity or social class of the manpower in a unit, so it should have some kind of population-type object similar to EthnicGroup.

It's great that you gotten this off the ground!

[This message has been edited by Mark_Everson (edited January 10, 2001).]

	13-01-2001 13:48									#3
	Support Apolyton, buy Civilization III: Complete

I have questions about how to model a unit controller:
A Unit has one civ, but then it may be controlled by a province or may be a rebel during riots...
Basically, Units are created by a UnitBuilder, which may be civ/province/... and probably also implements the General interface.
When units meet, they can fight or cooperate or whatever. If fight is based on their belonging to different civs, I 'd have trouble managing armed revolutions. So basically, a unit would be loyal to its General rather than its civ. This can allow for civil wars quite easily, but units may have some trouble fighting together if they are not under the same General.

	13-01-2001 19:10									#4
	Full PM-box? Change here!

IMO each UnitBuilder should have a list of who it is friendly towards, neutral towards, and hostile to using some sort of uniform scale. The TF can then query its builder's list to see what the status is for anyone they should encounter. That seems to me to solve the issue you raise. This list should probably be in an interface so that you could have a list just for rebels that have no state associated...

So if the US were in a feudal government, California's units (all with civ US, but Calif. as builder/controller) would know that they are friendly with everyone in the US except Nevada, to which they are hostile... So the civ flag doesn't matter in this case. If Los Angeles is in revolt against California then whatever units under LA control would look to LA's list to see who they would fight or not.

Does this sound reasonable?

	12-02-2001 02:15									#5
	Tired of ads?

I have coded basic fighting stuff.
I added to the TaskForce / Unit pair a new thing, Units class, thus the military model TaskForce, Unit and Element are all represented.
I need to put a minimum of move code before it looks like something real (terrain checks, no teleport).
The scouting phase, deploy phase and assault phase are separated but the first ones just do nothing for the moment. I'll integrate Krenske's equations sometime this month.
For the building of units, units are described by UnitsArchetype objects which refer to a list of UnitArchetype objects.
The costs and abilities of armies are defined from these archetype classes.
I would like to read those abilities from a text file so that it be easier to twitch. Has anyone done some parse stuff yet?

	12-02-2001 02:26									#6
	Support Apolyton, buy Civilization: The Boardgame

Hi Laurent, sounds great! F_Smith has some parsing code for XML, and is using that for ini files. I think its already in the package you have. He will probably have more examples done shortly.

	13-02-2001 00:02									#7
	Support Apolyton, buy GURPS/ Alpha Centauri

Here is an example grammar I would use.
It may not be XML, anyone knows how to write DTDs?
If anyone has got a full-fledged XML-parser or knows how to use javacc (I used to when it was named Jakc or jacc but that's far away... ) please tell me, otherwise I'll StringTokenize the stuff and that will be painful.

The example:

< !-- comments here -->

<Element> Phalanx null 1 1 1 </Element>

<Unit> Phalanx Phalanx 10 </Unit>

<Element> Engineer Phalanx <Civ>Barbarian none !</Civ> <Attribute name="attack" value = "0"/> <Attribute name="orders" value="Fortify"> </Element>

<Unit> Legion <Civ>Japanese Samurai</Civ> Phalanx 9 Engineer 1 </Unit>

mainEntry: | elementEntry mainEntry | unitEntry mainEntry | comment mainEntry

   comment: < !-- []* -->

   unitEntry:  id civ (id number)+ attributes* 

           // Could have attributes like deployment, dispersal. Not sure.

   elementEntry:  id id civ combatInfo fancyInfo 

           // First id is unit name, second is unit prototype: all

	   // info not precised here is taken from prototype. "null" 

	   // means there is no prototype and all info must be provided.

   id: [a-zA-Z.]+

   number: [0-9]*(.[0-9]*[1-9])?

   allow: "!" |    // ! means forbidden: e.g. a unit is forbidden for one civ

   civ: |  id id allow  civ

        // Fist id is civ name, second id is element alternate name

   combatInfo: number number  number attribute*  ranges

            // Attack Defense Move

       | attribute* ranges

       // Attributes would include:

       // element type, move, mobility, defense, base supply cost,

       // production cost, personnel cost, rebuild supply , armour,

       // element strength, assault (aka attack), bomb, bomb range,

       // orders

   attribute: 

       |      

   ranges:

     *

   fancyInfo: |  attribute* 

       // Attributes would include : icon, sound, sprites ...

 

	13-02-2001 01:00									#8
	Support Apolyton, buy GURPS/ Alpha Centauri

Laurent:

You really need to contact F_Smith to see what he has set up for XML first. I don't know what he's done, and I don't know much about it anyway...

[edit] I said something dumb, and now its not here!

See ya'

-Mark
[This message has been edited by Mark_Everson (edited February 12, 2001).]

	13-02-2001 04:22									#9
	Browse Apolyton AD-FREE

Hi:

Good deal, it looks like you're very far along!

The 'example' above is more along the lines of what I think we should do. That's straight XML, I believe. I have partial XML parsing code in the GameFileIO class, altho it's not full or complete.

The 'grammer' you post seems somewhat difficult to read. Am I wrong in thinking that you can easily put that in XML format, with tags, to make it easier for the scenario designer to read at a glance?

That is the only real reason for us to load these things from a text file, I believe. So scenario designers can quickly and easily copy/paste/alter parts of a scenario with little special knowledge. They will largely not be programmers, so will not be use to a code-type of syntax.

Otherwise, we could just stream objects, and save data in binary format, coming out of the scenario editor . . .

	06-03-2001 02:03									#11
	Full PM-box? Change here!

In demo4 code, the unit movement logic (which I'll reuse) was in a MapCanvas class. Where will we put this code in demo5?
I am afraid of listening to the keyboard directly because we might end up with lots of listeners and two of them using the same keystroke for different things.
Do we need a common dispatcher? It'd lie nicely in the controller package.
I try to put most of the combat model in the code now but it will soon be done and thus time to tackle the UI a little.