Yes, but you can only write primitive types to files. How are you planning to store the locations of objects?
One thing to interject, here: if we bring the player back to relatively the same state after each adventure, then this wouldn’t be too much of a problem. For example, if I have the object from your story, and I begin my story with that object, then no matter what, I get that back at the end of the adventure. I won’t be able to lose that object, once the adventure is complete. This is not the best solution, as it would force authors to create some kind of artificial means to give the player back all of their previously gained items at the end of the story, but then the outside table would just have to check whether or not an adventure had been completed, and what they received in that adventure, to determine what they get back. Would something like this work?
I suppose so, but what if the player leaves my adventure after getting the object but before completing it, and enters yours? It would be odd for the save to suddenly remove that item from their inventory.
I suppose we could use some sort of system with two levels of saves. A “quick save” within an adventure is broken when the game updates, but a “real save” in the Wood (or whatever we’re calling it) would persist.
It only would do that if that item doesn’t exits in my game.
I know we wanted to keep this open ended to travel between stories at will, but maybe the stakes should be higher for the player on entering a story, a pass / fail state. Dying in a story could require an undo, or offer the chance to return to the forest, outside the story. If we integrate more RPG elements, maybe some stories will be too difficult to access or complete until completing other stories, especially if there is a main, arcing story. Stories could display their difficulty levels in the intro, offering players a chance to back out, or preventing them from entering.
You all know more about this than me. I only had an idea.
One suggestion to make collaboration easier: I’ll define an “author” as a kind of value, defined by a table. There can be a global variable called the “current author” which will be set upon entering a story. This way you can write rules like “Every turn when the current author is Draconis…”
sounds good to me
Also, if we do this, we can also have a various-to-one relation between things and authors. (“The banana belongs to Draconis. The coin belongs to Craftian. The banana belongs to Craftian.”) Then if the player enters a story where the object does not “belong”, the items can be automatically dropped. (In this case, the banana can be brought into my world or Craftian’s, but the coin can’t enter mine.) Perhaps they are incompatible with the structure of the world you are trying to enter or something.
Very good idea then. one question though. Who owns the first room?
Probably you, if you build the “in-between” area (which we really need a good name for). Or I can make the default be a “global” author, which indicates that an area accepts all items or an item can go into all areas.
Probably you, if you build the “in-between” area (which we really need a good name for). Or I can make the default be a “global” author, which indicates that an area accepts all items or an item can go into all areas.
go with global.
Probably you, if you build the “in-between” area (which we really need a good name for).
How about the Woods?
That would work, but I don’t want to be too close to C.S. Lewis’s work. Are we planning to have it be in a forest of some sort?
That would work, but I don’t want to be too close to C.S. Lewis’s work. Are we planning to have it be in a forest of some sort?
Why not? perhaps with a village. But for now we can call it the woods.
Okay. I’ll implement the author code and send it to you.
What sort of source control should we use? I’m most comfortable with Mercurial, but I can switch.
There we go, a prototype Worlds extension. I’ll put it up here for anyone who’s interested in collaborating.
Right now it’s just the “author” code, but as we go we can add to this.
Very nice – this will work great. I have an idea for abilities, powers, and curses, too. An ability, power, or curse could be connected to an object that is carried, but can’t be looked at or dropped, and is not listed in inventory. If a story gives a character superpowers, these would be connected to this object, and enabled when its carried, or disabled (when sent to this object holding room you’ve already defined) for a game world where this power doesn’t exist. Then, if the file that determines whether or not a player has finished a story tells the game that this power is unlocked by the player, and the power is disabled (not present), there could be a default explanation stating why the power is disabled, and this would be set by the author. Same goes for items. Instead of removing them from player inventory, swap them with items that don’t work, and have default fail messages. They can’t be dropped, because they are quest items, but are listed, because they are physical objects. This would keep the continuity that these objects are owned by the player.
That’s clever. How do you think that would best be managed? A “quest-based thing” kind, with an assembly to give it a non-working version, wouldn’t allow use of the container and supporter types. But assemblies don’t work with adjectives, only nouns…
What about an entirely disabled object created by the author. Each quest item will have 2 objects: the working one, and the non-working one. The non-working one goes to a holding room that is not accessible until unlocked. Then, the player is given the working one in game. At the end of the game, this is automatically swapped with the non-working one, and the working one is placed into a treasure room – a room of unlocked objects that are disabled. So, the player is always carrying either the working or non working object. The rule would be, that if there is an instance where an author takes everything away from the player, these items have to be restored by the end of the game unless there is a reason why the item is destroyed, and this would have to be agreed with by the author of the item.