Cloak of Darkness 2

Great idea.

I think one crucial thing would be including a person you can talk to. One problem with this is that the type of conversation should probably be left open, so the definition of the game should avoid dealing with differences between SHOW and TELL etc - but something whereby the PC exchanges some information for an object or the other way around.

Maybe there could be something which includes a very specific verb? So the implementations need to go through how to define a custom verb. (If possible, this should be done in such a way that you can do it in a choice-type system, although the idea of a “verb” clearly applies more directly to parser languages.

Locks and keys and containers are taken for granted, but they’re not used in Cloak of Darkness, are they?

Thinking about it, it could even be hosted at http://www.intfiction.org, finally giving some content to the site! :smiley:

The big question, though, is if XYZZY will need to be implemented.

Seriously, though, I think an introduction hinting something like ABOUT and CREDITS would be good to have, since Beta-Testing and so forth are now part of what is expected from authors. As would X ME, which maybe could be hinted by the person you need to talk to.

I think you need to consider what features seem consistent in most IF systems. For example, should CoD2 have multimedia? If so, should the same image/sound/url be used in each model?

I think it should be limited to parser based languages. The choice based languages can come up with their own one if they want.

It should involve more complicated tasks IMO. Things like:

  • new actions, with multiple verbs including one that overlaps with an existing action
  • disambiguation
  • dynamic output
  • dynamically changing the names of nouns and have the parser match correspondingly
  • some form of conversation. peterorme said to leave the conversation interface open, but I think maybe it should be constricted. I think most systems can do menus?
  • implicit actions?

I wouldn’t make multimedia a requirement. We already know which systems can do multimedia, but this would be to help us choose based on some features which are harder to quickly identify.

As a choice-based partisan, I agree. I did a quickie implementation of Cloak of Darkness in ChoiceScript at one point; IMO it was a very awkward translation. It failed in its core task of demonstrating the similarities and differences between parser-based languages and choice-based languages.

IMO the parser-based tools are all helping the author build roughly the same kind of game, stories with exploratory puzzles, of which Cloak of Darkness is a reasonable example. Choice-based games often include no puzzles at all, and are usually tightly plotted, with no opportunity for free exploration (except on subsequent replays).

That’s an interesting idea, but probably unworkable. Some of the most interesting choice-based “languages” aren’t programming languages at all in the traditional sense: they’re web sites, like inklewriter, Varytale, and StoryNexus. Probably ChoiceScript and Undum would be the only relevant candidates where you could provide a web page with ASCII samples like firthworks.com/roger/cloak/

Choice based systems might be the better way to say it. I also don’t know if it would really help, do you think the various choice based systems are aiming for feature parity to any extent? Undum for example allows you to change text after it’s been shown, but I think some systems don’t, and it’s entirely fair for them not to make that a goal.

I think it’s more accurate to say that Beta-Testing and so forth have always been expected from publishers … and when authors self-publish, they inherit that expectation the instant they put the extra hat on their head.

My thinking about this is mostly in line with Dannii’s – it would be good to add features like dynamic output and dynamic name-parsing. Maybe a timed event.

At the same time, if the feature list gets too long, people won’t want to pick up the job for their favorite language. CoD was tiny, which is a big plus for it. We shouldn’t try to cover everything IF can do, or even that IF commonly does these days.

Multimedia is definitely a landmine. I wouldn’t go there. Neither is it necessary to talk about “x me” or “about” – those don’t demonstrate anything about the IF development system. The goal here (as I take it) is to give a developer an idea what writing in the language is like. It’s not about demonstrating good game-design practice.

I’m not sure about NPC interaction. It’s certainly important, but there are so many ways to approach it in a single dev system – does it make sense to compare them across systems? Maybe throw in the simplest possible case: you say hello to somebody, he replies with a specific message.

(If you want a sign of the times, try this: take darkness out of the spec. Darkness is no longer interesting.)

Hm, yes, when you put it that way, looks like X ME can go. But I think ABOUT serves a dual purpose of good programming practice and, more importantly, showing the user how to create a new verb on the simplest level.

Maybe the verb doesn’t have to be ABOUT, but it’d be nice to see a quick way to expand the parser’s vocabulary.

Is anyone willing to take this project on and be the driving force? I have too many things on my plate unfortunately. I’d hate to see this as just another of those projects that people think is a good idea, but just never gets around to being implemented.

Hey all.

It’s been a long time since I’ve been in the textual IF scene. Being overseas and lots of stuff have intervened. But in coming back, I saw this thread and I think this is a great idea. Back in the day I used to teach classes on textual IF, and I can tell you that we often experimented with different systems. In going back over my notes of those classes, here were what the majority of people wanted to try out, in no particular order:

  • The ability to customize the status line (if the system provides one) including not having it appear at all.
  • The ability to navigate between locations via different means (such as “go to” or “find my way to” type actions).
  • The ability to not rely on score, but rather on something like “Goals Completed” or “Actions Taken”.
  • The ability to implement “think about” or “remember” type actions and have those utilize a context-based data set.
  • The ability to intelligently handle implied actions when necessary or desired, including the ability to override default implied actions.
  • The ability to easily construct room descriptions that change based on in-game situations.
  • The ability to customize the interface to allow areas where concepts like “facts learned” would be constantly displayed.
  • The ability to customize the font style and viewpoint voice of messages that solely originate from the parser.
  • The ability to implement color as part of the text based output. (For example, different NPCs might “talk” in different color.)
  • The ability to implement an effective burn-down dialog option tree for NPC conversations.

There was also a focus on the ability to do action scenarios and usually this involved these (paraphrased) things in some variation:

“I want NPCs to act intelligently in the sense of following a scripted set of actions. Those actions can be interrupted by the actions of the player. But unless the player does something to alter the goal or the ability of the NPC to carry out the script, then the script should resume after the player is done interacting with them.”

“I want to see if the system can handle a time travel scenario. So I want to see if I can have the player’s actions recorded and then played back at a certain time by an NPC that represents the ‘previous self’ of the player. The player can then travel back in time in the game and watch their ‘previous self’ doing those actions.”

“I want a skills-based system, similar to an MMO or RPG. The idea is I want the player to be able to progress through ‘levels’ and certain actions can only be done easily if those ‘levels’ have been reached. These ‘levels’ do not have to be akin to hit points or attack rolls. It could be, for example, a measure of ‘persuasiveness’ in conversations. So the more conversation paths where the player got what they needed would earn them more ‘persuasiveness’ and that would make subsequent conversations a little easier.”

“I want a milestone ability. The idea here would be that the game has certain milestones that, when reached, will automatically trigger a ‘save state’ event. So if the player later gets into dire straights – or is just curious about what the other path would have been – they can revert to that milestone and go on from there.” [The rationale here is that the player might not know of a milestone so wouldn’t think to save at this critical spot.]

===========

I don’t know if any of this is in line with what is being sought for a new Cloak of Darkness initiative but I can say that being able to see how the above elements could be put in place was something that was a key determinant for those taking my classes. Just a hint of how the above concepts were possible was usually enough to inspire confidence in the system. Not everyone wanted the same things, of course, and not all people wanted all things to the same extent, but the above is fairly indicative of what I saw and heard most often.

Hope I didn’t derail the thread.

I understand where you are coming from, but I don’t think it’s possible to demonstrate most of that stuff in a short piece of source code.

You’ve got a mixture of very high-level and very low-level features there, and both sorts of cases are prone to be handled by libraries or extension code. E.g., the answer to the “think about” feature is liable to be “Use Epistemology by Eric Eve” (an extension). But seeing this line in a demo doesn’t tell you anything about Inform, except how to include extensions.

(Knowing that there is an Epistemology extension is valuable, but the point here is to get an idea what it’s like to code in a language.) (Reading the Epistemology source code would tell you a lot about Inform, but that’s way more involved.)

If there were a comprehensive guide comparing IF systems, these would be chapters in it.

Are you suggesting we should make one as an aside from COD2, perhaps including the sample within the guide?

Agreed. But does it have to be short? Or could there be iterations of the “short” version that build it up? (I think Hugo used to have a “Scavenger Hunt” example that was useful in this regard. You built up a version as you went, but you could stop at any point.)

Agreed. That, however, is what most people who want to learn a system need to have confidence with in terms of choosing a system, at least in my experience. Will it let me do the easy stuff and will it let me do the harder stuff? And what does the code look like when I do that stuff? How do I learn that as quick as possible so I don’t go down a path I don’t want to? These are questions I was often dealing with.

I’m not saying that’s what “Cloak of Darkness” should be answering to necessarily. I’m just saying that for many people I worked with, having a simple example like the original Cloak of Darkness was of little benefit largely because it was so simple and most of the manuals or tutorials for the systems available at that time adequately covered how to do the simple stuff.

Certainly a fair point. I wonder if a Cloak of Darkness 2 could be the springboard to that? Or am I starting to go too far into the weeds here?

I wrote a short example “The Flower Garden” a few years ago. (Tested disambiguation and pronouns.)
geocities.ws/ralphmerridew/Flower.zip

Contains TADS 2, Inform 6, ADRIFT 4, and ALAN 2(?) source, compiled, and transcript. TADS and Inform handled it without missing a beat; ADRIFT 4 failed badly (though a later ADRIFT 5 version handles it just fine); I don’t remember about ALAN.

1 Like

These are basic things that any IF system should be able to do (or that should be provided by Core Extensions That Everybody Knows About) and would be useful in a Cloak of Darkness-like thing:

These feel like generalist extensions, rather than core features. (Of course, how broad a range of extensions are available for a platform is of no small importance when choosing one, but I’m not sure that a Cloak of Darkness-like project is the best way to demonstrate that.)

And these next, I think, are more about novice designers/programmers who have solid experience as players of games, and strong, complex concepts, but don’t have the design background to figure out how they would build that given the tools available. There are only really two replies to this kind of thing. The first is “Yes, it’s possible, but you’ll have to work out how to do it yourself, and doing so will probably be somewhat challenging for a novice”; a human could do that, but there’s no real way for a pre-designed document to anticipate their specific needs. The second is “Somebody has already done all the work for you: here it is.” That’s the job of a highly specialised extension, not of a core feature showcase.

It would not be practical to cover design problems this specific within the scope of a Cloak of Darkness-like project. However, it might suggest some extensions that authors might want to implement; and certainly, a Novice Guide to Extensions might be a valuable project.

And, finally, this is a horrible thing that should be kept far, far away from new authors until they are proficient enough to know better.

As someone who doesn’t know any of these languages (Inform 7 only) I think I really soaked up a lot from reading the source code of “Flowers.”

I’m not an expert on what should be taught generally, but as a neophyte, I remember being intrigued by how easy it was to create a new verb, so I’d be curious how a new verb like “pluck (flower)” might work & if it would add too much overhead.

I don’t know if you want to add comments in the source code–I mean, I was able to pick out what does what generally, because the languages and the source are pretty readable, but it can’t hurt to have more explanation. Not that I can volunteer anything beyond questions of “Just checking, does this mean this?”

I’m not sure what else could be added without making the project start to bloat, but this seems at the very least a good start–besides maybe having a successful ending and an unsuccessful one. I also don’t know if testing commands fall under the scope of what you all want to do. As someone who’s never worked on the black box of adventure program writing, I can only speak as an end-product user.

Maybe you could add a bad ending for plucking the flowers and a good ending for sniffing them all. I don’t suppose story is terribly important here, but I don’t like ending with “>quit.” As I understand it, if the object is to show a complete game, it would be best if it were winnable and losable–like Cloak of Darkness is.

That’s my two cents–I’ll let you all decide what is useful and useless here.

So is anyone willing to take this on? It really just needs someone to coordinate the project. Perhaps one way we could come up with a game is to have a competition - everyone could enter a game in the system of their choice, then the most suitable one wins and becomes the new CoD?

How would we judge suitability – judge (or several)? An open vote, comp style?