Well, you could start with something like this:
enum raining, snowing, sunny, cloudy;
case raining: "It's overcast and wet. "; break;
case snowing: "Flurries of snow fall from the cloudy sky. ";
case sunny: "It's a clear blue sky with scarcely a cloud to
be seen. "; break;
case cloudy: "Dark black clouds frown across the leaden sky.
default: "You see nothing remarkable about the sky. ";
weatherType = nil
Of course, you may need something more complicated, depending on
what exactly you want to achieve. How do you want it to affect
NPC's, for example? Is it enough to test defaultSky.weatherType in
NPC descriptions, or might you want some means of selecting
ActorState according to weather? Is it your intention to implement
HOLD OUT CUP as a command? In that case you could perhaps test for
defaultSky.weatherType == raining in Container.actionDobjHoldOut()
and fill or not fill the container accordingly.
Perhaps you first need to get a clearer definition of what exactly
you want to do, however. Maybe you already have, but I can see a
danger of leaping in here with a half-baked idea and then finding
halfway through that you've chosen the wrong tools for the job
(e.g., in your case perhaps what you really need is not a minor
tweak to defaultSky's desc method but a set of WeatherState objects
that define different kinds of behaviour according to weather type).
> I'm a newbie to this, and am still going through Eric
> Eve's Getting Started (great help though)
I'm glad you're finding it useful.
Hmm... That would probably work. As long as I check with the NPC
what the weather is. I havn't planned what I want to do with it quite
yet. I'll probably have mostly snow in the game I'm planning right
now. I think at least initally it will be for part of the description
of the area. If the weather is snowing, then the room description
should mention that. I'm still in the planning stages for this idea,
so I'm sure more and better ideas will come as I go.
It does sound to me like you need to plan what you want to do with
your weather before you try to work out how to implement it. If it's
just a question of room descriptions then all you'd need is to add
an extra property to libGlobal, say weather:
weather = nil
Then maybe define an enum for different weather conditions:
enum sunny, raining, cloudy, snowing;
Or whatever your need, and perhaps finally, in a header file you'd
include in all your game source files, you might have
#define gWeather (libGlobal.weather)
Then your room descriptions (and defaultSky) could simply test
gWeather to decide what to display.
Anything more elaborate than this might need a different
implementation - it all depends what you actually want the weather
>Hmm... That would probably work. As long as I check with the NPC
>what the weather is. I havn't planned what I want to do with it quite
>yet. I'll probably have mostly snow in the game I'm planning right
>now. I think at least initally it will be for part of the description
>of the area. If the weather is snowing, then the room description
>should mention that. I'm still in the planning stages for this idea,
>so I'm sure more and better ideas will come as I go.
You are in the library. Drifts of snow cover the lower shelves,
and there is more coming. The librarian is shovelling snow off
>ask librarian about weather
She hands you the shovel. "Weather this!", she snarls.
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
I assumed that's what you had in mind, but you could, of course,
have indoor locations affected by the weather conditions too
(there's a leaky roof, or the rain pounds the window while the wind
rattles the doors). Again you have to decide what you want your
weather effects *for* before you can meaningfully think very much
about how you might implement them. For example, is your weather
going to be purely atmospheric (in the literary rather than the
meteorological sense) or is it going to effect the plot and puzzles
in some way? Do you need changes in the weather to be plot-driven,
turn-count-driven, or real-time driven? Is snowfall going to block a
road or simply make a field look picturesque? If you have a
snow-coverered field will you want/need to implement footprints in
the snow if the PC or an NPC walks across it? Is your rain going to
cause flooding in a nearby river, or simply encourage your PC to
carry an umbrella? I'm sure TADS 3 would be able to handle all these
possibilities, but no one can tell you how (or will be willing to
write a long treatise explaining how) until you come up with a more
On the other hand, if at this stage you're trying to feel your way
towards what's implementable before commiting yourself to a
particular plot or game design, you might simply want to devise a
dummy game for your own trial purposes and try out various ideas in
>Gene Wirchenko <ge...@mail.ocis.net> wrote in message news:<udobg0l020gcl9lv3...@4ax.com>...
>> ri...@lycos.com (Brian Ronk) wrote:
>> >Hmm... That would probably work. As long as I check with the NPC
>> >what the weather is. I havn't planned what I want to do with it quite
>> >yet. I'll probably have mostly snow in the game I'm planning right
>> >now. I think at least initally it will be for part of the description
>> >of the area. If the weather is snowing, then the room description
>> >should mention that. I'm still in the planning stages for this idea,
>> >so I'm sure more and better ideas will come as I go.
>> You are in the library. Drifts of snow cover the lower shelves,
>> and there is more coming. The librarian is shovelling snow off
>> her desk.
>> >ask librarian about weather
>> She hands you the shovel. "Weather this!", she snarls.
>Ok, how about Outdoor Rooms mentioning that instead...
You are not out of the woods yet. There are small patches
of snow on the ground below gaps in the tree coverage. The
odd snowflake lands on your coat.
However, back at the library:
You are in the library. There is a window on the south
wall. Through it, you can see nothing but a void. It is as
if the outside world does not exist.
You are in the library. There is a window on the south
wall. Through it, you can see what was once a grassy field
and that the snow is really coming down. The library's
bookshelves are filled with books that you just have not had
time to read.
No more snow.
I have a many-faceted intellect. I hope "facetious" is the
adjectival form of "facet". <flip, flip> Oops, no. Bad luck.
> If you have a
> snow-coverered field will you want/need to implement footprints in
> the snow if the PC or an NPC walks across it?
This is hideous to implement well. (At least it was in TADS2, I don't
know how much easier it would be in TADS3, possibly a little better as
I understand there are some nicer built in data structures, which
would be useful). The main difficulties are in formulating the
appropriate description, because there's a lot to take into
consideration. Keeping track of this information in a reasonable way
also causes difficulties.
If there are multiple actors, you have to consider whether the
footprints are distinct enough for the PC to be able to identify the
maker. As time passes and more snow falls or the snow thaws, the
footprints should get more indistinct to the point where they become
vague and unidentifiable. Footprints have direction - they can pass
through a location rather than just being there, so if you want to
implement this level of detail, you need to keep track of who made
what footprint, what direction they came from and where they were
going. And since it may be possible for an actor to travel through a
location more than once from and to different directions, you need to
cover that circumstance as well.
Wandering around inside a location may make a mess of footprints.
But the real difficulty is taking this information and making it into
something that you can read without your eyes forcing themselves shut
to avoid the tortured English. Two or more actors footprints that go
the same way should ideally be described as such. If footprints become
vague, so should that.
Implementing all this becomes a major headache. And there's more,
which I decided was taking things too far, although it's possible.
Ccould you refer to an individual trail of footprints, obscure a
trail, does dragging an object cause other marks in the snow... what
if a character takes their shoes off - apart from getting cold feet of
course - or hops, or walks backwards? Is there a difference in the
resulting trail if the actor is running?
> On the other hand, if at this stage you're trying to feel your way
> towards what's implementable before commiting yourself to a
> particular plot or game design, you might simply want to devise a
> dummy game for your own trial purposes and try out various ideas in
This is excellent advice. When implementing simulationist things I
find it's a big advantage to write out the end result that you'd like
to see. From that, you can work out what features the implementation
needs. Ideally, of course, it should allow easy extensibility when you
decide you need it to behave another way.
And you do an excellent job of going on to spell out why this is.
TADS 3 might offer a few more powerful tools that TADS 2 to do it
with, but it would still be pretty hideous, I think, unless you kept
the implementation fairly vague ("there are fresh footprints in the
snow" rather than "a fresh set of footprints (your own) leads from
the gate to the front door, crossed by a second pair of footprints
(apparently made by some small quadruped) leading from the small
yard to the east to the copse just to the west, while an older set
of footprints, which seem to have been made by some wearing size ten
rubber-soled boots, leads from the southwest corner of the
snow-covered lawn to the wooden gate at its northeastern corner.").
As you probably surmised, my example of footprints (which you've
most usefully expanded upon) was intended to invite the original
poster to consider what he actually wants to achieve with weather
effects such as snowfall.
>And footprints in the snow... tracking someone down maybe, or
Or maybe the opposite... you have to find a way to avoid leaving
footprints in the snow, or someone tracking you down will find you.
Occasionally I toss around an idea for a puzzle which involves leaving
several sets of tracks through the game world -- no two trails are
allowed to cross.
Then I think about how to implement it. Doable. But not without pain.
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
* Make your vote count. Get your vote counted.
The courtyard is approximately thirty feet sqaure and is
covered in two inches of snow. There are four statues
equally spaced, and there are gates to the north, south, and
You cautiously walk backwards towards the north gate but
slip on some hidden ice and bash your head against a statue.
The good news is that no one else knows which way you are
going; the bad news is that you do not either.
Absolutely. The reason I replied was partly because, having
implemented this recently, I thought the information might be useful
to anyone considering these problems and partly because I wanted to
share the full horror. In my implementation I ended up having to
rewrite from scratch a couple of times because I hadn't considered
carefully enough what I needed to do.