Hello! Welcome to my rather extended effort to make a classic-style-ish Mega Man game. My name's Nevi, my main is @afniel, and I'm here to be everyone's problem. I used to be tracking progress for this on Twitter, but we all know how that went, so now I'm here instead.
First, the top 3 questions I tend to get:
What is this?
A fan game, created in the NES style. Well. Eventually it will be. Making a game is not a quick or easy task.
What's it about?
When I was young, I always thought it was boring of Capcom to not give Roll her own game. I got older and I still think that, but I've also thought other things along the way, like, why do these games always raise such alarming existential questions and then completely forget they happened? How long would it take to learn a functional amount of music theory? Is it Metool, Mettaur, or Metall? Whatever they're called, why aren't there a lot more of these little guys in the games?
Basically, I'm giving Roll the game I always thought she deserved.
Can I play it?
Currently, there's really nothing to play. I've got the basic engine functioning quite well and a good chunk of the visual assets finished to a working degree, but refining everything, getting the gameplay as tight as it needs to be, and making sure nobody's AI breaks or sucks is a pretty big job.
That all said, my first real roadmap goal is to have a single-stage playable demo. While I don't have any notion of a release date for that, I am working steadily towards it, so please stay tuned!
The rest of the FAQ is long and maybe less interesting, so I'll stash it under a cut to save you a little scrolling.
The Game Itself
Is it going to be girly?
Probably not as girly as you're imagining, if you're asking that. After all, there's still explosions, boss fights, insta-death spikes, a ton of weapons to choose from, and quite a lot of shooting. Just because the main character is in a dress won't change the core feel of the game, nor will it be easier than other MM games.
Also, a thing being girly isn't bad anyway. It's just a style.
What makes this different from any other MM game/fangame?
Fair question! I'm going to be a little secretive about it though and just say 'choice.' It's a thing that the MM series isn't known for giving players, outside of what order you want to explode the robot masters. I think it could be more interesting than that.
That said, the mainline classic MM games don't have a whole lot to distinguish them from each other, and they're still fun and each one of them is someone's all-time fav game, so even if it just ends up being Another MM Game, that's still not a bad crowd to be in.
Are we fighting Dr. Wily? What's the plot?
:)
Some of that will come with the eventual demo release. The rest will be on full release. I don't want to spoil it up front, you know?
You will get to see some familiar faces for sure, I'll say that much.
Will this game be accessible?
I want it to be! I think games in general have a lot of work to do to become more accessible to disabled gamers, and as a disabled gamer, I want to try and do my due diligence in that.
It is playable on both keyboard (not comfortable) and controller (a lot more comfortable), and while the controls are fairly simple, there is already a fully-functional option to switch between classic MM style down+jump to slide, and MMX style dedicated single button slide.
Remapping buttons is somewhat beyond the scope of the engine I'm using, which is unfortunate, and all the more reason for me to learn something more flexible like Godot.
I'm trying to choose palettes for things that should be eyestrain-friendly. Flashing will be kept to a minimum in the default game mode, and I plan on having a sensory-friendly mode with no flashing whatsoever and certain other effects lessened/changed/removed. Of course, I can't guarantee that certain patterns won't affect sensitive people regardless, but I'm going to give it a good try.
Depending on how easy the game engine makes sensory-friendly mode, it may end up being a separate download version, but I hope not, that's just not as good.
Alternate difficulty modes are also something I want to do! I just haven't looked at implementation yet, but it should be pretty easy.
Game Development Stuff
What are you using to make MMR?
The engine itself is in Pixel Game Maker, which is kind of an underdog DIY game engine and if I'd really been thinking I'd probably have started it in Godot or something, but I'm already here and honestly, I like how it works, so I'm keeping it. The assets are entirely made in Aseprite, and the music is entirely Famitracker, with a little use of Audacity to make sure tracks loop properly and to get things into the right format.
Very few visual assets are taken from the games directly, mostly some enemies and most of the sound effects (because those are not something I want to try to recreate using only Famitracker—I only have so many hours in a day).
How NES-like are we talking, here?
I'm aiming for NES-like in the way that Sonic Mania aimed for Genesis/Master System-like: the style matches, the limitations are mostly observed, but certain limitations are disregarded when it would be extremely awesome to do so.
Some examples: I'm very fastidious about color palettes per tile and per minor enemy sprite; I'm less fastidious about color palettes onscreen at a time and color palettes per boss sprite. I'm not trying to replicate the sprites-per-scanline flicker. Number of frames per animation isn't something I'm really considering as long as it looks visually appropriate. I'm sticking with 2A03 music, except for where I mean business, and then I may whip out the VRC6 channels instead.
So no, this wouldn't run verbatim on an actual NES, even if you recoded it in 6503 Assembly, but you would be able to get quite close.
How did you learn to make pixel art?
Well, when I was a wee little neurodivergent child, one of my favorite hobbies was making tiles and characters in MS Paint and building big collages out of them. I made a lot of beehives, for some reason...
Then I became a medium-sized neurodivergent teenager, got really into RPG Maker 2000, and the sprites and tiles were not to my liking, so I started editing them and eventually making my own from scratch.
I'm now a fairly normal-sized neurodivergent adult, and making pictures out of little dots is still a lot of fun, especially with a harshly constrained palette. Doing NES-like graphics just kind of comes naturally after all that.
How did you learn to make music?
Honestly? I just began throwing myself at it. My first attempts were unabashedly bad. When things didn't make sense and I couldn't get them to sound right, which was all the time, I looked them up. Starting with general chord theory was what really made it begin to click. The first thing I composed and kept was the Lagoon Stage music, and not coincidentally it's been through the most refactors as well. Coming from an art background where I'm very used to the Ugly Painting Stage of any given piece has definitely helped with patience, too. The important thing is to just keep beating your head against it. It's frustrating, but you only learn to make music by making music.
Every track on the OST represents about two days of feverishly slamming notes together for four-six hours a day, preceded by one-four whole months of tapping and humming random things until one of them ignites something in my brain that goes, "Oh, I know how the rest of this should go!"
How did you learn to code?
Well, honestly, I didn't; PGM is a visual scripting engine, so everything pretty much looks like flowcharts, and the number of functions is kind of constrained. Every object in the game is a state machine, so that's pretty much the paradigm I understand. I could not code my way out of a paper sack in any actual language.
That being said, I do understand the core concepts of what programming is, and most of that I learned by watching Retro Game Mechanics Explained on YouTube until I suddenly understood what 6502 Assembly was all about and everything else just kind of made sense. I don't know either! It's a little weird. But it did work, so I can't complain.
Is this related to [Other Fan Project]?
Nope, it's not part of or related to any other fanworks. I'm a solo dev working on just this one project right now. (However, if you're making a classic or MMX-style game and need pixel art assets, I'm open to talk about that! Please note though that I do not work for free.)
Your robot master has the same name/concept as [Other Fan Character].
Sorry if that's the case! There are so many really stellar MM fan characters out there that a little name/concept-sharing is basically unavoidable. No infringement is intended, no profit will be made from this game, and I'm uninvolved enough with the general fandom at large that I can pretty confidently say I didn't even know about your character. Take it as a case of Great Minds Think Alike, if it happens.
Do you have anywhere else I can keep up with this?
I sure do! I've got a Discord specifically for it where I toss a lot of WIP sprites and such, and that's where eventual playtesting will happen too if you're into that sort of thing, and a Trello that I don't always remember to update, but it exists at least!
Mega Man R Secret Gamedev Clubhouse Discord
Trello Roadmap (when I remember to update it...)
What's the pixel art in your banner?
That was just me greebling at random for practice and funsies. The full image isn't used anywhere as-is, but I did end up using some parts of it in the tiles.
So I've had a...some number of months break. I deal with a lot of chronic pain, and it started getting so bad back around March that I couldn't really do much of anything. I finally got it under control and was just about to get back to working on Mega Man R, but then my health took another turn and decided to be sick for a month straight (with at least five different things, in sequence, some of them overlapping!).
So that's where I've been.
But! I'm finally on the mend, fired up my current build yesterday, played through it once to refresh my memory...and promptly wrote a huge checklist of things that needed to be fixed. I'm about halfway through that, so it's going pretty well, actually! Most of the rest of the list is things that need finished, moreso than fixed, which is a very cool and exciting thing. When I'm through with that, I'll have...
Well...
An intro stage?
But it's something playable, and I think everyone will be surprised by some of it, so I'm pretty hype to get back to it.
But, uh, if you wanted to knock on some wood on my behalf, I wouldn't stop you...
I just realized that I forgot to even mention the broken wrist.
I think maybe we didn't knock on enough wood, because at the start of November, I promptly got hit by a car (as a pedestrian no less) and fell onto my hand badly, and my wrist was broken. Fortunately that was the only injury between both my partner and I! I can't even be too upset, because it could have been a lot worse than it was.
I got the cast off in December and it's been steadily getting easier to use my right hand again. And hey, I'm back in the game dev mines. I've solved a few tricky issues that turned out to be easier than I expected and I'm building a little momentum again. This time, let's knock on a whole lot more wood. Like, I'm going to invent Wood Man just so I can knock on him.
I'm still making progress! It's just been slow. I've recovered from my broken wrist adventure pretty well, but I have so many hobbies and so little energy...
But hey, don't cry. Sleeping metool animation, okay?
For absolutely full disclosure, the only thing I've used that could be called 'generated' was a plain random algorithmic melody generator. This is very different from generative AI under the hood in that it's given simple rules, not a training set, and no training is involved whatsoever; it's not even an AI in any sense, it's just a randomizer that works from a random seed and some manual settings, rather like Minecraft or Terraria worlds are generated, only with a very simplistic melody output. Even then I didn't use the output directly, because honestly, it wasn't very good, lol. I used it as a starting point for other ideas and that was all.
I am strongly anti-genAI as it's currently being developed and deployed and none of my projects use it, including this one.
So I've had a...some number of months break. I deal with a lot of chronic pain, and it started getting so bad back around March that I couldn't really do much of anything. I finally got it under control and was just about to get back to working on Mega Man R, but then my health took another turn and decided to be sick for a month straight (with at least five different things, in sequence, some of them overlapping!).
So that's where I've been.
But! I'm finally on the mend, fired up my current build yesterday, played through it once to refresh my memory...and promptly wrote a huge checklist of things that needed to be fixed. I'm about halfway through that, so it's going pretty well, actually! Most of the rest of the list is things that need finished, moreso than fixed, which is a very cool and exciting thing. When I'm through with that, I'll have...
Well...
An intro stage?
But it's something playable, and I think everyone will be surprised by some of it, so I'm pretty hype to get back to it.
But, uh, if you wanted to knock on some wood on my behalf, I wouldn't stop you...
Got bullet reflection from shielding enemies such as metools working.
Broke it again somehow that I couldn't figure out what had even changed.
Fixed it again but better.
Refactored it some more to make it easier to apply the ability to shield to enemy types.
Refactored the enemy types too: enemies that share behaviors and general appearance (metool groupings for example, or palette swaps of one enemy) are just one object now.
Got gabyoalls working.
Didn't like that the implementation I used made it so that they would freeze for 2 seconds when shot, but you couldn't reset the timer by shooting then again while frozen. Refactored gabyoalls next. Gabyoalls are now behaving really, really accurately. Probably don't have to mess with them much more other than to implement a couple weapon weaknesses later once those weapons fully exist.
Realized that I had not accounted for some screen transition behavior with regards to ladders and the different between falling down/jumping up a ladder and climbing down/up a ladder, and now you can properly jump up ladders to the next screen to conserve momentum.
Knocked out some preliminary stage design!
Got annoyed because during playtesting, metools still weren't reflecting shots quite right: if you stood RIGHT next to them and shot rapidly, only about every third shot would reflect and the others would disappear.
Got more annoyed and started to say I couldn't fix it with engine limitations.
Realized mid-sentence that I totally could.
Refactored the entire reflect system AGAIN, this time for keeps. It works perfectly. It's going to be leaps and bounds easier to implement and test. I'm so pleased.
Implemented a bunch of sound effects since I've been lazy on that front, which is no good. That'll start adding up to a lot to deal with if I don't do them as I go, but I'm pretty much caught up on that front.
It's been a busy week, but it's been productive too, which feels nice. Eventually I'll maybe even have something playable to show?
Been slowly ( s l o w l y . . . ) working on some initial stage design and working out some weird bugs that I swear didn't exist but now they do? But that's just game dev life. Things happen. On the plus side, I'm getting leaps and bounds faster at diagnosing and solving issues, and it's all gameplay stuff that once it's really nailed down, it's set for the rest of the game.
(Unless it breaks again?)
Also, this works now. Very important mechanic, you know. Literally unplayable if you can't get inked by Octone.
Here, have a couple of old friends with new frames of animation while we're here:
So far, I've actually been sticking to it! The New Year's resolution, I mean. I went back and did some much-needed cleanup on the intro sequence, fixing timing and some of the art, and I've been working on stage design a little bit. Gasp! Playable content? In MY fangame? (It's more likely than you think.)
There is so much enemy AI design to slog through, though, because I have this thing about interactions all needing to be interesting...and I mean, I'm not wrong, 'generic thing that sits there and shoots at you #6' is not that much fun to deal with. Everything should have some single thing that makes it kind of unique to deal with. Not complicated, that's generally reserved for bosses, just not an absolute vanilla nothingburger of an obstacle, either. It's those single details that make emergent challenges when you start combining them. So that's the next big work thing.
That and sound effects. I kind of have been ignoring them. No more of that. Going back and retrofitting an entire game's SFX would suck. I gotta start including that in the workflow better.
I really need to update the Trello, too, I've nearly forgotten it...
(I can't even mention my game on Bluesky without getting flooded with follower farm accounts...it's very annoying. I think I'll be sticking to Tumblr indefinitely as the social media outlet for it. I like room to expand on things in posts, anyway.)
Happy New Year! This year I'm going to actually work more on this game and not write another 500k+ words of MMX fanfiction instead...(even if that was very satisfying to do)
I am so looking forward to this. As a Roll fan and that I run a meme page on Facebook based around Roll, I'm pretty hyped. I hope Kalinka makes an appearance but I know you're working on the engine which honestly makes a lot of sense. Since I'm in school (Nursing hehe like Roll though that was a coincidence) now, I have time to wait. So looking forward to playing this.
Question is she going to be ranged like Mega Man or is she going to be melee like in Powered Up?
Awesome! I admit I don't really have any Kalinka appearances planned, but that was mostly because I hadn't thought about it...if I can find a place to fit her in, I'd like to at least try.
And yeah, waiting is definitely a thing, though I'm done enough that I'm very slowly getting started on creating actual playable content. Stage design is tougher than it looks, but so far pretty fun.
That's a good question, though. Roll will be largely ranged. I am planning on having some of the weapons she acquires do different things like mobility or melee, so there's going to be some variety in that, but generally speaking she'll play like Mega Man for this game. I know different games like to give her different abilities, like you mentioned and like Rock 'N Roll's double jump, but eeh, I decided to keep it fairly close to classic. If she's got anything different it'll be via acquired weapons. (Subject to change if anything really crazy happens, but I pretty much have the weapon system nailed down in the engine, so I don't expect anything much to change on that front.)
When I say "backward", I mean that when work actually begins on a game, there's typically kind of an… order… to how things should logically go: make the game engine and all the conceptualized bits and bobs, test to satisfaction, and then make all the assets. A lot of people do it the other way, though. I used to, back when I dabbled. Realistically, though, making the entire engine first with all it entails just makes more sense to me, these days.
As for the save system? Here's what I expect from a Mega Man save:
Save Game Slot
Stages beaten and/or weapons collected (2 to 4 bits?*)
I am definitely going engine-first, generally speaking; a lot of those assets are UI bits and pieces. I'd say the majority even. I do have a fair amount of other sprites/tiles at least roughed out, but that's because I'm a visual artist so that's the fun part for me, and it all needs to happen at some point anyway, so I haven't tried to stop myself from working on the parts that sound fun at the moment. Especially since getting a cohesive 'look' across the whole game is a massive task, and having a really long time to think it over and refine things is only going to be of benefit.
A whole lot of what you've listed is just not possible to implement easily, if at all, in the engine I'm using. Total playtime per file, items used, enemies killed, the basics that make the game work at all (Robot Masters defeated and the like)—sure, that's all doable and largely done even, but lifelong stats across multiple files aren't supported in any reasonable way because save files simply don't interact with each other. If I load one to reference a variable, I have nowhere to store said variable to add it to another from a different save, because referencing that save will lose the first variable entirely no matter what I do with it or where I put it. Cumulative totals simply cannot be a thing with this engine, essentially, which isn't the end of the world. After all I'm basically doing an NES-like with a few modern bells and whistles, so being somewhat less detailed in save data than other modern games isn't going to make or break it.
I have no idea what is actually in each save file as far as data. They're all in JSON and they're not particularly human-readable, because everything is obfuscated. If this were actually something I was coding from scratch in a real language, yeah, I could worry about individual bits and bytes, but I picked an oddball engine off the strength of its being easy to learn (...and having already been in my Steam library from a sale...)—I know exactly zero programming languages, unless you count Pixel Game Maker MV's visual scripting system. So that hampers a lot of things; it's state-based, not object-oriented, and things like menus and UI absolutely suffer for it. The degree of tedium it takes to set up a basic foundation is...yeeegh. I do understand the concepts better, and I will probably switch to Godot or something with a lot more fine control if I do another project, but as it stands... the bit/byte count is all very interesting but I have no access to the save file structure beyond, "Keep these switches and variables, allow these others to reset to default." (Also I don't know how to do math in hex much beyond being able to generally count from 0 to 15, which is all I need to use Famitracker effectively, lol.)
I kinda just started on a whim to see if I could do it, so the order of operations has been whatever I'm confident will actually allow me to keep making progress. Things like doing the music first happened because I didn't want to get years deep into making a game only to discover that I have no ability to compose, so I completed a fair amount of it first to make sure it happened at all. (It turns out I'm okay at it, fortunately.)
But yeah, I'm sure there's a lot of nontraditional stuff happening, because I have no idea what a traditional workflow even would be. I'm emphatically not a programmer, even if I do seem to be programming. My entire background is making dumb things in RPG Maker 2000 back in high school. The fact that I've organized myself enough to get this far is a testament to the combined power of ADHD medication and sheer stubbornness.
But believe me when I say that I am painfully aware the save system should be X, Y, and Z things. It just is what it is, though, and what it is is extremely limited and very, very prone to producing errors if things aren't laid out just so. Even trying to save two files too quickly will cause at least one of them, if not both, to simply not output at all. So for even just this basic functionality I feel pretty accomplished and while I do want to add some more miscellaneous stats plus some way to view them, which is a whole other UI setup that I'll need to do, there is no way to add much beyond that.
But again, I think that won't horribly impact anyone's enjoyment, in the end. People still have plenty of fun with much less. I almost didn't even include saves, but my dev Discord voted down a classic NES style password grid system. Would have been relatively very easy to implement, but alas. The people have spoken.
I should add that there is one way that would technically work for multiple save files with lifetime play stats and you could support any sort of cumulative save data you could imagine with it, but I'm not doing it, because it would involve emulating multiple save files within one save file...meaning that for every single time a saved variable or switch is changed, I would need a bunch of branching logic to disambiguate exactly which "save file" I'm changing, and I would rather eat my own teeth than deal with the bugs that would invariably produce if anything at all in the entire game was set up even slightly wrong.
You know, you remind me of someone I know. Me! topkek. I actually got back into MegaZeux last year just to "see if I could" still have some vague idea of how to code tile-based games. Honestly, my progress with my stupid little game astounded me. I managed to code a Wolfenstein 3-D-style "guard pathway" system without too much trouble, among some other things. "To see if I could" is sometimes a very powerful motivator. For better or worse, though, I feel like my main motivator beyond that is… spite. I've made a lot of Mega Man 2A03 arrangements purely because the ones in Mega Man Maker were so crap. Hee hee.
Anyway. In my experience, making a game (or getting, say, a bloody title screen to work) is rarely fun. I mean, sure, I've gotten utterly lost in the code (MegaZeux, ROM hacking…) as I troubledshooted the same thing for three hours straight only to find out, "Oh! It was this little thing I overlooked all along!" And yes, that dopeamin hit when it all comes together is freaking sweet as Lik-M-Aid powder… but yeah. The road there is fraught with ick and bleh, not to mention a lot of confused swearing~ So, yeah. I understand wanting to do the graphics first — especially if they're UI-related.
Regarding the whole "duct tape and bubble gum" thing… Yeah. I helped with several Sprites, Inc. projects and a couple of Blyka's Door's games. Also, I played through Mega Man Eternal, somehow. I am all too familiar with the "duct tape and bubble gum" method of programming. Also, the original Battletoads was very fragile, too. Something to think about~
As I implied, I like to think that the code comes first, the graphics and sound come later. That's how I'd do it, anyway, but that doesn't necessary mean it's "right" or "correct". Game development is all about priorities. Not "necessities". Priorities. And unless you're under contract, those priorities should be personal ones. Don't let me or anyone tell you what you should do, when, where, and especially how. If it works for you, then that's all that matters, yo.
Regarding the save game system… The hell are you using? Klik 'n Play? Without user-made plugins? That system you're using sounds terrible and bad. d:
Joking (???) aside, it baffles me that whatever save system you're using is that convoluted. Even old DOS games that I love sometimes just use, like, 24 consecutive bytes of data rather than this whole big thing. Now, having it encoded is good to prevent people from editing their saves. I actually poked around the Mega Man 2.5D save files and force-unlocked stuff since it's just a simple INI file with open variables. (Which is another option.) But, if you're serious about not letting people cheat their way through, then yeah. I guess encoded JSON works.
As for save file content? I more or less just listed all the possibilities I could think of, thinking of fan games like Rock 'n Roll and Unlimited, or even Mega Man 9 or 10. Honestly, most of that stuff I mentioned is entirely useless if you're just making a simple NES-style game. All you need is game progress. That's it. Everything else is a frivolity. Maybe Tanks and/or Lives if you're feeling generous, but beyond that? Just progress. It'd be very Mega Man 2 style, in that regard. And honestly, the culumuative totals thing is something no game has done, as far as I'm aware. It was something I considered, since games like Chrono Trigger have been on my mind, lately.
You really have no idea how the save system works, though? None at all? Oh, you sweet summer child… Please, consider Godot. Quickly. (,:
I do understand how a save system would work. It's just not something that I can implement in Pixel Game Maker MV. I just never learned to do math in hexadecimal, or to code. (Also I'm 40...I know it's just a saying but ??? I'm neither that young nor that inexperienced.)
PGMMV is actually extremely good at certain things and is specifically tailored towards platform games, not unlike how the RPG Maker engines are for RPGs. The sprite animation system is fantastic, scene management actually makes sense unlike the time I looked at Game Maker and immediately got lost, and being a state engine makes it very easy to deal with enemy/object behavior since games are largely state engines anyway. It's UI/UX and utility functions where it kind of falls flat, since none of those things are streamlined and looking at them from a state engine perspective is a little wacky. Fully doable, just very, very not streamlined.
The thing that makes the save system convoluted is that 1.) The engine gets mad if you use more than one command interacting with save files per runtime action (the box part of the flowchart in this visual scripting system) and will ignore file command after that until you give it a new runtime action to read; 2.) This fact wasn't documented and is probably a bug, but if I upgrade I risk breaking the game thus far, so I'm not even on the newest version of PGMMV...I'm back where I have to be in order to make a text plugin that I'm using for dialogue SFX work; 3.) Nothing at all is set up out of the box for you with this engine, so even restarting from the beginning of a stage when you die isn't natively a thing. (Dying isn't a native behavior, either.) Having any kind of checkpoint is actually a use of the save system, and I've got three: start of stage (if you die without reaching a midway checkpoint), midway checkpoint, and autosaving at stage select. They all work just fine. Getting them there was unnecessarily convoluted, but it works great now and from a player side you'd never know.
The thing that was the biggest hurdle was coming up with a way to display the data in any given save file. I set out envisioning something like this:
This was an early mock-up and ideally would have displayed the information for three files at a time, but then I realized I can only have one file's variables loaded.
So I refactored it to fit those constraints:
And honestly? It looks much better and it works just fine. (This is a live test window, thus the little dev controls at the bottom.) I'm not a programmer but I do like problem solving, which is almost the same thing, and while PGMMV has problems, they're pretty solvable, and I think I work better with some weird constraints, thus the decision to make an NES-like game in the first place: the constraints are something I'm familiar with, it's a consistent vibe, and scope creep is easy to fight when all I have to do is ask myself if this makes any sense in the context of the rest of the game.
When I say "backward", I mean that when work actually begins on a game, there's typically kind of an… order… to how things should logically go: make the game engine and all the conceptualized bits and bobs, test to satisfaction, and then make all the assets. A lot of people do it the other way, though. I used to, back when I dabbled. Realistically, though, making the entire engine first with all it entails just makes more sense to me, these days.
As for the save system? Here's what I expect from a Mega Man save:
Save Game Slot
Stages beaten and/or weapons collected (2 to 4 bits?*)
I am definitely going engine-first, generally speaking; a lot of those assets are UI bits and pieces. I'd say the majority even. I do have a fair amount of other sprites/tiles at least roughed out, but that's because I'm a visual artist so that's the fun part for me, and it all needs to happen at some point anyway, so I haven't tried to stop myself from working on the parts that sound fun at the moment. Especially since getting a cohesive 'look' across the whole game is a massive task, and having a really long time to think it over and refine things is only going to be of benefit.
A whole lot of what you've listed is just not possible to implement easily, if at all, in the engine I'm using. Total playtime per file, items used, enemies killed, the basics that make the game work at all (Robot Masters defeated and the like)—sure, that's all doable and largely done even, but lifelong stats across multiple files aren't supported in any reasonable way because save files simply don't interact with each other. If I load one to reference a variable, I have nowhere to store said variable to add it to another from a different save, because referencing that save will lose the first variable entirely no matter what I do with it or where I put it. Cumulative totals simply cannot be a thing with this engine, essentially, which isn't the end of the world. After all I'm basically doing an NES-like with a few modern bells and whistles, so being somewhat less detailed in save data than other modern games isn't going to make or break it.
I have no idea what is actually in each save file as far as data. They're all in JSON and they're not particularly human-readable, because everything is obfuscated. If this were actually something I was coding from scratch in a real language, yeah, I could worry about individual bits and bytes, but I picked an oddball engine off the strength of its being easy to learn (...and having already been in my Steam library from a sale...)—I know exactly zero programming languages, unless you count Pixel Game Maker MV's visual scripting system. So that hampers a lot of things; it's state-based, not object-oriented, and things like menus and UI absolutely suffer for it. The degree of tedium it takes to set up a basic foundation is...yeeegh. I do understand the concepts better, and I will probably switch to Godot or something with a lot more fine control if I do another project, but as it stands... the bit/byte count is all very interesting but I have no access to the save file structure beyond, "Keep these switches and variables, allow these others to reset to default." (Also I don't know how to do math in hex much beyond being able to generally count from 0 to 15, which is all I need to use Famitracker effectively, lol.)
I kinda just started on a whim to see if I could do it, so the order of operations has been whatever I'm confident will actually allow me to keep making progress. Things like doing the music first happened because I didn't want to get years deep into making a game only to discover that I have no ability to compose, so I completed a fair amount of it first to make sure it happened at all. (It turns out I'm okay at it, fortunately.)
But yeah, I'm sure there's a lot of nontraditional stuff happening, because I have no idea what a traditional workflow even would be. I'm emphatically not a programmer, even if I do seem to be programming. My entire background is making dumb things in RPG Maker 2000 back in high school. The fact that I've organized myself enough to get this far is a testament to the combined power of ADHD medication and sheer stubbornness.
But believe me when I say that I am painfully aware the save system should be X, Y, and Z things. It just is what it is, though, and what it is is extremely limited and very, very prone to producing errors if things aren't laid out just so. Even trying to save two files too quickly will cause at least one of them, if not both, to simply not output at all. So for even just this basic functionality I feel pretty accomplished and while I do want to add some more miscellaneous stats plus some way to view them, which is a whole other UI setup that I'll need to do, there is no way to add much beyond that.
But again, I think that won't horribly impact anyone's enjoyment, in the end. People still have plenty of fun with much less. I almost didn't even include saves, but my dev Discord voted down a classic NES style password grid system. Would have been relatively very easy to implement, but alas. The people have spoken.
I should add that there is one way that would technically work for multiple save files with lifetime play stats and you could support any sort of cumulative save data you could imagine with it, but I'm not doing it, because it would involve emulating multiple save files within one save file...meaning that for every single time a saved variable or switch is changed, I would need a bunch of branching logic to disambiguate exactly which "save file" I'm changing, and I would rather eat my own teeth than deal with the bugs that would invariably produce if anything at all in the entire game was set up even slightly wrong.
Fantastic news! Well, not very exciting from the outside, probably, but still good. I've got a functioning save system! This only took me *mumbletymumble* months to figure out, most of which time I spent dragging my feet and not wanting to deal with it, because it sounded like it was going to be terrible, if not impossible.
However! It's extremely possible, works like a charm, and looks pretty slick too. Just...you know, tedious as anything to build, but it's basically done now.
This does mean, now that I've got that sorted, that some other menu screens will need to be somewhat refactored and finished, but that's all good news too. I'm closing in on the basic framework of things being done enough to begin actually developing some gameplay, which you would think happened more in game dev, but I've been working on this for somewhere over two years now and I haven't gotten that far still...Never mind that I've composed most of the soundtrack, produced hundreds of visual assets, and spent hundreds of hours programming, there's still no gameplay. It be like that. ✌️ But soon I can get that leg of the journey started, and I am super excited about it.
Well, first of all I keep writing really complicated novel-length MMX fic instead...which isn't making my other hobbies go any faster...sweats profusely.
But anyway!
Roll can die from taking damage.
Of course, this makes her lose a life.
She'll respawn at the start of a stage...
...Unless she's hit a checkpoint, in which case, she'll respawn from there instead.
And if Roll runs out of lives, you go to the game over screen.
From there you can choose to continue from the start of the same stage...
Or you can go back to the stage select.
(Or, technically, you can quit to desktop.)
So yeah, basic expected gameplay loop functionality, more or less. Doing all this from scratch is a lot more involved than it sounds like, though. There's a perfectly good Game Maker setup for making Mega Man fan games, aaaaand I'm not using that engine so it's basically useless to me and I started from quite literally nothing instead. Figuring it all out by myself instead took a long time and a lot of rubber ducking.
On top of that, Pixel Game Maker MV is, as I've learned the hard way, very tetchy about handling load/save operations, and I couldn't figure out why it was refusing to save checkpoints properly until I figured it out: the version I'm using for my dev environment will only succeed at a single file operation per runtime action. Any others in the same runtime action will silently fail. That was hours of trial and error to figure out why it was failing to write save files, but only about half of them, for no apparent reason. But it's been troubleshooted! Troubleshot? Whichever. It works now! It's actually been a huge hurdle.
All the Robot Master boss music exists, too, which is pretty cool. The first iteration accidentally sounded like John Cena's theme, which was, uh. Funny as heck, but not intended. So I went back and made that not be the case, though that means that the SiIvaGunner joke of remixing tracks to be John Cena's theme and saying they're an alpha version is not even a joke here, it's literal. That is a real thing that happened and I didn't even realize it until someone in the dev Discord pointed it out.
Next on the roadmap is getting individual file save slots functional. Checkpoints and level start actually use save files as well; they're just temporary, and the engine deletes and recreates them pretty frequently to avoid buggy shenanigans. I'd like to be able to display at least basic save file information on each save slot, so I'll need to figure out how that works and what that screen should look like. Games will autosave on the stage select screen, though you can always clear a slot manually to start a new game. Very SNES kind of system.
After that's all implemented and debugged, I can probably start thinking about actual playable content, since that wraps up the vast majority of the UI. Good thing, too, because I actually kind of hate working on UI. 🥲 It's a necessary evil, though, and I think it'll be a pretty alright UI when it's finished. Nothing groundbreaking, but does a classic-style Mega Man game need a groundbreaking menu? I think probably it doesn't, and I can save my energy for the gameplay.
Hello, I'm working on stuff still! Like this game over -> continue animation, because I need to actually have a game over case, and that means I need it to look cool also.
