Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

has_not_created vs !is_exists

A topic by Garry Francis created Sep 05, 2019 Views: 219 Replies: 13
Viewing posts 1 to 5
Submitted(+1)

I have been using a test like:

: if (!is_exists "object") {}

quite a bit to test whether an object does not exist, i.e. is not yet in play. However, I have just discovered there is a has_not_created test, so that I can use:

: if (has_not_created "object") {}

I think the latter is better for me most of the time. Am I right to assume that the life cycle of an object that is not placed in a room or your inventory at the beginning of the game is:

  • nowhere (has_not_created returns true, is_exists returns false)
  • in play, i.e. after object has been created or pocketed (has_not_created returns false, is_exists returns true)
  • limbo, i.e. after object has been destroyed (has_not_created returns false, is_exists returns false)
Host(+1)

Yes, all your lifecycle assumptions are correct.

If an object exists at the start of the game, or is made to exist at any point during the game, then has_not_created will permanently return false. is_exists is for the current existence status of an object.

Submitted

Great. Thank you. I have one object that can be destroyed and recreated, so it needs !is_exists, and the others can use has_not_created.

Submitted

"Storeroom", seems to me a right and simple word to define the position of objects that "are not" in the game (word used in the TRS-80 Manual: Adventure Editor (Bruce Hansen))

Adventuron's documentation refers to "special non-existence location" or "object exists somewhere in the game world"; this can create confusion (but also words like Create, Destroy, is_exists, has_not_created etc.)
The objects are in the Storeroom or not. If they are then is_exists == false, otherwise is_exists == true.
The definition of the swap() function, is now correct (Swaps the location of object1 and object2) and easier to understand in this case:
o1 in room1 (is_exists == true)
o2 in Storeroom (is_exists == false)
swap (o1, o2)
o1 in Storeroom (is_exists == false)
o2 in room1 (is_exists == true)
I'm not sure I'm clear, but it seems to me that Storeroom makes it easier for beginners to understand things.

Host(+1)

I think the concept of non existing is relatively easy to understand.

If we used "storeroom" as an alias for the place where things don't exist, I'd personally find it more difficult to understand and find it more difficult to explain - especially as a lot of games may have a room called the storeroom. Certainly, I'll try to clean up the description in the documentation, but storeroom is not the appropriate name for the non existent place in my view.

Submitted

I quite like it as it is right now. It's convenient to know whether something exists or does not, instead of just shifting items around to additional rooms.

I definitely don't like the idea of a "storeroom". It's really very clear as it is. 

Submitted

I don't like the term "storeroom". Adventure authors have been using the term "limbo" for many years.

Inform handles this differently. Any object that does not start in a room is in "nothing". When it's destroyed, it returns to nothing. If you don't want it to return to nothing, you create a room called limbo and move the object to that room. In this way, you have full control over the life cycle of the object.

Adventuron does the latter automatically, but you can't return an object to nothing. There's nothing wrong with this. You just have to be careful to use the right tests for the situation and it needs to be explained more clearly in the user manual.

Submitted (1 edit)

THE ADVENTURE SYSTEM (1982):
"Room zero is reserved as a storeroom for objects currently not in any room. The player can not get to room zero by using one of the reserved directions. Actions usually do not permit the player to enter this room. The last room is reserved for some sort of limbo state should the player die. This is where the player is sent with a DEAD command. It may or may not contain exits back to the other rooms."

Submitted

So that's a bad word. This is probably due to my poor translation and understanding of these words.

Host

I'm very sorry if it feels like you received too much disagreement for your well-intentioned idea . 

Language is very very tricky, especially when it comes to coding semantics and many people have many strong opinions.  Gareth (8bitag) will tell you how I struggled even to settle on the name of location (for game locations) rather than room. I went back and forward second guessing myself. Also a struggle was naming the entities section objects.  I thought it was just more ergonomic to non-coders but I can't escape that it's really wrong. But, it's done now. A design is a design and you have to stick to it.

The idea of having a location where objects are when they don't exist is sensible, and as Garry said, most adventure systems use this approach. In Adventuron, the name of the place where objects are if they are nowhere is "ether". I don't use it in the documentation as I don't want to confuse children or beginners by making it known that nowhere is actually somewhere. But nowhere is somewhere - and existence is a per-entity attribute that is altered when an object moves in and out of the ether.

Submitted

Can an object move back into the ether in Adventuron? I didn't think it could.

Host

Ether is just the place where things don't exist. Anytime something doesn't exist in adventuron, it is in the ether. There isn't a place called limbo though. It's not that clever (or complex).

Submitted

No problem, we're talking and that's fine.

Your definition of the Swap function is incomplete. It can also create and destroy objects, as in my previous example. And it is important to mention it.
I will stop this very useful discussion here.