From: Lincoln Peters <sampln@sbcglobal.net>
To: Hans Ronne <hronne@comhem.se>
Cc: Stan Shebs <shebs@apple.com>, Xconq list <xconq7@sources.redhat.com>
Subject: Re: Reduced Visibility Table?
Date: Tue, 02 Dec 2003 00:54:00 -0000 [thread overview]
Message-ID: <1070325128.378.40.camel@odysseus> (raw)
In-Reply-To: <l03130302bbf180b6678d@[212.181.162.155]>
My two cents follows:
On Mon, 2003-12-01 at 15:42, Hans Ronne wrote:
> >Heh, it's very messy coding to have a unit be there and not there at the
> >same time.
> >AI, UI, plan, and task code should only ever iterate over the stack of
> >images,
> >never over the real units. Action prep sometimes needs to know,
> >sometimes not,
> >which is part of the messiness.
>
> Actually, this raises a philosophical question. Should a ZOC be ignored
> just because the unit is invisible? I'm not sure. Think about a black hole
> making its presence felt way before it is seen. Or infantry hidden in the
> woods preventing you from moving forward.
That should probably be left to the game designer. In the case of
infantry hidden in the woods, the units entering the cell would know
that something is out there simply because it would be shooting at
them. However, in the case of an unseen stealth bomber, it seems
reasonable that no presence should be felt, and only the stealth bomber
(assuming it can see whatever is entering its cell) could initiate
combat.
>
> A related problem is posed by the user area layer that is used by the
> advanced unit code. You may find that you are unable to use a certain cell
> because another advanced unit is using it, even though the latter unit is
> invisible to you.
You might not be able to see the unit that is using the cell, but
shouldn't you be able to see that the cell is used and act accordingly?
There would have to be *something* tangible there in order for the other
unit to use the cell.
--
Lincoln Peters <sampln@sbcglobal.net>
next prev parent reply other threads:[~2003-12-02 0:30 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-01 22:35 Elijah Meeks
2003-12-01 23:18 ` Hans Ronne
2003-12-02 1:09 ` Elijah Meeks
2003-12-02 4:02 ` Hans Ronne
2003-12-01 23:23 ` Bruno Boettcher
2003-12-01 23:27 ` Lincoln Peters
2003-12-01 23:43 ` Stan Shebs
2003-12-02 0:30 ` Hans Ronne
2003-12-02 0:54 ` Lincoln Peters [this message]
2003-12-02 0:58 ` Hans Ronne
2003-12-02 4:46 ` Eric McDonald
2003-12-02 4:04 ` Eric McDonald
2003-12-02 4:16 ` Eric McDonald
2003-12-02 20:56 ` Hans Ronne
2003-12-03 2:41 ` Eric McDonald
2003-12-03 3:04 ` Lincoln Peters
2003-12-03 21:13 ` Eric McDonald
2003-12-01 23:32 ` Hans Ronne
2003-12-02 15:04 ` Bruno Boettcher
2003-12-02 19:57 ` Emmanuel Fritsch
2003-12-03 2:12 ` Hans Ronne
2003-12-03 2:22 ` 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=1070325128.378.40.camel@odysseus \
--to=sampln@sbcglobal.net \
--cc=hronne@comhem.se \
--cc=shebs@apple.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).