Du könntest eine Art Diff der Objekte im Speicher halten - sprich: Wenn du die Map verläßt werden die Daten gesichert, die gegenüber den Standarddaten verändert wurden. Damit würdest du den Speicherbedarf reduzieren können.

Das könnte man so realisieren, daß du einen Queue von Pointern auf Structs mit Diffs hast, wobei jeder Diff angibt, zu welchem Objekt er gehört. Beim Laden der Map wird dann der Queue durchlaufen und die Objekte werden initialisiert. Die einzelnen Queues sind in einem Baum organisiert oder liegen als Member der Mapobjekte vor.
Falls das zu viel Aufwand auf einmal ist und die Maps hinreichend groß sind könnte man auch die Map partitionieren und die Objekte erst nach und nach initialisieren (alternativ könnte man auch Precaching betreiben und alle Objekte aus anliegenden Maps/Partitionen initialisieren, bevor der Spieler sie betritt; das braucht aber natürlich mehr Ressourcen). Allerdings muß man beachten, daß einige Events nur dann Sinn machen, wenn sie gleich aktiv sind.

Das mit den Timern könnte man dadurch lösen, daß man eine globale Liste (vermutlich Multimap) mit ausstehenden Events macht, in der sich die Events mit einem Zeitstempel (bspw. time()+300 für "in fünf Minuten") eintragen. Wann immer ein Stempel niedriger als time() ist wird die zugehörige Funktion ausgeführt. So muß man nur über eine Liste iterieren, anstatt 1000 Warteschleifen laufen zu haben. (Hmm, gibt's da nicht eine effizientere Wartemethode? Threads können ziemlich efffizient warten...)

Die Markierung, daß das Event durch ist, könnte man so machen: Wenn das Event in der Zeitliste gestartet wird wird es aus selbiger entfernt - wenn es wieder was getimert haben will muß es sich neu eintragen (oder man benutzt einen Befehl, um den Timer explizit zu beenden). Damit das Ding beim Betreten der Map nicht neu ausgelöst wird macht es im entsprechenden diff einen Eintrag, daß es bereits gelaufen ist.


Ich weiß nicht, ob dich diese Ideen weiterbringen, aber hey, du hast darum gebeten...