iOS Collections and a strange algorithm

Question

So I want to know if this is a good idea or a bad idea.

I'm building a simple iOS game (using standard UI Controls) which allows a user to create Characters, and Monster "Templates", then build Encounters which references Characters and Monsters and interact with them.

When the user creates an encouner, there is a simple Modal View which allows them to name the encounter, then push to another VC to select the characters participating, go back, push to a second view controller to select the Monster Templates involved, as well as how many of those monsters will be participating.

The goal, in the end, is to have the Monster Templates be used to construct "real" monsters that will be references in the Encounter.

Sample Encounter
  Player Characters
    Ramza Beoulve
    Delita Hiral
  Monsters
    Orc 1
    Orc 2
    Orc 3

For the character selection piece, I used an NSSet to store the Character Entities selected and pass it between view controllers. (This way I avoid having to mess with the managed object context very much prior to actually saving the new encounter)

For the monsters, since I need to store a quanitity as well as the entity, it's a little more complicated.

So my original thought was to store them in an NSArray of NSDictionaries which in turn contain the Monster Template and the Quantity.

The problem with that approach is I have to loop through the NSArray and open each individual dictionary to check if a particular monster template exists or not.

It might not matter much at this scale of application, but it seems inefficient.

So I thought instead it might be better to simply maintain two NSMutable Arrays

NSMutableArray *selectedMonsterTemplates;
NSMutableArray *selectedMonsterTemplateQuantities;

This way I can simply call

[selectedMonsterTemplates containsObject:monsterTemplate]; 

when I need to check if something is already in there, and when I add or subtract the quantity for a particular monster, I can simply update both Arrays.

Then when the Encounter is saved I can simply iterate over the Array once to create my individual monster instances in the quantity desired, and associate them with the Encounter.

I'm concerned that this approach, while simple and efficient, might lead to concurrency problems if there is a small mistake in the code. Is there a better way to go about this?

Answer 1

Maybe its a better design to add a class, lets say TemplateStore. (Or whatever you like)

@interface TemplateStore : NSObject {
   MonsterTemplate *template; //Super class of a monster entity. 
   NSInteger quantity;
}

- (id) initWIthMosterTemplate:(MonsterTemplate *)temp;
- (void) increaseQuantity;
- (BOOL) isKindOfTemplate:(MonsterTemplate *)otherTemp;

@property (readonly, retain) MonsterTemplate *template;
@property NSInteger quantity;

@end

WHen you store this kind of object in an array, you can iterate over it and use the isKindOfTemplate method to know if the MonsterTemplate exists. Then just increase the quantity.

Answer 2

Generally speaking, you wouldn't make an array of dictionaries just to hold structured data, you'd use a single dictionary with the item (template) as the key and the quantity as the value. Pseudocodey it would be like:

quantity=dict[template];

Of course that's assuming you have templates stored as pointers somewhere. A better alternative is to use structures:

struct monster_t { template_t t; int quantity; }

And then you hold an array of these things:

monster_t[] bestiary;

Or even better, figure out an ID of sorts (unique monster name file?) and hold it in a dictionary:

dictionary<string, monster_t> dict;
dict["big_monster_01"].quantity=5;

Of course this system is pretty useless, you don't care about quantity at all. What you do care about is about actual monster instances in the world, basically templates with customized values for hit stats, loot etc and a position:

struct monster_instance_t { monster_t template; vector position; }
monster_instance_t[] monsters; // who cares what they are? 
                               // that's what polymorphism is for!