"bhaaluu" <[EMAIL PROTECTED]> wrote Let me preface this message by saying that I've never written a TAG before - either procedurally nor using OOP. so I don't know if the following approach is a good way to go or not. However it's where I feel things moving...
> I have a tendancy to think about > things as actual objects (but probably not OOP > objects -- more like real objects, like a vase). But thats the right way to go. The whole point of OOP is that you are trying to simulate the real world objects. Thats why people who haven't been trained in "classical" programming techniqiues usually find OOP much easier to pick up than experienced programmers do. Its logically more sensible to say "move a table" in a direction for a distance than to change the x,y coordinates explicitly! > Explorer: has strength & wealth, can carry weapons & food, > can wear armor, can pick-up treasure, can fight monsters, > can wound monsters, can defeat monsters, can move from > room to room. A good start so Explorer looks like a class with two scalar attributes: strength and wealth. Also a number of lists of objects - weapons, food, treasure and maybe armor. Looks like we might have a set of methods to pickUp(object) and to wear(armor) and maybe some test methods hasWeapon(weapon), isWearing(armor) etc. Also we have some methods around fighting, BUT... We are interested in what we can do TO the objerect not what it does to other objects (at least at this point). So rather than fighting a monster maybe the monster can be fought - ie the fight method is a method of monster? Except.... > Monster: can be anywhere, has Ferocity Factor / Danger Level, > can fight Explorer, can wound Explorer, can defeat Explorer. It looks like the same applies to monsters and Explorers. So maybe both Monster and Explorer are subclasses of a Fighter because they share the same methods. Now we can have a battle between two fighter objects - and this could allow the game to be extended to allow monsters to fight monsters and explorers to fight explorers, almost for free! class Fighter(object): def fight(self, fighter) def attack(self, weapon) def repulse(self, weapon) def isKilled(self) def currentStrength(self) Notice that one of the things that seems to come out of this is that maybe the strength attribute and the list of weapons belongs in the fighter class? Or maybe not if monsters don't have weapons - a design decision... Now we can make a stab at how the fight metjod might work: def fight(self, fighter): weapon = self chooseWeapon() fighter.attack(weapon) if fighter.isKilled(): self.strength += fighter.value And from this we could maybe do the attack method too: def attack(self,weapon): if self.canRepulse(weapon): self.repulse(weapon) else: self.strength -= weapon.value if self.strength < 0: self.die() And this reveals some new attributes and methods we can add, and also probably some ideas for how to write the repulse method too... And by constantly repeating this cycle of invent a bit, write a bit, test a lot we gradually build up the individual classes. Remember the >>> prompt is your friend for testing these things. Create a few instances of fighters and weapons and get them to fight each other using the prompt. When you stop being sure of where to go, go back to your text description and look for more clues about other objects that might help. As I say, I don't actually know if the above aproach will really work for a TAG but it looks worth a try. But one of the beauties of OOP is that each object is a mini program that can be played with and experimented with at the >>> prompt so you find out what works and what doesn't very quickly. HTH, -- Alan Gauld Author of the Learn to Program web site http://www.freenetpages.co.uk/hp/alan.gauld _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor