Version 2020-12-09:
https://filebin.net/7spaiz2xfys6b2i1/SoM_Turbo.201209.zipChanges:
- Implemented Bug_Fixes\Whip_8th_Charge_Animation; fixes a vanilla animation mistake for the up-facing and down-facing versions of the whip's strongest charge attack
- Implemented unique Cobra Shuttle graphics via Graphics\Polished_Weapons
Bugfixes:
Do you have a specific place for us to send bugs we find or is the forum here fine?
The biggest one I've found so far is some errors in enemy attack patterns with Turbo attacking on. Those being:
- Kid Goblin will (almost) never swing his axe, he'll walk near you and occasionally throw boomerang, but typically that's it.
- Iffish I can't seem to get an attack pattern off at all, just sometimes spellcasting?
- Zombies will occasionally cast a spell on you but I believe they also aren't melee attacking whatsoever.
Here would be the best place.
I've never really settled on how I want to tackle this. The vanilla AI is often very faulty on its own, so in some cases Turbo behavior is the same as vanilla, in some cases it just magnifies existing flaws, but in some cases it
is the cause of new flaws (especially when the AI relies on stamina / exhaustion to change AI logic). I tried a simple approach to deal with the latter, where a random number check fills in for an exhaustion check, but that isn't a panacea.
Rewriting all the AI (or at least what needs rewriting) is the best solution, but a pretty huge undertaking, and the most annoying aspect is dealing with calculating relative jumps in the AI scripting. The ZPS format doesn't have any ready-made capability for that, and counting by hand at least doubles the work load to make AI script edits. I haven't reached the point where I want to make secondary tools just to handle AI scripting, so that stymies my efforts to make changes.
Anyway, feel free to note anything that seems off. It gives me additional reminders of what may need improvement. The three you wrote of there are a good way to describe the issues you notice: the enemy and a concise description of what's wrong.
Future plans:
Any chance you'll make Randomizer Rom files compatible in the future, or add some of the features from it to your project yourself? Notable standouts include:
Randomizing weapons and weapon orbs (Insane variability and replayability over the base game)
Enemy/Boss rearrangement or randomization (Even more replayability)
A difficulty slider (Which as far as I can tell mostly allows you to multiply or divide the attack power of every monster/boss in the game)
I just don't see full compatibility between the projects as technically feasible. The randomizer (and Turbo) makes significant changes to the ROM where there is just no sane way to coordinate / communicate said changes between the two patchers to avoid changing the same bytes and resulting in an unusable SNES ROM. It would be possible to figure out some subset of Turbo project features that are compatible with a randomized ROM, and so could be applied after using the randomizer on a ROM, but doing that in detail would take... many hours, or days? Doing it via trial and error would be worse, but it's not something I want to commit to at the moment (it's a laborious and tedious process at best to cross-check what changes what and work around and/or label conflicts).
As for those specific features, the ZPS patcher doesn't have a mechanism for making decisions based on a random number. Hand-made reorganization of weapon locations or boss / enemy selection is possible, but it glosses over how much work Mop put into normalizing and scaling enemy stats so that relocating them would result in something fun (and all the bugs they resolved related to relocating bosses especially).
What's probably not obvious is how much needs to be changed for any of that to be possible (and how much Mop's randomizer is actually doing to make it possible). Weapon orbs require changes to events for boss drops, object spawn tables for static orb chests, and enemy drop tables for the Mana Fortress orb drops; the enemy drop tables is the least likely to be relocated or conflict with another patch, the object spawn tables more easily have conflicts (these are fairly fragile and are often shifted to pull off some interesting patches that add or move enemies or chests), and the event edits have a huge chance of conflict (any text replacement, i.e. VWF Edition, Relocalized, Reborn, is going to alter where in the ROM needs to be changed to alter boss orb drops). And that's to directly exchange weapon orb drops; if you wanted to move them to locations that weren't already a weapon orb, it's even more work. Changing bosses require a lot more effort than juggling weapon orbs around (changing boss code that makes assumptions based on their vanilla arena, changing which event activates when a boss is defeated or changing the events themselves, overhauling their stats so that they're a balanced fight at the point you encounter them... surely countless other things I'm not guessing ahead of time since I've not pursued this).
The difficulty slider can be approximated with Balance\Monster_Stat_Modifiers (and the related settings in the Advanced Options menu). Obviously it's not exactly the same, and not as simple for the user, but it's available.
Pipedreams:
I'd love to see all 3 players capable of casting magic and the ability to select who gets which spells in the in the launcher.
Bonus selectable stat points on level up, 2 or 3 points you can put in any stat of your choosing (I could see this one being incredibly difficult to code, consider it a huge curiosity of mine)
It's not impossible to change which two of the three characters cast spells, and then which spells they have access to. It would likely be a decent chunk of work to let all 3 have spells at the same time (lots of hardcoded assumptions that one character won't have spell menus, unlocked spell flags, etc.). The UI for assigning spells in the ZPS patcher would probably be pretty clunky.
Likely the sanest approach for a selectable skill point on level system would be to co-opt the event system to prompt the user, and add some new event commands that would assign the points selected. As far as I recall, there's nothing in save data to account for this (stats are pulled from a static table based on current level), so would require extensions to save data saving and loading to retain the choices, well, and overriding the table-based stats.
These just aren't something I currently have interest in though. While, sure, some of my favorite games are ones where I allocate skill points and such as I level my character, I like that I don't have to make permanent character progression choices in Secret of Mana. In theory, the boy, girl and sprite's stat differences are a stand-in for allocating stats as you level (à la Final Fantasy Adventure), and exaggerating these differences might be a more Secret of Mana-y way to spice up your choice, but even that isn't something I personally have interest in doing (planning and plotting stat curves isn't my idea of fun).
I know that this response is largely "sorry, but, no" but I hope it comes across that I did appreciate what you had to say. To continually work on this project, what's kept me going has been a mixture of:
- Did I wish it worked this way when I played this 26(ish) years ago?
- Will I enjoy using the change I'm making?
- Bugs go squish.
- If acting on someone else's request, will implementing it be fun?
The first or second, I can usually put up with some extremely tedious implementation requirements to see it to fruition (see: art edits, map edits, time of day system, equipment affecting hero appearance, world map edits, as examples; they're pretty much all huge amounts of effort), the fourth has a pretty high bar for what level of tedium I'm willing to put up with,
especially if it's not something I'd play with enabled myself. My motivations are selfish but intrinsic, driven by my whims, yet that's allowed me to keep at this for two years now.
Topic: Secret of Mana, Turbo - Beta 210329 (Read 482500 times)