From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7882 invoked by alias); 4 Jul 2004 03:37:58 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 7872 invoked from network); 4 Jul 2004 03:37:57 -0000 Received: from unknown (HELO lead.cat.pdx.edu) (131.252.208.91) by sourceware.org with SMTP; 4 Jul 2004 03:37:57 -0000 Received: from sirius.cs.pdx.edu (root@sirius.cs.pdx.edu [131.252.208.57]) by lead.cat.pdx.edu (8.12.10/8.12.10) with ESMTP id i643bfcA000247 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 3 Jul 2004 20:37:41 -0700 (PDT) Received: from sirius.cs.pdx.edu (cwood@localhost [127.0.0.1]) by sirius.cs.pdx.edu (8.12.10/8.12.10) with ESMTP id i643bfLJ023368 for ; Sat, 3 Jul 2004 20:37:41 -0700 (PDT) Received: from localhost (cwood@localhost) by sirius.cs.pdx.edu (8.12.10/8.12.10/Submit) with ESMTP id i643beDe023365 for ; Sat, 3 Jul 2004 20:37:41 -0700 (PDT) Date: Sun, 04 Jul 2004 03:39:00 -0000 From: Christopher Wood To: xconq7@sources.redhat.com Subject: Re: xConq alternate combat engine project In-Reply-To: <40E74E3B.7070207@phy.cmich.edu> Message-ID: References: <17030786.1088898907645.JavaMail.root@skeeter.psp.pas.earthlink.net> <40E74E3B.7070207@phy.cmich.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-SW-Source: 2004/txt/msg00636.txt.bz2 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 >