Cloak Of Darkness (GAC) – text adventure game demo

[lurkio]

This is an implementation of Cloak Of Darkness in Graphic Adventure Creator (GAC) for the Beeb:

https://github.com/ahope1/Beeb-GAC-CloakOfDarkness

Cloak Of Darkness is a small demo game that demonstrates how easy or hard it is to implement some fairly simple game mechanics in your text adventure creation system of choice. Cloak Of Darkness has become a sort of Rosetta Stone for IF authoring systems.

What Cloak Of Darkness reveals about GAC is its fiddliness when it comes to implementing darkness and light-sources. GAC doesn’t have per-room dark/light flags, so you have to trap the movement of the player whenever they move from each dark room into any adjacent lit room, or vice versa, and toggle the one global dark/light flag accordingly. Perhaps there’s a better way, but if so I don’t know what it is!

[8bitAG]

Richard Bos did a GAC version for the Spectrum. I did a PAW version, but I can't remember off the top of my head how I did the darkness bit.

[dr_d_gee]

With PAWS you have just one light source — object 0 — and one flag to represent light or darkness (flag 0). You would need to change flag 0 appropriately when moving from light to dark and vice-versa. This does have the advantage that you can change the light/dark situation in a lot of places all at the same time.

[julie_m]

AdveBuilder has a light/dark setting for each room, which affects how the description is displayed and the verb TAKE behaves, but this can be overridden.

Probably the most common case is where exactly one movable object in the game behaves as a light source when activated and present in the room or the player's inventory; so code is incorporated automatically at `art_light` to handle object 9 (the number is chosen for historical reasons) behaving as a light source if game state bit 9 (because for any bi-state object, its state depends on the matching numbered state bit) is active.

But you can easily bypass this and implement your own code between `select_room` and `disp_desc` to have e.g. a permanent light source which does not require activation; multiple objects that can behave as light sources; rooms whose light/dark status depends on a game state bit (perhaps the gameplay takes place over several days and nights, or part of a building is dark until the player resets a circuit breaker); or even light spillage into a dark room from a light source in an adjacent room. And of course you can implement things like explosive atmospheres in rooms into which naked flames must not be carried, or light sources with limited energy (which there may or may not be any way to recharge) and even -- if you really want the player to hate you -- limited on/off cycles.

(I also tried an experimental modification to implement four light levels, not just effectively "broad daylight" and "pitch darkness"; but could not quite expand this concept into a full, playable game.)

[EdwardianDuck]

For what it's worth (almost certainly nothing), when I was actively trying to write an adventure game, both in assembler and Inform6/PunyInform, I had several goes at implementing variable light levels because I felt the full light to absolute dark transition was unrealistic. I'm not sure why I was bothered about realism in a game about a toy duck but there you go. As an aside, I also had four light levels, plus absolute darkness. I was never entirely satisfied with any of my implementations although the implementation in release 2 was, in my opinion, the least terrible. In the end all I did was add constraints on required light level to key actions for a few objects, such as (spoiler alert) not being able to see the sewing needle in the cavern in less than full light. The player could do most things in dim light and that sort of seemed reasonable.

Jeremy