 |
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:13
|
|
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.
|
|
| |
|
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:13
|
|
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.
|
|
| |
|
|
|
Gary Thomas
|
 |
New Zealand
Mar 2001
time: 17:13
|
|
I just saw this thread, My XML format is different, so:
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
[This message has been edited by Gary Thomas (edited April 15, 2001).]
[This message has been edited by Gary Thomas (edited April 15, 2001).]
|
|
| |
|
| |
|
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:13
|
|
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.
|
|
| |
|
|
|
Gary Thomas
|
|
New Zealand
Mar 2001
time: 17:13
|
|
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.
Cheers
[This message has been edited by Gary Thomas (edited April 16, 2001).]
|
|
| |
|
| |
|
| |
|
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:13
|
|
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
|
 |
Canton, MI
Jan 1970
time: 00:13
|
|
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!
|
|
| |
|
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:13
|
|
The code I sent Gary fights a la civ, which means when you enter a square, fight occurs, with the drawbacks you gave. For testing, it should be enough I believe, though you might have 2 armies remaining in the same square and they won't fight till someone else comes in with such a system...
The code is made so you give orders to armies, the orders specify a target square, and MoveManager manages all the armies at once, so it would be possible to put a end-of-turn button now. The button just has to tell the MoveManager which armies it manages, but that should be trivial from the Civ info and the Map/Gamedata, so we could do it that way now (provided we have the button). The problem would be the lack of feedback (the arrows you suggested) to the player.
I elaborate on your arrows idea. That seems a good way to show information, particularly if we can change a few things on the arrows, like color, arrow shape/icon to express different orders, like Fortify (go and fortify in that square), attack, support, scout, spy, whatever.
|
|
| |
|
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:13
|
|
Writing this here not to clutter the movement thread, though it may be remotely related.
As FSmith said somewhere, we could have a notion of mount for units, so you can have chariots on horses, or donkeys, and cavalry on horses or elephants. I think that could be interesting to specify this because horses/donkeys/elephants are resources, so you can't build cavalry in America until horses have been imported by Europeans.
That could also affect movement, since we could use the same cavalry unit, but the "mount" would change speed and defence, maybe assault. I am not sure whether it is better to have a cavalry element with available mounts horse or elephant, or two elements: cavalry and elephants.
What I think is important is that there be a requirement for building cavalry, that horses be available. That may be a purely tech requirement so that you can't learn horseback riding without horses.
|
|
| |
|
|
|
Gary Thomas
|
|
New Zealand
Mar 2001
time: 17:13
|
|
The current military model has pretty much everything as some variant of "Army". The interactions between Army, Element, Unit, TaskForce and TempTaskForce is quite labyrinthine and difficult to manage.
My instinct (not for D5 though) is to separate the physical object from the command structure. As it stands, it is not possible to have a command structure covering more than a single square - a TaskForce is the only structure, but it is treated as a physical object. This has caused me to have a lot of trouble differentiating the various pieces of information. A lot of coding effort goes into making sure that each component is located in the right square, for example.
In my view, the physical location of a unit, like its personnel and hardware, is a physical variable.
The way I would design the model is to have physical elements (Element class), which define the fighting characteristics. The elements are grouped into physical units (Unit class) which, in turn, hold the location information.
Then, units can be grouped into commands, in a variety of ways. However, the location of the unit remains with the unit.
On the other hand, the civilization that the unit belongs to is part of the command structure. Units did swap civilizations. Their allegiance is a political matter, not a physical one.
A unit, on its own, will never do anything until it is made part of a command.
In particular (as far as OO coding is concerned) a unit is not a command, and a command is not a unit. However they can both have a contained object called (say) CombatData, which covers such matters as attack strength (and the myriad other factors involved).
Whether command levels have differentiated levels (brigade, division, army, army group, front) is another issue. I would be inclined to do it that way, simply in order to make it easier for the player to grasp what is going on.
The advantage I see in this system is that it clearly separates the physical and the social factors.
Cheers
|
|
| |
All times are GMT. The time now is 05:13.
Apolyton Time is 00:13. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|
06-04-2001 00:16
.
|