Objects - minimum, medium, and (near) maximum goals

When trying to create my own syntax (language), I get past branching (CYOP) and immediately consider objects and inventory. These items become so complex and so detailed, I don’t know where to begin (or end) for version 1. It seems that I continually think of something new, or something additional that “needs” to be added. At his rate, I am just spinning my wheels.

Is there a list (or pdf) of guidelines? Are their Tier 1, Tier 2, Tier 3, levels of thoroughness? Thanks for pointing me in a starting direction. Initially just looking for minimum and medium tiers.

1 Like

The way Colossal Cave worked, and the way I think the Scott Adams games worked too, was to have:

  • An array of room names and descriptions, indexed by room number
  • A variable for the player’s position (a room number)
  • An array of item names, indexed by item number
  • An array of item positions (each a room number), indexed by item number

For the last one, you’ll also set aside one room number to mean “carried by the player” (and perhaps one room number to mean “not anywhere”, for when you throw a treasure off the Cliffs of Despair).

Infocom went a step further and made things recursive: items and rooms (and the player!) are all “objects”, and every object has a location, which is another object. This gives you containers, supporters, etc.

But you don’t need that right away. Colossal Cave’s arrays work just fine.

Another possible “next step” is to give items more properties. Maybe each item has a description, which is printed when you examine it. At this point you may want to switch from a bunch of arrays to a single array of structs.

5 Likes

Colossal Cave’s arrays may work just fine now, but if you intend to implement more sophisticated systems later, I think you need to start with a system that can be extended without heavy modification.

Your first goal, I suggest, is system that allows items that can be picked up and dropped and listed in the inventory, but that would allow clothing, containers, light sources, etc. to be added later without re-writing the basics.

That said, trying to predict code that will be written in the future is not easy, and some re-writing will be required, but you will find it easier if you plan ahead. And so will authors wanting to implement their own weird gizmo.

thanks to both. Keeping track of where items are, is easy enough. A simple example of me over-thinking: Beside being locked or in chains, a refrigerator can be open or closed, on or off, plugged in or not, the light inside can be on or off. it can be cold or warm, you can put items in it (food), on it (magnet), on top of if. It probably never will be carried, but can be moved. What is enough, what is too much (meaning not just for the refrigerator but for all items).

From my experience, IF systems commonly implement:

  1. objects that can be opened, closed or locked (and only unlocked with an appropriate key)

  2. objects that are containers and objects that are supporters (in the fridge / on top of the fridge.) Different systems may differ in how they do this. Ideally it would be possible for a thing to be both a container and a supporter and the system would differentiate between both uses, but some systems take the shortcut where a thing can only be either a supporter or a container. In that case the story author might have to use workarounds for a fridge like creating a thing that is actually two things internally.

  3. objects that can be taken and cannot be taken.

IF systems usually do NOT implement:

  1. Something like magnets on a fridge. At least I haven’t seen it, yet. This seems like something extremely specific and the burden of implementing it should probably be placed on on the story author.

  2. Light/dark inside objects. At least from the systems I remember, lightness/darkness is usually reserved to rooms. (I may be misremembering, though.)

  3. cold or warm, plugged in or not plugged in. Again, these are probably things the game author should implement in a way that makes sense to the specific game.

Unless the refrigerator is somehow central to the game, you’d be fine including zero of these actions. For items that are important, one or two actions are probably sufficient. A good way to manage complexity is to have a clear goal and figure out the minimum you need to accomplish that. You might try playing some of the more minimalistic games out there.

I think you always have to keep your initial aim in mind, which I believe you said was to create a system that is incredibly easy to use. Keep that at the forefront of any of your decisions. Don’t try and chase the complexity of systems like Inform. If people want that… then they’ll use Inform!

I’m biased, but I’d say keep it simple, in the same sort of way that 1980s and 90s adventure writing systems did. Code the key common properties and then allow the user to assign (or associate) generic flags to reflect other statuses.

Common properties could include: its location? (including if it has been created or destroyed) portable (which can just be defined by the objects weight in respect to the strength of a player)? wearable? container? light source?

So a refrigerator - portable? NO wearable? NO container? YES light source? …maybe… I guess it depends if the door is open?
Then flags/variables to set whether the door is open or closed, it’s turned on/off etc.

Give an author simple building blocks and they can still use them to code complicated behaviours. How can I get around the issue with the fridge door being a light source? I know, I’ll have two fridge objects… one with the door closed, which isn’t a light source, and one with it open which has the light source property. I’ll just swap them over (without the player seeing) when the door is open/closed.

True, refrigerator was just for example purposes. I have to think more on containers and supporters.

I think the Scott Adams game format is a good example for minimalism (in his case, imposed by the very small amount of RAM on his target systems).

Rooms in his system have a description and nothing else. Objects have one property (portable vs fixed in place) and nothing else. There are global variables for the starting room, the “treasury” where treasures should be placed for points, and which object is the light source. Everything else is left to the user.

Now, this is both very minimal by modern standards and has a bit of unnecessary complexity: modern games don’t necessarily have a treasury and a light source. But those were standard assumptions at the time.

Definitely go back and look at the early Scott Adams system for Adventureland e.g. in SoftSide Magazine Issue 22 (Adventureland) : Free Download, Borrow, and Streaming : Internet Archive (July 1980) & Captain 80 Basic Adventures : Free Download, Borrow, and Streaming : Internet Archive It influenced so many later TRS-80, PET, C64 etc. games.

Ken Reed’s Adventure II article from Practical Computing in August 1980, defining a very similar theoretical system, was similarly influential https://vintagecomputers.sdfeu.org/mags/praccomp/1980/80aug_Adventure_II.pdf
particularly in the UK, leading to the development of systems like Trevor Toms’, the Graphic Adventure Creator, and the whole family of Gilsoft systems (The Quill, PAWS, The SWAN and DAAD).

They’re really good examples of very simple adventure systems and inspired hundreds of people to make thousands of games.

4 Likes

I enjoyed the article

Some great ideas already here, so I’ll just mention a few other things;

  1. Firstly, don’t bother to separate locations and objects. Make everything an object, including the player.

  2. You can get a long way with just one property “in”;

    objects in rooms are just objects “in” a room-object.
    inventory are objects “in” the player.
    objects do not need to be “destroyed”, just moved “in” to a special “dead” object.
    The current location is the object the player is “in”.
    For example, “drop” is moving an object from “in” the player to “in” the current location.

  3. Scope

    You’ll need the concept of “scope”. This is the set of things the player can interact with. It must be updated whenever the world changes.

    If you have a parser, you’ll need scope to resolve words into objects.

    for example. if there’s a “key” in the current location and also one the other side of the game. the word “key” needs to resolve to the key that’s in the scope.

    Scope is the set of objects recursively “in” the current location.

Get these three working and you’ll be able to make a small set of core “verbs” and thus a game.

good luck!

2 Likes

Great stuff. I’ll add
4. Game turn/player turn. This is to implement daemon for background tasks in the game.
5. I like to have LIMBO as scratch room for discarded objects. GAMEMASTER character as daemon server.

1 Like