-
I think this isn't so much that OO design doesn't work but that the analysis that makes the actions methods of the objects is flawed. I think the actions belong to the "world" which acts on the objects contained in the world.
I think that having an instance of WorldObject class is the correct solution where the class can have a few attributes that objects have in common but little in the way of methods. The objects would have a list of catgegories to which they belonged [Breakable, Throwable, Eatable, Droppable, Burnable] etc. to allow the world to perform generic actions on them when there is no specific Interaction involving that exact instance of the object.
There would be an instance of this for each item in the world.
I'd model the interaction between items by having an Interaction class with the world containing *many* instances of Interactions. Some would be specific ones between individual item objects, and some would be interactions between categories of objects.
An interaction object would specify an action and one or more objects involved in that action. You'd then tie that interaction to a function in a "World" object.
When something happened the "world" would consult it's big list of all of the possible interactions between objects until it found a matching one and then perform the action required. It would look for actions involving the specific objects, and then if it didn;t find one look for the categories to which the objects belong.
So the world would know how to give an item from one player to another, or to combine two specific objects - the objects themselves would not care that they could be combined -
I've not explained this very well - I Might write up my ideas and post them somewhere as this is quite an interesting area for OO design.
-
Hmm I see your older post is somewhat similar to those thoughts. I should have read it first!
-
One nice thing about python is that you don't
actually have to care if it is a class or instance. As long as it does what you expect.
class Foo(object):
short = "A Foo"
long = "Gazing upon a Foo you see a bazzing bar"
>>>a = Foo
>>>b = Foo()
>>>b.short = "A dead Foo"
>>>print a.short
'A Foo'
>>>print b.short
'A dead Foo'
Design Patterns is mostly C++ specific, but the "prototype pattern" is where you create instances and then do customozation so the intsances all behave differently.
In python you have the luxury of doing it in the class or the instance. As long as getattr() behaves the same, who is to know? I also frequently use classes to get close, and then instantiate and tweak to get the exact behavior.
-
Well, there sure isn't any magic bullet for something as complex as role-playing games, but it's always struck me as perfectly natural to model the gaming world using OO practices as a foundation.
class Creature: # I'm old school
....
I think that we can agree that all critters, NPCs and such are creatures of some sort. They have location, size, weight, and a few other common attributes. Methods would include health monitoring, movement initiation, etc.
class Dragon(Creature):
....
Dragons are, of course, creatures. But where all creatures don't have wings, four limbs, and tails, dragons DO. They are also of particular size class (so maybe there's an intermediate class in there somewhere), special attacks, and a given range of hit points and damage. Blue and Red Dragons, of course, are subclasses of Dragon().
Class Elf(creature):
...
Elves are a specific size, weight range, etc, plus have thier own special attributes, such as improved vision, dexterity, etc. Not all elves are warriors or wizards, though, but not all warriors and wizards are elves, so we need to plan ahead:
Class WarriorMixin:
...
Warriors can be of various races, so we either get silly with subclasses or we get crafty. The WarriorMixin incorporates all the needed attributes and methods needed to manage a warrior of any race. Attack methods, advancement trippoints, skills, etc, are all defined here.
class Legolas(Elf, WarriorMixin, ArcherMixin):
def __init__(self):
Elf.__init__(self)
WarriorMixin.__init__(self)
ArcherMixin.__init__(self)
weapon1 = bowOfGaladriel()
weapon2 = elvenBlade()
inventory = [
weapon1 ,
weapon2
]
...
Combine the right class with the right mixins and you can create a pretty thorough description of the elements of a righteous AD&D; adventure.
Objects won't make it all work, though. Adventure games consist more or less of "nouns" (our classes) and "verbs" (thier actions) and sometimes the objects that they interact with. This is the part I always trip over. I can see the design of the objects in the world clearly in my mind, but defining an interaction framework does not lend itself to the same design. For this it really looks like procedural practices are more appropriate, with the big ugly bag of snakes that goes with it (i.e. "spaghetti code").
The fact I can't envision the entire thing doesn't convince me it wouldn't work, just that I probably need to think harder :-)
-
A metaclass can easily turn all your class's methods into classmethods. Something like (untested):
class ClassMeta(type):
__def __new__(meta, className, bases, d):
____for name, value in d.items():
______if isinstance(value, types.FunctionType):
________d[name] = classmethod(value)
____return type.__new__(meta, className, bases, d)
A better version wouldn't change quite everything into a classmethod, of course, among other details.
-
Just a though on your class list.. Instead of Room, you might think "Container".. A Container could be a room, or it could be a box. Since you open rooms, and open boxes, and they both contain "objects" (or other containers), thats probably a better concept. Could lead into interesting things..
> enter box
You enter the box, and you are magicly teleported to Mars.
You can't breathe.
You see Beagle2.
>
Not that I'm a game designer or Python Guru or anything.. Just a thought..