public inbox for xconq7@sourceware.org
 help / color / mirror / Atom feed
From: Lincoln Peters <sampln@sbcglobal.net>
To: Eric McDonald <mcdonald@phy.cmich.edu>
Cc: Xconq list <xconq7@sources.redhat.com>
Subject: Re: Item Units
Date: Tue, 24 Aug 2004 02:51:00 -0000	[thread overview]
Message-ID: <1093315174.2792.30463.camel@localhost> (raw)
In-Reply-To: <412AA34A.6030408@phy.cmich.edu>

On Mon, 2004-08-23 at 19:09, Eric McDonald wrote:
> Lincoln Peters wrote:
> 
> > I experimented with control-range in a game module involving
> > necromancers and undead armies.  The idea was that undead units would be
> > helpless if they were more than 16 cells away from the necromancer,
> > except for vampires and liches, which can function normally up to 24
> > cells away and can relay orders.
> > 
> > It seemed to work decently, but it was around the time that the
> > pathfinding code was radically re-engineered (and later radically
> > un-re-engineered), so I ran into a bunch of problems that may have been
> > totally unrelated to the control code and eventually lost interest in
> > it.  Maybe I should take another look at it.
> 
> Yes. I bet it will turn up some bugs. Depends on how well the 
> actor/agent (unit/unit2) separation has been honored and enforced in the 
> kernel action code.... Actors are units which have ACP's and are doing 
> the controlling, whereas agents are being controlled and using the 
> actor's ACP's. Or, at least, that is my understanding of the code.

The way it seemed to be working was that agents had their own ACP's, but
they stopped working if they moved too far away from the actor.  I
didn't notice anything about agents using an actor's ACP's, although
that wouldn't have made sense for this game.

One thing that surprised me was that if an agent went out of range, it
became not just impossible to make it act, it became impossible to
select it at all!  I don't know if this is how it's supposed to work.

> 
> Encumberment should be able to be modelled with the 'occupant-adds-acp' 
> table. I am thinking that I forgot to test it with negative values, but 
> did deliberately set it up allowing values between TABLO (-32768) and 
> TABHI (32767), and so it should be able to be used to model negative 
> effects on ACP as well as positive ones.

True, but I had hoped that I could prevent a knight from wearing two
suits of armor at all, thus avoiding this whole issue.  Although I might
want to set up a game to allow knights in light armor to move faster
than knights in heavy armor...

Maybe I've got another idea to experiment with in 'knights.g' (or
whatever I end up calling it once it's finished).

> 
> > 2. If I use generic capacity, I can ensure that a knight can wear one
> > and only one suit of armor, but I lose the ability to do anything
> > similar with other items (different kinds of shields, helmets, magic
> > rings...).  I would have to make various kinds of armor, shields, rings,
> > etc. fit in generic capacity; therefore a knight could wear one suit of
> > plate armor normally, and one on his finger in place of a ring of
> > protection (now *that's* a silly mental image).
> 
> Don't forget the 'occupant-max' table. You can set the total capacity 
> high, and then limit certain types using 'occupant-max'.

But can you limit groups of units, so that a knight can only wear one
suit of armor even if I define multiple kinds of armor?

> 
> One exercise you can do is:
> Sit down and draw a square, say a 5x5 square, representing the unit's 
> total capacity. Then, place, say, a 3x3 square inside the larger square, 
> and let it represent the "armor slot". Then, lay out other squares and 
> rectangles representing other contents the unit may have. You can, of 
> course, use rectangles for your container instead of squares.
> 
> After this, you have a crude visualization of your space consumption, 
> and can fill out the various tables accordingly.

That had not occurred to me.  However, I notice one possible exploit in
this solution:

Suppose that a knight's generic capacity is 24.  A suit of armor is size
13, a shield is size 6, and a helmet is size 5.  If a knight has no
armor, he can carry 4 shields instead!


Perhaps I could prevent this if unit capacity could be represented in
two or more dimensions, but it would still be awkward and prone to
error.

> 
> >>Yeah, no kidding. And I thought it was 10000 in order to win the magic 
> >>donut.
> > 
> > I guess I need to get back to work on knights.g!
> 
> I thought it was 'red-wizard.g' now. But, whatever it is called, I think 
> it did have promise last time I looked at it.

I've been re-naming it every time I decide to radically re-engineer it,
so that (hopefully) I can re-trace my steps if some weird bug crops up. 
The current incarnation is called 'knightmare.g'.

---
Lincoln Peters
<sampln@sbcglobal.net>

Keep your eyes wide open before marriage, half shut afterwards.
		-- Benjamin Franklin

  reply	other threads:[~2004-08-24  2:38 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-20 16:22 Three thoughts mskala
2004-08-20 18:34 ` Eric McDonald
2004-08-20 21:17   ` Andreas Bringedal
2004-08-20 21:28     ` Eric McDonald
2004-08-20 23:57       ` Andreas Bringedal
2004-08-21  1:21         ` Eric McDonald
2004-08-21  4:35           ` Jim Kingdon
2004-08-21 20:38           ` Jim Kingdon
2004-08-20 22:03     ` Elijah Meeks
2004-08-20 23:27       ` Eric McDonald
2004-08-21  1:17         ` mskala
2004-08-21  2:31           ` Eric McDonald
2004-08-21  4:33             ` mskala
2004-08-22  3:09 ` Hans Ronne
2004-08-22  6:38   ` Item Units Elijah Meeks
2004-08-22  9:37     ` Eric McDonald
2004-08-24  1:43       ` Lincoln Peters
2004-08-24  2:38         ` Eric McDonald
2004-08-24  2:51           ` Lincoln Peters [this message]
2004-08-24  3:32             ` Eric McDonald
2004-08-22 14:00   ` Three thoughts mskala
2004-08-22 18:56     ` Hans Ronne
2004-08-22 19:16       ` Lincoln Peters
2004-08-23  4:31         ` Jim Kingdon
2004-08-23 13:04           ` Elijah Meeks
2004-08-24 18:07             ` Eric McDonald
2004-08-24 20:59               ` Elijah Meeks
2004-08-25  0:54                 ` Unit-Image Bug Elijah Meeks
2004-08-25  4:58                   ` Eric McDonald
2004-08-23 16:48         ` Three thoughts Eric McDonald
2004-08-24  0:55           ` Lincoln Peters
2004-08-24  2:09             ` Eric McDonald
2004-08-24  3:02               ` Lincoln Peters
2004-08-24 18:12                 ` Eric McDonald
2004-08-25  5:34                   ` Jim Kingdon
2004-08-25 17:16                     ` Lincoln Peters
2004-08-25 22:09                       ` Jim Kingdon
2004-08-26  2:15                         ` Eric McDonald
2004-08-26  6:17                           ` Jim Kingdon
2004-08-26 19:12                             ` Eric McDonald
2004-08-26 22:08                               ` CXP??? Elijah Meeks
2004-08-27  1:50                                 ` CXP??? Lincoln Peters
2004-08-27  5:10                                 ` CXP??? Eric McDonald

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=1093315174.2792.30463.camel@localhost \
    --to=sampln@sbcglobal.net \
    --cc=mcdonald@phy.cmich.edu \
    --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).