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: Marketing Xconq


"The other is some way of providing multiple unit
attacks and standard combat results tables based on
odds. Like three units against one getting 3-1 odds,
or whatever when other factors are computed, and a
"die roll" resolves the combat all at one time. The
current combat models do not lend themselves to doing
this well. So maybe with the newer Xconq programmers
on the list now, someone can think about addressing
these things."

I consider myself saavy enough to put together an
interesting combat model, but not so saavy as to be
able to write it and bug-check it within Xconq itself.
  Would it be feasible to create a Combat Model 2 that
affords the designer more control over combat
resolution?  You could set it up as follows:

Designer-Defined attributes for units.
In the same way that Combat Model 1 has Attack and
Defense for units, except the designer could define
new attributes and assign them to units.  This way
someone building an armored combat simulator could
define the attributes, "Lower Hull Front Armor",
"Upper Hull Front Armor", "Turret Armor", and so on,
while someone who was designing a sub game could
define, "Stealth", "ECM", "Depth" and so on.  The
attributes themselves do nothing, except what the
designer defines them to do in the next step:

Designer-Defined Combat Resolution.
With the ability to define various sets of attributes,
we could then use simple (And more accessible for
relative non-programmers such as myself) logic to
define how hits are determined and how damage is
applied.  The simplest way to do this is to have a
hardwired To-Hit system (Like Combat Model 1) and then
have an Attribute-To-Attack-Attribute table that
defines which attributes are used to plug into the
system, as well as an Attribute-To-Damage table that
does the same for damage.  With something like the
tank model, you could introduce a
Attribute-Chance-To-Defend table with which you could
simulate a little more complexity.  Even better would
be to allow the designer to punch up the algorythm
himself, but I think I remember bringing this up and
being told that we wanted to limit the amount of
complex code in .g files.

Boy, that went on forever, but I think it'd be worth
it.


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree


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