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 01:43:00 -0000	[thread overview]
Message-ID: <1093309008.2792.30314.camel@localhost> (raw)
In-Reply-To: <41283FA9.7000708@phy.cmich.edu>

On Sat, 2004-08-21 at 23:39, Eric McDonald wrote:
> I think one problem with cow patties is that ideally one would like them 
> to be actionless, and hence they could not be selected as active units. 
> So, having a transport offer to pay for everything would not do much 
> good for items that cannot even be selected as actors.
> 
> A dedicated pickup/get command like most good dungeon games have would 
> be nice.

In many respects, these "cow patty" units could be treated like
facilities, so if someone implemented an easy way to pick up *and drop*
such units, you might have something useful.

On the other hand, the AI's understanding of facilities is a solid
"brain-dead"; I honestly think that the AI will need to be radically
re-engineered before it will ever truly understand facilities.

> 
> Another possibility would be to get Xconq's control range stuff working 
> (if it's not already; I haven't experimented with it, but there does 
> appear to be some support for it in the code). Then set the control 
> range of regular units to be something like 1 or 2 cells for item units. 
> Thus the item units would only be able to act (i.e., move) in the 
> presence of a regular unit.

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.

(This module might make a good addition to the library, but its premise
*is* rather twisted.)

> > I'd like to introduce three item types in Opal: 
> > Weapon, Armor and Gear.  
> 
> I'm looking at Weapons and Armor for Wreckreation. Armor could already 
> be done since the 'protection' (should really be called 'vulnerability') 
> table already exists.

I tried to implement armor in a game module I wrote a while ago (the
game module was never interesting enough to add to the library).  I
discovered that I could not provide more than one kind or armor without
running into the following dilemma about how the armor "occupies" the
knight:

1. If I use unit-capacity-x, I can prevent a knight from wearing two
suits of plate armor, but I can't prevent a knight from wearing a suit
of chainmail over a suit of full plate.  (If I was to allow a knight to
wear two suits of armor simultaneously, I'd want to find a way to adjust
their ACP's and hit chances accordingly.)

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).

> 
> > So far, so good (Heck, only six new
> > units, I'll never reach 1000 like this).  
> 
> 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!

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

A quarrel is quickly settled when deserted by one party; there is no battle
unless there be two.  -- Seneca

  reply	other threads:[~2004-08-24  0:55 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 [this message]
2004-08-24  2:38         ` Eric McDonald
2004-08-24  2:51           ` Lincoln Peters
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=1093309008.2792.30314.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).