A lot of people are dumping XML in favor of JSON. If you guys do decide to use XML, you might want to stop and consider it.Originally Posted by Flash Man
It might be a little less human readable (especially if you're not used to seeing it), but it's just as flexible if not more so than XML, while using less characters to express the same data. Supposedly there is no conceivable data structure that can't be expressed in JSON.
Shattered Earth, coming soon!
Mappers needed. If you want to help, send a PM to MasterSwordUltima.
I use and favor JSON in while working with Web technologies. Steam uses a very similar format called VDF. It can definitely represent all the data structures I think we will need.
For space saving we could even research the use of BSON.
Yes, I have complete and exacting info for how FFVI's data is arranged. What do you need to know exactly?
All spells in the game are one table (including sub-ranges for regular magic spells, esper summons, blue magic, and enemy-only spells).
This is distinct from the list of items (a couple of items are implemented with spells, i.e. they have a unique spell that is fired off when the item is used, but that is really an exception and not the rule).
Great! Thanks!
Do you know if items contain the same number of bytes regardless of type? (like potion : armor)
This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.
Let me direct your attention to this fine page: http://www.tales-cless.org/docs/ff6hack.htm#part4
According to this, every item is stored with 30 bytes, though not every item uses all 30 of them.
Shattered Earth, coming soon!
Mappers needed. If you want to help, send a PM to MasterSwordUltima.
Yes, in Final Fantasy 6, all items take up 30 bytes although I preface that by saying that many do no actually use the whole 30 depending on the type, and what the different fields within that 30 can mean different things based on the type (e.g. the same byte may be battle power on a weapon and defense power on an armor). Personally, I find 30 bytes too restrictive but of course if you're familiar with the game, they did a lot with those 30 bytes.
EDIT: rather than speak in hypotheticals, let me just post the data format:
Code:Item: Tools Weapon Armor/Shield/Hat Relic Item -------------------------------------------------------------------------------------------------------------------- $0000 Type (0) Type (1) Type (2, 3, 4) Type (5) Type (6) $0001-$0002 -- Equippable Chars. Equippable Chars. Equippable Chars. -- $0003 -- -- Spell Learn Rate Spell Learn Rate -- $0004 -- -- Spell Learned Spell Learned -- $0005 -- Field Effects Field Effects Field Effects -- $0006 -- Cond. 1 Protection Cond. 1 Protection Cond. 1 Protection -- $0007 -- Cond. 2 Protection Cond. 2 Protection Cond. 2 Protection -- $0008 -- Cond. 3 when Equip Cond. 3 when Equip Cond. 3 when Equip -- $0009 -- Status Effects 1 Status Effects 1 Status Effects 1 -- $000A -- Battle Effects 1 Battle Effects 1 Battle Effects 1 -- $000B -- Status Effects 2 Status Effects 2 Status Effects 2 -- $000C -- Battle Effects 2 Battle Effects 2 Battle Effects 2 -- $000D -- Battle Effects 3 Battle Effects 3 Battle Effects 3 -- $000E Targetting Targetting Targetting Targetting Targetting $000F -- Elem. Properties Elem. 50% Dmg. Elem. 50% Dmg. -- $0010 -- Vigor+/Speed+ Vigor+/Speed+ Vigor+/Speed+ -- $0011 -- Stamina+/Mag.Pwr.+ Stamina+/Mag.Pwr.+ Stamina+/Mag.Pwr.+ -- $0012 Attack When Used Attack when Used Attack when Used Attack when Used -- $0013 Weapon Properties Item Properties $0014 Attack Strength Battle Power Defense Power Defense Power HP/MP Affected $0015 Hit Rate Hit Rate Magic Defense Magic Defense Cond. 1 when Used $0016 -- -- Elem. Absorb HP Elem. Absorb HP Cond. 2 when Used $0017 -- -- Elem. No Effect Elem. No Effect Cond. 3 when Used $0018 -- -- Elem. Weak Point Elem. Weak Point Cond. 4 when Used $0019 -- -- Cond. 2 when Equip Cond. 2 when Equip -- $001A -- Evade%/MBlock% Evade%/MBlock% Evade%/MBlock% -- $001B -- ???/Spec.Atk. Special Action $001C-$001D Price Price Price Price Price
EDIT: Sorry, didn't notice that Glenn already said pretty much the same thing. I can only redeem myself by saying that I can get you info on what all these things mean, as well as any other data format, if it helps to illustrate how the game operates.
Thanks guys; I'm still going through those. I can't believe they were able to fit so much data onto one SNES cart. Pretty amazing when you think about it...
Anyway, I've got the complete monster sprite atlas done. Loading and saving xml and resources finally works now (including sprites and animations). So I can finally load these in, expose them to the scripting engine, and draw them. Not quite at the point where we can get down to it with enemy stats vs. player stats in combat, but I think getting something like a in-game bestiary done would be a good morale victory for now. :)
This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.
JSON (or possibly even YAML) is definitely a better way to go than XML. XML is ridiculously verbose; JSON is actually easier to read thanks to the removal of all the clutter the opening/closing tags bring with XML. You should go with what's most human-readable. Sure, XML would get you standardized validation, but if you're going to do things like smash tons of int values into a single text node like your example, you're losing a fair amount of that.
File size is pretty irrelevant; JSON/YAML has the benefit of being smaller, but no matter what the format it's going to be ultimately compressed anyway, and any text format is going to compress more than well enough.
Alright. I think I've the gist of everything properly sorted out. There's a lot of strange special cases, many of which can just be put into misc values though, like an item that can cast a spell or cast another spell when attacking and adds a status (debuff) effect that casts a random spell every turn (all of which should be possible with the engine - with a script)... weird.
..Anyway. Two design dilemmas:
1) equippable-by and jobs flags. If 32 character classes/etc is not enough these need to be changed to a dynamic bitset. (FFV I think only had like 22 jobs so 32 seems like it should be fine.)
1B) status effect flags. Same as above. (also same as below)
2) Elemental attributes: Similar issue,; have a fixed amount (32 total - though 20 is probably more reasonable) or a pay for what you use policy by making them dynamically sized. (see below)
2B) Elemental attribute logic: FF just uses bits for weak--strong--absorb. If we use this structure then elements only need to be three bitflags which represent elemental attribute data, and actual values need to be removed. Similarly, if actual values are kept for these then the aforementioned structure should not be used in favor of values over flags.
3) Status attributes: (Same as Elemental)
Side note: Yay encapsulation for being able to easily change stuff.
This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.
(all 3) - I like the dynamic sizes, for reasons I think I've explained already. But basically, I can imagine wanting to exceed some of those limits. Perhaps force bitwise flags if using more than 32 in a given chunk? I could live with that tradeoff. Or perhaps a mix of some bytes and some bits, up to a maximum size (which can be done via script anyway, not a problem). See my reasons below...
regarding elementals specifically: I used to always wonder why FF6 had separate bytes for each of the 4 elemental persuasions that it supports (in order of evaluation, they go absorb, nullify, 1/2 damage, weak, normal). I thought to myself, why not just have it store a multiplier per elemental (-2, 0, 1, 4, 2 in terms of halves)? But then I finally realized the answer: FF6 has the Debilitator, which has the effect of setting a random weakness to its target. If the target is already weak to everything, it misses. Otherwise, it will always pick an element at random, make the target weak to it, and clear any absorb, resist, or nullify that it may have. So, there is some monster which has all weaknesses already--but it also has all absorbs. Since the "weak to everything" check occurs first, this makes the monster invulnerable to Debilitator's effect.
Am I saying it can't be done with byte-per-element multipliers? Absolutely not. It would take more logic, but it certainly can be done. I'm just saying that sometimes there is a reason to do a bitwise elemental scheme. Also, if each element gets a multiplier, the multiiplier either needs to be a float, or expressed in some integral number of a fraction (like eighths). And it would also have to be signed (to account for absorb; i.e. negative damage).
---
A similar argument could be made for statuses, but I can see the flexibility that would be brought by having bytes to express a continuum rather than on/off. You could have Haste and Really Really Hasted with bytes. :) But I can't imagine Toad and Kinda Sort Toad. Some things lend themselves to binary quite well.
------------
EDIT: Another pair of design dilemmas:
1. The order of priority for elemental 'persuasions' (to use my word) is not always the same across games. If a game has a bitwise elemental scheme as above, then there is a priority (I mentioned FF6's system whereby Absorb is first and Weakness is last as an example). If there's a byte-scale to it, then it's conceivable to just add up the multipliers and get an aggregate (if that is desired), but typically the first 'match' wins in FF games so that would be a major change from norm.
2. Multi-elemental attacks: Again, noting the 'first match wins' standard, if a theoretical attack were to be flagged with fire and ice, and it hits a target with fire absorb and ice weakness, what should happen? In FF6, the full spell power would be absorbed by the target, as absorb has priority. It's conceivable to have it grant (2+(-4))/2 = 1/2 spell damage to the target by using multiples of 0.5 for each element involved. How do we handle multi-elementals, that is the question.
Last edited by Imzogelmo; 01-25-2013 at 03:29 AM.
There are currently 1 users browsing this thread. (0 members and 1 guests)
Posting Permissions
Reply With Quote