Hi Tom, I’m going to disappoint you; I don’t know of any Squiffy Cloak of Darkness. That’s not to say there isn’t one.
You’ve awoken a thread which is 5 years old, so thank you for that . Now I’ve taken the time to read it I think it persists in being an important discussion.
At the time I was doing IF in Python, I regarded CoD as the Hello World of IF frameworks, and so I specifically documented my implementation in the open source package I published.
I acknowledge there are shortcomings in the scenario. It’s not really a test of the candidate’s implementation of darkness. That would imply that the engine understood the propagation of light.
Unless anyone can point me to an IF engine which incorporates a ray tracer, I’ll declare that darkness is really only player blindness (or sensory attenuation if you prefer).
Looking back, what I regret is that my Python CoD is not an admirable template for a larger project. Because in order to achieve the criteria in only a few lines of code, I departed from some of the design patterns I had hoped to promote as good practice.
If there is an update to Cloak of Darkness, I hope it will assay the scalability of an IF framework, so that big aspirations don’t run into combinatorial sand.
thanks for the reply. We had other discussions about COD in the Inform and Retro threads. We surmised that parser based languages do better than choice based languages for this demo test. Further, the built in inventory systems in some parser based engines make the demo even easier in those languages. I was just checking Squiffy, which I enjoy but probably only use 10% of what is possible.
if in Inform 7 (and other similar parsers), if you start with the cloak is being worn, you can immediately type I for inventory. You can also take, drop, wear it, with no additional code. Choice based engines do not have these functions automatically. They need to be programmed for. This is the case for verbs as well. The better parsers will know what is meant by open door, close door, eat fruit, etc. In choice based, these all need added coding.
The problem, in my view, with Cloak of Darkness as a specification is that it fails to specify. It should include walk-throughs leading to win and lose results that properly test a system.
For example, you can create a game that does not have an INVENTORY command. That seems to me a very basic requirement for any parser system. And could be included in a walk-through.
And what is it that triggers the failed game? What does disturbing the sawdust in the bar mean in game terms? Do I need to implement a DISTURB verb, because what else will the player do in a dark room that could disturb the dust (I know the answer is “no”)? A walk-through that shows the commands that lead to the game being lost would be so useful.
I say this as someone who has written two versions by the way.
There have been a lot of discussions about this, but in simple terms, light absorbing cloak will darkens the room wherever it is located. Therefore, merely dropping the cloak should not brightens the room. If I understand it correctly, that’s the original “bug” argument.
It’s different if the specification says "Light absorbing cloak when worn. "
Edit: or while being carried, whatever the case may be.
I also read the last line, but not having referenced the two versions, I have no way to check.
I have also checked a few implementations, and the PunyInform code example was to give light to the (bar) room when the cloak is dropped/put on (hook), as opposed to turning the current room (out of all rooms) dark when the cloak is present.
Not darkening rooms other than bar location is a divergence with current specification. How are your games implemented?
I stated two failing of the spec; your response was about something else entirely from earlier in the thread. Looks to me like you did not actually read what I said.
I think implementing an INVENTORY command is relevant as it is fundamental to parser games.
I think stating what actions by the player cause the game to be lost should be a part of it of the spec. This is certainly NOT irrelevant.
You play an instrument? Do you know “Knocking on Heaven’s Door”?
So you’ve constructed a new IF framework. Let me see your “Cloak of Darkness”.
If you hope your audition of [1] to benefit from the automatic string accompaniment everybody gets with the free version of Ableton Live, you will no doubt be emboldened in your attempt of [2] by computational generation of shouty vocabulary which continues to suggest, 50 years later, that every Interactive Fiction is at its heart nothing more than an ASCII dungeon.
All bickering aside, I’ve had plans for a new parser engine milling around in my head since last Saturday and you can bet your light-absorbent butts I’m doing a CoD in it for basic functionality testing.
COD is mostly useful for quickly giving people an idea of what coding in a system looks like. It’s not meant to prove the “completeness” of any system.
Y’know what? It seems to me that CoD is kinda like a more involved Hello World. Just about every programming language under the sun has one of those and all it does is demonstrate how to print a short text with no consideration of the rest of the language’s features and flaws.
What I was trying to say was that I regard CoD as a loose brief to showcase the features of an IF framework, while still being simple enough for a newbie to get to grips with.
So defining a canonical walkthrough would bind the framework author to some preconceptions about how an IF should play, and I don’t think that’s healthy for the future of the form.
And reading earlier, I see that I posted a hope that a future spec for CoD could try to prove that an IF framework scales well for large projects. I’m not sure how compatible that is with what is clarified here, so that part is optional.
I get your point, but I think it fails on that score too, because it is too prescriptive. Someone mentioned NPCs earlier. CoD stops you including an NPC in the game that is supposedly showcasing what your system can do!
I am curious how the scaling issue could work with a game that would have to be small. It is important, but how do you showcase that?
I think this thread is starting to veer into territory that has been covered by at least one other, recently… as in, what would be a “better” alternative to Cloak of Darkness… something that would cover some of the other key elements of IF. Cloak of Darkness’ focus on light/dark seem incredibly old fashioned even to someone like me who spends their time exclusively playing old text adventures!
There’s nothing to stop you coming up with your own specification for an alternative “standard demonstration game” that might include elements like containers or NPCs. The trick is to come up with a tiny, compact game that incorporates all the key elements of a “good” IF/text adventure system whilst also having some narrative appeal to encourage others to recreate it on multiple platforms. There are plenty of clever people here, though, who could handle that challenge… So, I guess, the main obstacle might be how much of a need for a new CoD is out there? Do people really use it to help them get an idea of what systems are like?
As an aside, I think that aiming to produce a much larger demo game would be a mistake. You want something small and streamlined enough that a newcomer to a coding system can easily take in the full scope of the game code. That is one of the attractions of CoD. Any new “standard” game should be able to be replicated across the full range of systems; but most systems can cope with containers, NPCs, wearable items, item weight, etc. without getting too bloated.
Unfortunately, Scottkit cannot easily handle wearable items and items weight. It’s too limited that way. Maybe if you assign a special room as “worn”, and have the daemon sums up each items weight being carried. But there’s no easy, convenient way to do it.
Also, a 2 word parser is inconvenient to deal with container system, anyway. You’d create special verbs to deal with that.
Which begs the question: Do I need to specify that items be worn/equipped? Do I need to worry about size/weight? Do I even need inventory systems?
My conclusion is that you don’t need it to have a good, fun game. In fact, it’s better if you skip it, if my test game is of any indication. So what if a player wants to put an elephant into his pocket?
My favoured systems of choice are old-school text adventure ones, so there are always workarounds. In simple systems, object states can be implemented by using multiple items, e.g. “a torch” and “a lit torch”. For worn items I can swap two objects over, e.g. “a cloak” with “a cloak (worn)”. Containers can often simply be dealt with by “a bucket” and “a bucket of water”. EMPTY BUCKET or OPEN BOX are usually sufficient to deal with simple containers of that type. NPCs just take a lot of manual coding, but are doable. So, as long as any demonstration adventure isn’t too specific, it can still be implemented in old school adventure systems.
. Now I’ve taken the time to read it I think it persists in being an important discussion.
