News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: FF1 MMC5 Disassembly Updates  (Read 77375 times)

Jiggers

  • Sr. Member
  • ****
  • Posts: 254
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #300 on: May 12, 2019, 03:13:33 pm »
WHAT AN HORRIBLE NIGHT TO HAVE A CURSE.

Sorry couldn't resist. This idea is really in the wrong game in my opinion. Day/night cycles were never part of Final Fantasy series (except for story-related events).

Hee, I think we were all thinking that line. And that's exactly why I haven't put any more than passing thought into it. If I do code something like that, it'll be for when I branch off into making my own RPG--if the mechanics fit with whatever else I have in mind!
Good Evening;
I'm excited to see this project coming along so nicely.  I would like to ask a couple questions or make a couple suggestions (I didn't see them mentioned in the thread).
1)  Would it be possible to implement the ability to 'forget' spells? i.e. I purchased three level 1 spells, and I want to remove one of them.  In the original FF1 game this would not be possible and I would be stuck.
2)  The ability to move spells around.  For instance I have 'Fire' on the right portion of the level 1 spell list and I want to move it to the left hand side (for convenience)...or ideally anywhere I want.

Keep plugging along :)

~needsleepnow

Forgetting spells is in there! Have you tried the latest version? Its on Github now, I don't think I ever updated the first post in this thread... https://github.com/JiggeryPonkery/FF1-MMC5

I'm afraid, at the moment, moving spells around is too difficult to implement. In the original game you could pick what spell was where by the order you learn them, but because of the way I compress spell data to make all 64 spells learnable with only 8 bytes for each character, its not currently possible to even do that.

But, given that Vanya wants 128 spells, and I just freed up a lot more space in save RAM by getting music data outta there... we'll see what's possible when I get around to doing that. XD
I know exactly what I'm doing. I just don't know what effect it's going to have.

Vanya

  • Hero Member
  • *****
  • Posts: 1489
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #301 on: May 12, 2019, 03:19:44 pm »
But, given that Vanya wants 128 spells, and I just freed up a lot more space in save RAM by getting music data outta there... we'll see what's possible when I get around to doing that. XD

Werd!

Jiggers

  • Sr. Member
  • ****
  • Posts: 254
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #302 on: May 12, 2019, 09:01:09 pm »
So I made a Google Doc, even though I loathe Google Docs.

It lists bugs, things to do, and requests. It should be editable by anyone who can click it.

https://docs.google.com/document/d/1vXa_OLn408BxQ2GpIRRnGNPRJliOv_YBiP21ARdnhxo/edit?usp=sharing

So now I don't have to keep forgetting what I was doing and what people want to see!



So Mesen displays its frame rate as 60/30 ... sometimes it goes to 61/30 and that's when the airship shadow starts to flicker, then change between being solid or gone. Nothing to do with my other video settings.

Update: So RivaTuner just sets every game I play to 30 FPS I guess, instead of making sure FF14 caps at 60 frames...
« Last Edit: May 13, 2019, 04:39:34 pm by Jiggers »
I know exactly what I'm doing. I just don't know what effect it's going to have.

Vanya

  • Hero Member
  • *****
  • Posts: 1489
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #303 on: May 12, 2019, 10:15:10 pm »
That's a good idea.
It'll make things much easier.

I already have a list of little tweaks I think should be added to the base project.

Jiggers

  • Sr. Member
  • ****
  • Posts: 254
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #304 on: May 13, 2019, 09:44:45 pm »
We got a problem!

I was making a spreadsheet of all the treasures and shop items in order of where the average playthrough takes you, so I could start figuring out some treasure balancing issues that have been annoying me--and then I figured, why not add enemies to that spreadsheet!

Then in the middle of that I'm like, reading through this walkthrough that lists where enemies show up is tiresome, I'm gonna go through that battle formation list and mark things properly.

And so, it turns out Garland and the Pirates share battle data. And the Eye isn't a unique enemy? It shows up in groups of 2-3 somewhere else? I thought that was Phantoms that did that. So all those battles will play the miniboss theme instead.

I'll work something else out, but I don't think it will work for the Eye.
I know exactly what I'm doing. I just don't know what effect it's going to have.

Vanya

  • Hero Member
  • *****
  • Posts: 1489
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #305 on: May 14, 2019, 07:53:50 am »
Is there any room to expand formations so we can just make unique entries for all the high level monsters to have their own formations?

I also thought we could add new unique mini-boss monsters, but they would still need to have their own formations regardless.

So... is there enough space to do both?

Jiggers

  • Sr. Member
  • ****
  • Posts: 254
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #306 on: May 14, 2019, 02:15:21 pm »
Space is certainly not an issue. Its just the organization of everything...

There's 128 enemies, 128 battle formations. I know if I work at it I can figure out how to double that, but then there's so many smaller systems that need to be adjusted to handle that, too. Enemy name printing, stat loading, whatever else.

Adding new enemy graphics and palettes, I don't know if we'd have to add an extra bank and shift everything around, or if there's room for a few more where they currently are.

I think before I do something like that, I want to go through the fixed bank and make sure there's going to be enough room there for anything new. And finish up tagging data structures. lut_Domains, lut_MapObjects; I'd like to figure out which map is which!

Edit: Okay... not sure I can double battle formations. I think they already have.
Code: [Select]
LDA a:btlformation        ; get the formation ID
    AND #$7F                  ; remove the 'Formation B' bit to get the raw formation ID

Think what this means is that a battle formation ID of $80 would be the same as $0, but with the second formation.

HOWEVER.

Astos and the Vampire don't use a B formation. Nor do the Fiends or Chaos. I'll look into making them all share. So Lich has 1 battle formation with A and B instead of 2 with A, and so on.



Update: Changes pushed to github!

So it looks like Vampire, Astos, and Garland can't share because of the byte that loads the graphic sets. Like, they could share, but then you'd get Astos looking like a Vampire, I think? Which... to be honest, sounds pretty cool to me. The Fiends can all share themselves, because they're pretty much identical. I've kept the IDs the same for the tile battles, because I don't know how to change those yet, and changed the IDs in the talk routines so the initial "lighting the orb" battles should load up the first version of the fiend.

The pirates and Garland no longer share with Sahag/WzSahag and IronGolems, respectively. BUT, that's still 2 extra boss battles; one with mixed formation and one with 9 small enemies, if they're in the same graphic sets. There's also now 6 more regular battles to be filled in, though one of them will have to be sea enemies and one will have to be whatever the IronGolems share graphics with.

Adding more battle formations will be something beyond my ability at the moment, because we'd have to start using 16-bit numbers and I still only just barely grasp how its loading things up.
« Last Edit: May 14, 2019, 07:51:45 pm by Jiggers »
I know exactly what I'm doing. I just don't know what effect it's going to have.

Vanya

  • Hero Member
  • *****
  • Posts: 1489
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #307 on: May 14, 2019, 08:23:01 pm »
Excellent work nonetheless.
That's still a handful more formations than we had before.
I had forgotten that the Fiends have 2 fully separate formations.

Second question concerning these formations.
Is there room in the graphics banks to add more graphics sets?

And along with that, is there space for more graphics indexes to be called?



So single target attack spells are still borked?
« Last Edit: May 14, 2019, 08:57:01 pm by Vanya »

Jiggers

  • Sr. Member
  • ****
  • Posts: 254
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #308 on: May 14, 2019, 10:23:01 pm »
Good questions. So, I don't know if there's more space for graphic sets. Bank 7 and 8 hold most of the enemy graphics I think (I am having trouble opening them in editors again to check.) Going by the hex data, looks like both are full, so adding more graphic sets would involve pushing all the banks 1 over and having 9 be a third one for graphics.

Indexes--no, the way its set up now, all 16 are used. Would have to re-do how the whole formation is done to add more.

To be honest, until I get to Kraken or Tiamat, I'm not sure the new Fiends will even work. Maybe they each had their own thing because of some limitation I'm not aware of in how fiends are loaded; which means I might have to hunt that down and work out a way to add a B formation to the loading... >.<

Really out of my depth here again.

Code: [Select]
So single target attack spells are still borked?
Um... are they? I forget if I fixed it. Or did my fix not work...? Huh, it seems they don't bother casting at all now?! Rghh...
Edit: Oh. Loading the right command into A then pulling from the stack and overwriting it. Dumb. Fixed now?
I know exactly what I'm doing. I just don't know what effect it's going to have.

Vanya

  • Hero Member
  • *****
  • Posts: 1489
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #309 on: May 14, 2019, 11:32:33 pm »
Seems perfectly fine now! Woot!



EDIT:
OK I looked at the built ROM and it seems like al the graphics are indeed all right up against each other.
There is a ton of space in the ROM of course.

Farther down the line, I think it would fit into the scope of the project to rearrange things so there can be more space for various graphics.
Not just enemies, but tile sets and character graphics, too.
Might even be a good idea to look into expanding character graphics a smidge so that each class can have a special pose for their special skills.
Everyone that uses this as a project base is likely going to want to add things like this.

And if there is any tedious work to be done to make this happen, I'll be glad to volunteer!
« Last Edit: May 14, 2019, 11:50:23 pm by Vanya »

Disch

  • Hero Member
  • *****
  • Posts: 2728
  • NES Junkie
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #310 on: May 14, 2019, 11:45:42 pm »
I'm not sure the new Fiends will even work. Maybe they each had their own thing because of some limitation I'm not aware of in how fiends are loaded; which means I might have to hunt that down and work out a way to add a B formation to the loading... >.<

See 'FinalizeEnemyFormation_FiendChaos:' in Bank B

Code: [Select]
FinalizeEnemyFormation_FiendChaos:
    LDA #$01
    STA btl_enemycount      ; There is exactly 1 enemy for Fiend/Chaos formations
    LDA btlform_enids       ; Just use the first enemy ID as the only enemy in this formation
    STA btl_enemyIDs
    STA btl_enemyroster               ; ???  Duplicated to 6BC9?  Why?  I doubt this is ever used
    JMP WriteAttributes_ClearUnusedEnStats

That 2nd comment is the culprit you're probably interested in.  B formation only changes the quantity of enemies, but not the enemies themselves (that is, the "first" enemy ID in the list is going to be whatever enemy is listed first in the roster, even if it has a quantity of zero).

To fix this, you'll probably want to scan the enemy quantities (in btlform_enqty+0 through btlform_enqty+3) and use the first nonzero entry.  I whipped this together to do that.  Note it's untested, but unless clobbering X breaks something I don't see why it wouldn't work:

Code: [Select]
FinalizeEnemyFormation_FiendChaos:
    LDA #$01
    STA btl_enemycount      ; There is exactly 1 enemy for Fiend/Chaos formations
    LDX #3
    @ScanLoop:
        LDA btlform_enqty,X
        BEQ :+
            LDA btlform_enids,X
            STA btl_enemyIDs
            STA btl_enemyroster
      : DEX
        BPL @ScanLoop
    JMP WriteAttributes_ClearUnusedEnStats

That should allow for B formations to be used with fiends/chaos.  Note you are still restricted to one and only one enemy in each fight.  Changing that to allow multiple enemies would be a much larger task.

Jiggers

  • Sr. Member
  • ****
  • Posts: 254
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #311 on: May 15, 2019, 01:34:27 am »
Oohhh, thanks for pointing me to that! But I'm not sure I understand your fix...

I think this might be easier?

Code: [Select]
FinalizeEnemyFormation_FiendChaos:
    LDA #$01
    STA btl_enemycount      ; There is exactly 1 enemy for Fiend/Chaos formations
    LDA a:btlformation      ; See if this is a B-formation
    BPL :+                  ; if it is, load second enemy ID
      LDA btlform_enids+1
      JMP :++
   
  : LDA btlform_enids       ; Just use the first enemy ID as the only enemy in this formation
  : STA btl_enemyIDs

If I understand the way the formation data is stored... Oh, oh, I think I get what you're doing with X now. But wouldn't it keep looping through X, then, until it got to the last one anyway? And if not--wouldn't it be going through this even if it was an A formation, then end up doing the B formation?

Vanya: Yeah, definitely. I'd like some magic preparation poses like FF4, give the black belt a proper kick and have them zoom across like the thief does (and have the thief just show up behind an enemy, crouching, like Locke in FF6) and other wild things. I want animated summons, I want 8x32 character sprites in maps! Spacing things out is definitely a requirement for all that.
I know exactly what I'm doing. I just don't know what effect it's going to have.

Vanya

  • Hero Member
  • *****
  • Posts: 1489
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #312 on: May 15, 2019, 02:14:09 am »
Vanya: Yeah, definitely. I'd like some magic preparation poses like FF4, give the black belt a proper kick and have them zoom across like the thief does (and have the thief just show up behind an enemy, crouching, like Locke in FF6) and other wild things. I want animated summons, I want 8x32 character sprites in maps! Spacing things out is definitely a requirement for all that.

Damn, bruh! I thought I was bordering on overly ambitious! ;P
Seriously though, pretty much all of that is on my wish list.

For my own version of FF1 I, was thinking of using smaller character sprites on the overworld kinda like in Chrono Trigger to get the world to feel a bit bigger.

I'd be satisfied with static summons, animated ones would be icing on the cake.

You're putting my heads in the clouds, man! LOL

Disch

  • Hero Member
  • *****
  • Posts: 2728
  • NES Junkie
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #313 on: May 15, 2019, 10:43:06 am »
I think this might be easier?

Yeah that would also work but makes the assumption that A formation always uses the first enemy and B formation always uses the second enemy.  Which is a pretty safe assumption, but I like avoiding those kinds of assumptions.

Personal preference, I guess.  But yeah your approach should work just fine, and looks to be smaller.   :thumbsup:


Also... you don't need the 'a:' prefix (LDA a:btlformation).  That forces absolute mode.  If you get rid of it, the assembler will use zero page mode and you'll save a byte.  Those are only in the original disassembly so it would produce an identical ROM to the original, but functionally it's useless and wastes space.

Quote
Oh, oh, I think I get what you're doing with X now. But wouldn't it keep looping through X, then, until it got to the last one anyway?

It's looping to examine all four enemy quantities, and will use any enemy that has a nonzero quantity.  Since it's looping in reverse order (starting at 3 and counting down), the "last" enemy it finds will actually be the "first" one in the enemy list.  But that only really matters if there are multiple nonzero quantities, which there probably wouldn't be.

Quote
And if not--wouldn't it be going through this even if it was an A formation, then end up doing the B formation?

A/B formations don't matter at this point in the code.  The only difference between them is enemy quantities, and by this point A/B quantities have already been applied to btlform_enqty (see PrepareEnemyFormation)




.... but I just realized that this code runs AFTER the graphic for the fiend has already been drawn, which is stuck at using the graphic for the first enemy in the roster.  So both of our code will only REALLY work if they share the same graphic (which would be the case for the TOFR version of the fiend sharing a formation with their original counterpart).

Barrrrrrrrf.  So yeah my approach is not as dynamic as I thought.  Your solution is looking better and better, since there's a lot of assumptions with how fiend formations have to work.   :beer:

Jiggers

  • Sr. Member
  • ****
  • Posts: 254
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #314 on: May 15, 2019, 04:40:10 pm »
For my own version of FF1 I, was thinking of using smaller character sprites on the overworld kinda like in Chrono Trigger to get the world to feel a bit bigger.

I'd be satisfied with static summons, animated ones would be icing on the cake.

Hey, if you wanna do the sprites for that, I'd like to see them. A big part of why I am doing this instead of my own hack is I gave up doing map sprites because it was too hard to get the detail in such a small space. Ditching detail for aesthetics might work if it looks neat enough!

For animations I was more meaning like... 2x2 or 2x3 or 3x3 (scandalous!) sprite boxes that rise up from the bottom of the screen, flash a bit, then zoom off.

Barrrrrrrrf.  So yeah my approach is not as dynamic as I thought.  Your solution is looking better and better, since there's a lot of assumptions with how fiend formations have to work.   :beer:

Hah, thanks! I like seeing the neat ways you do things: The BPL and DEX stuff is something I could possibly use later, if I remember to. (And now to go kill all the absolute stuff...)

I think I might try re-jiggering formations to allow more graphic sets? Orrrr have the Fiend code do something else to pick the graphics. Figure out a way to make them use just one or two formations. Heck, maybe I can find a way for boss battles to not use formations at all just by faking the data somewhere... I guess today's one of those "I feel insane and nothing's looking impossible" days? XD

I finished my spreadsheet. It lists the general advancement of locations in game, the treasures found there (weapons, armor, items; not money or spells), and the enemies you can possibly encounter.

https://docs.google.com/spreadsheets/d/1VKrmx1zHV-rNP9wW7NV05fLNVCjFEhSXPkmxpODXOaI/edit#gid=835979563

The idea is that this will help figure out a better equipment advancement plan--get rid of "got this too late, now its useless" items, like the Great Axe, Long Sword, whatever. 6 classes, 50 levels, 64 weapons, gotta be a way to make it so each class gets a little upgrade more often. More hammers and knives and staves! More gloves and light armor for mages! ALSO, not shown in the spreadsheet yet, is the average level of the party when they get there.

Instead of steal difficulty for enemies, I'm going to give them a level, which should be near enough to the player's average level for the area the enemies first show up in. Then Stealing can be Thief Level vs. Enemy level, and insta-death spells can be Mage's Level vs. Enemy Level, or something like that, to make them more useful.

I've been playing with my experience boost option on, and I haven't needed to grind much at all so far. So the gameplay progression reminds me of Chrono Trigger, where the simple act of not running away means you're pretty much OK to handle things.

And I'd like to make battles just a little harder/longer to compensate. Just anything to get out of the "mash attack" mindset I find myself in so often. Making status enhancements a better use of MP and stuff; and then, depending on how that goes, maybe I'll be more inclined towards having MP work as later FF games.

Ideally, I'd want to make it so getting to level 50 by the time you reach Chaos isn't going to take hours of grinding. Maybe you hit 44-ish by then, naturally. I'm used to getting to level 30 by the time I'm ready to take on the last dungeon, then feeling blegh about not being strong enough to survive...

I worry that these ideas are drifting away from what people might enjoy about FF1, so they're not in my "do it next" list, though...

SO, back around to what I meant to say: What would be helpful, is if people would take the enemy list, reference the spreadsheet I made (or not!) and note down what level they think enemies should be. I'm doing that myself, but having a few different thoughts on what people think would be better for balancing it, surely?



Sorry to make such a giant post... but does this look right? Skipped over Thief Agility Vs. Enemy Evade for now. Its just Level vs. Level.

Code: [Select]
StealProbability_LUT:
.byte $5B, $4B, $32, $19, $05, $01
   ;; #91: same level
   ;; #75: 1 level lower
   ;; #50: 2 levels lower
   ;; #25: 3 levels lower
   ;;  #5: 4 levels lower
   ;;  #1: 5 levels lower

StealFromEnemyZ:
    LDA btl_defender
    JSR GetEnemyRAMPtr   
   
    LDY #en_item
    LDA (EnemyRAMPointer), Y        ; get their "has item" byte
    BEQ @Nothing                    ; battle_stealsuccess remains 0
   
    LDY #en_level
    LDA (EnemyRAMPointer), Y        ; get their level
    SEC
    SBC MMC5_tmp                    ; subtract thief level from enemy level
    BMI @Success                    ; negative flag set if thief is over the enemy level
   
    LDA MMC5_tmp                    ; next, subtract enemy level from thief level
    SEC
    SBC (EnemyRAMPointer), Y
    CMP #6                          ; if the enemy is 6 levels higher, automatically fail
    BCS @Fail                       
   
    TAX
    LDA StealProbability_LUT, X     ; get the probability based on the level difference
    STA MMC5_tmp
   
    LDA #0
    LDX #100
    JSR RandAX
   
    CMP MMC5_tmp                    ; if A is less than the probability, success
    BCC @Success                   

So many CMPs ... I feel like either the BCC @Success or the BCS @Fail is wrong...

Here's an alternative where it boosts the thief's level by 2 before making checks.

Code: [Select]
StealProbability_LUT:
.byte $62, $5A, $4B, $32, $19, $05, $01
   ;;  #98: 1 level higher
   ;;  #90: same level
   ;;  #75: 1 level lower
   ;;  #50: 2 levels lower
   ;;  #25: 3 levels lower
   ;;   #5: 4 levels lower
   ;;   #1: 5 levels lower

StealFromEnemyZ:
    INC MMC5_tmp
    INC MMC5_tmp                    ; add 2 to the thief's level

    LDA btl_defender
    JSR GetEnemyRAMPtr   
   
    LDY #en_item
    LDA (EnemyRAMPointer), Y        ; get their "has item" byte
    BEQ @Nothing                    ; battle_stealsuccess remains 0
   
    LDY #en_level
    LDA (EnemyRAMPointer), Y        ; get their level
    SEC
    SBC MMC5_tmp                    ; subtract thief level from enemy level
    BMI @Success                    ; negative flag set if thief is +2 over the enemy level
   
    LDA MMC5_tmp                    ; next, subtract enemy level from thief level
    SEC
    SBC (EnemyRAMPointer), Y
    CMP #7                          ; if the enemy is 7 levels higher, automatically fail
    BCS @Fail                       
   
    TAX
    LDA StealProbability_LUT, X     ; get the probability based on the level difference
    STA MMC5_tmp
   
    LDA #0
    LDX #100
    JSR RandAX
   
    CMP MMC5_tmp                    ; if A is less than the probability, success
    BCC @Success                   
« Last Edit: May 15, 2019, 07:58:00 pm by Jiggers »
I know exactly what I'm doing. I just don't know what effect it's going to have.

Vanya

  • Hero Member
  • *****
  • Posts: 1489
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #315 on: May 15, 2019, 10:50:11 pm »
Hey, if you wanna do the sprites for that, I'd like to see them. A big part of why I am doing this instead of my own hack is I gave up doing map sprites because it was too hard to get the detail in such a small space. Ditching detail for aesthetics might work if it looks neat enough!

Yeah, they will definitely be sacrificing some detail in favor of the immersion of a seemingly larger overworld.
I'll whip something up and post it when I get a chance.


For animations I was more meaning like... 2x2 or 2x3 or 3x3 (scandalous!) sprite boxes that rise up from the bottom of the screen, flash a bit, then zoom off.

That's still more than I was thinking.
Player sprites "blink/flash" away, Summon "blinks/flashes" in and does an attack.
Repeat blink/flash in reverse.

I suppose having a couple variations would be nice.
Maybe one rising up, one swooping in from above, and one blinking/flashing in.


I finished my spreadsheet. It lists the general advancement of locations in game, the treasures found there (weapons, armor, items; not money or spells), and the enemies you can possibly encounter.

https://docs.google.com/spreadsheets/d/1VKrmx1zHV-rNP9wW7NV05fLNVCjFEhSXPkmxpODXOaI/edit#gid=835979563

The idea is that this will help figure out a better equipment advancement plan--get rid of "got this too late, now its useless" items, like the Great Axe, Long Sword, whatever. 6 classes, 50 levels, 64 weapons, gotta be a way to make it so each class gets a little upgrade more often. More hammers and knives and staves! More gloves and light armor for mages! ALSO, not shown in the spreadsheet yet, is the average level of the party when they get there.

I sent a request to view it from figarosbackpack@gmail.
Technically 8 classes. 4 are just upgrades, and 2 are are reasonably different enough to count as separate classes.


Instead of steal difficulty for enemies, I'm going to give them a level, which should be near enough to the player's average level for the area the enemies first show up in. Then Stealing can be Thief Level vs. Enemy level, and insta-death spells can be Mage's Level vs. Enemy Level, or something like that, to make them more useful.

That's how most games do it.
It might be worth it to come up with a formula that calculates a level value based on an enemies' stats.


I've been playing with my experience boost option on, and I haven't needed to grind much at all so far. So the gameplay progression reminds me of Chrono Trigger, where the simple act of not running away means you're pretty much OK to handle things.

And I'd like to make battles just a little harder/longer to compensate. Just anything to get out of the "mash attack" mindset I find myself in so often. Making status enhancements a better use of MP and stuff; and then, depending on how that goes, maybe I'll be more inclined towards having MP work as later FF games.

I would advise not adjusting difficulty based on the HIGH settings.
If you make the game harder on the HIGH settings it'll feel amplified on the NORMAL settings.
Power creep can be a bitch.
However, you might want to add a difficulty option that adds a multiplier to enemy accuracy/damage as a fine tuning element on top of the XP, Gil, and encounter rates.


Ideally, I'd want to make it so getting to level 50 by the time you reach Chaos isn't going to take hours of grinding. Maybe you hit 44-ish by then, naturally. I'm used to getting to level 30 by the time I'm ready to take on the last dungeon, then feeling blegh about not being strong enough to survive...

Well, isn't that what the HIGH experience setting is for?
The way I see it the NORMAL setting should be pretty close to the original game in most cases.


I worry that these ideas are drifting away from what people might enjoy about FF1, so they're not in my "do it next" list, though...

A wise assessment.
Yeah it's important to examine the scope of a project as you come up with ideas for improvements.
In most cases, when you are considering a change that might fundamentally change the experience the original game offered, that is not strictly a bug fix, it is likely best to make it either optional or leave it out entirely.


SO, back around to what I meant to say: What would be helpful, is if people would take the enemy list, reference the spreadsheet I made (or not!) and note down what level they think enemies should be. I'm doing that myself, but having a few different thoughts on what people think would be better for balancing it, surely?

I'm considering whipping up an app in game maker to make some calculations and extrapolate a level value for any given enemy.


Sorry to make such a giant post... but does this look right? Skipped over Thief Agility Vs. Enemy Evade for now. Its just Level vs. Level.

Code: [Select]
StealProbability_LUT:
.byte $5B, $4B, $32, $19, $05, $01
   ;; #91: same level
   ;; #75: 1 level lower
   ;; #50: 2 levels lower
   ;; #25: 3 levels lower
   ;;  #5: 4 levels lower
   ;;  #1: 5 levels lower

StealFromEnemyZ:
    LDA btl_defender
    JSR GetEnemyRAMPtr   
   
    LDY #en_item
    LDA (EnemyRAMPointer), Y        ; get their "has item" byte
    BEQ @Nothing                    ; battle_stealsuccess remains 0
   
    LDY #en_level
    LDA (EnemyRAMPointer), Y        ; get their level
    SEC
    SBC MMC5_tmp                    ; subtract thief level from enemy level
    BMI @Success                    ; negative flag set if thief is over the enemy level
   
    LDA MMC5_tmp                    ; next, subtract enemy level from thief level
    SEC
    SBC (EnemyRAMPointer), Y
    CMP #6                          ; if the enemy is 6 levels higher, automatically fail
    BCS @Fail                       
   
    TAX
    LDA StealProbability_LUT, X     ; get the probability based on the level difference
    STA MMC5_tmp
   
    LDA #0
    LDX #100
    JSR RandAX
   
    CMP MMC5_tmp                    ; if A is less than the probability, success
    BCC @Success                   

So many CMPs ... I feel like either the BCC @Success or the BCS @Fail is wrong...

Here's an alternative where it boosts the thief's level by 2 before making checks.

Code: [Select]
StealProbability_LUT:
.byte $62, $5A, $4B, $32, $19, $05, $01
   ;;  #98: 1 level higher
   ;;  #90: same level
   ;;  #75: 1 level lower
   ;;  #50: 2 levels lower
   ;;  #25: 3 levels lower
   ;;   #5: 4 levels lower
   ;;   #1: 5 levels lower

StealFromEnemyZ:
    INC MMC5_tmp
    INC MMC5_tmp                    ; add 2 to the thief's level

    LDA btl_defender
    JSR GetEnemyRAMPtr   
   
    LDY #en_item
    LDA (EnemyRAMPointer), Y        ; get their "has item" byte
    BEQ @Nothing                    ; battle_stealsuccess remains 0
   
    LDY #en_level
    LDA (EnemyRAMPointer), Y        ; get their level
    SEC
    SBC MMC5_tmp                    ; subtract thief level from enemy level
    BMI @Success                    ; negative flag set if thief is +2 over the enemy level
   
    LDA MMC5_tmp                    ; next, subtract enemy level from thief level
    SEC
    SBC (EnemyRAMPointer), Y
    CMP #7                          ; if the enemy is 7 levels higher, automatically fail
    BCS @Fail                       
   
    TAX
    LDA StealProbability_LUT, X     ; get the probability based on the level difference
    STA MMC5_tmp
   
    LDA #0
    LDX #100
    JSR RandAX
   
    CMP MMC5_tmp                    ; if A is less than the probability, success
    BCC @Success                   

I feel like these could be simplified.

steal difficulty = target's level - thief's level (minimum 1)
make a hit roll (0 ... 49)
if hit roll > steal difficulty, steal succeeds
else, steal fails

No need for a table.

Jiggers

  • Sr. Member
  • ****
  • Posts: 254
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #316 on: May 15, 2019, 11:18:35 pm »
Bah, Googledocs. The file should be set to viewable to everyone now. Sorry!

Working up a lot of new stuff; Player Regen is almost ready I feel. Soon as its done, I'm taking a break for the night, so I'll reply tomorrow! Just wanted to update on the spreadsheet link working now (maybe???)



Regeneration is live. I've changed the Heal spells to do it for testing purposes; if you don't want it, look for lut_MagicData in Bank C and swap the commented-out Heal data lines.

There's 3 potency variations, which are set by the effectivity byte, and up to 15 turns of regeneration, set by the Hit Rate byte. Regeneration is effect $15.

Instead of using the magic healing code to do it, it works more like the enemy regeneration code (and in fact, shares some of the division routines with it now!) It uses the battlestate ch_stat as well: The low bits are how many turns to regenerate, and the high bits are the two in the middle:
%0xx0xxxx <- regenerating
%10000000 <- guarding ($80)
%00010000 <- hiding ($10)

So $2x is low potency, $4x is medium potency, and $6x is high potency. That's about 9% HP restored per turn, or 19%, or 25%. I tried to get it to 15% for medium potency but... dividing is finicky and I didn't want to deal with setting up the DoDivision routines to handle it, since the enemy regen code works almost the same. I will look into it later.

YEAH I KNOW THIS IS UNBALANCED AS A TAILLESS SQUIRREL.  :D

Also updated are the icons. Now, hiding, guarding, and regenerating should all show up. Hiding at the bottom, guarding in the middle, and regenerating on top (uses the old stun icon for sparkly healing magics!)

If you test it out, let me know how it goes with hiding and guarding. I had a bug earlier where character 2 was hiding, 3 and 4 were not, but then after regenerating, 3 and 4 went into hiding. I think I just fixed it but I'm not sure and too tired to try and replicate it a third time...

Quote
I would advise not adjusting difficulty based on the HIGH settings

Well, the only difficulty change is less grinding. The individual battles are the same. I just spent less TIME getting as strong. I was still getting whooped in the Ice Cave even after being a couple levels higher than I used to go in there!

What I mean is that each battle, it still feels to me like the optimal choice is attack. I want to balance HP and damage and abilities in a way that will make using status effect spells rewarding, making hiding one turn and attacking the next a viable strategy for some, make using elemental-resistance spells... not mandatory, but do something with them that just makes it worth the effort? While doing the enemy lists for the spreadsheet, I was looking at this guide talking about using AICE and AFIR and things in a certain order on bosses, and I was like, that sounds neat, but from my experience, its pointless. The randomness involved with the spell damage makes it so I either get hit for 200 HP or 30. I want to find a way to balance that out so there's a better risk/reward option there: Go nuts and try to kill things before you die, or play it safe and smart? Right now, the go nuts option is better almost every single time, because the HP loss isn't great enough--or else its so great that I get wiped out in a turn, so I don't even have time to set up a defense. Just, again, from my experience lately.

The no-grind progression is what I would be wary about changing. I'm just surprised that using the High setting makes the game feel more smoother in leveling and getting through the maps. First-time players who don't know where to go, though, would definitely feel overpowered after wandering around too much!

I feel like emulating a great RPG (Chrono Trigger) would be the thing to do for my own story, rather than patching in Bravely Default-esque settings to make old school game mechanics more bearable.
« Last Edit: May 16, 2019, 02:20:36 am by Jiggers »
I know exactly what I'm doing. I just don't know what effect it's going to have.

Disch

  • Hero Member
  • *****
  • Posts: 2728
  • NES Junkie
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #317 on: May 16, 2019, 11:31:09 am »
I'm considering whipping up an app in game maker to make some calculations and extrapolate a level value for any given enemy.

You know... I'm just going to throw this out there.... maybe this is a good opportunity to learn Python.

Jiggers

  • Sr. Member
  • ****
  • Posts: 254
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #318 on: May 16, 2019, 03:58:03 pm »
I made some new running calculations.

All enemy's speed combined / 4
Against character's level / 2 + speed (+15 if hiding)

If that's too kind towards the players, the level/2 can be dropped? I like the idea of killing enemies to make an escape route though.

With the current speed of, say, a MAGE, those jerks in the Ice Cave, a level 18 non-thief with 18 speed wouldn't be able to run from 4 of them unless hidden (Mages: $26 - Hidden Non-thief: $2A.)

I kinda just made it up so I don't know how balanced it is.



Also just fixed a bunch more bugs. Sleeping warriors sliding forward in victory, armour in the battle item slots not getting the right spell to cast, various NPC dialogue checks were wrong because item IDs changed, Warp/Exit spells didn't shut off MenuHush when exiting the menu so music was wonky, stuff I did previously wasn't working because of typos or the wrong variable (+2 instead of +1)... made the Bottle vanish when used again; gotta take out the "Its empty" description text still.

Running calculation isn't as cheesed as I thought it would be. I actually am having a rough time running away lately. Also changed the random number added to player/enemy speed in the turn order, since the range (0-30) seemed like it was influencing things a bit too much; its now 0-15. But, might set that back. Or just have it be like... Speed + (0...Speed)? Yeah, gonna try that.

Edit: Gah. Maybe don't download that last update. Something is crashing the game while figuring out turn orders. Looking into it, but the crash seems to be happening during a part I haven't touched?

Very weird. There was an infinite loop that, for some reason, was not infinite before. Adding loop counters to break out of it fixed it, I think. Also, turn order stuff wasn't looking at the IDs of enemies and players to get their speeds, all this time; not until the second turn, anyway? Uh... anyway, fixed that, too.
« Last Edit: May 17, 2019, 01:28:56 am by Jiggers »
I know exactly what I'm doing. I just don't know what effect it's going to have.

Vanya

  • Hero Member
  • *****
  • Posts: 1489
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #319 on: May 16, 2019, 11:09:54 pm »
You know... I'm just going to throw this out there.... maybe this is a good opportunity to learn Python.

Don't know if I really have the spare time to set up the work environment for that, plus I'm working off a laptop cause my desktop's power supply seems to have finally died after nearly 12 years of faithful service.

Though, correct me if I'm wrong, but the syntax in Python isn't super different from GML / C++?



@Jiggers: I see what you mean.

I dunno, I kinda think we should not worry about balancing the game until after all the new features you want to do are finished.

I think it'll cut down on the amount of testing that has to be done and prevent redundant work.
Makes sense?
« Last Edit: May 17, 2019, 12:52:40 am by Vanya »