Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>What I don't like in this solution :</p> <ul> <li>Simple solutions is best solutions</li> <li>Difficult to maintain since your xml is based on a graph.</li> <li>Don't really take advantage of OOP</li> <li>Source of bugs</li> <li>Probable use of <code>Reflection</code> for small problems (I say small because if your do a such game you'll face far more difficults problems ;) ). This implies unnecessary complexity.</li> </ul> <p>What I like in this solution :</p> <ul> <li>You have just perfectly understood the problem. Each item have a list of transormations with some other objects. Now the problem is how to <strong>represent</strong> (and not store) it</li> </ul> <p>What i would have do (juste IMHO, your solution is good, too) : use OOP in a node-only point of view. So your tree will become a <strong>state machine</strong> (as you were speaking about path ;) ) if you want to attach that to a data structure. </p> <pre><code>public class InventoryObject { protected Dictionnary&lt;Type, InventoryObject&gt; _combinations = new Dictionnary&lt;Type, InventoryObject&gt;(); public InventoryObject() {} public InventoryObject Combine(InventoryObject o) { foreach (var c in _combinations) if (typeof(o) == c.Key) return c.Value throw new Exception("These objects aren't combinable"); } } public class BlueHerb : InventoryObject { public Herb() { _combinations.Add(RedHerb, new BlueRedHerb()); _combinations.Add(GreenHerb, new BlueGreenHerb()); } } public class BlueRedHerb: InventoryObject { public BlueRedHerb() { _combinations.Add(GreenHerb, new GreyHerb()); } } </code></pre> <p>Then just call <code>BlueHerb.Combine(myRedHerb);</code> to get the result. You can also do <code>BlueHerb.Combine(myStone);</code> and easily debug.</p> <p>I try to keep my example as simple as possible. A lot of modifications can be done in order to light up the code (a class <code>Herb</code>, a class <code>CombinedHerb</code>, use LINQ queries, etc...) </p>
    singulars
    1. This table or related slice is empty.
    1. POComplex tree data structure
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USNicolas Voron
    1. USNicolas Voron
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COActually, what you just came up with is exactly the way I'm gonna handle 'HealthItems' - in general: items that occur more than once in the game, for a number of reasons one of them is there's no need to be a db for them because the numbers are limited (herbs, drugs, syringes, etc). I can pre-define all that via code. And I actually do have a lot of OOP going on, (inheritance, interfaces, etc) I just didn't show it. Also, the part where you mentioned dictionary, I do have a dictionary as well, with something very similar to yours.
      singulars
      1. PO
      1. USvexe
    2. COBut doing this to all 'other' type of items is just a lot of manual work, I can get away with a general solution that covers the "Other" category of items. Check out this thread for more info on my items http://gamedev.stackexchange.com/questions/59884/c-item-system-design-approach-should-i-use-abstract-classes-interfaces-or-vir?noredirect=1#comment106153_59884 - I have something in mind, I will see if I can answer my self. I will also look into your idea as well.
      singulars
      1. PO
      1. USvexe
    3. COPlus, the benefit of my db approach is that now the even game designer/artist could set the mates/levels/paths, I've already made a simple C# app for him to interact with and use for generating xml files.
      singulars
      1. PO
      1. USvexe
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload