Messages

1

Game Modification Station / Re: FF1:DoS Projects

« on: November 10, 2017, 04:46:05 PM »

Still plugging away at my main project. Right now I'm putting the finishing touches on the Sea Shrine, which involved lots of changes to the map layouts and map features data, and even the addition of two new map palettes: as in the NES version, the Shrine gets darker the lower you descend. It's a nice touch that was left out of the remakes.

While adding a second exit warp to the bottom floor of the Sea Shrine, I also discovered a weird edge case with how sprites are handled: apparently, only the first two 0000 sprites on a map can be walked through, and any more have collision. That's a little odd, but there are other ways to indicate a warp tile so I'll put that issue on the backburner.

I may put together a quick readme and release a demo here. So far, all the testing has been done by myself, and while that's alright for technical issues there's bound to be problems with balance that I haven't considered or have become inured to. Having a fresh perspective on things like the overall difficulty, encounter rate, magic selection and classes would be helpful in general too. This demo would go up to the Sunken Shrine and Waterfall, leaving just the Wind Crystal dungeons and the final dungeon to go. Anybody here interested in giving it a try?

2

Final Fantasy IV Research & Development / Re: FF II: A Threat from Within - Expanded ROM = New Features!

« on: November 03, 2017, 01:35:40 PM »

Good to have you back! Though I myself am too swamped right now to do much hacking...

I'll second the suggestion to drop monster level scaling - I've never seen any such system that wasn't broken in some way, or else made leveling up pointless. Even making Agility (or even all five main stats) independent of level would be a neater solution.

edit: I do like the idea of multiple encounter sets for the same area. Wizardry 8 did something similar, where each area had a minimum and maximum level based on the party's average level, and would scale the encounter compositions only within that range. So if an area had a level 12-15 range, the encounters wouldn't get any tougher for a party past level 15, nor any weaker for a party below 12.

3

Game Modification Station / Re: FF1:DoS Projects

« on: August 30, 2017, 09:25:27 PM »

Don't remind me! I have enough on my plate these days 

4

Game Modification Station / Re: FF1:DoS Projects

« on: August 24, 2017, 01:22:16 PM »

Haven't done much with FF1 lately (Dragon Warrior 2 and X-COM have taken up my free time), but here's a little thing: 16x16 icons for all of the 200 map sprite IDs in FF1-DoS:


I plan to use this with Tiled, to be able to place NPCs on the map as a separate layer, and in the future I'll do something similar for other types of map features. Making this work would require a tool to read properties from the tile layers and the map, and then format it for insertion - so I may end up asking for your help in this area after all Squall.

Interestingly, the big gray statues of the Fiends that guard the entrances to the Soul of Chaos dungeons aren't a separate map sprite - they use the same ID as the regular fiend sprites. Either their associated Event ID or some hardcoding by map ID makes them gray and motionless. I haven't looked into the exact mechanism yet.

Also look at that broken robot sprite next to the beaver. In the Soul of Chaos floor where it normally appears, it can take several different forms; this is probably also due to some map ID business. Nevermind! It's just determined by the facing/sprite index byte.

5

Game Modification Station / Re: FF1:DoS Projects

« on: August 16, 2017, 05:45:58 PM »

Gotcha, that makes sense. In FF1-DoS, whether a tile can be walked over, if random encounters can be found and such are tied to the (logcial) tile ID in a separate data structure.

FF1a does support variable map height and width. I'm not certain what the maximum dimensions and area are, but the overworld is 255x255 logical tiles for example. Most maps are much smaller of course. It may also depend on the map type.

6

Game Modification Station / Re: FF1:DoS Projects

« on: August 16, 2017, 10:16:45 AM »

Actually, here's a better-formatted example of the tile data. This is the Western Keep tileset, first using the 'interior' set, then the 'exterior' set.

The top-left part of the image signifies...something. Maybe to do with the TSA or GFX headers? I admit this isn't my area of expertise. The central column represents the background tiles; the right column are the foreground tiles, which are layered over their corresponding BG tiles at runtime.

Edit: The stuff on the left is indeed part of the header; TSA data in FF:DoS starts with a twelve-byte header which defines things like the size of one TSA tile (usually 2 bytes) and the total number of such tiles.

7

Game Modification Station / Re: FF1:DoS Projects

« on: August 16, 2017, 09:21:57 AM »

Thanks for the excel tip - I'm not much of a spreadsheet expert.

The tile IDs in the tilemap refer to the overall 16x16 tile, but as you say, this ID is used to piece together two layers of 8x8 logical units - one layer for the foreground and one for the background. For example, here's what the 16x16 tiles of Elfheim's item stores look like, with each tile using its assigned palette:

I ripped this and every other tileset by making a map with every tile from 0-255 in 16-long rows, taking screenshots ingame and stitching those screenshots together. Thus, every 16x16 block represents one tile.

But on the more basic level, the tiles graphics are really made up of 8x8 blocks with transparency; here's how the same tileset looks in the ROM with TSA applied:

When the game reads a tile ID, it uses that to index to a set of tile graphics to load; here's some of my notes on the subject:

Code: [Select]

At 0x68644
-Upon loading a map tile ID halfword:
-Take low 4 bits, multiply by 4
-Take upper 12 bits, multiply by 256
-Add together, add to (decompressed) TSA pointer
-If map type is 0x1 and you're outside a room, add 0x20 lsl 0x7 (0x1000); save in r12
-This way, if you're in a room you'll load different GFX
-Navigate to next tile data to overwrite(?) r10 lsl 0x5 + r7 lsl 0x1 + 0x4C + r4; save in r3
-load [r12], [r12+2] and store to [r3], [r3+2] (top left/right of tile)
-load [r12+0x80], [r12+0x82] and store to [r3+0x40], [r3+0x42] (bottom left/right of tile)
-Storing to tile map as 'background' tiles
-Top nybble is palette ID, rest are tile ID
-load [r12+0x40], [r12+0x42] and store to [r4 + 0x84C + count*2], [r4 + 0x84E + count*2]
-load [r12+0xC0], [r12+0xC2] and store to [r4 + 0x88C + count*2], [r4 + 0x88E + count*2]
-For 'foreground' tiles drawn in front of the above tiles and the player character (eg for armor stands)
-Same format: top nybble as palette, rest as tile ID

When you say tile data, do you mean tile bits or tile properties (flip, palette,..). And in general does Tiled provide tile/palette data in a raw format that can be injected in the ROM without transformation? Or that is the separate process you mentioned ...

I mean just the tile map/list of tile IDs, with a header on top to define the map width and height. Tiled doesn't provide raw palette or tile GFX data, so if I want to modify the basic graphics or palettes of a tileset I do indeed have to do that separately.

8

Game Modification Station / Re: FF1:DoS Projects

« on: August 15, 2017, 09:52:33 AM »

Sorry I just poured out my thoughts. I guess the right question is: what data you get from Tiled and what data you need for FF1a (just in general no need for details)?

Having drawn the map in Tiled, the corresponding .tmx file contains an CSV-formatted list of the tile IDs used in each square. I copy that CSV data into an Excel-equivalent and make sure to format it all as text; from there I run "=DEC2HEX([cell] - 1, 4)" on every cell to obtain a hexadecimal halfword equivalent of each tile ID. I subtract 1 first because tile IDs in Tiles must start from 1, whereas FF1-DoS counts from zero.

At that point, we still need to make the data little-endian, so I copy the hex data from Excel into Notepad++ and use its column editing mode to remove the first column of 00's and insert a column of 00 at the end. This step obviously wouldn't work for tilesets that use tile IDs above 0xFF, but only the overworld does that, so in most cases it works out. I then copy the tile data into a separate .bin file and add the 8-byte header that all maps need; this header mostly just defines the map's dimensions. That done, I use BatchLZ77 to compress it, at which point the map data is ready to be inserted into the ROM, and I can update the map data pointer to point to the new map data I inserted.

So that's how the sausage is made. Far from elegant, but it works and doesn't take very much time once I got the hang of it...though a tool to automate and foolproof it would be handy. In general, I can leave the data for the tilesets and tile GFX/TSA alone if I just want to modify a map; editing those would be a separate process. Fortunately every aspect of a tileset is stored separately, so I can edit palettes without having to rebuild the tile arrangement data if that's what I want.

9

Game Modification Station / Re: FF1:DoS Projects

« on: August 14, 2017, 12:39:40 PM »

That's very generous of you! As it happens though, most of the work goes into setting up the map feautres and tile properties as well as just drawing the tiles; converting the tile data from .tmx to binary format takes only a couple of minutes, whereas mapping for the Waterfall was an hourslong process. Still, thank you for the offer.

If I can ever find the time to dedicate to such a project, an all-in-one map/tile property/map features editor for FF1-DoS like FFHackster's map editor would be ideal for this game; at some point I want to make a general-use editor for Dawn of Souls (probably in Python or Java), but that's a long-term prospect; programming a binary file editor like that isn't something I've ever done before.

10

Game Modification Station / Re: FF1:DoS Projects

« on: August 13, 2017, 08:39:41 PM »

Continuing on, I've recently coded and implemented a big change to the way equipment works:

• Equipment cannot be changed during battle
• Equipment that casts a spell can only be used in this way while equipped
• Spells cast from enchanted equipment (or items!) do not benefit from the user's Intelligence

This has a big impact on the way enchanted equipment is used - instead of anybody being able to use anything anytime, you have to be able to equip the piece and give up the appropriate equipment slot for it, so making use of a Healing Helm means a Knight or Ninja is going to miss out on a Ribbon. Preventing midbattle equipment swaps goes hand in hand with this design and eliminates the temptation to micromanage your weapons and armor each turn for the precisely optimal setup at that moment. Instead, equipment decisions must be committed to before battle begins, and using enchanted equipment becomes a more serious choice. In lieu of a more extreme reworking of how the inventory works, I like this system.

And since I still feel like writing, some thoughts on stat design - namely, the primary statistics Strength, Stamina, Agility, Intelligence and Luck. My philosophy with FF1 is that each stat should serve either one specific purpose or a few smaller ones; characters already have their levels classes, equipment and spell choices to set each other apart and define their power levels. With that in mind, here's how I'm thinking the primary stats should operate:

Strength
Influences physical attack power:

• Unarmed Master: ATK = STR + LVL/2
• Unarmed other classes: ATK = STR/2 + LVL/2
• Armed characters: Adds STR/2 to Attack

Strength does one thing and one thing only, which is just fine by me. It might be nice if Strength points above a given cutoff had a greater effect on your Attack (eg if you have more than 50 Strength, you add [STR-25] to Attack). A more radical alternative would be to make Strength influence a character's number of strikes instead of attack power, but I'm fine with the system I have.

Stamina
Adds STA/4 to maximum HP on level-up
Determines Master defense, Monk unarmored defense

Also pretty simple; the way it works for the Master is that his Defense is equal to STA/2, regardless of any equipped armor - he just ignores their defense values. Still, I don't like how Stamina only has a marginal, out-of-combat use for other classes. One idea I have to make Stamina more valuable generally is to allow it to mitigate a character's chance of being inflicted with a status ailment from a monster's physical attack, where:

Code: [Select]

Current: M = RES
Proposed: M = STA + RES/4This makes the Master uniquely resistant to status attacks while still leaving him vulnerable to the effects of spells.

Agility
Adds to Evade
Leader's Agility slightly influences chance of an Ambush/Normal/Preemptive Strike random battle
Influences turn order:

Code: [Select]

Priority = random number from (AGL/4..AGL+10); units with higher priority go earlier in a turn
This turn order formula is, btw, an edit of the vanilla formula of rand(AGL..AGL+50).
Vanilla Dawn of Souls makes Agility do even more things than this, but I'm still wondering if Agility is involved in too many formulas; I might like to make Evade based solely on your class (possibly with a level component) and equipment weight. What do you all think?

Intelligence
Increases power of damage and healing spells (rough formula is Damage = X + (INT*Y)/4 before defensive modifiers)
Increases accuracy of indirect spells like Slow and Hold

I'm continually indecisive over whether to make INT continue to directly affect spell damage, or to use an NES-like formula where damaging spells have an accuracy roll and deal double damage on a 'hit'. Otherwise Intelligence is right where I like it.

Luck
Influences success rate of Flee command
Adds a little bonus damage to damage spells
Target's Luck influences amount of HP restored by healing magic
Leader's Luck slightly influences chance of an Ambush/Normal/Preemptive Strike random battle
Cannot be modified by equipment

Luck does a lot of little things, but apart from maybe removing its bonus to attack spell damage I think that's acceptable. The main thing is the chance to run away; everything else is just a bonus. Dawn of Souls normally makes your chance to run based on Agility, Intelligence and Luck, but I think it's much more sensible to base it just on Luck; Agility already helps you out by letting a character try running earlier on in a round anyway.

11

Game Modification Station / Re: FF1:DoS Projects

« on: August 08, 2017, 12:18:45 PM »

After another while (and a hospital visit), I'm back. I took a break from moving forward with the hack to rip every tileset used by the game. One thing led to another and now I can edit maps semi-conveniently, using Tiled Map Editor.

It's not a perfect system, of course. Most tilesets have two sets of tiles used depending on whether you're inside a room or not, and a tile's graphics, palette and properties are all tied to its ID, which doesn't mesh well with how Tiled works. At some point I'll want to code a dedicated map editing tool for FF1-DoS, but for the moment Tiled works pretty well:


And, yes, that is a gigantic map. I got a little carried away, so the encounter rate is going to be cut to compensate. In fact I've reduced the frequency of random encounters in general; there are simply too many in vanilla Dawn of Souls, especially compared to the NES original's more restrained rates.

12

Final Fantasy V Research & Development / Re: Too many in-Battle Loopholes

« on: June 27, 2017, 11:19:39 PM »

I do not see how the majority of the boss battles would be improved by piling on the hitpoints; some of the Rift bosses do have too little health, but on the whole this aspect is well tuned. It's a credit to FF5's developers that they allowed for a savvy player to figure out alternative approaches to boss fights, rather than simply trading blows over and over. Even Omega has two purpose-built weaknesses, the Lightning element and song magic. If the player figures out how to combine abilities and equipment to deal 65,000 damage in a single round, I say they've earned their victory.

The Advance bonus dungeon bosses are a different matter, because there you're obviously expected to have grinded out the power combos and have all the best gear, so the bosses are balanced to match what a fully-powered up party is capable of. In the main game, you're not going to get much more than 2,000 ABP per character without stopping to grind.

And if 65K HP is very low, you should take a look at FF1. Chaos only has 2,000 hitpoints, and bonus boss WarMECH only 1,000, but you'd be hard pressed to claim that Safer Sephiroth is thousands of times harder to defeat than either of those two.

13

Game Modification Station / Re: FF1:DoS Projects

« on: June 21, 2017, 01:58:09 PM »

Been working on a few more things for the FF1 hack. First off, I've been going over all of the random and fixed encounters in the Citadel of Trials and rejiggering the map connections to make use of a few unused segments. The biggest thing missing for me to be able to completely redesign dungeons is the map data format itself; I haven't made any headway on that, for now.

Second, a minor enhancement for the Bestiary. It now loads and displays a monster's number of hits and Critical Rate (out of 200). It can help to make sense of the attacks of monsters like this little guy:

I had to shift all of the text and number positions around to get the extra line to fit, but I think it looks alright now.

Recently, most of my time has been spent working on spell animations. Some monsters cast NulShock or NulFrost in my hack, and it always bothered me that the animations for those spells didn't account for a monster using them - it appears as if your party is getting the benefits, which can be confusing. So, one dive into FF1's animation scripting bytecode later, that has been remedied:

Specifically, I switched the barrier animation to use that of NulBlaze - which does have a left-side animation - and horizontally flipping/repositioning all of the little thunderbolt animations There are several more spells that don't account for monster or player casting, but having done it once fixing other animations will be relatively easy. It's a good opportunity to document the scripting language too.

Related to the above, I've also fixed the Protera animation crash that arises when a monster attempts to cast Protera on more than six targets. The first part of the Protera animation generates eight animated objects per target that all remain active until the second part begins, which is more than the game can handle. My fix involved halving the number of animated objects used when a monster is casting Protera, which works nicely:


Next up...I dunno. Probably going to keep on with editing the dungeons/encounters/monsters etc. I'd like to have all of the main game see at least one pass before making an initial hack release, which could be a some time in the future yet.

14

Game Modification Station / Re: FF1:DoS Projects

« on: June 09, 2017, 11:01:41 AM »

I have to disagree with you there - to me it makes sense that magic attacks play by different rules. You've got to spend MP or a spell charge to use one, so for damaging spells at least you should see some impact even against a guy with 200 MD. If anything, the weird part about FF1's system is that spells deal damage within fixed ranges, though I like that part too.

15

Game Modification Station / Re: FF1:DoS Projects

« on: June 07, 2017, 07:45:15 AM »

I see what you mean. It may be a deliberate omission though, given how all spells must start from Level 1 and work their way up. Perhaps if Magic Evade was depressed all around it might work out, but that would still make higher level magic even better compared to its lower levels since it would now be guaranteed to do additional damage per hit on top of getting additional hits.

I don't recall was it the same in FF1 though ...

That depends on which version you're talking about. In the NES/PSX versions it works like this for damage spells:

Code: [Select]

E = Spell base Power
If target resists spell element, E = E/2
If target is weak to spell element, E = E*1.5
The above two modifiers stack.

Next, roll for spell hit. If spell misses:
Damage = [E...2E]
If spell hits:
Damage = 2*[E...2E]

A spell's chance to hit is dependent on its base accuracy, the target's Magic Defense, and whether the target resists or is weak to the spell's element(s).
Check the link above for more details.

As you can see, the caster's Intellect has no effect; it may have been intended to add to spell accuracy, but there's no way to know for sure.
For Dawn of Souls, the formula is almost completely different:

Code: [Select]

A = (Int+Luck)/2 + (Int/10)*SpellPow
B = Luck/2
D = [A...(A+B)]
If target resists spell element(s), D = D/2
If target is weak to spell element(s), D = D*1.5

Then the same spell accuracy vs Magic Defense calculations are followed, but if
the spell hits it only adds Int/5 to damage - no, I don't know why.

If and only if target is a player character:
   If MDF > 200: D = D/2
   If 200 => MDF > 100: D = D*3/4
   If 100 => MDF: D = D*7/8It's a weird, weird formula, and one I've made a point of changing.