Thx Fuzz.
I don't have any formal training in databases. I once wrote a set of utilities for use with a de-clawed cue-cat bar code scanner, to search, reference, alphabetize, add and delete items from a master list based on the bar code.
My current project will be a step above that, involving multiple and user-creatable libraries with entries of variable sizes. Every entry would have the same form and be separated by a "|" token. The form would be thus: four fixed attributes, UnitName$, UnitDescription$, Unit_Health%, and Unit_PNG$ thumbnail path, followed by a series of attributes; StatName$ and StatValue, for however many stats a given unit needs. A set of these unit types forms a library, weather it be a Warhammer library, a D&D player library, a Creature library or so on. Units from any given library can be loaded into any of eight rosters, and thereby form a player army. So it isn't enough to simply look up units from a library, they have to be copied over to form player rosters which can then be modified as damage is done to a given unit. Rosters units must be deletable (when dead) or not (so they can be 'healed' or rezed.) In many ways managing the rosters will be more challenging than managing the static library lists.
Including weapons as items with their own stats would be problematic, for then we need some way of chaining a weapons 'unit' to a creature 'unit'. Hmm.. We could include a simple descriptions of any weapons and damage potential in the text of the Unit description, or even display, in a very simple way, a given weapon as an attribute with its own health bar as one of the Unit attributes; but the ability to call up a library of weapons to pick and choose from for a given unit is an entire level of complexity, the implementation vision of which eludes me. But now that the seed is planted, I'll have to chew on it. Maybe that can be a goal for version 2.0.
The program itself will be fairly inert towards any given roster, unit or attribute. No animation, no automated updating of stats. Nothing taken for granted. The program largely won't know what a stat is or means. So any changes must be made by the GM. (Maybe I can grey a unit when it's health bar reaches zero.) The program will simply show a list of units on a roster with a 'health' stat bar next to it. Click on a unit and a detailed description including the full set of stats and a thumb-nail (if present) will open in a window. Up to two windows (for two units from up to two rosters) can be open at the same time. To change a stat, simply click on the desired stat and a set of buttons will appear by which the stat can be changed by +/- 1, 5, 10, 100. This will modify the stat, even taking it to a negative value. Very easy for a GM to modify on the fly in the heat of a game.
The real challenge isn't in the libraries, which will be very simple text file lists. The challenge will be in formatting all of this on the screen and keeping track of each stat location on the roster and in the pop-up windows so they can be clicked on and modified. Throw list scrolling in there and things will get very complicated very fast. That is what scares me about this project. I may be over my head. lol
Anyway, as a data-base, the libraries will be very bare-bones and simple things; which is all I can really handle.
I've never heard of MySQL. Do you think it might be of help given what I have in mind? I would love it if you can give me a link or two to check out.
I'm not worried about efficiency of library file sizes (at least for version 1.0), but the data must be in a format which can be easily fed into my Unit TYPE structures.
That being said, anything which can make the job easier will be very welcome, so I am eager to take advantage of any advice you can give.
Cheers, Lee!
-CW
