Insane Difficulty: Some Questions about Coding - Insane Difficulty

I've been reading through some of your discussion about the game mechanics, particularly enemy movement and tactics, with interest. I've been thinking about the possibility of making a more minimal mod aimed at making the game harder. I suspect that the main problems are poor enemy unit design in the mid and late game, poor enemy tactics and strategy, and player item abuse. Some of these would be reasonably easy to change (if the data layout is sane), like enemy formations and what items are available in shops and their costs. Enemy tactics and movement would be harder, but it sounds like you've already done some work in that direction.

• What tools do you use the modify the rom?
  
• Have you written anything about the changes you've made, at the memory/code level, like what enemy tactics or pathfinding are available?
  
• Do you have a map to the data for shops and enemy unit formations?

I don't use any game-specific utilities, so just a hex editor. I fairly recently started using Asar so that I can code in ASM instead of HEX, but I haven't put out a new release since making that switch. If you're looking to make a more minimal mod, you'll probably want to start by checking out: http://www.romhackin.../utilities/984/ and seeing if that suits your needs.

I looked at OBEdit, but it's a Windows binary and I use Linux . I assume the source isn't available? Since my original post, I've found some of the information it would need other places, but I think OBEdit can work with some parts of the ROM I don't have a map for. The best map I've found so far is on FinS's page, by VerySneaky.

Now that I know how enemy formations are encoded, the possibilities are more limited than I'd hoped. The inability to use more than 3 types of units is probably the biggest problem, but the limited choice of formations isn't helpful either. There are some unknown bytes in the formation data listed in that spreadsheet, do you know what they do? I could speculate whether they might control something like the chasing behavior certain units display, but that could just as easily be hard-coded to certain unit numbers wherever the movement code is. If I were to do more extensive modifications beyond modifying the existing data, I'd probably start by trying to lift those limits, but I don't know how hard that would be.

I'm probably going to write a Python tool to serialize and deserialize the formation data into some human readable format, then see how far I can get with that. You're very patient to have written anything in raw hex. Sadly, there don't seem to be any good C compilers for the SNES processor out there.

You could try looking into Mr. Vimes' spreadsheet-based editor, as well. I don't know whether or not that editor was platform-specific.

For enemy formations, the 9th and 10th bytes are both related to map movement. As I recall, the 9th byte is comparised of two 4-bit values which are the IDs of a set of map movement behavior. Each behavior set contains 5 behaviors, and the 10th byte relates to how aggressively the enemy will escalate from one behavior to the next (it doesn't ever backtrack through them). As to which behavior set is used, some of them are conditional (such as the whether the player controls at least one town), this is specific to each behavior set. I didn't get into figuring out what each individual behavior does, and it was often difficult to discern even in the few cases where I tried. I ultimately just scrapped this whole system and created my own behaviors, as I deemed it rather unusable...

As to how many unit types you can put in an enemy squad: not only are you hard-limited to 3 types, but the game designers limited themselves to ensuring that all of an enemy squad's minions share the same palette, which is abysmally limiting. If you do not limit your designs in the same way, then you will get erroneous palette swaps when you meet those enemies in battle. This doesn't affect gameplay, and sometimes looks cool, but it's also confusing since there are already class palette swaps in the game, and sometimes looks terrible. No one has come up with a zero-loss work around for this issue. The SNES is limited to 8 foreground palettes at once, and 5 of these are reserved for the player, 2 for the enemy, and 1 for battlefield effects. FinS made a patch (though I don't recall if he ever posted it for use) that degrades enemy palettes a bit in order to have a 3rd enemy palette. My hack takes the approach of consolidating palettes such that the bug will only occur if there are actually 8 distinct character palettes at play in the field, thereby massively reducing the prevalence of it, and allowing the player to choose to avoid it by ensuring each of their squads has only 4 distinct palettes, if they so choose. And even with that, I still have to limit myself to 3 enemy palettes. But yeah, it's just a fact of life when it comes to hacking this game that you can't have enemy squads that are diversified to the same degree as player squads without running into problems.

zombero, on 28 December 2016 - 08:39 AM, said:

Where would I find that? I did some looking with Google but failed. My Python script is probably going to use csvs, though currently I'm using JSON.

zombero, on 28 December 2016 - 08:39 AM, said:

You haven't posted your new behavior yet, have you? If you have any information on how the original movement behavior works, like where those bytes are read or where the routines are, I could take a look myself.

zombero, on 28 December 2016 - 08:39 AM, said:

That is abysmally limiting and goes a long way to explaining why the later parts of the game are so easy. I don't think they chose a good compromise between aesthetics and gameplay here, to have sacrificed one so much for the other. Okay, so, given that I would make a different choice, how bad are the aesthetics of palette swaps, and is there any easy way to predict which combinations will look terrible? Do you think writing to Finshore could get his patch? Would you be willing to share your code?

Here's his website:
http://www.verve-fan....php?board=10.0

Though, at a glance, I didn't see the spreadsheet-based program listed there, so it may not be there... in which case I don't know what happened to it.

I have movement behavior as being read from a 7x7 table at $2990A (unheadered)
But that's really about all I know about it.

From what I recall, the palette result is entirely predictable. One of the two minion groups always gets overridden and it's always the same group. So, you can judge which palette swaps look passable and which do not.

This is Finshore's website: http://www.freewebs.com/finnshore/
If he hasn't posted the palette patch there, then there's probably a reason for it... but you could try asking him anyway. Since I wrote stuff in hex, I don't really have "code" to share, the code is what's in the ROM. But it's typically changes built upon changes built upon changes... individual features are not easily extract from it onto the base game. And the palette swapping one, in particular, is a beast.

zombero, on 01 January 2017 - 06:26 PM, said:

I found this thread where MrVimes complains about being unable to create his mod because his hex editor is inserting rather than overwriting. His one post on the site you linked occurs after that date, though.

It's pretty much immaterial at this point since I've reimplemented a script that takes information formatted as CSVs and converts it to data in the rom. The only thing I could get from it would be information on the parts of the rom that I don't currently have a map for.

zombero, on 01 January 2017 - 06:26 PM, said:

Thanks! That's helpful, since that falls into a big gap in Finshore's text rom map:

Quote

zombero, on 01 January 2017 - 06:26 PM, said:

My testing so far indicates it's deterministic.

zombero, on 01 January 2017 - 06:26 PM, said:

I did ask him, but didn't receive a response so far. (I'm not surprised, as you said, he probably doesn't want to post it or otherwise he would have.) I'm taking a more structured approach than you are, I guess, which is why I was surprised your changes are so hard to disentangle. I understand, though. If you have a map to your changes or notes on them, even, that would be useful.

Have you ever used a disassembler for the SNES, and if so, do you have any recommendations for one? Asar says that it runs on Linux, so if I need to do actual programming (which I admit I'm hoping to avoid), I will probably use it.

Do you have any suggestions on advertising a mod or getting beta testers? Once I get it more finished, I'm going to put the code up on Github, but I don't want to distract from the purpose of your board, for your mod, any more than I already have. Thanks for answering my questions .

iainuki, on 07 January 2017 - 10:48 AM, said:

Ah, sorry, I thought he got further along with his utility than that. Yeah, I do the same thing for data hacks these days, my methods were more primitive when I was working on this mod.

iainuki, on 07 January 2017 - 10:48 AM, said:

Heh, no worries, there's not much to distract from at the moment since I'm still finishing up my other mod. Geiger's Debugger is what I use, and to my knowledge it has no real competition. I'm pretty bad advertising myself, so I can only offer basic suggestions (a lot of which I haven't done myself). Make YT vids, do Twitch streams, find modding communities, find communities for the specific game, get a twitter/fb/wordspace dedicated to modding.

iainuki, on 07 January 2017 - 10:48 AM, said:

Unless you plan to re-assemble the entire game, any injected code is going to be at least a certain degree of messy and entangled. But there's also things like if I change the data structure of an enemy formation or a character palette, then new features that interact with those couldn't simply be extracted and applied to the original game.

iainuki, on 07 January 2017 - 10:48 AM, said:

Sorry, I can give info about the original game, but I don't really want to share information that would aid in extracting added features from a hack that isn't even released yet.

zombero, on 07 January 2017 - 01:28 PM, said:

Unfortunately, it looks like you're right about Geiger's debugger: it's not available for Linux, and there doesn't seem to be anything equivalent that is . Ugh, that is going to make things much more difficult, verging on impossible, for creating new code.

zombero, on 07 January 2017 - 01:28 PM, said:

Yeah. I'm thinking at this point that any changes I make will be in a series of discrete patches that some other tool will generate and apply, but with interdependent changes, that patch could get to be large.

zombero, on 07 January 2017 - 01:28 PM, said:

That's your prerogative . I admit, I'm a bit disappointed that SNES modding has so much closed-source software. (I write and use a lot of open-source software for other purposes than editing SNES games.)

On the topic of the original game, after playing around with unit design some, I think that only being able to use three classes in enemy units is workable from the perspective of being able to build units that are threatening enough to the player. The palette issues remain, but I'm going to ignore them for the moment. The bigger issue is proving to be the formations, particularly that there's literally one formation that allows two different big classes, both of which have to be in front. Finshore's text rom map mentions that "group formations" are at 2e83d unheadered, and there are exactly 19 7-byte blocks before the next entry in the table, so I think that's them. Do you know what what the 7 bytes mean? Any nonobvious problems I'm going to run into from changing them if I make sure to edit all the units that use the formations I change so they're still valid?

Yeah, being limited to Linux is going to be rough as far as tools go. Though if you're looking to make a simpler hack, then having a debugger isn't really essential.

No non-obvious problems. The 0-9 numbers represent the position of the enemy within the formation. The first byte is the position of the unit leader, then 3 bytes for minion type A, 3 byte for minion type B. $FF for blanks.

I've been doing some more research. Apparently, some of the Windows-only tools do work under Wine, so I may end up trying some of them as I start to narrow down what changes I feel are needed outside the data tables.

• Does your hack use an expanded rom? (I'm assuming it has to, from how much you've added, but I thought I'd verify.) Is it at all practical to make changes to the code in a non-expanded rom?
  
• Do you know where the code that determines experience gained for kills lives? At the moment, the sheer amount of experience available with the quantities of units you find in later stages (with 24+ enemy units) is a balance problem, and increasing the numbers of units in the early stages makes them harder but the midgame easier. I've also been toying around with lowering the effective level cap on experience gain (4 levels above is where experience gain drops to 1) to limit the super-unit strategy.
  
• VerySneaky's rom map has 1F8FF listed as the location for the damage coefficient by terrain table, but there are only 100 bytes, so I'm not sure how that maps to actual damage modifiers given there are 10 movement types and 20 terrain types. Is that what this table does? If so, how is it laid out?
  
• They have some discussion of city events (pointers to pointers start at 384AE), but not enough information about the events so that I could change anything about the items that events give, or e.g. move an event from one city to another, or across stages.
  
• Do you know anything about how the code for determining enemy unit drops works?