I’ll preface this post by saying that I really should have edited and pushed it out a long time ago. The subject matter, however, I find is still relevant, so here we are. Should I be wrong about something, then I will try to come back and make edits accordingly. Or do a whole followup post, if there’s enough need for it.
In the past, I’ve talked about my involvement in the Gen III Pokémon ROM hacking scene. From learning about it to my early years in hacking, to a few posts about my hack Pokémon Creamy. Despite a great deal of experience, my direct interactions with the community are relatively few, and I’ve not really kept up with it even after coming back from a fairly long hiatus. In general, though, it’s about the same as when I left. That is, not great.
That’s a very broad statement, however, and I need to provide some context as to why I say it when it’s arguably much the opposite now.
For the longest time, if you wanted to make a Gen III hack, you did it through binary hacking. That’s directly editing the raw data of the game’s ROM (read only memory). This has long been the primary method of ROM hacking in general, but it doesn’t come without its own pitfalls. Simply the fact that we’re dealing with binary data and not, say, a human-readable programming language, means that it’s inherently less intuitive. In this case, Gamefreak did not plainly lay out how everything worked after the game was compiled from C, and early pioneers of the community had to figure it out themselves. You’re not writing code, you’re changing bits and bytes in a hex editor, and that sort of workflow is esoteric.
Once you have some semblance of understanding, though, you can begin to make tooling. A hex editor remains king for general purpose editing, but now you can start to abstract and automate the tedium. What once might have involved editing or altogether repointing entire sections of the ROM can be encapsulated in a single program. It might not be perfect, or user friendly, or bug free in the slightest, but it opens the door for others to begin. That’s tremendously important, as the growth of the community and its momentum are paramount to not only the creation of more hacks, but improvements to the workflow and understanding of games involved. You can look at any ROM hacking community, and see that progression from very simplistic hacks to creations that rival or exceed the games they’re based on.
For Gen III hacking, we’ve come a very long way from the days where hacks like Pokémon Quartz and Chaos Black were novel. They’ve more than earned their place in history, but they’re relics of a time where replacing in-game graphics was still fairly new. Compared to today, that’s pretty crazy to imagine, but you have to consider that modern mainstays like the ability to expand the number of Pokémon weren’t possible for years. You had to replace existing ‘mons, moves, and such, or use blank entries in their respective data tables. If they even existed, or weren’t buggy and never intended to be used at all. Even then, you still had to mostly work within the purview of Gamefreak’s engine, its variations between the Gen III games, and the limitations of the GBA itself.
This is all to say that binary hacking is a continuous process of discovery and innovation within the restrictions given to us by the original devs and the targeted platform. Regardless of how rudimentary your tools and knowledge of the game(s) are, you are able to make something of them, for better or for worse. Ideally, especially for the former, more advanced, optimized, and accessible tools are made, to help bring in newcomers, and alleviate the troubles of existing hackers and the overall workflow.
Yeah, that’s not the case here.
The binary side of Gen III hacking languished for years in horribly obsolete, buggy tooling that, up until fairly recently, hadn’t seen any substantial alternatives. Just take mapping, for example. The longtime map editor of choice was Advance Map (A-Map), which hasn’t seen an update in over a decade. Not only that, but the safer path involves using two separate versions, the last beta which had greatly needed improvements, and the previous, clunkier version, which isn’t nearly as prone to corrupting your ROM. We can even get into the legal aspects of A-Map’s existence, since it’s based on an old Gen II map editor (Gold Map) licensed under a GPL license, thus requiring source availability to any users that ask for it. This is usually accomplished with a public software repository nowadays, to make it easier for everyone. Despite a legal obligation to do so, A-Map’s source has never been released, and to my knowledge, the last we ever heard of the dev LU-HO was them saying that they planned to put it on Github in 2014.
An unfortunate trend has gone on in the community for a long time, with dated, buggy, closed source abandonware becoming integral to development, and any alternatives- open source or not- rarely getting anywhere close to replacing them. I can name three failed A-Map successors off the top of my head alone, and it’s not the only example of this phenomenon. Time and time again, someone would come out and proclaim that the age of insert obsolete tool here was over, and it was going to have blackjack, and hookers! Sometimes we got actual releases, and maybe for a while, too. Then, more often than not, it’d just get added to the pile, and nobody would step up to pick up the pieces (if they even could). Rinse and repeat, and binary hackers were left to scrounge up whatever they could find from over a decade’s worth of utilities.
Now, do not think for a moment that I’m going to point fingers at any of the developers that contributed to the Gen III scene. That would be a disservice to them and their efforts at best, and unfounded privilege at worst. This is, after all, a hobby, and we’re not making money off of our hacks- or, I sure hope not- but for a love or interest in Pokémon as a medium. People move on, get busy, lose interest, so on and so forth, and we have to acknowledge that. It’s not okay that the scene has been left like this, but part of that also stands with us, and whether or not we stepped up to try and improve it. Sadly, not enough people did, yet despite the storied state of binary hacking, it’s very easy to download some tools, a totally legal ROM™ or two, and get cracking.
Yet, it could, and should, be better.
Thankfully, we’re finally seeing hope in the form of Hex Maniac Advance (HMA), an all-in-one editor that promises to replace the classical binary hacking toolkit. As of right now, it’s quite usable, and the map editor is well under way. If anyone were to get into binary hacking right now, that’s what they should be using most of the time. There are still things it can’t do at the moment, but it’s getting there. Things are looking up for Gen III binary hacking.
As long as they’re using Windows, that is.
HMA, sadly, is not cross platform, and there is no plan (to my knowledge) to change that. Honestly, I’m not terribly surprised by this, as it continues another longstanding issue in the scene: lack of support for other operating systems. Are they and their users a minority in the face of the unrelenting Windows monopoly? Yes, and there is no argument there, though said “minority” is in the context of over a billion Windows users compared to MacOS, Linux-based systems, the BSDs, and so on. Accessibility is key here, and I vehemently stand by that statement. This is simply another hurdle to overcome, and one which must be done to open the community to more users.
Alternatively, however, the Gen III decompilations have finally become usable, and the majority of their tooling- at a glance- is cross platform. Or, if you decide that ROM hacking just isn’t for you, there are, arguably, better ways to make Pokémon fangames that aren’t held back by the hardware limitations of an old handheld system.
Overall, we’re in kind of this weird spot for the scene. Not just in support for other OS’, but this fracture that’s been growing with time. While many still engage in the binary side of the scene, we’ve seen the rise of the decompilations (which shall be explained shortly) in the past few years. It has also given us debate, and heated emotions regarding the state of the former and its relevance today. This is best encapsulated in what inspired my initial drafts for the post, months prior. A thread with the lovingly crafted name of Stop Binary Hacking; It’s Holding Back The Entire Community, whose careful, thoughtful wording would not possibly create pages of debate and criticism.
Strap in, folks.
Before we get into that, I need to explain what a decompilation (decomp) is. I sometimes describe it in a profound way as the ultimate goal of ROM hacking. The end result of years of deciphering and reverse engineering the game back into its original source code. What this means is that you no longer have to primarily deal with binary data, and the entire game is available in a human-readable form that you can freely edit. Do absolutely anything with, in fact, within the realm of the GBA. Then, once you’re done, run it through a compiler, and it spits out a brand new ROM for you without any of the hassle. The advantages of this approach compared to binary hacking are definitive in many respects, and you gain access to tooling that’s actually received regular updates in the past decade. You might have seen the Mario 64 decomp, the amazing hacks that have come out of it. After perhaps way too long to get to this point, the Gen III games have been decompiled, and are ripe for a similar treatment.
These are genuinely fantastic developments, but there is a level of tact required for their proliferation. The Gen III hacking scene is at a crossroads right now, and the transition from binary to the decomps is going to be messy. If it ever happens, even. Especially when it divides the community and breeds tension, leading to such brilliant titles as Stop Binary Hacking; It’s Holding Back the Entire Community.
Within the linked thread above, the OP tells readers in no uncertain terms that the decomps are superior to binary hacking in every conceivable way. As I mostly just described, you get modern tooling, access to all source code, and the entire breadth of the GBA’s capabilities at your fingertips without resorting to ARM assembly or C injection. There’s no rooting around in a hex editor to expand a data table, or insert assembly routines. In addition, the risk of corruption is miniscule compared to binary, due in part to the nature of the decomps themselves, but also the use of git, a version control system (VCS). It’ll keep track of everything you do, and save your ass when something eventually goes wrong.
These are, admittedly, good points, and the thread brought a lot of discourse with it. Needed discourse, in fact, from a wide spectrum of the community. Hackers old and new, proponents of both sides, mere observers, and even the perspective of someone from the Super Mario World hacking scene, which went through a similar scenario as we are now. For that, I thank the OP, in that they created a discussion allowing us to highlight the many problems plaguing every corner of our community, regardless of how one makes their hack.
At the same time, I must condemn their rhetoric, because they missed the point to a frankly hilarious degree. Their entire argument hinges on a misplaced animosity towards binary hacking, and makes them come off as an aggressive elitist. Which others were quick to note, and when pressed with the very real possibility that both forms of ROM hacking could peacefully coexist and have their own merits, brushed it off as “the enlightened centrism approach.”.
I shouldn’t even have to explain what’s wrong with that statement.
Special mentions go to Pokémon Crown and the person who shared their take from the view of the SMW hacking scene. The former is a very impressive hack from a technical standpoint, yet is accomplished through binary means. The dev even commented in the thread, expressing that they could have done it years ago, long before the decomps were completed. The latter gave a much needed perspective, as there’s a lot of overlap with our situation. In their case, the SMW scene is inherently married to Lunar Magic, a very polished binary editor that, despite its own shortcomings, remains their primary tool in the belt. The decomp, in comparison, is used as a reference to draw from for binary work, and some do also make their home there. That’s a pretty good balance, I think, and one we might strive for.
The flaws of binary hacking do not lie in its very existence, and to think so is more than a little silly. Can it be more esoteric and limited compared to the text-based workflow and safety nets of the decomps?
Yup.
Yet, we must acknowledge that this contention comes down to that very same clunky, inefficient way Gen III binary hacks were made for years. There lies our actual conflict, not the overarching principle. Do away with that, and the argument against almost entirely evaporates. HMA already obsoletes the majority of the programs that might corrupt your ROM out of nowhere, so there goes that argument. Furthermore, using version control isn’t even remotely exclusive to the decomps, and while you might not be getting the exact same utility out of it, you can still organize and keep track of your work. It all comes down to improving the methodology of creating a binary hack, and we’re moving in the right direction. Regardless of those that might not like it.
Let’s also not kid ourselves, and say that the decomps are anything resembling perfect. They’re not, and have their own problems to iron out if people are going to be able to transition smoothly. First and foremost, overcoming the barrier to entry and assuaging newcomers’ fears. You’re not downloading a few ROMs and a set of tools, but setting up a whole toolchain, more than likely tangling with the command line, and maybe even learning a programming language. That is a tall order to ask of many people, particularly as computer literacy rates have only declined in recent years. For someone with only the most basic understanding of how to operate a computer- let alone file management- this could appear daunting. You can argue that the end result is a good set of skills acquired, and this can be true, but you’re involving yourself in an uphill battle that negatively affects our entire society, and can frustrate and turn people away.
Once again, there is a level of tact to be applied. I am, admittedly, being somewhat hyperbolic, but we cannot ignore this eventuality. At the moment, binary hacking remains the more approachable of the two, choice of OS aside. For the decomps to rival or exceed it, they need to deliver a similar or, dare I say, superior user experience on the major fronts to bring in new blood. I have no doubt that this will happen in some measure, especially once we consider that these are still the early days of adoption for the decomps. There’s ample time to figure things out, and hopefully we can move on from this ridiculous binary vs decomp debate.
In the end, I think the biggest thing this whole discourse demonstrated is the need to do better. On the methods of making our Pokémon hacks across the board, and for the community itself. What drags us down is hostility and arbitrary division, whether through the actions of people or the tools we’re forced to work with. Improve those, and we all benefit.
Of course, this is my own view, that of a lurker. One that’s certainly out of the loop, and I might be wrong about stuff here. The fact remains, though, that I’ve been watching the scene for over a decade, and many of the problems ten years ago persist today. Calling myself a Pokémon fan these days is a real stretch, but I have a lot of investment in Gen III Pokémon ROM hacking, and want it to do better. This thread was not the right way to go about it, and I’ve been stewing on this for nearly a year now. Or, well, not exactly, but I thought it’d be good to share it on here… months later.
Honestly, just my luck that I suddenly picked this back up two days before PokéCommunity began migrating forum software.
Until next time.