This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: xConq alternate combat engine project


Hi all. I am the other person in this group along with Damian. I'm not
at school right now so I can't get the information yet on the make and
congif. From what happened on my computer the configure did succeed.
Well at least it didn't give us any errors. And Damian is right that the
errors given by make were virtually the same if not exactly the same to
those in that link. What exact information do you want us to post about
it to clear up the problem? Anything outputted to the terminal
after we type the command?

Let me clear up a bit what our idea is for the combat engine, especially
since I am the one who has sort of been delegated to work on designing
this thing. Using the example of the Prussian campaign with the general
/leader container units, the idea would be to go to this external combat
system when a fight takes place. I have worked on some text based wargames
before where we developed rules and procedures to deal with lines of units
opposite enemy lines of units. While it would be cool to have it shrink
to a small hex grid for the tactical combat, I am perfectly willing to
enable this tactical engine just using a popup window with a text
interface.

The basic plan would be to have three parts of the army. A center or
vanguard and two wings. You would then place the units in the container
as you want within the three areas. Then there would be a limited option
of tactics that could be carried out. For example a simple one would be
have your center defend and overpower your wings to destroy the enemy
wings. Then when their wings are destroyed you crush their center, like
Cannae for example. With my knowledge of c and programming in it I am
fairly sure I can work out a text based system to do this. As something
else to look at, both Damian and me are working on a graphics course
this term as well. An idea would be to make a very basic open gl
interface.

>From what you have said the most complicated thing would seem to be
figuring out the networking aspect of it, and doing things like the
functions that check if a function is progressing. To simplify the
above process, only a limited amount of features would be added to
the tac engine at first. And for added simplicity I'd say to make
it only workable with multiplayer, since then we don't have to deal
with the AI and how it would handle such a system.

Anyways I'll take your advice and try to figure out how we can create
a model 2 and see how the program works with model 0 and 1. What I have
found tricky is not the stuff within combat, but what I want to know
is what is calling combat, which I haven't been able to find yet. Then
again I've not looked that hard as of yet.

On Sat, 3 Jul 2004, Eric McDonald wrote:

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]