RE: Battle Evaluator API

["Erik Jessen" <ejessen at adelphia dot net>]

Brandon,
I don't know what Tags and Values are in Python; it sounds like fields &
values in database tools I've used.

Rather than pass lots of parameters to the BE, I'd think I'd pass
- a list of involved units
- type of action taking place

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.

This would be an excellent use of a scripted language - even if it did
nothing else, but paw through a database loaded using GDL, it would
permit a much more flexible range of combat (and make the C code much
simpler, as the C code wouldn't need to support all possible ranges of
events for all games - each game would have a relatively-simple BE for
it.).

Erik

-----Original Message-----
From: xconq7-owner@sources.redhat.com
[mailto:xconq7-owner@sources.redhat.com] On Behalf Of Brandon J. Van
Every
Sent: Tuesday, November 18, 2003 1:52 AM
To: xconq
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.