Reply to thread

Message: <blockquote data-quote="BeerSkunk" data-source="post: 349150" data-attributes="member: 6915">The evolution of the YugoYou're quite correct in your assumption.  The Character object would be a vast collection of data.  As new games come out, old games are changed, and new information about a character is required, the Character Object would evolve to incorporate all of that data.So, to use your vehicle example, lets suppose you take your Honda to the Saturn dealership and they say, 'Well, it's like a Saturn, but not quite.  It needs x, y, and z.'  So, they add the extra parts and voila.  It's now a Satonda.  Great, lets go to the Mazda dealer.  They add a few extra pieces and now it looks like a Mazda to them.  A Mazsatonda?  After a few more rounds of this, the car eventually morphs into a Tarrasque and devours everything in its path.  Humanity is ultimately saved! <img src="https://cdn.jsdelivr.net/joypixels/assets/8.0/png/unicode/64/1f609.png" class="smilie smilie--emoji" loading="lazy" width="64" height="64" alt=";)" title="Wink    ;)"  data-smilie="2"data-shortname=";)" />Our gangly beast of data does make certain requirements on those who view it.  It requires that when a Saturn dealer (Cthulhu) looks at our Honda (D&D char) he's able to recognize common parts that make up our car.  He recognizes our tires, steering wheel, motor, etc.  He's also able to look at the parts and map them to a language he understands.  Lets say the Honda wheel is labeled a 'RoundThing'.  The Saturn dealer then needs an interpreter to tell him that a RoundThing is what he would call a 'Tire'.  So, based on the model I've set forth, there is probably also a fourth piece now that would be necessary for Interpreting our common Object so that the OA could recognize it and make sense of all of its parts.Addressing your point about coupling data.  I would argue that part of the nature of the original problem (avoiding the need to rebuild the generator every time a new game or piece of data comes out) is because data and the rules are coupled.  The very act of coupling them dooms the effort, because now data has become self aware.  So, like a 2 or 3 year old running wild through the aisles at Wal-Mart, the data becomes unruly and difficult to manage because it's in constant need of attention.  It's environment (the game) constantly changes, therefore the data is needing to constantly change.  If the rules are coupled with the data, then those too will have to constantly change, which in turn necessitates that our generator is also constantly changing.  Damn toddlers!We're not going to eliminate the need for changes, nor would we want to.  We really just want to limit the changes so that our generator isn't broken by them.  This is why I separated things into three parts, possibly more as time goes on.  The parts so far are an arbitrary set of data, an Object, and an Object Analyzer  (possibly an Interpreter as mentioned above).   You could couple the Object and the OA into a single entity.  The only reason I chose to separate the two is because I believe that the data needs only to be data, and that it's possible for multiple, arbitrary OAs to share a single data set as long as they can interpret them.  If you couple them, you would need a separate Object/OA entity for every possible game.  If you try to combine them so that a single Object/OA entity covers every possible game, it would become so large and complex it would be unmanageable.I have more to say on the topic, but it's getting too much to post here.  I will add one caveat that I am well aware that some of my concepts have huge holes in them, but I can't address everything here.  Some of them I'm probably not even aware of. <img src="https://cdn.jsdelivr.net/joypixels/assets/8.0/png/unicode/64/1f642.png" class="smilie smilie--emoji" loading="lazy" width="64" height="64" alt=":)" title="Smile    :)"  data-smilie="1"data-shortname=":)" /></blockquote>

Verification