This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
RE: One Hex Combat Resolution API
- From: "Brandon J. Van Every" <vanevery at indiegamedesign dot com>
- To: "xconq" <xconq7 at sources dot redhat dot com>
- Date: Tue, 18 Nov 2003 04:47:08 -0800
- Subject: RE: One Hex Combat Resolution API
From: Erik Jessen [mailto:ejessen@adelphia.net]
>
> I don't know what Tags and Values are in Python; it sounds
> like fields & values in database tools I've used.
I don't mean it as some Python term. I mean it as a bonehead "any old
programming language" term. With the important provisio that order is
not important. Python would be able to work with such constructs
natively.
> Rather than pass lots of parameters to the BE, I'd think I'd pass
> - a list of involved units
In my terms, a list of Unit Definitions.
> - type of action taking place
In my terms, a list of Environment Definitions.
> The BE should be able to collect all the data it needs from the units
> (location, status, etc.); from units locations, it could determine
> weather conditions, range, etc.
Ranged combat is beyond the scope of what I imagined for a BE. I
imagine a BE as simply a one hex combat system, with something occupying
a hex and something else trying to enter the hex. Ranged combat would
be implemented by a projectile entering a hex, with some Environmental
Definitions stated for line of sight, range from target source,
intervening obstructions, or whatever. I don't think BEs should be in
the business of complicated map traversals. I think they should be in
the business of processing fairly simple, closed form results. That
way, game designers can easily change them without scratching their
heads too much.
"One Hex Combat Resolution" is a more accurate term for what I have in
mind, so that's the term I'll use from now on. OHCR.
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
Taking risk where others will not.