public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: "Erik Jessen" <ejessen@adelphia.net>
To: "'Brandon J. Van Every'" <vanevery@indiegamedesign.com>,
	"'xconq'" <xconq7@sources.redhat.com>
Subject: RE: Battle Evaluator API
Date: Tue, 18 Nov 2003 12:13:00 -0000	[thread overview]
Message-ID: <001a01c3adc9$6e130d80$6401a8c0@Win2k> (raw)
In-Reply-To: <OOEALCJCKEBJBIJHCNJDGEOHGLAB.vanevery@indiegamedesign.com>

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.



  reply	other threads:[~2003-11-18 11:37 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-17  7:15 OSX Crash on Build Dialog Elijah Meeks
2003-11-17 14:09 ` Hans Ronne
2003-11-17 19:06   ` Eric McDonald
2003-11-17 23:25   ` Marketing Xconq Elijah Meeks
2003-11-18  2:14     ` Eric McDonald
2003-11-18  3:11       ` Elijah Meeks
2003-11-18  3:46         ` Eric McDonald
2003-11-18  4:26           ` Elijah Meeks
2003-11-18 19:34             ` Lincoln Peters
2003-11-18  8:59       ` Andreas Bringedal
2003-11-18  9:41         ` Battle Evaluator API Brandon J. Van Every
2003-11-18  9:55           ` Brandon J. Van Every
2003-11-18 12:13             ` Erik Jessen [this message]
2003-11-18 12:53               ` One Hex Combat Resolution API Brandon J. Van Every
2003-11-18 13:11                 ` Brandon J. Van Every
2003-11-18 18:41     ` New combat model: d20? (was: Re: Marketing Xconq) Lincoln Peters
2003-11-18 20:17       ` Elijah Meeks

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='001a01c3adc9$6e130d80$6401a8c0@Win2k' \
    --to=ejessen@adelphia.net \
    --cc=vanevery@indiegamedesign.com \
    --cc=xconq7@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).