Inherit from struct data - c++

Question

Imagine the following situation:
I want to create various monster factories. These monster factories create monsters based on the data provided by a struct array. The monsters only differ in these stats, therefore creating a subclass for each monster is overkill.
struct monster_data
{
int HP;
int strength;
int speed;
// even more attributes
};
A class monster can handle all the behavior of a monster based on a monster_data:
class monster
{
public:
monster(monster_data* initial_stats, int length);
void attack();
void walk();
void die();
// and so forth
};
So far, so good. Now I have a class monster_factory that creates monsters based on a hard coded monster_data array:
const monster_data district1_monsters[]
{
{ 500, 20, 4 }, // monster1
{ 550, 5, 12 }, // monster2
{ 420, 8, 10 }, // monster3
{ 310, 30, 7 }, // monster4
// 100 more monsters
};
class monster_factory
{
public:
monster_factory(monster_data* monster_to_create) ;
monster* create_random_monster();
};
My problem is that I have to support several monster_factories for several districts with with minor differences in the lists:
const monster_data district1_monsters[]
{
{ 500, 20, 4 }, // monster1
{ 550, 5, 12 }, // monster2
{ 420, 8, 10 }, // monster3
{ 310, 30, 7 }, // monster4
// 100 more monsters
};
const monster_data district2_monsters[]
{
{ 500, 20, 4 }, // monster1
{ 750, 5, 12 }, // MONSTER2B <<
{ 420, 8, 10 }, // monster3
{ 310, 30, 7 }, // monster4
// monsters 5 - 80 from district 1
};
const monster_data district3_monsters[]
{
{ 500, 20, 4 }, // monster1
{ 550, 5, 12 }, // monster2
{ 720, 80, 10 }, // MONSTER3B <<
{ 310, 30, 7 }, // monster4
// monsters 8 - 90 from district 1
};
Instead of copying and pasting the array data, I would like to somehow inherit from it, because the data stays mostly the same between the various versions. Copying the whole struct array declaration just to have a slightly different variant seems like the wrong way. Too bad that district 2 and 3 just don't append data, they modify and omit existing entries. Of course they change more than one monster, too.
In addition changes on the monster data of district 1 should apply to district 2 and 3 as well.
Another problem is that there are districts that will have monster data completely unrelated to districts 1,2 and 3.
const monster_data district4_monsters[]
{
{ 100, 20, 10 }, // monster 401
{ 200, 50, 20 }, // monster 402
{ 300, 40, 5 }, // monster 403
{ 400, 30, 30 }, // monster 404
// 20 more monsters unrelated to district 1,2 & 3
};
Now to the question: How can the outlined design be changed, so that redundant monster_data declarations are avoided and that districts can be added that either derive their monster_data from an existing declaration or use a completely new one?
Bonus points, if your design ensures that there can only be one factory instance for every variant of the monster stats list.

Answer 1

This can be solved elegantly by the decorator pattern by decorating the "default" table with the changes in each layer:
class MonsterTable
{
public:
virtual monster_data const* getMonsterForIndex(int i)=0;
};
class DefaultMonsterTable : public MonsterTable
{
public:
monster_data const* getMonsterForIndex(int i)
{
return district1_monsters+i;
}
};
class OverlayMonsterTable : public MonsterTable
{
public:
//public for brevity, should be private in real code - can also be std::map
std::unordered_map<int, monster_data> OverlayData;
// Init this with the "previous layer", which is always the Default table in your examples
MonsterTable* Decorated;
monster_data const* getMonsterForIndex(int i)
{
typedef std::unordered_map<VGLindex, monster_data>::const_iterator Iterator;
Iterator Overlay=OverlayData.find(i);
if (Overlay!=OverlayData.end()) // Monster data was changed in this layer
return &Overlay->second;
return Decorated->getMonsterFromIndex(i); // Defer to next layer
}
};
You would then add all "changes" in higher districts to the OverlayData and let the OverlayMonsterTable refer to the default table (district1).
To support omitting of data, you can either add another decorator "layer" that remaps indices (for example, maps [0...80] to [0...10], [30...100]), or integrate this functionality into the existing OverlayMonsterTable. Either way, you have full flexibility. For example:
class OmitMonsterTable : public MonsterTable
{
public:
int OmitBegin, OmitEnd;
MonsterTable* Decorated;
monster_data const* getMonsterForIndex(int i)
{
if (i > OmitBegin)
i += OmitEnd;
return Decorated->getMonsterForIndex(i);
}
};
Your factory would just take a MonsterTable pointer/reference.

Answer 2

You keep using the word "inherit" but I would definitely not consider inheritance here, you only have one type of behaviour, i.e. one type of factory class, you just want to initialize the factories with different data.
I would have one large array with all the distinct monster_data values:
const monster_data all_data[] = {
// district1_monsters
{ 500, 20, 4 }, // monster1
{ 550, 5, 12 }, // monster2
{ 420, 8, 10 }, // monster3
{ 310, 30, 7 }, // monster4
// 100 more monsters
// ...
// district 2 monsters (index 104)
{ 750, 5, 12 }, // MONSTER2B <<
// district 3 monsters (index 105)
{ 720, 80, 10 }, // MONSTER3B <<
// district4 monsters (index 106)
{ 100, 20, 10 },
{ 200, 50, 20 },
{ 300, 40, 5 },
{ 400, 30, 30 },
// 20 more monsters unrelated to district 1,2 & 3
// ...
};
Then create sequences containing the right ones:
typedef std::vector<monster_data> data_seq;
data_seq district1_data(all_data, all_data + 104);
data_seq district2_data(all_data, all_data + 80);
district2_data[2] = all_data[104];
data_seq district3_data(all_data, all_data + 3);
district3_data.push_back( all_data[105] );
district3_data.insert(district3_data.end(), all_data+8, all_data+90);
data_seq district4_data(all_data+106, all_data + 126);
Then create factories from those sequences:
class monster_factory
{
public:
monster_factory(const data_seq& monsters) ;
monster* create_random_monster();
};
monster_factory district1_factory(district1_data);
monster_factory district2_factory(district2_data);
monster_factory district3_factory(district3_data);
monster_factory district4_factory(district4_data);
If the monster_data type is only three integers that should be fine. If it's a bigger class then you could make data_seq a vector<const monster_data*> so it only holds pointers to the elements of the all_data array. That avoids copying the monster_data objects, they just live in the master all_data array and everything else refers to those master copies through pointers. That would take a little more work to create the vector objects, as you'd need to fill it with addresses of the array elements, not simple copies of the elements, but that's something you'd only need to do once at program startup, so writing a little more code to do it right is worth it:
struct address_of {
const monster_data* operator()(const monster_data& m) const
{ return &m; }
};
// ...
typedef std::vector<const monster_data*> data_seq;
data_seq district1_data;
std::transform(all_data, all_data + 104,
std::back_inserter(district1_data), address_of());
data_seq district2_data;
std::transform(all_data, all_data + 80,
std::back_inserter(district2_data), address_of());
district2_data[2] = &all_data[104];
data_seq district3_data;
std::transform(all_data, all_data + 3,
std::back_inserter(district3_data), address_of());
district3_data.push_back( all_data[105] );
std::transform(all_data+8, all_data + 90,
std::back_inserter(district3_data), address_of());
data_seq district4_data;
std::transform(all_data+106, all_data + 126,
std::back_inserter(district4_data), address_of());
An alternative, probably more maintainable, way to initialize the sequence for each district would be to have arrays of indices for each district:
int district1_indices[] = { 0, 1, 2, 3, 4, ... 103 };
int district2_indices[] = { 0, 1, 104, 3, 4, ... 79 };
int district3_indices[] = { 0, 1, 2, 105, 7, 8, 9, 10 ... 89 };
int district4_indices[] = { 106, 107, 108, 109 ... 125 };
Then construct a factory with one of those arrays (and its length). The factory can just pick an index from the list and then use it to index into all_data to get a monster_data.

Answer 3

Storing data in a binary is often bad practice and does not scale, especially if it is going to be a huge amount of data. You shouldn't have much trouble to define your own mini-language that supports simple inheritance of data and then parse it into a class that contains an unordered_map. That would enable you to also implement simple data sharing and a more complex property system, should you ever require it.

Answer 4

I'd have one factory where I pass the district when I ask for a monster.
Then I can do something like (pseudo code only)
getMonster(int district)
{
monster_data dat = getRandomBaseMonster();
// dat has to be a copy so we don't stomp in the base data
if (district == 2) {
dat.HP += 10;
}
return dat;
}

Answer 5

One solution may be to have a base table that contains the "standard" monster data, and then for each district you have a table containing only a list of the modified monsters.
something like this:
const monster_data base_monsters[] = {
{ 500, 20, 4 }, // monster1
{ 550, 5, 12 }, // monster2
{ 420, 8, 10 }, // monster3
{ 310, 30, 7 }, // monster4
// 100 more monsters
};
struct monster_change_data
{
int monster; /* Index into base table */
struct monster_data data; /* Modified monster data */
};
const struct monster_change_data district2_monsters[] = {
{ 1, { 750, 5, 12 } }, // MONSTER2B
};
const struct monster_change_data district3_monsters[] = {
{ 2, { 720, 80, 10 } }, // MONSTER3B
};
This way you only have to list the changed monsters.

Answer 6

For completeness' sake I'll post the design I came up with before ltjax posted his answer, although mine is inferior. As it has a different approach it might be of interest to others nevertheless.
It combines the factory with its table as the table by itself has little meaning.
The filling of the table is done in the factory's constructor. This way other factories can inherit the constructor and make changes to the table.
The drawback is that every factory creates its own full table therefore storing redundant data during runtime. At least maintenance becomes easier.
This might be improved by moving the helper methods add, replace and remove to a separate table class to encapsulate them properly. But monster_factory_abstract would be basically empty in this case, IMO.
class monster_factory_abstract
{
private:
monster_data* table; // or map with sequential indices
int table_length;
protected:
// add monster to table
void add(int HP, int strength, int speed, etc.);
// index starts with one to match monster names in this example
void replace(int index, int HP, int strength, int speed, etc.);
void remove(int index); // nulls an entry
void remove(int from, int to);
public:
virtual monster* create_random_monster();
}
class monster_factory_district1 : public monster_factory_abstract
{
public:
monster_factory_district1()
{
table_length = 0;
add( 500, 20, 4 ); // monster1
add( 550, 5, 12 ); // monster2
add( 420, 8, 10 ); // monster3
add( 310, 30, 7 ); // monster4
// add 100 more monsters
}
};
class monster_factory_district2 : public monster_factory_district1
{
public:
monster_factory_district2() : monster_factory_district1
{
replace( 2, 750, 5, 12 ); // MONSTER2B <<
remove(81, 100);
}
};
class monster_factory_district3 : public monster_factory_district1
{
public:
monster_factory_district3() : monster_factory_district1
{
replace( 3, 720, 80, 10 ); // MONSTER3B <<
remove(5, 8);
remove(91, 100);
}
};
class monster_factory_district4 : public monster_factory_abstract
{
public:
monster_factory_district4() : monster_factory_abstract
{
table_length = 0;
add( 100, 20, 10 ); // monster 401
add( 200, 50, 20 ); // monster 402
add( 300, 40, 5 ); // monster 403
add( 400, 30, 30 ); // monster 404
}
};