From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16243 invoked by alias); 3 Jul 2004 23:55:09 -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 16234 invoked from network); 3 Jul 2004 23:55:08 -0000 Received: from unknown (HELO conure.mail.pas.earthlink.net) (207.217.120.54) by sourceware.org with SMTP; 3 Jul 2004 23:55:08 -0000 Received: from skeeter.psp.pas.earthlink.net ([207.217.78.186]) by conure.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1BguLb-0002qV-00 for xconq7@sources.redhat.com; Sat, 03 Jul 2004 16:55:07 -0700 Message-ID: <17030786.1088898907645.JavaMail.root@skeeter.psp.pas.earthlink.net> Date: Sun, 04 Jul 2004 00:05:00 -0000 From: Ramsey Reply-To: Ramsey To: xconq7@sources.redhat.com Subject: xConq alternate combat engine project Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004/txt/msg00625.txt.bz2 Hello everyone. 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. We have looked at xConq's code and played the scenarios that came with the latest distribution. We were impressed by the game's ability to model game systems like those used in Empire, Panzer General and Civilisation. Combat seems to be resolved as a situation where a single unit fires onto or attacts an enemy stack. The combat algorithm calculates the results based on the strengths and attributes of the opposing units and the results are applied. 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. Many war games have a two-tiered system; the most popular are perhaps the Total War series, where the armies on the strategic map battle it out on a 3D field. Others are the tactical card system used by Avalon Hill's boardgame "We The People" and the simple "battle plan" system used by the Advanced Risk game in the Hasboro's CDRom version of "Risk". Another system would make the user the combat resolution function, having them simply type the results back into the program (for officiated games or play-by-mail). 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). What we would like to ask is: 1. Is there any logical way to do this without changing xConq's code? 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. 3. We are having trouble compiling the program on Redhat Fedora. We are users on the system (don't have root) and our compilation errors match exactly those encountered by Lincoln Peters when he tried to compile it on Debian: http://sources.redhat.com/ml/xconq7/2003/msg00966.html Would the solution be functionally different? Thank you for your time. 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. Sincerely, -Damian Ramsey, Chris Wood