Yep. What the title says.
Here is my crappy editor work-up from a little while ago: (It won't look this crappy later though)
http://i235.photobucket.com/albums/e...mat_AD/me1.jpg
http://i235.photobucket.com/albums/e...mat_AD/me2.jpg
Here's how I had/have it:
-The editor will allow you to rename any or all names of attributes/status_conditions, etc. to anything you want.
-There is support for 32 integers (stats), 64 16-bit integers (status/elements) and a shit ton of true false values.
-Attributes are basically stored as arrays with no knowledge of what it stores, just that it can represent a percentage or be added or multiplied together with other attributes. In this way it has no concept of things like "HP" or "Agility" at all. Consider this:
We have equipped 2 swords, 3 armors, and 12 accessories (hey, why not right?).
Suppose armor A increases all elements by 20 percent and lowers speed, B increases only HP and defense, and C increases all sorts of weird things but adds the status flag assigned to "Poison". (Forgetting about accessories for now.)
We'd like to just say that the players stats are [ base + a + b + c ] (armor only here)
There are a few quirks:
-Suppose that multiple items that modify by percentage are equipped. What is the order of operations? Do they stack like in Valkyrie Profile 2? ie; multiply, then multiply again. ..or are they non cumulative?
This also applies to buffs too I guess.
Back to more on what does the engine "needs to know": What is HP anyway? Is it edible? Can I @#$% it?
Suppose the battle engine sees that enemy 4 has -12 HP and decides to remove it. Suppose you gave it "Zombie" status, or cast Life 3 on it or something and now it's gone so you have to write a script to workaround the fact that it was removed in the first place. Why not just have the Battle Engine controlling script say "engine.remove_enemy(e)". This also allows scripts to customize death animation/effects, bring it back to like, or whatever. So we could say knowing about stats and effects are a bad idea to things that have no business knowing about them. If we just follow good c++ object oriented paradigms it will allow the most flexibility.
So... Attributes and modifiers are pretty important to get right at the get go since they cannot be changed easily. (This means you have to demand stuff be put before it gets to the shipping station)
[edit] Just to be clear; is this a reasonable way to do this, enough room for custom use? Should item and spell data use a different structure than characters and monsters?
Thoughts?
Reply With Quote