#mothermaker | Explore Tumblr Posts and Blogs

va1ennyx · 1 year

Text

MOTHERMAKER Progress Report

(WEEK 1)

INTRO:

Ever since 2020, I've been toying with the idea of making an authentic 'MOTHER' engine within the limitations of RPG Maker.

I bounced from engine-to-engine, trying to find the right Maker to start work in, and eventually settled on RPG Maker MV.

You can even see some of my early progress here!

The hyperfixation eventually subsided after some small adventures in the MOTHER fangame scene, and I took a fairly long hiatus.

Fastforward to 2023 and you'll find me. In my room. Really Fucking Bored.

It started off with me brushing up on my event code, making some practice menus and playing with switches and variables. Eventually I ended up with this.

NOW. For the fun stuff...

TECH! TECH! TEEEECHHHH!!!!!!!!!!!!!!!

Going into this project, I had like. Three Fundamental Rules.

Those being;

All CORE systems must be retroactively achievable in previous versions of RM.

Everything must be achievable through RM's default features (i.e. I must utilize the default map editor, database, etc.)

Plugin/Script usage MUST be kept to an absolute minimum.

This will definitely make things difficult moving forward, but if I wish to create some sorta out-of-the-box MOTHER framework (especially one with THIS scale), I think it's important to adhere to SOME kind of design philosophy.

With these principles in mind, allow me to show you some of the duct tape and bubblegum holding the code together!

Starting with;

Menu Stuff!

In RM, developers are very limited when it comes to customizability, at least out of the box. That changed around the time we first received those iconic Don Miguel fan translations. Many developers were dissatisfied with the default systems given to them, and instead opted to use in-game eventing to manipulate pictures to do whatever they wanted. Very interesting stuff!

However, despite me being able to Talk For Fucking Centuries about RM history, I don't wanna lose too much focus on the subject at hand. You can check out my favorite website ever over here to learn more about the early lil seedlings of our community!

Anyways, almost every graphic-based aspect of this project is done through vanilla eventing. Now, as any Well Seasoned RM Developer can attest, THIS IS NOT A FUN PROCESS!! This is done by modifying variables based on inputs, and referencing those variables to determine where your image should be drawn.

This process can range from easy:

to HARD:

(just reference the scrollbar size for an idea of the process, this kinda shit is NOT something you want to see)

Now, for the save system, it was relatively straightforward. I just changed some switches to record which save the player selected, and a few variables to record which 'flavor' the player chose. These are referenced at various points, such as the battle system, the in-game menus, and even small stuff like dialogue boxes.

For the naming system, well, I haven't actually finished that yet. But you'll undersTAND WHY I PROMISE..

Basically, if I wanted to do this in a way I could "easily" downport to other versions, I had to avoid writing a plugin for it. As you can imagine, eventing an entire custom naming system is Not Fucking Fun. It's fairly easy to do however, just mighty tedious. I did some digging in threads for old RPG Maker MOTHER fangames, and I saw a few examples of people explaining how they made their systems.

Let's call my Chosen Approach 'The Roach Method'. This is named after the creator of a long-since-cancelled fangame called EAGLELAND. Essentially, he made different 'Actor' slots in the database for each letter of a characters name, and referenced them in dialogue through text codes. Once set up, it should look a little something like this;

So on and so forth.

The frontend of my keyboard (and a tiny bit of the backend), is functional. Obviously I can make it prettier and more responsive, but I want to make the naming process smooth first.

I'm thinking of making it so that when you press okay, it triggers a switch to move onto the next letter, and then when you press the cancel key it goes back by one? Idk yet this Keyboard Is The Worst Fucking Thing Ever.

Movement:

Most RM devs know this, but 'pixel' movement doesn't really play nice with the way the engine handles collisions. In my (few) years of Mother Fangame Experience, I've come to learn that the weird pseudo-collision detection utilized by RM (iirc its just a coord check to see if you can move or not) doesn't really Provide the Movement Experience we've come to expect from the MOTHER series.

This is one of the many contentious aspects of making MOTHER fangames in RM. A lot of devs treat (newer) makers like this "out of the box" solution to everything, this framework that you can just absolutely stuff to the brim with plugins to achieve whatever functionality you want. However, in practice, this proves to (almost) never be the case.

It's an especially nasty mindset because it contradicts the reality of gamedev (at least within RM) being a constant uphill battle full of compromise. Unfortunately this stuff takes effort, more effort than just dragging and dropping a JS file into the plugins folder.

tl;dr: plugins and scripts should only ever be complimentary to your event code, don't expect them to do everything for you!

RANT ASIDE!! For the most part, unless you want to make a whole new movement and collision system from scratch, you're gonna wanna stick with the grid. Most grid-based diagonal movement plugins allow you to turn on a setting that lets you clip through the corner of tiles (PLUS, the default follower system is 'MOTHER' enough). This is good because it allows you to make pseudo-slope collisions, which is really useful for stuff like fences and buildings!

You can even see an example of this here!

So yeah, when it comes to movement, the main compromise is choosing between functionality and fluidity.

Mapping:

I'll keep this one brief. The default RM mapping system is less than stellar. However, parallax mapping is NOT a good solution. It leads to massive bloated images inflating file sizes like no tomorrow, long loading screens, and occasionally lag. That's why its better to design your games around the limitations of RM, and maintain your project's scope.

That leads us to our....

CONCLUSION

Unfortunately when it comes to fangaming (specifically within RM), you need to be willing to compromise. You (most likely) will not be able to perfectly replicate your favorite game, and that's okay.

This is where The Big Question really rears it's head;

Are you making a good MOTHER game, or a good RPG Maker MOTHER game?

This is the main conflict when it comes to developing one of these weird lil things, and it's been the death of many a project. After all, you'd have to be Fucking Insane to put yourself through all the eventing bullshit that comes with the territory of anything custom being done in Rm. I mean, sometimes even *I* wonder if i even like doing this, or if I just REALLY wanna flex. Usually it's a lil bit of both. ;)

HOWEVER, it's important to manage your expectations and work ALONGSIDE the limitations of the engine, rather than forcing it to do something it can't and ending up dissatisfied with the final product.

Good read? Good read. See You next week (maybe) mwuaHAHAHAHAHAHAHAHAHAHAHAHAHAH

#rpgmaker #rmmv #earthbound #mother 3 #mother #rpg maker #gamedev

13 notes · View notes