OO and game design questions

Roy Smith roy at panix.com
Tue Oct 19 14:19:23 CEST 2010


dex <josipmiskovic at gmail.com> wrote:

> I'm building a turn based RPG game as a hobby. The design is becoming
> increasingly complicated and confusing

Such is often the case in real life code :-)

> In turn-based games, the order of action execution in battle can give
> unfair advantage to players. [...] Is there a design
> pattern that would remember changes to an object, and apply them
> later?

This sounds like a database transaction.  Perhaps what you want is for 
each object to include a delayedActions list.  Each time something 
happens to an object, you push a closure onto the list.  At the end of 
the turn, you run

for obj in global_object_list:
   obj.apply_delayed_actions()

> Sorry for the wall of text.

No problem.  The newsgroup ducks, swivels around on its Content-Type 
header, hides behind an NNTP outcropping on the server, and just barely 
avoids being hit by the oncoming wall.  You roll 2d10 and make your 
saving throw against Magical Text Wall, preventing any residual effects 
of the attack.  Whew, that was close!

In another article, Dave Angel suggested:

> Simply replace room B with a "destroyed room" object.  That can be quite 
> small, and you only need one, regardless of how many rooms are thus 
> eliminated.

I worked with an OODB system which did exactly this.  Each object class 
had a Class::Deleted singleton.  Whenever an object was deleted, 
references to it were replaced by references to the Deleted object.  For 
the most part, this worked, but resulted in a 4-byte memory leak for 
each reference (there was still a C++ pointer to Class::Deleted).

This memory leak was a known problem, but deemed to be small enough that 
we could live with it.  In the particular application domain we were 
working in, object deletions were rare.  I don't know if that's the case 
in your MUD.  I would assume that the physical structure of the world 
(rooms, corridors, doors) for the most part get created and rarely 
deleted, but that may not be true of other objects in the game?



More information about the Python-list mailing list