Quote:5. Table (has class PutableInventoryItem), it turns to Table3DObject, because in 3D world it has some actions, like put food on it, eat something.

Those are user (inter)actions. They have little to nothing to do with 3D.

The simplest way is to define a base class:

struct Action {  virtual string getName();  virtual int id();  virtual string getDescription();  virtual string perform();}struct InteractiveObject { // base class for objects user can interact with  list<Action *> getActions(User *); // get list of actions for given user};

This approach is known as command pattern. On creation, each instance populates its actions, or creates them on demand in response to getActions. In Java, Swing uses this with Action class to define UIs. Most other UI frameworks offer similar. QT, being almost a clone of Java standard library uses almost identical semantics.

Renderer will be completely separate, the only connection will be some ray picking algorithm, which will determine which piece of geometry the user clicked.

Then, the ID of this geometry is sent to server. Server resolves the ID to object, calls getActions, and serializes that back to client.

Client now displays the UI (popup or similar) with list of action names.

When user chooses an action, it sends its ID or similar to server, and server calls ->perform() on that action.

But there really shouldn't be any, or very little relation between 3D and logic. Or, logic should still be separate, but perhaps connect itself to collision detection. I don't think there is any realistic need for logic to know any kind of details regarding meshes or textures.

At least not at this stage, or for simple to moderately complex interactions.

Well, what you're talking about here is the result of crossing the list of verbs with the list of nouns.

The trick here is spotting that you're trying to express a MANY<->MANY relationship between nouns and verbs.

One of the simple ways of doing this is to imagine a grid. It has verbs across the top, and nouns down the side. The intersection of the rows and columns are what happens when you try and do verb V to noun N.

At each intersection, you want to be able to set what happens. So you have "EAT/BOOK" which says "it's not nutritious", "EAT/APPLE" which increases a stat. "READ/APPLE" doesn't do anything and "READ/BOOK" tells you what the book is about.

So what you have here is a "sparse grid" of actions. Where there's no interaction, you can just omit it. Your verbing system detects there's nothing there and says "don't be silly". Otherwise it calls the verb function.


So, the next question is how do you populate your rows?

The easiest way to do this is to have "mixin" classes. These are small aspects of objects, "Eatable", "Readable" etc.

The mixins just populate the rows of the object with function pointers.

This makes it really easy to do things like create new classes of objects; you can do it in one of two ways. Firstly you can list the mixins which make it up, but also you can use another object as a prototype.

So you can pick an INSTANCE of an object and use it as the root of a new class. You can say that "Orange001 is like Apple887, except that it has attribute[colour]=orange".

You can also clone the objects and add a mixin. Oranges often have a small label on them saying where they come from, so you can say "Orange001 is Readable, text='grown in Florida' " and now it can be read.

This is particularly useful for highly dynamic environments when you don't know how many of the things to make.

Serialising the object to a DB or other store is a little more tricky but with some thought upfront, not so bad. Firstly it's a set of name=value pairs. And secondly it's just a set of verb=functionname pairs. Store both and you can put the object in and out of a datastore.