dex <josipmisko...@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? -- http://mail.python.org/mailman/listinfo/python-list
