Zippy-Egoboo Home EgoWiki > Documentation > ModuleLinkingPlans EgoWiki webs:
Main | TWiki | Know | Sandbox
Documentation . { Changes | Index | Search | Go }
This topic is meant to facilitate discussion about module linking, so please add your comments.

Plans for Module Linking in Zippy

Overview of Current Plans

Current planning about module linking has covered the major gameplay decisions; it has been decided that module transitions can be of two types:

To this end, we need to make it possible to have multiple modules loaded and active simultaneously.

Gaps in Current Planning

The major gap in the above planning is that we don't yet know how players and characters will be transported between modules, or how the engine will determine which characters get transported. Example situations:

Ideas

Elmin's Idea

When a character activates a transport mechanism, it must initiate a LeaveModule action towards that transport mechanism. Characters that care about leaving the module with the player can put out a watch for actions of that type involving the player. A separate action, EndModule, must be initiated by the transport mechanism if the current modules are to be deactivated -- characters that want to do something before the module ends can cause this action to fail and then direct the transport mechanism to initiate the EndModule? action again when they are ready.

How this handles the examples above:

If LeaveModule is not overridden, the player will see his character enter the next module, and sometime later he will see his pet or monster enemy enter. If LeaveModule is overridden, we could engineer it so that the player "enters" the staircase and is stuck there until everyone who wants to leave has left.

Arakon's Idea

In the case of a module ending the old module, after loading the new one, that would make it difficult for a monster/pet to follow. Unless the module is not unloaded for a specific length of time - but then how long should that be? A simple fixed amount of time?

As far as the pets canceling a Leave Module though, we'd need to be careful that the pet can always reach the exit point in order to cancel the action.

I think the best solution would be to leave the module active for a limited amount of time, and let the Leave Module alert act as notification so that other NPCs can attempt to follow for that time frame.

The only problem I see with this is the delays that saving the module out will cause. It would be nice to save any persistant items of the module BEFORE play begins in the new one, so that all of the delays happen at once. We can't "cheat" easilly though, since a player may lay traps around the stairs to stop monsters, and if a monster can just leave with the player, it would avoid the traps. Maybe we could step up the simulation time for a small period to allow for unloading the module quicker?


Well, we can have the staircase put in a callback timer and initiate the EndModule action again after a certain time. Maybe one of the effects is TimeoutEffect, and convention is that nothing can override the initial value for TimeoutEffect. Then the apply_EndModule method for the staircase ends the module if either EndModuleEffect or TimeoutEffect is above a threshold.

As for saving, it's important to realize that we're not saving anything to file -- the only thing we might want to do is free all of the module data for an ended module minus whatever we want to keep about ended modules -- otherwise we're just loading a new module and making it the active one, then freeing whatever memory we can from the old module when it's done. I think we can safely figure out what data we want to keep (probably just modifications to the layout of the module as a result of digging and tile-swapping) and archive it whenever a module becomes inactive. So then if monsters are digging around after the player leaves, their digging doesn't get seen again unless the player goes back to the module before it ends (if the module becomes active again, we just discard our archived data). If this is the right gameplay decision, we should be able to work it out so that the performance considerations are minimal. Otherwise, we'll just have to go back and compromise on our gameplay decisions to make the performance work out.

-- ElminI - 25 Feb 2005

Topic ModuleLinkingPlans . { Edit | Attach | Ref-By | Printable | Diffs | r1.3 | > | r1.2 | > | r1.1 | More }
Revision r1.3 - 25 Feb 2005 - 23:22 GMT - ElminI
Parents: WebHome
Copyright © 1999-2003 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding EgoWiki? Send feedback.