Re: xConq alternate combat engine project

[Eric McDonald <mcdonald@phy.cmich.edu>]

Ramsey wrote:

>              I'm part of a small team (two people) of undergraduate students at Portland State University. 
>We are looking into the possibility of building a pathway for alternate combat engines into xConq. 

Xconq already has two combat models. Model 0 resolves combat in such a 
way that each round must be explictly initiated, and involves only a 
single attack (with possibility of counterattack); combat hits are 
determined by tables of probabilities ('hit-chance', 'protection', 
etc...). Model 1 combat, which is used in the Advances and Civ2 games, 
loops until the combat is resolved, and relies on relative strength and 
defense values.

Following the example of Model 1 combat, you could conceivably add a 
"Model 2" combat system.

> What we would like to explore is the ability to substitute in other functions or other programs for the built-in 
> combat resolution system. They would be functionally equivalent, taking in the same arguments and returning compatible 
> return values.

Calling another set of functions for a new combat model shouldn't be 
that big of a deal. Talking to an external process would require that 
some IPC stuff be added to Xconq, or that the existing TCP/IP 
infrastructure be expanded.

> In the case of xConq, a separate interactive combat engine would be best for modeling conflicts where relatively 
> small forces (closely clustered in a small number of armies) manoeuver around a large area and engage in a small 
> number of decisive battles (i.e. the ancien regime conflicts of the 17th-18th century). Because these battles 
> were so important, it would be good to have a system to model them without bringing the strategic map down to the 
> scale in which it would allow tactical manoeuver (making it huge and unplayable).

Adding multiple scales is certainly something I have had in the back of 
my mind as something to do in the long term. However, to do so, would 
require significant work. If you guys are planning on doing this as a 
semester project or something, it would probably prove to be too much 
work in the given time frame. Even if you are doing this independently 
of any scholastic endeavor, you would probably want to familiarize 
yourself with Xconq better by working on a number of smaller things 
first, and maybe writing a game module or two....

>               What we would like to ask is:
> 1. Is there any logical way to do this without changing xConq's code?

You would have to write new code to add a new combat model to Xconq.
After we get the 7.5 release out the door some day, I hope to modularize 
  the combat system to the point that various custom models can be made 
just by toggling some booleans in GDL. But, we are definitely not there yet.

> 2. If not, where might be a good fissure point in xConq's action/combat system to interface a "black-box" combat 
> resolution system? Hopefully as early as possible after combat being joined.

I would suggest that you take a look at the various Model 0 and Model 1 
functions in 'kernel/combat.c'. Particularly, pay attention to how Model 
1 combat was spliced in.

>                Our idea, if this functionality is not already built into the system, is to add a GDL tag 
> that would turn on this extension and give the system the name and/or location of the combat resolution 
> system to be used.

There is already a 'combat-model' GDL tag. My recommendation would be to 
proceed along the lines of adding a new combat model.

Hope this information is of some help,
    Eric