jump to navigation

All About Dynamic Object Creation in Inform January 10, 2006

Posted by samwyse in Interactive Fiction.

New authors frequently don’t fully understand the difference between classes and objects. Don’t take offense, it is a common problem with which new authors often struggle. I don’t think that it is Inform specific, either; you need to understand the same concepts to use TADS’ mechanisms, or if you want to becom a professional C++ or Java programmer.You may want to take a break and read this:


All done? Good. In programing (be it Inform, TADS, C++ or Java), classes are very similar to Plato’s Forms. To use examples from the Wikepedia entry, we can write this:

Class Applehood
with name 'apple',
before [ ;
Eat: remove self;
"Yum!  That was a delicious apple!";
Class Redness
with name 'red',
description "It's red.";

We have defined two Platonic Forms here. We cannot use these in the game; no one would expect TAKE REDNESS to work in any game set in a physical world. But as authors, we can use these forms to create Platonic Particulars:

Object my_fruit "red apple" Kitchen
class Applehood Redness;

Now, when a player enters the kitchen, they will see an object that is described as red and that tastes like an apple. It is exactly as if the author had instead said this:

Object piece_of_fruit "red apple" Kitchen
with name 'red' 'apple',
description "It's red.",
before [ ;
Eat: remove self; "Yum!  That was a delicious apple!";

This is all well and good, but it turns out that authors rarely need to do this. Unless you need Applehood and Redness to encompass many more behaviors, and you have lots of objects that encompass various combinations of Applehood and Orangehood, Redness and Orangeness, it’s a lot easier to cut out the middlemen and just use that final definition.

When you do need to use classes, you almost never need to use multiple inheritance. “Multiple inheritance” is where I said ‘class Applehood Redness’ in my first definition of my_fruit. Instead, you want to create a lot of apples, and don’t want to retype the definition:

Class RedApples "red apple"
with name 'red' 'apple' 'apples//p',
description "It's red.",
before [ ;
Eat: remove self;
"Yum!  That was a delicious apple!";
Object apple1 class RedApples;
Object apple2 class RedApples;
Object apple3 class RedApples;
Object apple99 class RedApples;

This happens often enough that Inform lets you skip even more typing and just say this:

RedApples apple1;
RedApples apple2;
RedApples apple3;
RedApples apple99;

You can also pick a particular apple and change it a bit:

RedApples poisoned
with before [;
Eat: remove self; "Oops!  It was a poison apple!"; deadflag = 1;

This could be useful if you wanted to play Russian Roulette with Snow White or something.

An aside: you may have noticed that I’m using two different naming conventions for my classes and objects. If I’m defining a class, I name it using capital letters and run the words together, i.e. RedApples. (This is called camelcase, BTW, because the capital letters look sort of like the humps of a camel.) If I’m defining an object, I use lowercase and separate any words using underscores, i.e. piece_of_fruit. This is useful because I can now glance at a word and tell if it is a class or an object. Thus, when I see something like “move self to Spoon;”, I know immediately that something’s wrong, because Spoon is a class and thus shouldn’t have things moved to it.

As I’ve said, you almost never need to use dynamic objects. The exception is, however, something that new authors try to do and almost always fail: implementing things that normally exist in mass. Liquids are one example, money is another. Unless your game involves making change, you don’t want to implement money as seperate bills and coins, and you certainly don’t want to implement liquids as individual molecules. If the player has five doubloons, and receives another three, you don’t want to have two objects of class PileOfMoney to keep track of. Instead, you create a class that allows objects to be created and destroyed dynamically. When the player receives the object that represents three doubloons, the existing object that represents five doubloons is changed to represent eight, and the object representing three is destroyed. If the player then puts one doubloon into a treasure chest, the “eight” object is changed into a “seven” object, and a new object is created to represent the “one”, which is then moved into the chest.

All of this is very complicated, and should not be attempted by beginners. Suffice it to say that there are many special cases to consider. There are, fortunately, many extensions available in the archive to handle these cases. You should use one of them if you really need liquids or money in your game, and if you decide that not of them are suitable for your needs, then you should only write your own after the careful study of their code.

I hope that this helped. Good luck with your game.



No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: