Let there be light

4 views
Skip to first unread message

Marnix van den Bos

unread,
May 31, 1994, 9:41:09 AM5/31/94
to
In article <2sf2s5$i...@lyra.csx.cam.ac.uk>,
Gareth Rees <gd...@cl.cam.ac.uk> wrote:
>Marnix van den Bos writes:
>> I have a question about light sources: How do I determine whether or not
>> there is (indirect) light in a location or object?
>
[algorithm and remarks deleted]
>--
>Gareth Rees
>
>
In my opinion, I still have a problem here, Gareth. Namely with the
position of the viewer. I think an object can be in light according to
your algorithm, with the character not being able to see it. Suppose
I am in a closed box and outside the box is an object. Both box and
object are in a location which is lit. I will not be able to see the
object, although IsLit(object) will return true. Now, if someone else
enters the location, he will be able to see the object. I think what I
am really looking for is a function like IsVisibleTo(object, viewer),
that tells me whether viewer is able to see object. If I misinterpreted
your algorithm, please let me know.

Marnix.

C
I have a


Gareth Rees

unread,
May 31, 1994, 6:17:41 AM5/31/94
to
Marnix van den Bos writes:
> I have a question about light sources: How do I determine whether or not
> there is (indirect) light in a location or object?

The function IsLit(X) below is an algorithm to determine if object X is
in light or darkness (I posted something like this in Inform source code
a week or so ago). It assumes that objects are related to each other in
the standard way, with each object having a single parent (the
container/room/etc in which it appears) and containers/rooms/etc have
lists of children.

IsLit(X)
{ Let Y be the parent of X (if any).
If X has a parent, and X is 'transparent' (i.e. the children of X are
visible to the siblings of X; in general this will be the case
unless X is an opaque container of some sort), then light will
penetrate into X, so return IsLit(Y).
Otherwise X is the outermost container surrounding the object we
started with whose children are visible to that object, so if X is
in light then so is the object we started with.
Return HasLightSource(X).
}

HasLightSource(X)
{ For each child Y of X:
{ If Y is a light source then return TRUE.
Otherwise, if Y has no children or if Y is an opaque container such
as a closed box then return FALSE.
Otherwise, if HasLightSource(Y) returns TRUE then return TRUE.
}
If this point is reached, no child of X was or contained a light source.
So return FALSE.
}

If your game has objects with multiple parents then you'll need to think
a little more carefully about the semantics of light than this. One
possibility would be to decide that an object was in light if any of its
parents was in light; another one would be to consider only those
parents of the object that were chidren of the location of the object
whose point of view we are considering (typically the player). Neither
of these seems entirely correct and this suggests that multiply-parented
objects shouldn't have children, a sentiment with which in these days of
family values and back to basics one can only concur. (-8

--
Gareth Rees


Gareth Rees

unread,
May 31, 1994, 11:04:00 AM5/31/94
to
Marnix van den Bos writes:
> I think an object can be in light according to your algorithm, with
> the character not being able to see it.

All my algorithm claimed to do was report if an object was in light, not
if it were visible to another object.

[In fact there are a couple of problems with my algorithm; (i) what
IsLit(X) actually tells you is whether the *inside* of X is in light; so
you should call IsLit() on the parent of the object you want to find the
lit/unlit status of (consider the case of deciding whether a locked box
is lit); and (ii) HasLightSource(X) should check if X is a light source
first before examing X's children. Just goes to show that all this is
rather fiddly.]

Here's an algorithm for IsVisibleTo, given a naive model of
line-of-sight in which objects are visible as long as they're not in
closed boxes; i.e. things can't be hidden around corners.

IsVisibleTo(TARGET,VIEWER)
{ Let X be the parent of VIEWER.
Return TRUE only if IsLit(TARGET) and LineOfSight(TARGET,X)
are both TRUE; otherwise return FALSE.
}

LineOfSight(TARGET,X)


{ Let Y be the parent of X (if any).
If X has a parent, and X is 'transparent' (i.e. the children of X are
visible to the siblings of X; in general this will be the case

unless X is an opaque container of some sort), then visibility will
penetrate into X, so return LineOfSight(TARGET,Y).
Otherwise X is the outermost container surrounding parent(VIEWER)
(i.e. the object we started with) whose children are visible to
VIEWER.
Return HasChild(TARGET,X).
}

HasChild(TARGET,X)
{ If X = TARGET return TRUE.
If X has no children, or if X is an opaque container then
Otherwise, for each child Y of X:
{ If HasChild(TARGET,Y) returns TRUE then return TRUE }
If this point is reached, no child of X is TARGET.
So return FALSE.
}

In practice, something like HasChild() ought to be a primitive of your
adventure-writing system, and at parse time you'd probably compile a
list of all objects visible to the player rather than doing individual
IsVisibleTo() tests on each one.

--
Gareth Rees

Marnix van den Bos

unread,
May 31, 1994, 4:09:26 AM5/31/94
to

I have a question about light sources: How do I determine whether or not
there is (indirect) light in a location or object?

The way I set things up now, is the following. Each object and location
has two flags: VISIBLE and LIT. VISIBLE means visible to the player
character. In order to determine whether or not there is a light source
available (i.e. the player can see), I test all objects in the players
current location for both VISIBLE and LIT to be set, If there is an object
or location that is both visible and lit, it is a light source. This
mechanism allows me to handle situations where the player enters a shed and
leaves his lamp outside (lamp will be lit but not visible and thus not a
light source) or the player putting a burning torch in a glass box and
closing it (the torch will remain visible and lit (for some time)).

Yesterday it occured to me that the VISIBLE flag is not usable for
characters other than the player. In the shed example, suppose the player
is in the shed with the door locked and the lamp outside. Suppose a thief or
a troll enters the location where the shed is. To the thief/troll, the lamp
_is_ a light source, but this can not be decided by the VISIBLE flag.

I have been thinking about trading the VISIBLE flag for a BLOCKING flag
to indicate that no light can go `through' an object or location boundary.
I would appreciate suggestions on how to handle this light source problem.
I am mainly interested in algorithms, no source code, as I am not using a
particular developers kit.

Thanks,

Marnix J. van den Bos
M.J.B.v...@research.ptt.nl

Reply all
Reply to author
Forward
0 new messages