This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
RE: Battle Evaluator 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 01:51:53 -0800
- Subject: RE: Battle Evaluator API
Brandon J. Van Every
>
> Perhaps you could decide on a minimal spec of what a "battle
> evaluator" API would need to be. A plug-in interface.
And fired by a late night craving for Mr. Pibb, I'll take a stab at what
kind of a KISS API it would need to be.
You would want Unit Definitions, which would be arbitrarily long lists
of TAGS and VALUES. You can do this readily enough in Python.
You would want Terrain Definitions, which would be similar.
You'd want Environmental Definitions, which would be similar. Things
like whether there's currently smoke on the battlefield, or artillery
supporting from other hexes, or whatever. Sort of a game-specific
catch-all of stuff that isn't obviously a Unit or Terrain. Maybe you'd
pass the length of time to have the battle, the number of "rounds" of
battle, or some such through this mechanism.
You'd pass these Unit, Terrain, and Environmental definitions to a
script as input. As output, it would pass a (probably lesser) number of
things back. Or else vomit. "I don't understand your bloody TAGS" or
"Your VALUES suck!"
You'd probably want to use some OO inheritance methods to implement your
various Battle Evaluators. This isn't an ironclad sureity, as perhaps
you want things to behave differently than the inheritance hierarchy
allows for. No problemo; write your own class in that case. But often,
in practice, people would just inherit stuff and make minor changes to
someone else's Battle Evaluator.
A "definitely OO" interpreted language such as Python would be
appropriate for this.
Cheers, www.indiegamedesign.com
Brandon Van Every Seattle, WA
20% of the world is real.
80% is gobbledygook we make up inside our own heads.