Game Objects?

Game Play & Game Design
#1

Just wondering how other people deal with in game objects in their projects, and what their thoughts were about it. I’ve always done mine with straight inheritance and composition, but I’ve just started to find out about active object frameworks, where you basically write your own object framework.

http://www.d6.com/users/checker/ObjSys.ppt is a description of what i’m talking about.

Most of what I’ve seen is in big studio production, with a very clear divide between programmers and designers. But I just like the look of this kind of thing from the flexibility you could get from it, along the lines of (assuming you were playing a MUD) (and talking about orcs coz im going to see ROTK tomorrow ;D)

light torch
throw oil at orc
throw torch at orc

The torch oil would set the flammable property of the orc, and the torch throw would set fire to the mofo.

Anyway, active objects(meta data, component framworks, call em what you want) have got me interested, what do you lot do?

#2

My older brother came up with a system for MUDS years ago he called DOOR (Door Object Or Room.)

EVERYTHING in the MUD is a DOOR. DOORS have two properties:
(1) They can contain other DOORs
(2) They can contain regexp commmands that run scripts.

I added one concept which was two regexp lists, an “inner” command list and an “outer” command list.

You throw strings at objects as commands. The match order AIR was follows:

(1) OUTER commands of my children
(2) INNER commands of my Parent
(3) OUTER commands of myself.

This simple structure allowed for virtually EVERY action necessary in a MUD. If you want some examples, describe a few scenarios at me and I’ll show you how it decomposes into DOORs :slight_smile:

A simple example is a lighting example.

Outer command “look” on the character is a script that prints my parent’s description.

A dark room has an inner command “look” that prints “The room is dark.” This has precedence (see above).

A torch has an outer command “look” that prints the description of my parent’s parent. So this overrides the dark room when placed in the inventory of the character.

While one could simply look for a torch object in the player’s inventory in the room “look” command, this would mean that the room would have to have apriori knowledge of all light sources. By using the DOOR paradigm the torch can be created after the fact and the dark room need know nothing about it.

#3

The moral of the DOOR story is that you really can’t ask “how should you architect a game” in abstract. There are specific architectures that lend themselves well to certain types of games. DOOR is great for a text adventure. It would suck for an FPS.