LarryFr wrote:
I've began to create a database for storing all datas and I've got some problems with the squares.
If you have any ideas, you can contact me by MP.
I can't send PMs yet, but that's OK.
My database schema is in a bit of flux at the moment, and when it solidifies I'll pull together an ERD and send it off to you. Broadly speaking, I'm following a bottom-up methodology with this app. I started with the smallest components, such as ActivePowerTypes and Metas, for example. They hold the name and description of each item.
From there, the next stop is ActivePowers. I added a join table between ActivePower and ActivePowerTypes, because there are a handful of ActivePowers with two types, necessitating a many-to-many relationship. Metas were simpler, as there's always one-and-only-one each of physical, mental and spiritual metas. So I have three foreign keys in ActivePowers pointing to their respective metas.
This leads to Boards, which is indeed more complex. The Board itself just holds its type (active/passive/skills) and dimensions. Boards are always square, so I just hold one dimension. Thinking ahead (mainly of the Godi archetype), I also have foreign keys pointing to four sub-boards; but I digress.
I added a join table for a many-to-many relationship between Boards and ActivePowers (there are other relationships, to PassivePowers and Skills, but I'll just deal with ActivePowers in this post). Unlike the join table between ActivePowers and Metas, for example, which just holds foreign keys, this join table holds a lot of extra data.
In addition to the foreign keys for the Board and ActivePower ids, it also holds the row and column coordinates. I also needed to account for the many instances where a board links to an ActivePower, but modified it as well, giving it a different name, type, and metas. So this join table includes a column for name as well as foreign keys pointing to the physical, mental and spiritual metas. There's also a join table setting up a many-to-many relationship between this join table and ActivePowerTypes, to accommodate those cases where a board modifies an ActivePower giving it two types. Finally, I noted some cases where a board gives an active power a description of the power's effects, so I added a column for that as well.
The name, metas, types and description are all optional. If they are nil or empty, the system defaults to the values on the actual ActivePower.
All of this can be a little unwieldy to actually code against, so I've set up a series of simple facades. Take, for example, the Dweller class*. A Dweller object looks through all the ActivePowers assigned to it (through the BeingsRunes table, but that's another story), the rune tied to it, handles any modifications a board has made to that power, pulls in the void rune assigned to the Dweller's chosen archetype (I'm not 100% happy with how I'm handling Void rune assignments, one reason my schema is in flux) and any modifications made there, and puts it all into one, easy to use, hash. This greatly simplifies things like displaying the character in a view, and keeps the view code much cleaner.
*: As an aside, I don't have a Dweller table. I have a Being table with a type column (STI scheme), a Being class, and Dweller and Denizen classes which inherit from Being. The ORM handles the instantiation based on the type column. This is the reason I'm developing dweller and denizen support more or less in parallel.