The title is probably going to give you a few questions out of the gate if you don’t get what that means.
A frontend/GUI for MUGEN? Why MUGEN would need it?
If you want to start with what is even a frontend in the first place, you could simplify it to being the interface that you use in any application, whether by web, on your phone or on your desktop. So you could say its the interface…but in this context, I want to refer to something more specific.
One example of things that can be considered frontend are programs that are often known as GUIs, which stand for Graphical User Interface. These are a general term, but it can also be used to programs that act as GUIs for other programs usually only available to use in command line.
But I want to focus on a more interactive definition, which can be exemplified by Emulator Frontends, which is most likely where I got this notion from. These are programs that have their own interface but allow you to set directories to emulator and games so that it can act as a menu that loads those games in the right emulators you set for them.
Kind of like a console main menu, except that while you have to configure most things, it allows you to basically put whatever you want in one in your PC or else.
Got that? Yes or no, time to move on.
Act as a replacement alternative interface for MUGEN. At first, this sounds redundant, since MUGEN does have its own interface- and options to customize them as well through screenpacks.
MUGEN did allow for certain characters to be fought in later stages and characters can be coded to have interactions between them...but some things retail fighting games do aren’t possible by default in MUGEN.
A key example would be doing something like the old Mortal Kombat games do, which is to show your animated character in your side and posing when selected. Since MUGEN only allows a still image of a character as a portrait, you can’t have something like that there. Unless you go and code the characters of your game [or a character that acts as a custom menu inside MUGEN] that loads its own bespoke character select that allows you to do it, like some Mortal Kombat Project games do or N64Mario’s SF2 character pack. But that’s another level of ingenuity required.
That would also apply to condition-specific hidden bosses to say another example- one that is also demostrated by N64Mario’s Street Fighter II character pack.
The description of a little video bringing the April Fools myth Sheng Long to life mentions that you need to be using a specific definition file from the pack for both yourself and the CPU match against M. Bison instead of the character-specific defs for the specific unlock conditions to work in an arcade run, which would be to be using the pack's universal def and pick Ryu or Ken inside it, then get to Bison and do the strange conditions...and only then you'd get the secret Sheng Long fight.
Point is, if you wanted to do cool boss stuff and even unlockable, your only option was to code everything in your game or character pack to work through an universal definition to be loaded that could know what’s going on between rounds to know what to do. But if you ever wanted to be silly and do things like that with stock MUGEN characters from here and there without any modifications...nope.
At least not unless you created something that skipped the usual MUGEN interface limitations altogether.
What this program would do when going into a fight is that it would read the variables of things necesary for a fight, such as the characters, stage and rounds from what’s programmed in the frontend…and then pass it over to MUGEN thanks to its support command-line launch parameters. So you essentially make a program that has its own menus, customizable and programmable to your heart’s content, custom menus for missions and minigames, ways to handling secret unlockable characters and so on, so forth...that leverages MUGEN exclusively as the engine that powers the fighting in the fighting game.
It’s the reason SaltyBet could exist as this semi-automized concept with how whatever handles the bracket would send MUGEN the green light to do its thing on its own instead of relying on someone manually selecting everything each time.
So, reasons to try and craft a frontend would be to have proper unlockables in the game instead of only being stuck with hidden character slots, extra modes with their own slots, and even just the idea of having a way more dynamic interface overall between normal menus and character select screen, just like most fighting games you know, as you’d be creating your own menu system rather than trying to fit a set of assets and animations into the MUGEN constraints.
Sounds that something that no one had done nor would need to do? Well, I got you there, because I have three whole examples of MUGEN projects that have used their own custom contraptions to do the dirty menu work in exchange for interface flexibility.
The first one is a straightforward example, albeit one that had been cut short due to its development being halted, but nonetheless there already being enough of a sample in the released versions to show what I mean.
You can tell if you are playing this yourself in windowed mode how the game switches between the MKTX executable and the MUGEN executable when it goes between rounds, but it’s also telltale when it does things usually not possible for MUGEN out of the box, such as the aforementioned fancy character select animations that are tradition in classic MK, fitting as it is a project based off Mortal Kombat Trilogy.
Another thing the project leverages its frontend for is to have the MK3 tower functionality to choose between difficulties and higher amounts of enemies depending of who you pick, something also not possible in MUGEN unless you code the functionality directly into the characters [again, something done by Mortal Kombat Project games as they run on a base template with that functionality].
It definitely helps add an extra air of authenticity to this game considering how it seems pretty straight into the idea of remaking MKT, keeping those additional doodads from the original intact thanks to the frontend. And as shown at the start of the video above, the frontend was made with Clickteam Fusion 2.5...although the video seems to have MUGEN's own loading times cropped out for a smoother watch experience.
But as I said, that was a SIMPLE example.
If you really want to see how a frontend can be pushed to do sillier things, then look to none other than…
Your eyes do not deceive you. Someone made an ARCADE CABINET of MUGEN, and it wasn’t just shoving MUGEN into a PC inside a cabinet and having some external mechanism [or just a dude] keeping tabs on who keeps playing.
No. It was a thing that could legitimately work on its own as an arcade cabinet…and that’s because, you guessed it, it’s all in the frontend it uses.
Support for inserting credits outside and inside the MUGEN-powered fights through an external program, being able to go through a MK styled tower preview also powered by the frontend, and the fact you could choose between a Normal Match and a tug-of-war-like Death Match mode, these are all bells and whistles done by the custom frontend programmed for this cabinet.
https://www.youtube.com/watch?v=SRNTKJLDM5w https://www.youtube.com/watch?v=UXzz5pTc_mM https://www.youtube.com/watch?v=B9m1B0dKmAQEheheheh...there's a fairly long story in that regard.
Basically, I found out about MKTX back in the day and wanted to try doing something like it myself. And it went from this proof-of-concept barebones menu that launched the game with the characters and stage you picked with a mouse...into something more surprisingly complete [even it not truly complete], especially looking back and realizing that since the project was started in March 2018, I was 15 years old by then.
Might sound cheesy to bring up a project of my own for an example, but it lowkey is the reason why I even started writing this again, as thanks to AxlThunder [HYDRO THUNDERRR] recently letting me know of Game Maker 8.2's existence, which makes the program work with enhancements and not dying in the process in Windows 10, I could actually look back at this old project...and the second successor that never managed to reach the same heights of ambition but certianly surpassed it in sophistication.
There is a playlist with some videos of the evolution the project itself went, so you can take a look at that if you want to see it grow from a plain gray screen with icons, but for the sake of the topic and focusing on the developed aspects and ideas, I'll instead ONLY talk about the last version of the MBF project.
And beyond the date, I can tell you like the back of my palm that the project is very old indeed, considering that some of the videos
So...on examples of things you can do with a frontend?
Want a mission mode that lets you fight as KFM against his evil counterpart? Program the menu and make the fight launch MUGEN with both characters set.
Want to make EKFM unlockable after winning the mission? Do a check on who won, and if you did, save something to your frontend to store that you have him unlocked.
And with that, you could either make the CSS show EKFM’s slot when unlocked, or if you want to be funny and lock it behind a button combo, program the functionality in the CSS so that only if you do the button combo AFTER clearing the mission, you get EKFM.
This specific example is one that I bring up in things you could do with the ingenuity of a frontend because...it's something I actually implemented back in the day for MBF.
Another fun thing I had done with it, which was also some of the last stuff I did with it, was to figure out a way to make an Arcade Edition of the frontend- directly inspired by MM2007. IIRC, I had to code a little AutoHotkey script that would check if you pressed the credit button and play a sound while writing to an .ini read by the frontend that would keep track of the credits, and while it wouldn't let a second player join mid MUGEN match if there were no credits, if there were, then it would close MUGEN and tell the frontend through an ini parameter that someone jumped in. Similarly, if you inserted a credit while the attract mode runs, which essentially loaded two random CPU chracters to fight each other and a custom lifebar that's just the logo shown in the corner, it would also close MUGEN and show the title screen...just like most arcade games would.
There's definitely some stuff that would be fun to explore in-depth regarding my old programmed stuff here in a separate feature, as well as some of the silly gotchas that appeared when I was finally testing it again with GMK8.2 [such as the frontend being unable to read the savedata .ini file unless I un-hided it, likely a security addition to 8.2 for good measure, and finding out that there was a result screen half implemented...because every character would have Terry Bogard as their win portrait lmao], but I think that on a description of what was done in itself, beyond what's shown on the videos, most of the interesting stuff is obviously in the way I was tackling some of the features...but on the outside, it was what it was: A sort of functional menu with some extra modes that launched MUGEN in the conditions it needed, and through a MUGEN 1.0 exclusive logging feature, it would read the end results to know when you won, lost...or the game was closed early.
This is basically my last project in that style, at least as of writing this, that was intended to be a successor to MBF and the lost attempt at reworking it. But unlike those, I only had been working first on a reliable way to make a character select screen and menu engine, hence the name...and thus, didn't have any actual functionality to plug with MUGEN implemented yet. Although it would have been trivial considering that it was a matter of taking a page from MBF to do that, which is likely why I focused on the meat of the frontend itself instead.
So back then, it was pretty much a very novel way to expand what MUGEN could do, and it certainly still can be today, but there's some stuff that has been enabled to be possible directly into the engine itself by...modifying the engine. Or rather, remaking it?
...Oh, whatever. You know what I mean: IKEMEN and many other modifications of it exist, and most of those aimed to add some of those classic fighter features like character-specific orders, arcade mode with credits, and obviously some stuff that a frontend can't do for the engine itself such as the pause screen allowing for universal support of per-character command lists [rather than having to be coded into the character or templates themselves like in MKP] and, noticeably as of this year or the one before...rollback netcode.
But there's still some obviously visible creativity and ingenuity at display when you look at projects like MKTX and MM2007 wanting to do so much more with the engine through their own contraption, and definitely think about how impressive it was that I locked in with my own project of the style for that long- even if it was mainly original only on the menu side rather than on the assortment of grabbed POTS characters and stages, due to how much I had to put in effort to be able to program the whole menus and systems altogether for it. Truly a time where I had quite the passion for tinkering with GML coding that made it fun to make progress with.
The project was initially started by Dark Mystic as a SOC mod, assisted by Princess Plushima (previously known as "Draykon") and Chaos Zero 64 on the side of coding and mapping, and while the release thread is dated June 28, 2006, the first post was edited to reflect Riders v1.46.4X, the LAST version of the original mod that got released in June 29, 2009.
There are messages after it that quote older posts and refer to earlier versions of the mod, but these old messages and mod versions are now lost to time; likely due to a message board change back then, which would explain why the first post is NOT marked as edited despite how the version mentioned is from much later than the marked date.
SRB2Riders was originally made out of separate characters and map files paired with a single script file (SOC) to modify the game and packaged together by the small team. There is evidence of how the SOC file itself used to be updated on its own for gameplay tweaks on the Message Board thread, with the evidence of mentions of Riders5.soc files and so on.
Some players also contributed with small things for the project, as seen in the thread with other members sending in their sprites and the credits inside the mod's files.
But at the time, SRB2's limitations did not allow for huge gameplay changes through SOC, so the older versions can be assumed were much more basic than what would later get released...
You see, Chaos Zero 64 eventually started working on a source code version of the mod, modifying the game's engine as much as possible to fit their needs instead of doing it through the limited SOC files, and this led to the release in February 27, 2007, of a new version of SRB2Riders, which in CZ64's words, was much more improved than before.
Features from Sonic Riders like the Air Gauge, boosting and mid-air tricks for extra air were implemented, and it had JTE bots to race against in the Single Player mode. These changes certainly pushed the mod to be way more than it used to be...but sometime after that, there would be a certain new addition important to this story.
An update from June 3, 2008 introduced a Mario Kart gamemode to SRB2Riders...and this is the very first seed of what SRB2Kart would eventually become. Though don't get ahead of yourselves; it definitely didn't play like it yet.
The handling and controls weren't very altered as with the Riders mode, and instead played closer if not virtually like re-skinned vanilla SRB2 gameplay but without normal jumps. You could hop but not drift, items were completely random (regardless of position), didn't have the single player bots, and you could even cut over off-road without a speed loss by hopping over and over with the right timing.
There are other details I noticed from investigating this build, such as...
Even though it isn’t possible to confirm this due to how the older versrons can’t be found anymore, it seems that the first Riders versions with the Mario Kart mode might only have included 8 maps made by CZ64, Chromatian and FlareBlade.
This is because out of the 10 tracks that were seen in this last version, two of them actually had standalone releases in the Message Board in 2009 intended for the Mario Kart mode: Crawla Cape by Violo, and Dusty Dunes by DaicheS9. It is possible that they were noticed by CZ64 and added to the mod, which is doable from how Crawla Cape seemingly was modified by CZ64 to have less lag as he mentions it on Crawla Cape's thread.
You can watch all the maps being explored in Riders 1.0 by following the playlist linked below, where you'll also likely notice the gameplay quirks.
The most noteworthy maps from this very first version would be Peach Castle, which actually survived virtually intact until the current SRB2Kart release as a hidden Map Hell map, becoming the oldest unchanged layout playable in the game, and Pipe Speedway, which is a very early version of what would later become Daytona Speedway, noticeable with the first half with the left circle turn and right turn with an earlier off-road shortcut to take with a mushroom/sneaker being already present, but otherwise being very plain in visual details and the rest of the layout.
Both Riders and the Mario Kart mode enjoyed a fair share of popularity back then, even in their primitive state, and aside from the aforementioned Violo and DaicheS9, there were a few other players such as Super Chris who made maps for Riders 1.0's Kart mode.
But the Mario Kart mode wouldn't REALLY take off until its next major update. See, in July 24th, 2009, SRB2 v2.0 was released, which added and polished many old details in the bae game, and was the logical step to continue SRB2Riders with.
It would take a few years until a port to the new version was finished in June 23, 2011, but aside from having the advantage of an improved base engine and new features to improve the Riders mode (such as the Riders countdown behaving like the original game, having to run through the finish line after the beam vanishes), the most noticeable change was that the Mario Kart mode was significantly reworked.
Not only the handling and acceleration were changed, but drifting and mini-turbos were implemented as well. If you have played KartZ before, Riders 2.0 plays the exact same regarding the physics, sticky wall collision and even the insta-thrusts from miniboosts- only that drifting has an oversight with being off-road invulnerable.
It still wasn't perfect, as there was an oversight where drifting over off-road didn't have a speed penalty, and the Star off-road oversight is still present, but otherwise is a noticeable improvement. Other details that can be mentioned are:
In any case, this update made the Mario Kart mode so popular that it eventually eclipsed the standard Riders mode in popularity, which is made evident with the amount of custom tracks that it received back in the day.
There actually were enough to the point that someone would be inspired to make a full track pack just for this mode...
Made by D00D64, who used to be an active community member and even a KartKrew member during SRB2Kart's development, it compiled both tracks from other players and of his own into a single player, mainly made for multiplayer.
While there were no single player additions nor any modifications to the gameplay, the expansion with maps was enough to warrant having some attention at the time, even though a majority of those were Mario Kart ports.
There were a few maps from this pack that returned to SRB2Kart through the Map Hell rotation, like Black Bliss and PWR Retro Maze (as well as Bleeding Green in the SRBKart 1.0 before being removed in later updates), but there'sone track that survived in the normal rotation.
Cloud Cradle K-E as it featured here would be the oldest track in Kart's vanilla map rotation that still resembles its original layout. However, the original Cloud Cradle K seen in this map pack had more obstacles to avoid and deadly springs in one section, which made the already challenging layout harder and prompted players to request it to be toned down, which is how the Easy variant that survived came to be.
At the time D00D Kart 64 released though, Chaos Zero 64 had lost interest and slowly retired from the SRB2 community, leaving SRB2Riders and the legacy of its Mario Kart mode up in the air...
...
...But you knew this wasn't the end, did you?
A coder named ZarroTsu wanted to expand this Mario Kart mode into its own mod, and with the help of many old contributors and brand new players alike, a new project would rise from the ashes of SRB2Riders. And in January 12, 2012, the arduous road for the yet to be named team of developers would finally begin with the release of...
Thanks for reading!
If you are here from the video version, then I'm glad that you checked this out :)
If this seems familiar to you, then it is because you might also have read the original version of SRB2Kart The Documentary on my old Wordpress site- what you just read is a considerably condensed version using the video version as a base (as I was working on it concurrently as I decided to move the article to this site).
There's already a video version of the Part 2 of this published [it should appear at the end of Part 1], so you can check that out if you want to follow on what's next already with visual reference and everything.
You can still read the old, longer but maybe outdated in some areas version of Part 2 in my Wordpress- although I hope that you have adblockers because I don't get a single penny from that site deciding to slap ads in a few places because of the free plan. I might eventually get to finishing a written version of Part 2 to share here though now that I have this new layout that makes me feel better about writing in this place.