Like I said. It is a clear, proven, solid spec. Your understanding of it is “dreadfully” flawed. 
Yes, probably.
I think what I like about the spec is that there is room for interpretation and variation. Seeing the different flavors of implementation over the years is interesting.
COD best works as method of comparing systems. Other specs could definitely help with testing authoring systems for completeness, which COD doesn’t do. COD is great as long as you don’t ask it to do something that it’s not intended to do. It’s certainly not meant to be great literature or even a great puzzle.
If CoD’s purpose is to show that an engine can do the standard IF-things, then there should also be an NPC.
I never said it was meant to be fun. Where did you get that from?
The spec (http://www.firthworks.com/roger/cloak/) doesn’t say that this is its purpose. What it says is that it is a means for authors to compare how the same little game is implemented in different engines. Its creation was a response to the frequently asked question of which engine is “best”, which of course there’s no one correct answer. This is what the spec actually says:
Again, I don’t know where you get this from, it’s neither in the spec itself nor in its intro text. The spec is not meant to “tick off all the boxes”.
Now the spec is meant to be used for debugging engines? Where in the world did you get that from? Certainly not from the spec, because debugging isn’t even mentioned there…
The spec itself calls it a game and says its purpose is to show (ergo demonstrate) how to implement the same game in different engines. It doesn’t say anything about it being a “development and debugging tool.”
I would certainly appreciate it if you could at least try to base your arguments on the actual facts in the future (instead of your provably false or ungrounded assumptions), and not berate people in this thread for a supposed “lack of understanding of the spec” – because it seems to me you are quite guilty of misunderstanding the spec yourself.
1 Like
Look, man, you’re welcome to make a new spec. The Cloak of Darkness, however, is not broken, bad, too old, etc. I understand the spec. You’re very confused. This is the last I’ll post on this. Go forth with your confusion and do what you will.
My arguments are based on facts. You want to define a new spec, simply because you’re having trouble implementing this spec in your new engine.
I’ve been pretty nice here, but let me be clear. Your engine needs to be fixed, not the Cloak of Darkness. The flaws that COD has pointed out in your engine are flaws that need correcting in your engine. The spec is designed to highlight potential problems people will run into if COD can’t be implemented in your engine. It has exposed this lack. It has done its job. (It can also be used to point out lack or flaws in your own skills as an IF author when using a particular tool, but since discussing that can feel more like a personal attack, I hadn’t brought it up before…)
You’ll continue to see resistance from the community at large to ditching COD (even if it’s only passive by not helping you make a new spec and not adopting whatever you come up with) because COD simply works. It’s like you’re proposing that people stop using “hello world” as a programming example…
As a moderator, I would urge everyone in this thread to try to keep discussion to the merits or lack thereof of the Cloak of Darkness spec, and not to make anything personal about the other posters.
This is a pointless discussion.
By your interpretation of the spec, the cloakroom should be dark. Now you can make a game where a cloakroom is dark. This would be a new interpretation, validated by the spec as written.
It’s fine that your interpretation would differ from all previous CoD games. There are many interpretations in hypertext that don’t adhere to CoD spec. Maybe your interpretation would redefine the spec itself.
But CoD is a game. It can’t be redefined or replaced by a theoretical specification, it has to be a game. So IMHO you have to present something playable first.
This wasn’t really my “interpretation” as such, but a consequence of the game providing a model for darkness;
Earlier on in this discussion, it was pointed out that one purpose of COD was to verify a story can override things like containership and darkness. Now, normally, and i think this is how most people do it, they would set the “Bar” dark, contingent on having the cloak.
However, in my case, i tried to be more accurate and model the idea that the cloak is “light-absorbent” (as defined). So my story provided a functional meaning of light absorbency to the system, whereupon everything including the cloakroom went dark. Of course, it would! and that was the point i realised that by making a “better” override, that appeared to fit the spirit of the specification, it actually made things worse.
You could call this an interpretation, whether deliberate or through model consequence, but it started asking questions about the game that are not addressed by the given specification. Whether the cloakroom was even necessary, for example.
So sure, i could change my model so that only the bar darkness is contingent on the cloak and then the game would work in my system.
I thought it might be interesting and constructive for people to discuss these issues and whether or not there is a weakness in the COD specification. I was actually expecting someone to point out something i had missed, or to make a simple extra suggestion to the spec that resolved the conflicts. But instead people seem to get upset that i am somehow kicking the tyres of something sacrosanct.
Couldn’t you define how many light sources there are and how strong they are, and then make the cloak absorb just as much light that it darkens the dimly-lit bar completely, but allows navigation in all other rooms because they are appropriately lit?
This would still leave the “just drop the cloak to win” issue. I’d say you could just not allow the player to drop it, by responding with something like “Drop my beautiful cloak in this mountain of dust? No, thanks.”
(The following post is made as an ordinary poster, not as a moderator.)
I don’t read the spec as saying that the cloak has to have a light-absorbent property that does anything in the game logic. The relevant sentence of the spec is:
The way I read this is that it specifies the response to examining the cloak; in the Inform 6 implementation: “A handsome cloak, of velvet trimmed with satin, and slightly spattered with raindrops. Its blackness is so deep that it almost seems to suck light from the room.” “Light-absorbent” isn’t necessarily meant to do anything else other than show up in the description. The game logic is specified by “Returning to the Bar without the cloak reveals that the room is now lit”–you have to have some way of making the room lit once the player doesn’t have the cloak, but it might not be dependent on a light-absorbency property of the cloak object.
As far as the “drop the cloak to win” issue, the spec says “The player can drop the cloak on the floor of the Cloakroom or, better, put it on the hook.” This suggest but does not strictly entail that the game should block the player from dropping the cloak outside the Cloakroom. This is also implemented in the Inform 6 version, along the lines of what jfhs just said.
Thanks for your input,
Yes, i do agree that there are other ways to interpret the spec or ways to patch up the spec. Nevertheless, it’s pretty clear the cloak is meant to affect the darkness. An idea, suggested earlier, was that perhaps the cloak’s ability to absorb light is limited and thus the situation could be explained as follows;
The foyer is dimly lit and the bar is itself unlit but benefits from light cast from the foyer, whilst the cloakroom is strongly lit. Of course, none of these lighting variations are mentioned in the spec, but it would give rise to the following conclusions;
- the strong light in the cloakroom would overcome the cloak’s capacity.
- wearing or having the cloak in the foyer would make it dark
- leaving the cloak in the foyer would leave the bar also dark (ie “drop cloak, go south” doesn’t win).
So like i said, there are arguments to patch up the puzzle. But they are contrived and undermine the idea of making a simple light-related logical puzzle. If we had these extra complicated rules for the cloak and as part of a much bigger game, it would make for a real design headache.
In addition to the darkness model, i want to complain about the hook:
In an IF system world model, the ability to be “IN” something is usually first class. The next most modelled coordinate location is “ON”. After that we have “under”, “behind”, and so on. The latter bunch are usually not specifically modelled and are grouped as things that essentially mean, if X is under/behind/near-to Y, then moving, getting, push/pull, search etc Y means you discover X.
This can usually be tested because, as a player, you can rarely ever put something “behind” something else or “under” it. Except, possibly as part of a special story-related puzzle sequence.
But “in” is almost always [em]really[/em] “in”. The system model almost always accommodates containers, their capacities and the sizes things that can fit into other things. All this is usual IF puzzle fare.
But let’s turn to “ON”;
The modelling of “on” is primarily to allow the support of surfaces and the idea of putting things on top of other things (youtube.com/watch?v=1f-kfRREA8M), such as things on tables, chairs, clocks on mantelpieces etc. In particular “on” usually covers the idea of the player being “on” something. Sitting on chairs, sofas, or even horses and magic carpets. This creates a new problem as now the player can see things they cannot reach. That’s all part of “on”.
But here we have a game design where you can put things “on” a hook. Such a coordinated location is not really “on” in the usual sense, it’s more like “hanging from” or closer even to “tied to” than the usual “on”. What exactly can be put “on” the hook? Conveniently there is only is the cloak. Suppose you can get a wine glass from the bar, could that be put “on” the hook? Of course not (unless maybe upside down, but what if it also had wine in it, oh dear!). If you had a hat as well as a cloak, could [em]that[/em] be put on the hook? maybe? But could both the hat and the cloak be put on the hook? Would one fall off when the other was placed? The complexity of this “simple” hook starts to really hurt if it was part of a larger game.
So here we have a game design with a hook that wants you to bastardise your system “on” model, either that or make you write a whole bunch of special case handing logic. But for what reason? For what gain, for what entertainment purpose? After making you implement this special hook, the design kicks you straight where it hurts by saying, Oh yeah, the “player can drop the cloak on the floor of the Cloakroom”. Ha ha! just waste all that coding time for the hook that could have been spent making something else more interesting and fun!
If i was the producer on this game and read this design, I’d be saying, hey Larry why don’t we make the hook into a locker? Then just use the system “in” model code and it would just work with almost no effort. Unless there’s some special story related reason for the hook, I’d just change it.
And this is why the hook in COD is so bad. it’s a direct example of how to make something unnecessarily complicated and cause all sorts of problems when the COD design was part of a bigger game.
You just wouldn’t do it this way unless you were mad.
I’m not sure I want to participate in somewhat heated discussion, but I would like to note, that from my understanding a typical IF world model is expected to work this way. For example in TADS we have universal containment modelling on top of which you can choose prepositions (by using specific class or directly specific properties) which are used for printing messages and for parser vocabulary, therefore you get in/on/under/behind variation, but the internal working is always the same. And we have another completely orthogonal system allowing limitation of what can be contained and how to disallow anything we don’t want based on bulk, weight, class or list of objects. Same way you can limit what can be put in and what can be put behind etc.
I’ve completely translated TADS library to my native language and even in Czech it works exactly the same way - messages are parametrized using grammatical case and prepositions, but the containment is the same. We just have different prepositions in some situations. For example with chair (the wooden one from dining table) we use “on” preposition (na židli) but in contrast with armchair (like the one standing next to sofa) we use “in” preposition (v křesle). (And ironically “on” sofa.) So I would claim that at least in TADS world model the usage of hook as a ON container is viewed as a best practice, you can even find this usage in RTDD example game. 
I’ve used that countless times so I’m quite surprised you think putting things on hook is something out of ordinary.
This seems true.
This seems separate from the previous idea. The player can be “on” something, but also things can be on other things. A vase on a table, a clock on a mantelpiece. It’s not the player who goes on those things, for the most part. And the player can be “in” something too, like a car or a telephone booth or a coffin.
For that matter, it is at least possible to say one is sitting “in” a chair rather than “on” it. Definitely I would say that a sleeping person is lying in a bed rather than on it.
Again, the idea that you can see something you can’t reach seems separate from the in/on distinction. If there’s a vase on the table I can reach it without being on the table, and if there’s a treasure in a locked glass cabinet I can see it but not reach it.
FWIW, in Inform I believe containment and support are represented by the same object tree; what determines whether something is “in” or “on” something else is whether the parent object is marked as a container or supporter.
Well, something is “on” a hook in a different way than it is “on” a table, but that can also be true for “in” (contrast being in a chair to being in a telephone booth or in a line for that matter). There’s the issue here that not everything that you can think of could go “on” the hook, but that’s also true for “in”–I couldn’t put a full glass of wine in a backpack either. Part of this is just that prepositions have a lot of different meaning and combine idiosyncratically and differently in different languages–it seems that in French you do say “sit on a chair” but “sit to the sun” where we would say “sit in the sun.”
Overall it seems as though what you have in mind is a fairly complex world model, with different levels of light and complicated mechanics for support versus containment, and your complaint is that Cloak of Darkness doesn’t interact nicely with that, since if you’ve got a certain logic for in/on, the hook doesn’t work nicely with that. And if you want a spec for complex world modelling you’d definitely need something different. The logic Cloak of Darkness checks is pretty simple.
@tombasb, Hi and thanks for your input. I think the TADS implementation method you describe is a good idea. I’m working on a system whereby the base locator is called “at” but it can be elaborated by things like “in”, “on”, under" etc. But in those cases, the location is (at in) or (at on) etc, so “at” remains as the base “key”. So this is much the same as you describe.
The problem comes with the constraints (your orthogonal rules), which will need some care. Working this way it a bit like separating the syntactical aspects from the semantical whereby the semantics is factored into the constraint set rather than the base representation.
Regarding “hooks”, this would give rise to an extra set of constraints, which i totally agree could be done and implemented just fine. if you wanted to.
Hi @Matt, thanks for your comments. I’d like to apologise if my complaints of COD seem rather overcritical. This was never the intent, as i DO think COD has (and has had) an important role to play for IF development.
My main issues really boil down to “keep it simple”, and although i do think that trying to explain the nuances of COD are not as obvious as at first glance, i would nevertheless agree that it is meant to be a simple game.
“Keep it simple” is always a good plan and my points about the hook were intended to suggest that there might be an even simpler way rather than to knock it.
For hooks and towel rails you only need a property that defines a surface as a “hook” and a property of objects as “can be put on a hook”.
Then you just need a rule that only objects with that property can be put onto a hook.
The same thing happens in reverse for liquids. You define a “can hold liquids” property for containers and prevent liquids being stored in any container that does not have that property.
That’s true, but it means you have to be able to invent new properties at will. if you had a tool for authoring the world, for example, this might not be so easy, since the tool would have to be aware of it too.
I think it depends on how much knowledge you want in the tool. For me, I want to have as little semantic knowledge in the tool as possible, only if it’s absolutely necessary, e.g. for handling user input. The tool knows that an item has properties and it knows how to test them, but it would not need to know the meaning of the property.
The advantage is that it gives the author a lot of flexibility in defining properties. The disadvantage is that the author has to code the handling of the properties himself (but it can be reused in other works).
Example: “open the box”
The tool finds that “open” is an action and that “the box” maps to an object in the room.
Next, it runs the following actions (as coded by the author in the game source):
- check if box has property “openable”
- if so, check if box has property “open”
- If not, check if box has property “locked”
- If not assign the property “open” to the box
- print a message that the box is now open and print a list of its contents.
The author has the flexibility to add more intelligence, like if the object has proprty locked, check if the player has the right key (another property) and then clear property “locked” and set property open, etc
To do the above the tool does not need to have an understanding of openable, open or locked. They could be as well called prop1, prop2 and prop3.
An example where the tool does need to understand a property’s meaning is with the “visible” property. There will be a process where the interpreter tries to map applicable parts of the user input to objects.
Let’s take “open the box” again. The interpreter knows that the word “box” is a noun and it will now check its object inventory to see if the text string “the box” can be mapped to an object. By default we want to exclude objects that the player cannot see from this mapping process. This means the interpreter must check the property “visible”. This also means that “visible” is a mandatory property in this world model and that the author must make sure it has the correct value.
It sounds like you have a core minimum in mind for what an authoring tool should do and want a spec to match that. I think it would be helpful to know what that was. What is the checklist of items you want the scenario to check off?
In other words, what is the list of things you think an authoring system should be capable of? I see this as a multi-level outline of criteria and then a scenario (and kit materials you spoke of) that addresses those criteria.
Ideally, no authoring system would meet all criteria. If you had a spec where one system came out with a score of 100% I would take it to mean that the spec was biased in favor of that system.
Once you have a decent spec, it will be much easier to come up with a scenario that fulfills the requirements. I recommend that the scenario still take place within the story world of Cloak of Darkness for the sake of continuity with the past. COD is well known and I think it would be good for buy in. Making a drink at the bar would certainly address a lot of the requirements under object manipulation. The bar is also a good venue to test NPCs and conversation.
Based on the prior conversation on this topic. I think some of the outline topics might start to look like this:
-
Input Accepted.
1.1. Parser Input
1.1.1. Whole bunch of technical stuff about parsing…
1.2. Mouse Click Input.
1.2.1 Hyperlink
1.2.2 Menuing
1.3. Drag and drop -
Navigation from place to place
-
Object manipulation
3.1. Standard verbs for objects.
3.2. Containment
3.3. Surfaces
3.3. Mixtures
3.3. Hooks? -
Non Player Characters
4.1. Goal seeking
4.2. Converstation
4.3. Travel
Can anyone point me to a COD in Squiffy ?