What do you think is the best approach to program inner and outer parts of a vehicle?
Things that
can / cannot be seen from the outside / inside
can be seen from the outside but cannot be operated
Also: The description of the vehicle and it parts from the inside / outside
Lab is a room.
The DeLorean DMC-12 is a vehicle in the lab.
Understand "car" as the DeLorean.
[accessable from both sides]
The windshield is part of the DeLorean.
[visible from outside, touchable from inside]
The time circuits are part of the DeLorean.
The flux capacitor is part of the DeLorean.
[visible and touchable from outside]
The nuclear reactor is part of the DeLorean.
(There is probably no worse time to ask than now, with IFComp having just startedā¦ )
While I canāt answer the substance of your question too much, Iād actually argue itās a really good time to ask, since people will be frequenting the board more, and this will fall under a list of ālatest topics,ā so more may stop by with an idea
The more stuff you can meddle with, the trickier the implementation is. So I donāt think you want to do too much. Maybe you could define a type called unimportant-car-partāthis would be a partial solution.
an unimportant-carp-art is a kind of thing.
instead of doing something with an unimportant-car-part when player is not in DeLorean: if current action is not examining, say āYou need to get inside the DeLorean before trying anything with [the noun].ā
Yes, that sounds very promising! Then I could simply create different categories:
window doesnāt need a new category, it behaves as usual
vis-out-touch-in: for things that can be seen from the outside and operated from the inside
-vis-out-touch-out: for things that can only be seen and operated from the outside
vis-in-touch-in: ditto from the inside
etc.
Iām just a little unsure whether Iām missing something here that will cause problems laterā¦
I wouldnāt worry too much about āunspecified problems later.ā There probably will be adjustments, but just organizing things by type helps a lot to minimize any code reorganization.
Defining new kinds of things, or thing properties (e.g. a car-part is a kind of thing. a car-part can be normal, vis-out-touch-in, or vis-in-touch-in. a car part is usually normal.) isnāt too bad.
Iāve had to even say āa fiddly-car-part is a kind of car-part.ā
Itās not something you want to do right away, maybeāI generally take a day before reorganizing types to see if I missed any big cases, as I figure the small ones can be tweaked later.
Well, itās too late to add to WP. And I donāt have enough ideas for a full sequel, anyway. Not even a short one to drop in EctoComp ā¦ right?
(Anyway, back on topic, I found types are really neat in a lot of ways, better than defining properties, which are also quite good. The code just reads that much more like natural language & if there is a bug in types, itās easier to fix. The main thing I get tripped up with while compiling is checking if things have specific thing properties. I think you can say āif X possesses the property Y.ā)
Agree (perhaps a room dynamically inside the current room), and then adjusting scope settings to decide what is visible from inside the vehicle and what inside-part is visible from outside the vehicle.
Unfortunately, things being part of containers is a bit of a mess of bugs in current Inform. I had to do a lot of hacking around that for Stormrider. (And vehicles are a type of container, soā¦)
"Vehicle Test"
Laboratory is a room. "A vehicle test track leads away to the north."
An experimental test car is a vehicle in Laboratory.
A thing can be interior. A thing can be exterior.
Before doing something to an interior thing:
if the player is not enclosed by a vehicle:
say "That's a little hard to mess with since you are outside of the car." instead.
Before doing something to an exterior thing:
if the player is enclosed by a vehicle:
say "That's a little hard to mess with since you are inside the car." instead.
A rule for reaching outside of experimental test car:
say "A safety alert buzzes, warning you to keep your hands inside the vehicle at all times.";
deny access.
A hood ornament is part of experimental test car. It is exterior. The description is "It's fancy and futuristic: a silver avatar of a scientist whose labcoat is flapping majestically in the imaginary driving wind."
Some fuzzy dice are inside experimental test car. They are fixed in place. They are interior. The description is "They wobble when you drive the car and are tied to the interior with a difficult knot."
[by default vehicles are open and enterable like a golf cart with no doors, you have to write rules and restrict access if you want openable doors that lock with a key and the vehicle run only if a key is in the ignition, which can be a container...etc]
Test Track is north of Laboratory. "This is an indoor test track with fake cutout trees and minature cities set up as scenery. Once you're done [if the player is enclosed by a vehicle]zooming around [end if]here, you can return south to the lab.";
An orange traffic cone is in Test Track.
Some fake cutout trees are scenery in Test Track.
Some miniature cities are scenery in Test Track.
Test me with "x dice/x ornament/enter car/x dice/x ornament/n/take cone"
The short version is that, when something is part of a container, some parts of Informās world model assume itās on the inside of the container, and some parts assume itās on the outside.
In Stormrider thereās a locked chest (a closed and locked container, pushable between rooms) with a lid (an enterable supporter, part of the chest), and you have to push it into place and stand on it to reach a high shelf. But if you stand on it, suddenly youāre plunged into darkness, because the light calculation code thinks youāre on the inside of a closed container! The code that checks for reaching, on the other hand, has no objection, and thinks youāre on the outside.
Yes, I think Informās default vehicle type was coded to be as generous as possible by default since itās easier to start with something that puts everything in scope and let the author whittle them down with restrictions than it is to by default assume the vehicle type is going to be more like an automobile and require the author to figure out how to lift an existing restriction.
Not every vehicle is an automobile - it may be a moving platform on a track where it makes sense that the player can interact with things that arenāt contained. The one difference is a āridable vehicleā (which is either built in or a core extension?) that does things a little more like youād expect - getting ON a horse instead of IN a horse to steer it around. My moving platform example actually would probably be more like a rideable vehicle than an enterable standard vehicle.
Fortunately, itās fixed in the next version of Inform!
Unfortunately, thereās no telling when thatāll be released.
Fortunately, thereās an extension called Basic Container Supporter Incorporation by Otis The Dog that fixes the biggest problems. Thatās what Stormrider uses.
Unfortunately, I donāt think itās had a formal release anywhere, just been shared around the forum.
I came up with a similar solution which might be slightly over-engineered (but Iām pretty certain meets your requirements):
Lab is a room.
The DeLorean DMC-12 is a vehicle in Lab. Understand "car" as the DeLorean.
A car-part is a kind of thing. A car-part can be interior or exterior. A car-part has a vehicle called the host-vehicle.
When play begins:
Repeat with P running through car-parts:
Now P is part of the host-vehicle of P;
A flux capacitor is an interior car-part. The host-vehicle of the capacitor is the DeLorean.
Some time circuits are an interior car-part. The host-vehicle of the circuits is the DeLorean.
A nuclear reactor is an exterior car-part. The host-vehicle of the reactor is the DeLorean.
A windshield is part of the DeLorean. [No special handling needed here.]
This is the reaching through vehicles rule:
If the noun is a car-part and the action requires a touchable noun:
Let V be the host-vehicle of the noun;
If the noun is interior and V does not enclose the player:
Say "[We] [can't] reach [the noun] from outside [the V].";
Rule fails;
If the noun is exterior and V encloses the player:
Say "[We] [can't] reach [the noun] from inside [the V].";
Rule fails;
The reaching through vehicles rule is listed before the basic accessibility rule in the action-processing rules.
This could be simplified a lot if thereās only one vehicle in the game with these properties. (Maybe it could be improved anyway - I feel like there ought to be a way to avoid the āwhen play beginsā rule but I canāt figure out how to tell Inform that every car-part is part of that car-partās host-vehicle.)
A similar solution using relations. I donāt know which one is better.
Lab is a room.
The DeLorean DMC-12 is a vehicle in Lab. Understand "car" as the DeLorean.
Surrounding relates one thing to various things. The verb to surround means the surrounding relation.
Exposing relates one thing to various things. The verb to expose means the exposing relation.
A flux capacitor is part of the DeLorean. It is surrounded by the DeLorean.
Some time circuits are part of the DeLorean. They are surrounded by the DeLorean.
A nuclear reactor is part of the DeLorean. It is exposed by the DeLorean.
A windshield is part of the DeLorean. It is surrounded by the DeLorean. It is exposed by the DeLorean.
This is the reaching through vehicles rule:
Let V be the holder of the noun;
If V is something and V incorporates the noun and the action requires a touchable noun:
Let V be the holder of the noun;
if V is something:
If the noun is not exposed by V and V does not enclose the player:
Say "[We] [can't] reach [the noun] from outside [the V].";
Rule fails;
If the noun is not surrounded by V and V encloses the player:
Say "[We] [can't] reach [the noun] from inside [the V].";
Rule fails;
The reaching through vehicles rule is listed before the basic accessibility rule in the action-processing rules.
test me with "touch reactor/touch flux/touch windshield/enter car/touch reactor/touch flux/touch reactor".
I have now stolen bits and pieces from all the suggestions and made a melange that should fulfill what I need.
Lab is a room.
"The laboratory is nothing more than an ordinary garage."
The DeLorean DMC-12 is a vehicle in the lab.
"The DeLorean is here, waiting for you to kill some time with it."
Understand "car" as the DeLorean.
I went with @aschultz advice on new kinds of things because I think it helps me to limit the scope of these to only use them with vehicles. It also allows me to create objects in a very compact and readable way, which I always find very convenient.
An externally-visible is a kind of thing.
An outside-only is a kind of thing.
An inside-only is a kind of thing.
The windshield is part of the DeLorean.
The glove compartment is an inside-only part of the DeLorean.
The time circuits are externally-visible parts of the DeLorean.
The flux capacitor is an externally-visible part of the DeLorean.
The nuclear reactor is an outside-only part of the DeLorean.
I think for less complex situations @HanonO approach is ideal since it lightweight and yet effective.
I went with a variation of @jwalrus and @rileypb rule and I donāt think itās over-engineered at all. Maybe it needs some refinement; I will find out when I put it in the context of the actual game. But once it has been well tested and polished, it should be easy to reuse. It might be even more elegant with the relations, but I shied away from it because Iām not so familiar with it.
This is the accessible vehicle parts rule:
if noun is something and the noun is part of a vehicle (called the holder):
if the action requires a touchable noun:
if the holder encloses the player and the noun is outside-only:
say "[We] [can't] reach [the noun] from inside [the holder].";
rule fails;
if the holder does not enclose the player:
if the noun is inside-only or the noun is externally-visible:
say "[We] [can't] reach [the noun] from outside [the holder].";
rule fails;
else:
if the holder encloses the player and the noun is outside-only:
say "[We] [can't] see [the noun] from inside [the holder].";
rule fails;
if the holder does not enclose the player and the noun is inside-only:
say "[We] [can't] see [the noun] from outside [the holder].";
rule fails.
The accessible vehicle parts rule is listed before the basic accessibility rule in the action-processing rules.
And @HanonO 's rule is needed to restrict the player from taking stuff outside the vehicle:
A rule for reaching outside of a vehicle:
say "You can see [the noun], but you can't reach it by hand from here.";
deny access.
A waffle iron is in the lab.
Thanks to all of you for all the good advice and code examples ā it has helped me enormously!
)
