I am curious whether there's a resource of some kind for modding shmups, or if it's ever done, because I've been thinking for many years that I should make my own shmup to better fit my own design sensibilities/preferences, but only now do I realize that actually, maybe, it's possible to just mod a game here or there, and enjoy them far more. I don't mean do overhauls, changing bullet patterns, etc, more like tweaking how often one gets extends, or changing the hitbox of one's ship, or what kind of powerups are offered.
I don't know any kind of programming, but I mean I have played for example CRPGs where I've found some instruction online for changing font size, make something higher resolution, etc, by just using notepad, or a game trainer and finding the correct line of code. Maybe I would need to know what program was used to make the game, to be able to decode it to begin with? I opened the .dat file in Mecha Ritz, and it's all just garbage that I don't understand anything of, rather than a very neat "hitbox=4y, 4x" or however the dream simple to understand thing would look like. Right now I would really enjoy making the hitbox smaller in Mecha Ritz, play around with (tweaking) the upgrades in Gunveins Arrange Mode, and perhaps also tweak extend numbers.
Modding in general is a whole can of worms to open as it really depends first of all what console or system you're targetting, if you have access to decompiled code or have to figure it out via trial and error what to modify using a memory viewer, and so on. Editing code that's stored in plaintext is quite different from what a lot of hacking entails and I'm honestly not sure of where to begin with some of the hacking wizardry I've seen. Somewhere like Romhacking.net might be an ideal place to start for tools and how-tos in terms of getting started.
If you're not familiar with programming languages, then it's not something you'll casually be able to mess with. What you're describing above sounds like mucking about in C#, which is simple enough to allow a novice to do little value changes like you mentioned, but decompiling a full game is a much more complicated project. That said, there are some good shmup examples out there: https://www.arcade-projects.com/threads ... und.19817/
Formerly known as 8 1/2. I return on my second credit!
I mostly enjoy non-arcade shmups these days, but perhaps they have know-how on that site, thanks. One of my first thoughts was actually to look into MAMEd games, since I thought that since there are roms of those games, then perhaps it's easier to reverse engineer for example cave games, than say a thing like mecha ritz which nobody has tried to understand in any coding/modding capacity, but I wasn't sure if making a rom of the game was even the same thing as "understanding" it in a way that would help me, or if it just meant that someone copied the game, without having any deeper understanding of it.
The Ketsui one to reduce the beeping sound volume are nice. In early versions of the game it was low, later ones made it very loud, it's nice to have it not beep too loud.
However, the ones that remove the voices from Thunder Dragon 2 and Blazing Star ARE A BLASPHEMY, A SACRILEGIOUS AFFRONT TO THE GOD OF SHMUPS AND A MOCKERY OF HIS DIVINE CREATIONS. (ง •̀ w •́)ง
There's no one-size-fits-all approach, unfortunately. As you've surmised, it's a matter of familiarizing with the technology that was used to build a given game, such that you know where to find the quantities that need to be tweaked - be that via pleasant text interface, or something more arcane like Cheat Engine or hex editing.
In fact, Cheat Engine is probably the closest thing to a general-case solution, since it essentially works like an Action Replay or GameShark for the PC; give it some condition to search memory for (N got bigger, N got smaller, N stayed the same, etc), make some in-game action that you suspect will cause that change, then filter the list of results until you find the memory address pointing at the value you're interested in, and change it to get the desired result. Cheat Engine needs to be running in order to recreate that change on future runs, so it's kind of like a 'hot patch' rather than a permanent modification.
Hex editing is a more concrete version of that; instead of finding the values at runtime, you take the compiled assembly code, reverse-engineer it (i.e. recover some semblance of structure, annotate it with notes about what does what) until you find the function or value you want to modify, change it, and save it back to make the change permanent. Cheat Engine can be used to inform this process, since it lets you observe the program as it's running and correlate things back to the code, but it still requires a lot more work, and understanding the underlying structure of the program.
Your CRPG example is a case of the developers exposing values in a user-friendly way, either because they considered modding support ahead of time, or because their non-coding designers needed an easy interface to tweak values during development.
Likely the latter, given that CRPGs tend to be numbers-heavy simulations with many variables. Tech-wise, it's possible to make that a pure design-time thing and compile the results down to binary data to make it efficient for the final release, but in many cases it's easier to just ship with the textual interface intact, as well as being a nice little extra for enthusiast players to fiddle with.
Which brings us back around to shmups; traditionally, such modifications manifest as ROM hacks (i.e. the hex editing approach), since the genre started out in arcades, where hardware limitations meant leaving inefficient design-time tools in wasn't an option.
Modern shmups are a bit of a different bag, since they tend to be made on modern engines, with less-limited machines in mind. Aftermarket tools exist for more popular ones, like Unity and Unreal, which specifically target their known data storage patterns and partially automate the reverse-engineering process. But it's still a mixed bag, since even with a consistent engine model, individual games will still vary wildly in the way they use it.
Tying your example to the engine fuckery mentioned above: Mecha Ritz uses STG Builder, which presents several problems.
All of the game logic is wadded into the DAT file with the assets, and it's in whatever proprietary form the engine takes it in, probably rendering it unrecognizable to anything else. The logic of the game is also likely going to be hacky and twisted in order to implement things the engine wasn't designed to accommodate.
By nature, the engine is almost totally concerned with interpreting the data from the DAT. So looking at the executable itself is useful if you were trying to understand how it interprets the data so you could reverse-engineer the DAT and then make a decompressor or editor or something, but not at all useful for understanding one game.
I don't have any experience with STG Builder. I'm pretty sure Mecha Ritz has a Darius-like hitbox which gets bigger when you're shielded. So is the hitbox size a simple variable, or is the big hitbox a separate object that gets crudely stuck on top of the player when a shield is active, or something weirder? Even if the input when making the game was as simple as "if shield then big hitbox", I have no idea what that potentially could have mutated into when it went into the DAT.
Modern Cheat Engine is extremely powerful for programs that are actually sane because it has a disassembler, can alter executables during runtime, and has scripting support. You can inject entirely new functions with that thing.
I know there's some extraction utilities that work for STG Builder but not all, I think it only works for older versions. I was trying to extract the audio from a few games where I didn't want to have to manually rip the music by disabling the SFX or by using a sound text with mixed success.
Reminds me that on a shmup themed Discord there was someone who wanted to know how to extract 3D model files and assets from some game, and we had to explain that you can't just "extract" them, it depends entirely on knowing first how the game's data files are compressed and if you can even get at them, knowing what format everything is in so you can actually read it assuming it's not a custom developer made format, and so on. It went noticeably downhill when we explained that spritesheets and music marked as gamerips (i.e. ripped/copied from the game) don't necessarily literally use the raw data files, they're often done painstakingly by people who had to take screenshots and crop out the background pixels, or people who had to unlock all the audio for the sound test and then manually record each track in game using audio capture software because the game audio isn't stored as user accessible files (lookin' at you Leiria -Stargazer-). He insisted this was wrong and argued the word gamerip only means they're using the raw data files they've somehow extracted. It was a bit weird.
There's some older games like Doom and Quake where the compression format is very well known and the filetypes within are well understood as the source code is released, but you can't count on that for most indie doujin shmups!
Technically, you can rip 3D models from old games in a generalized way if you're running the content through an emulator that uses a hardware renderer, since - beyond more exotic compute-based approaches - GPUs have a standardized set of supported formats that must be used to interface with the hardware, which can in turn be scraped using various readily-available profiling tools.
Though you can also say that's just a very roundabout way of embodying the 'figure out the format' problem, just with several layers of software doing it at runtime on the user's behalf.
The point about spritesheets is particularly salient - so many cases where otherwise-dynamic effects get baked into a given rip, since the people doing it either don't understand the underlying structure, or lacked the means to effectively reproduce it. Fighting games (and their cottage-industry rip consumers, like M.U.G.E.N.) are particularly affected by that.
It applies to 3D model scraping too, since you can get a bunch of triangles and textures out - a.k.a. the bare minimum needed to draw it to a display - but not necessarily any of the important supplemental data like skeletal rigging or object relations; for that, you need to dig in and do proper reverse-engineering.
If memory serves, the PC releases of the Judge Eyes series got severely delayed thanks to that - something about the talent agency for the main actor having ultra-stringent policies, which exclude assholes on the internet cranking out nude model rips for dubious purposes
Well shit, in Mecha Ritz you're almost always shielded, so that for sure would contribute to the feeling I have in that game that the hitbox is unintuitively large.
Funnily enough, the game that would maybe be the easiest to modify is Parsec 47, by ABA Games/Kenta Cho, because I get the feeling it's very open with how it was made, but it's my favorite shmup so there's actually not anything I would change about it! XD Although using it as basis for a bigger modding project could perhaps be something to consider, if I wanted say a Parsec 47X2 that is basically the same game, but with totally different bullet patterns, but I must say that I have no clue where to even begin with thinking about how bullet patterns are made, but I guess if I bought STG Builder or another program and just started to experiment, it would eventually make more sense. And oh, I just remembered that I actually contacted Kenta Cho, twice in the last 10 years, because I wanted a level trainer option in Parsec 47, but I never got any answer. Would be cool to have such a feature, but that is a bit harder to create than just modifying bullet patterns, I imagine.
Okey I'm gonna get Cheat Engine and experiment and get a sense of how perhaps that could help me with modifying some games. Thanks for the help everyone!
BulletML is probably worth a look if you're curious about how bullet patterns are defined; it's not a concrete standard or anything, but continues to show up in enough indie STGs to be notable.
Though - as with most nontrivial things - modifying it after the fact is likely to be onerous, unless the developer is nice enough to have kept their pattern scripts unobfuscated and accessible.
The only thing I've managed to get going in Cheat Engine is slowing down a game, because there's just a button there that says "enable speedhack", and the ONLY game it's worked with is Parsec 47, but why that is, I don't know. But while I'm at it, this might be a good time to ask about if anyone has tips for understanding how Parsec 47 handles savefiles.
So in that game you can start the game from level 0, 10, 20, up to 100, and then lastly from the highest level you've reached. I had the idea that I wanted to practice the levels inbetween say 250 and 100, and so I just made a bunch of Parsec 47 folders, basically copied the game to have one for each of the 10 levels. That worked, but only initially, and then it's as if the game hiveminded all the different game folders and somehow shared the savefiles across these, nullifying my attempt at separating them. Now my first thought was checking user/appsdata, roaming, those folders, but I couldn't find what I was looking for, and then I just gave up. Any ideas what might be going on? Was I just looking in the wrong place? Where are the savefiles if not in the game folder itself?
Well, ABA games are a good choice as the source code is included, and all the patterns are in BulletML as Lander predicted. If you're not prepared to go as far as altering the source I recommend going through the built-in tutorial for Cheat Engine. You should be able to get infinite lives set up at least (the games use pointers a lot and their implications for CE purposes are covered by the tutorial).
Changing the Parsec level real-time is slightly more convoluted. Changing the number won't do much because the game refers to the starting level when recalculating. You can alter the rank directly instead and get the proper result, but it will only kick in after reaching a multiple of 10+1 when the rank updates. There's probably a better way of doing it, the "current" rank has to be in memory somewhere.
Practice 1 + (4 every 10 levels)
Normal 10 + (8 every 10 levels)
Hard 22 + (12 every 10 levels)
Extreme 36 + (16 every 10 levels)
For saving, it looks like the game writes a few bytes to p47.prf in the game folder when you quit. Would be easy to hex edit the file. Dunno how they would cross-contaminate.
If a program ever looks like it's doing mysterious things, Process Monitor is a handy Windows-specific way to deobfuscate that and get concrete information on where it's reading / writing stuff like files or registry entries.
As an aside, I thumb my nose at OS-standardized data dumps like Registry and AppData. A necessary evil, perhaps, but a million-dollar mistake for intuitive behaviour.
Lander wrote: ↑Fri Jul 05, 2024 6:21 pm
Which brings us back around to shmups; traditionally, such modifications manifest as ROM hacks (i.e. the hex editing approach), since the genre started out in arcades, where hardware limitations meant leaving inefficient design-time tools in wasn't an option.
Gonna to take this opportunity to highlight a particularly good hack, created by editing a just a few values in the ROM. Slap Fight MD w/ Pink Bullets: https://www.romhacking.net/hacks/4270
Per the readme:
WHAT WAS DONE:
Some hexediting.
512 bytes were changed at the adress $79E00
512 bytes were changed at the adress $99E00
the original colors used are 1,2,6,8.
now it's color 5 (pink)
the bullet sprite is 16x16 in size, and is located in two adresses in the rom , splitted in :
-4 tiles with 4 variants at the first adress,
-and in another 4 tiles with 4 variants at the second adress. (so a total of 32 tiles)
Lots of shmups could benefit from tiny edits like this
That is indeed a tiny edit, that is very nice. I do not understand why older shmups quite often have almost invisible bullets.
If I got to make tiny edits, although a little less tiny, it would be to make games give out much more extends, since I don't enjoy playing for score very much these days, and probably never have as much as others, unless it's tied to surviving, like in Parsec 47 or Gunvein.
If you know even a tiny bit of assembly programming and understanding of how older games work, any game running in an emulator with a debugger should be prone for some hobby-hacking. I've done it for CPUs I'm not even familiar with the assembly syntax for (they tend to have a lot of similarities though)
Unfortunately the built-in MAME debugger is one of the most garbage debuggers I've ever tried, but it's sufficient enough for understanding mechanics and figuring out which lines of code or values in memory do what, allowing would-be hackers to edit the games to their desire. Small edits like changing colors, editing hitbox sizes, or modifying other basic variables should be a pretty easy job.
OP (or anyone else), I'm open to showing you how to mod a shmup using the MAME debugger (in tandem with Ghidra). I suggest working on a game from any of the following systems: MD, ST-V, 68k arcade, Dreamcast/Naomi, PS1.
If you're really interested in NES or SNES, Mesen2 has a great debugger for those systems.
One project I looked at starting awhile ago (but got sidetracked) was fixing the bugs of Terra Diver (ST-V).
Right now I would really enjoy making the hitbox smaller in Mecha Ritz, play around with (tweaking) the upgrades in Gunveins Arrange Mode, and perhaps also tweak extend numbers.
