Reply to thread

Message: [QUOTE="Lew Bloch, post: 599705"] But how to structure that process in my design? Interesting problem. Some of your space problems and complexity go away if you are willing to store references as object (e.g., monster) attributes. A reference is larger than an index, but it simplifies things tremendously. Allow me to essay a crude but, one hopes, illustrative object design, then you can pick it apart for flaws such as being too big for an embedded system. First, let me say that I won't speak to patterns as such. I am thinking in terms of composition and inheritance. I posit the following types (interfaces, ideally): Ability { ... } Weapon extends Ability { ... } Act { Set< Ability > abilities = new LinkedHashSet< Ability >(); .... } Monster { Set< Ability > abilities = new LinkedHashSet< Ability >(); .... } GameMaster { Set< Ability > allAbilities = new LinkedHashSet< Ability >(); Set< Act > allActs = new LinkedHashSet< Act >(); .... } Ability would be immutable, objects that report their state, such as speed augmentation factor, but never change it. At game setup, the master GameMaster object would initialize its lists with all available objects for the game to use. When a Monster gains, say, an Ability, it inserts a reference to an object from the GameMaster master "allAbilities" list into its private "abilities" list. The instance is shared by the GameMaster and by all Monsters that "have" it. This is relatively compact because you share instances between Monsters rather than have them add a new Ability(); to their private lists each time. The tricky part is to design Ability behaviors to support actions performed by different Monsters. One way is to make them completely passive - report factors that trigger Monster behaviors. For example, the Monster might have public void attemptAct( Act act, GameThing thing ) throws GameException { /* load required factors, e.g., speed, from Monster */ act.loadBaseFactors( this ); for( Ability a : act.getAbilities() ) { if ( act.requires( a ) && ! abilities.contains( a ) ) { return; } act.modifyFactors( a ); // apply mods from the ability } act.execute( thing ); // throws GameException } The Act object, "act", has to know how to perform its deed upon the passed "thing" - e.g., how to attack a Monster (subclass of GameThing). First it loads its attack factor (in this case) from the Monster's base attributes like strength. Then it examines each used Ability for how it affects those factors. The attack Act should know to add one to "strength" upon seeing a strengthPotion Ability, or subtract one for a fever Ability. After the Ability modification loop, the Act tries to do its thing (attack) to its GameThing target (other Monster), using its modified (attack) factors. (It can likewise scoop Abilitys from the target to calculate defensive capability.) This is a crude sketch, and optimizations suggest themselves almost immediately. The main point is that Ability objects are passive, so they can be shared and thus save memory. Actually, complete passiveness is not required, only immutability. The Ability class can define reentrant methods - no changes to the Ability's members, only to method parameters and stack variables. Incidentally, the Act object can be reused as each Monster gets its turn to try it. This also saves memory. I don't know J2ME so if java.util.LinkedHashSet isn't available use any java.util.Set, or failing that, roll your own with similar characteristics. [/QUOTE]

Verification