28 Feb, 2011, Kayle wrote in the 1st comment:
Votes: 0
I'm trying to determine the best way to go about this, so bear with me while I try and put it into words….

Ships are made of Components, components can be purchased from stores, salvaged from wreckage, or hand crafted by players with the appropriate skill set. Now, with the exception of store bought components, these components could have slightly altered stats from the baseline of the item. This is due to the fact that during player manufacture of these components, they can attempt to experiment with the design and features of a given component to try and boost certain stats. For example on a shield generator, they might experiment with the shield output, trying to make the shields more powerful while using less power, there is also of course the chance that the experiment could backfire and yield the opposite results, the shields are weaker and pull more power from the ships reactor.

Given this information, there has to be some kind of baseline for the component, a prototype. Now, store bought items would all be the baseline prototype, because they're mass produced by the components true manufacturer. But an experimental component, would not necessarily have the baseline components. So I guess what I'm trying to ask is, in your opinions what is the best way to go about having a prototype/instance system of a virtual object (meaning there is no physical object which gets created in the game world, it's just a name and number in a datapad menu), without having duplicate data structures (obj_data and obj_index_data for example)?

Currently, I have it set up so that in the component class, there is a Master field that is NULL if the item is a prototype, and which points to the Master copy if it is a derived or experimental object. In the instance of an experimental component on the components readout for the datapad it might show:

Your Parts Warehouse currently holds:
Incom TX-4 Starfighter Reactor 2 Incom TX-4 Starfighter Reactor 1
Incom TX-4 Starfighter Reactor 1

Now the first two might be the baseline item, but the second two would be Experimental items, And this is what got me to thinking my approach might not be the best approach for this given the possibilities of the above occurring. And now I'm looking for a possibly different approach, or a better way of continuing my current approach that might allow for a better solution to the above situation. If at all possible, I'd like to avoid duplicate data structures, but if that's the best solution, so be it.

Ideas? Input?
28 Feb, 2011, Davion wrote in the 2nd comment:
Votes: 0
Kayle said:
Currently, I have it set up so that in the component class, there is a Master field that is NULL if the item is a prototype, and which points to the Master copy if it is a derived or experimental object. In the instance of an experimental component on the components readout for the datapad it might show:

Your Parts Warehouse currently holds:
Incom TX-4 Starfighter Reactor 2 Incom TX-4 Starfighter Reactor 1
Incom TX-4 Starfighter Reactor 1

Now the first two might be the baseline item, but the second two would be Experimental items, And this is what got me to thinking my approach might not be the best approach for this given the possibilities of the above occurring. And now I'm looking for a possibly different approach, or a better way of continuing my current approach that might allow for a better solution to the above situation. If at all possible, I'd like to avoid duplicate data structures, but if that's the best solution, so be it.


The approach you're using appears to be very sound. I'm a little confused as to why this instance would cause you issues though. You're asking about the underlying mechanics of a prototype system, yet your showing a problem being displayed in the UI. I don't understand how your system exposes a flaw in this instance (more-so than any other.)

If you're using a system where items are derived from another, of course you're going to have times where two siblings are in the same list. This would be solve in listing, and fetching, rather then the underlying mechanics.

The route diku/merc took, with the two separate structures was likely for optimization. Live NPC's have no need for hit-dice, nor does index data have the need for hitpoints.
28 Feb, 2011, Tyche wrote in the 3rd comment:
Votes: 0
Kayle said:
Your Parts Warehouse currently holds:
Incom TX-4 Starfighter Reactor 2 Incom TX-4 Starfighter Reactor 1
Incom TX-4 Starfighter Reactor 1

Now the first two might be the baseline item, but the second two would be Experimental items, And this is what got me to thinking my approach might not be the best approach for this given the possibilities of the above occurring.


Make name one of those modifiable properties. I'd put all the properties in a map.

psuedocode

struct value
int type
union
string s
int i
float f
whatever w

class component
int id
int or ptr_t parent
map<string name,struct value>

component::struct value get_property(string name)
struct value
if ((value = map.find(name)) != NULL)
return value
else
return get_parent(this->parent) ? get_parent(this->parent).get_property(name) : NULL

A component with a null or 0 parent is a master.
Properties in instances derived from a master shadow properties in master.
Thus a basic instance would have an empty properties map.
An experimental instance would have just the properties that were modified in the map.
Properties might be derived from the master, like name…

If master had name -> string, "Incom TX-4 Starfighter Reactor"
creating experimental might derive its name as parent.name.s.concat("- Mk IV")
or name -> string, "Incom TX-4 Starfighter Reactor - Mk IV"
01 Mar, 2011, Kayle wrote in the 4th comment:
Votes: 0
Davion said:
The approach you're using appears to be very sound. I'm a little confused as to why this instance would cause you issues though. You're asking about the underlying mechanics of a prototype system, yet your showing a problem being displayed in the UI. I don't understand how your system exposes a flaw in this instance (more-so than any other.)

If you're using a system where items are derived from another, of course you're going to have times where two siblings are in the same list. This would be solve in listing, and fetching, rather then the underlying mechanics.


That example was probably a poor one given how late it was, but another example that has me concerned is the way they're tracked on players. I'm using std::map< Component *c, int amount> partsInventory; to track them, and my concern is that given that any could be a Prototype or an Instance, this might get confusing later on if I have to ever work on this again after it's done and several months or years have passed.
03 Mar, 2011, quixadhal wrote in the 5th comment:
Votes: 0
Taking a tip from database design here, add in a unique ID field that's empty for prototypes. If you modify (or copy) it, you get an instance with a unique ID. That way, you can easily serialize anything with an ID for storage. How you generate id's is up to you, I've found MD5 checksums work well, and so do the GUID things Microsoft uses. Integers will work too, of course, provided you don't lose your current counter.
0.0/5