Things I'm Learning About Making RPGs (in RPG Maker MV as Me)

For quite some time now, I've been trying to make an RPG in RPG Maker MV. Each time, I've run into problems, but I've also learned from those problems. They're pretty variable, but they all result in me getting utterly bogged down in particulars that drain me of all interest or motivation in continuing to make my current game. Along the way, I've also learned a few things about RPGs in general, both from my own gaming experience and from watching other's playthroughs. I'd like to share some of these thoughts, because I know doing so will help me better process the lessons I've been learning.

Before I really get into it, though, something that's important to know about me as a creative is that I'm a pantser. (A word from the writing world that refers to "flying by the seat of your pants." People like me need to figure things out as they go. It stands in contrast to "plotters," who plan everything out ahead of time, and then make the thing.) RPG Maker MV is rather unfriendly to pantsers because rearranging/reorganizing items in the database is terrible. Some amount of the trouble I've run into has been due to this, so if you function differently than I do, it's not unlikely that you'll have a different experience!

Now, let's dive in! These subjects are in no particular order.

The Dangers of Complexity (As a Designer)

Much ink (or pixels) have been spilled about the dangers of complexity for the player. Complex systems are, after all, both hard to learn and to teach, which can make it difficult for a player to get into a game. However, they're also hard to design. Therefore, for both players and creators, it's important to make sure the complexity is paying off.

Something I've often run into is having an idea that seems neat, but then results in me having to make a bunch of fiddly decisions. A common area this occurs is with armor creation. To use a current example, the game I've been working on, Astria: Princess of Light, has gone through various stages of armor design. At base, I had armor pieces with individual armor values for each damage type, and which part got hit was chosen at random, but some skills could target specific pieces. The problem is that this made it really hard to tell if a damage type was good against a specific enemy, since there was too much randomness to it (good against one piece of armor, but bad against another, for example).

I then decided to condense it down to just one armor piece, but going through and setting up all of the armor types, and trying to create variants within that, has been the height of tediousness. I don't think it's a bad idea, exactly, but what are the actual, meaningful gains from something like this?

And that's the balance point. The payoff for complicated systems needs to be sufficiently high to be worth it. And what is the payoff we're wanting? Interesting decisions in gameplay, whether that be tactical or strategic decisions during action periods (e.g. battle) or preparatory decisions during down periods (e.g. build-craft). A complex system can add depth—meaningful decisions—to these systems, or it might just be a lot of fiddling about with min-maxing to eke out narrow advantages. Some players might enjoy that, but I don't, and spending a ton of time working on those systems just doesn't work for me.

Another area I get in similar trouble from "making too much" (or, more accurately, setting myself up to make too much) is with other things like character classes or weapons. I want the distinctions between things to be meaningful, but I've often struggled to find ways to mechanically accomplish this, particularly within the confines of RPG Maker MV. In the end, I tend to go overboard here, but I'll talk about making meaningful distinctions later.

The summary of this is that it's very easy to end up creating systems that prove to be very complex, but that most players will probably kind of just ignore or gloss over because they lack any real depth. These systems often result in a high burden of design as you have to make a lot of decisions about what values to use for things, but this burden isn't worth it because it lacks good payoff for the average player's experience.

So Many Issues With Levels

RPGs are known for having character levels. These are usually linked to stats (there are a wide variety of stats, but common groupings are "HP, MP, attack, defense, magical attack, magical defense, and speed" and "HP, MP, strength, dexterity, wisdom, intelligence, and charisma" with "faith" sometimes making an appearance). Typically, you get experience points that result in you gaining levels, with each level gain increasing your stats in some way (common methods are static amounts, player allocation of points, or random amounts).

In abstract, the idea of getting better at doing things with experience makes a lot of sense. In practice, there are a lot of oddities about the way it gets implemented in games. Some of these are mechanical and some of them are logical. I'd be interested in hearing how other games I've not played address some of these things.

A lot of the mechanical objections I have come from problems around stats and balance. These are interconnected and kind of sit in my brain as a web or graph, so please bear with me as I find a way to present that mess in a linear fashion.

To start with, I find getting just a little bit stronger is usually uninteresting. This is why I like getting skills as I level (more on issues with skills later), as new skills do change how I play the game; or, at least, they can. The fact that slight stat gains don't typically translate into much change in play experience is an issue I've had with them for a long time. I can find some stat-based systems work for me, but usually when the stats themselves gate things, such as in the Souls games (Demon's Souls, Dark Souls 1-3, Bloodborne, Elden Ring, and similar games by studios that aren't FromSoftware). In these games, you have stat requirements to be able to use various things (weapons and spells are different types of things), so gaining access to new abilities like this can make levels interesting to me.

There are a few other issues with levels and stats that I've found as well, however.

One is that they're just a poor fit for an open world game. In general, open world games want to allow the player to access a lot of different locations at once. This has balance problems with level-based stats insomuch as you want lower level enemies for lower level players to battle. In other words, level-based stats are a linear mechanic that fit better with a more linear-style of game design. This makes it a poor fit for a game where the player can go in any direction—when the player has to return to those low-level areas that were directions they could've gone but didn't, the enemies will be extremely weak.

There are ways of addressing this, of course. Things like spawning higher level enemies in earlier areas when the player's level increases is one example. However, RPG Maker MV doesn't really come built-in with tools for doing that. There are some ways you could do this (using the "Appear Halfway" flag, for example) or by using plugins to add in the functionality (though this would likely be super clunky on the editor-side of implementation).

Oddly, there is another problem from more linear games, where the effects of level-based stats can be somewhat hidden because you typically aim to have enemies at generally about the same stat values as the player characters (or maybe a little above) to ensure the game remains sufficiently engaging and challenging. You don't want enemies to become trivial, after all, but this results in the player not really getting a sense for how much stronger their characters have become. You can compensate by sprinkling in some enemies from earlier areas in later ones so that players can feel the effects of their increased power.

Though that does bring up other issues related to stat-based leveling that are less mechanical and more connected to the overall narrative. Mostly, this has to do with the narrative meaning of more powerful enemies. This can create very odd scenarios where late game towns are surrounded by extremely deadly foes, while early game towns are surrounded by comparably weak foes. I like mechanics to have meaning, so this kind of thing bothers me a good bit!

There's also the narvisaud (a term I helped coin with Vernacular Games; it's a combination of narrative, visual, and audio and refers to the nonmechanical components of the game that work in concert with mechanics to build up a whole; ideally these should reinforce each other, but they can easily end up in dissonant places—ludo-narrative would fit within the idea of Narvisaud and is a term you're more likely to have heard) meaning of gaining more stats, particularly when they have evocative names like "strength," "dexterity," "intelligence," or "faith." What does it mean that gaining experience fighting enemies or doing quests increases your physical strength or dexterity? How does it do that? What are the greater world-ramifications of this? How can it make you more intelligent? I can maybe see an argument for bolstering your faith, but as a person of faith, I'd like to state that faith stats in games rarely do a good job of capturing faith itself.

In general, I've kind of reached a point where I'm not actually all that fond of stat-based levels. I think they can work well, but a lot of that "working well" isn't well explored in the greater narrative of most games, and decisions around them (e.g. enemy levels) are done for mechanical reasons rather than worldbuilding ones. The biggest benefit of stat-based levels mechanically is to give the player a feeling of progress; the dopamine hit of having a ding happen and seeing numbers get bigger. From a balance standpoint, they're terrible in my opinion, since they tend to invalidate a large number of enemy encounters (either too strong or too weak), and at this point, I think the only reasons to do that are narrative ones.

Of course, levels can be used for things other than stats, or they can be used somewhat minimally for stats (to avoid the greater issues mentioned here), but I've generally reached the point where I'm in favor of other methods of progression, especially progression that is opening up options and synergies, rather than just raw power level. Still, things like new gear or skill trees are reasonable alternatives in my mind.

Too Many Skills

I have a real problem with creating systems that have or need too many skills. There are a few things going on here that cause this, but to start with some initial headspace: I like games that let me have action-based buildcraft (where the focus of making a build is choosing what actions your character(s) can take). Guild Wars 1 and Magic: The Gathering are two of my favorite games, and I've also been a long-time fan of the Pokémon franchise. Something all of these games have in common is a large pool of options from which you select a specific set—skill bars in Guild Wars 1, cards in decks for Magic, and Pokémon and their four moves in the Pokémon franchise.

I often try to mimic those sorts of concepts in RPG Maker MV, but typically struggle with the actual execution. There are a lot of technical reasons for this that mostly have to do with how skill acquisition works in RPG Maker MV by default. I have found ways of overcoming them to an extent, but that isn't the point here.

The point is that too many skills on player characters leads to poor gameplay, at least in my experience. This is primarily because finding the skill you want to use on each character can become tedious, but also because it's easy to forget what tools you have access to. Another problem is player characters becoming too similar. The resulting lack of distinction brings with it its own set of problems.

The thing is, interesting decisions don't have to rely on a lot of skills, and while I like systems that have a lot of skills, unless I can also come up with a good mechanism for making the player choose what skills to actually get (or otherwise limit how many skills each character has), having a lot of skills can actually be a detriment rather than a bonus.

Also, and this bears saying, the more skills you have, the more complicated and difficult it is to balance them. Additionally, because I like to have each skill have purpose (rather than an upgrade structure like, say, Pokémon uses, where some moves are just blatantly more powerful than others), all of these issues are further complicated.

Lore and Storytelling

I've come to realize I run into a lot of problems here. As I mentioned in the levels section above, I like mechanics to have a narrative/lore reason for existing. I also like to have more of a Souls-style method of handling game overs (respawning at a checkpoint—note: not reloading at a checkpoint) rather than requiring the player to load their last save for a variety of reasons—I don't like requiring the player to remember to save regularly, and I don't like them having to remember things they've done (e.g. inventory management) or lose out on loot they've gotten. The problem is that I want an in-world explanation for why this method of handling game over happens. That's often difficult to concoct, and tends to have a huge impact on the type of story I can tell.

Another problem I run into is that I'm quite fond of Souls-style storytelling, where there's almost an archaeological feel as you read item descriptions, environmental clues (including things like enemies), and pick up details from NPC dialog. Item descriptions are possible in RPG Maker MV, but space for them is incredibly limited and information about gameplay is more important to include in my opinion. You also can do environmental clues in RPG Maker MV, but unless you have custom assets you're using (and if I was doing that, I wouldn't be using RPG Maker MV), the range of what you can do is extremely limited. There aren't any issues with NPC dialog, at least.

What I've come to realize is that, at least with the way I'm using it, RPG Maker MV just isn't very good for Souls-style storytelling. But it isn't just RPG Maker MV: Doing Souls-style storytelling requires a lot of plotter-type work because you need to plan out a ton of details in advance so you can design the game around them (at least, it seems this way to me). As I've previously mentioned, I'm a pantser, which means I'm naturally bad at plotting. That means I've got a double-whammy: both me and the tool I'm using are bad at Souls-style storytelling!

I also really like the worldbuilding and lore consistency of Souls games. They work well for more open-world games that are more exploration driven rather than being character driven. This is also not playing into RPG Maker MV's strengths. Things like acquiring new characters in unknown, variant orders (I like the shuffling of randomizers and have definitely been influenced by them in this regard—anything that can change up how a playthrough works is interesting to me) also just automatically hampers any real character interactions. Part of that is on RPG Maker MV—while you can adjust things like dialog based on whether or not a character is in your party, it'll quickly become extremely burdensome to do so, especially if there are a lot of possible combinations.

Overall, I've just really struggled with this aspect of making an RPG, but there are some other thematic issues I've run into as well. I find I've fallen into too many "chosen one" type themes that I'm realizing I don't actually want to do. This is in part due to greater storytelling things I want to do combined with wanting to have an explanation for why the player party doesn't game over if you all die. Like, a world where death doesn't stick opens up an enormous can of worms—the implications are enormous. So to avoid them, I then have to contrive a reason why only the player party can avoid death, which naturally leads to "chosen one" characters.

Because of many of these factors, I've tended to be bad at focusing on characters. This is something I'd like to change, in part because I think RPG Maker MV might be better for trying to tell a more character-focused story than the sort of Souls-style storytelling I've often wanted to do, and in part because conversations with my sister have made it clear to me that the best stories tend to be character-driven ones.

I also want something smaller in scale and lower in stakes than the kind of stories the "chosen one" narratives I've begun crafting create. That requires a different approach, too.

Frankly, the kinds of games I lean towards ultimately wanting to make have a lot of procedural generation, but that's not at all reasonable to do in RPG Maker MV (though I don't doubt that it's possible to do through plugins, I suspect it would be an enormous pain in the butt). Someday I do want to explore such systems, but it is not this day.

Economies and Rewards

Economies in video games are prone to inflation, which results in a number of potential problems. If nothing else, you'll need to plan around that inflation. Of course, there are rewards other than money ones, but all of them may have inflation. To be clear, when I say "inflation" in this context, I am talking about the player character's income or wealth steadily increasing.

From what I can tell, there are two main contributors to inflation. The first is increasing rewards for players, which is particularly common in RPGs. The second is that games don't inherently have bills and other regular expenses. If you consider the real world, we have so many things we have to spend money on: taxes, fees, bills, groceries, fuel, etc. These recurring, regular expenses force money out of our wallets. In the context of video games, if a game lacks recurring, regular expenses (which is often the case for a variety of reasons—more on this in a moment), then even a small amount of income (usually in the form of loot) will accumulate, potentially to a large amount. Of course, in this scenario, it is likely that this accumulation is happening because the player doesn't feel that there's anything worthwhile to spend their money on.

Oftentimes, RPG economies are undermined by loot and treasure chests. Sure, you may have healing potions that the player theoretically wants to buy from stores, but if enemies drop them or treasure chests contain them, then it can also be possible that they'll find enough out in the world and thus have no need to buy them. This is a common problem in games with consumables in general. Consider classic Zelda games, such as Ocarina of Time, where you can find consumables by breaking pots or cutting grass. There's no reason to spend rupees on a bundle of 20 arrows if you can just go chop down a patch of grass for at least that many. Simply put, offering consumables as a reward undermines their use as something for the player to spend money on.

This also applies to nonconsumable items, such as equipment. How often have you bought a new weapon in an RPG, only to find the same thing (or something even better!) in the next dungeon you dive into? How often do quest rewards outclass anything the shops sell? I know as a player, I often don't buy equipment from shops if the game establishes a precedent that quest rewards or dungeon loot will soon outclass anything I could buy.

There's more I could say about this (and will on the topic of healing specifically in a future section), but the lesson here is simple: Don't accidentally undermine your economy with loot and quest rewards. It's very easy to do, and like everything, it's fine if you do it intentionally. I for one have tried to be cautious about this sort of thing, but finding the right balance is really tough.

Which brings us to the next (first mentioned) issue: Increasing rewards for the player as they progress through the game. This is especially prevalent in RPGs because you want "harder" enemies to offer better rewards; or, more accurately, you don't want trivial enemies that the player's levels cause them to now radically outclass to offer rewards equal to those of enemies that are on par with the player characters' current power level.

This is one of those issues that comes from increasing stats with levels. There are, of course, multiple ways to address this, with the two most common ones being increasing costs along with increased rewards or keeping costs static, but decreasing rewards from defeating weak enemies. I think the former is more common, but I've spent so much time playing Guild Wars 1, which does the latter (to an extent; this is actually a bit more complicated) that my own perspective has been skewed.

This is a spot where having analytical experience with a wide variety of games is really useful, and that's something I can improve at. You see, I've often made potions that heal for percentage amounts (which, if I'm recalling correctly, Tales of Symphonia does—that's another game I've liked a lot). There are advantages to this; for example, healing items will remain consistently effective. There is a downside, too, however: they remain consistently effective.

If you have potions that heal a static amount (e.g. 50 HP), then it's much easier to increase the costs of healing items and have the player purchase them because they're so much more effective. This didn't dawn on me until I was watching a Chrono Trigger Let's Play, because that's when I recognized the solution to a problem I'd encountered, despite the fact that I have seen this exact same strategy employed by Pokémon, a franchise I've been playing for over 20 years. That would sort of make me feel silly, but I also haven't really played Pokémon games in an analytical mode that would lead me to observe this stuff, and it actually wasn't until I started writing this section that it even dawned on me that Pokémon does the same thing Chrono Trigger does with healing item costs.

In all of this, along with seeing my own play patterns while playtesting the RPGs I've worked on in RPG Maker MV, I've settled on a few key takeaways for game economies that I hope are helpful to you, too.

1. If you want money to be relevant and a meaningful reward, you need to not undercut it with other rewards. If you train the player that buying stuff is bad because they can a) get all the consumables they need for free and b) get the best equipment through quests or as loot, then the player won't have any use for money.

2. It's a good idea to find recurring uses for money, and I don't just mean optional "nice to haves," either. This means increasing rewards can feel freeing for the player by allowing them to afford the "nice to haves." Note: I am talking about in-game currency, like gold. Please do not nickel-and-dime your players for real. Also, this approach isn't right for all games.

3. If you're going to have increasing player rewards with later game enemies (however you want to conceptualize this), and chances are you will if you're making an RPG, then it's important to ensure there are good uses for those rewards.

Gear Properties

I've come to learn a lot here as I've muddled my way through trying different things. Many of these troubles come from attempting to mimic equipment concepts from games I enjoy; in this case, I want to particularly emphasize Guild Wars 1 and the Souls series. These games, in various ways, left me with a desire to not do the traditional RPG thing of having progressively more powerful gear. Rather, new equipment should have tradeoffs such that everything is useful in its own way. As I reflect on it, this created a lot of problems.

In general, I tried to create too much gear. Making any given piece actually meaningfully distinct in any real sense was rather fiddly and a balance nightmare. At this point, I think mostly keeping gear simple  is a better idea, with nuanced differences only really being good in situations where fashion is possible. (In other words, if your gear doesn't let you customize a character's appearance, then a bunch of small differences adds noise that, at least to me, is mostly meaningless.)

Clean, simple effects are easiest to understand and compare. I'll grant you that some players enjoy the process of min-maxing, but I've long been of the opinion that only actual changes (e.g. defeating an enemy with one fewer hits or being able to take one more hit) matter.

This also applies to too many types of gear, where efforts to create distinctions can result in increasingly narrow amounts of design space for any given type, which makes it hard to create a variety of things within each type. This is a problem I ran into on Astria, where I tried to make distinctions between a huge number of weapon, armor, and accessory types. The number of different properties available to me is decently wide, but when split up between as many different types as I had, it proved to be rather few indeed.

A special mention needs to go to armor. I've tried quite a few different damage formulas and armor schemes, and I keep coming back to a few core concepts. One is the meaningfulness of damage types—Pokémon has the right of it in this regard: if you want damage types to be important in your game, they need to have a significant impact, and calling out that impact (the classic, "Super effective!" and "Not very effective" of Pokémon being the example here) does wonders for providing the player with feedback. Otherwise, damage types end up mostly being noise.

I've also tried a number of weight systems, inspired by the Souls series. In general, however, those systems haven't worked out super well, often because things are somewhat unclear. This is in part due to the challenges inherent in the broader, more binary systems of RPG Maker MV and their implementation of a turn-based battle system. In Souls games, heavier armor's defense is counterbalanced by decreased mobility and sometimes lower stamina regeneration, which works well in a real-time combat system with free movement. Those concepts can be somewhat translated into a turn-based system, but often a bit clumsily. I think my biggest issue here has been with the UI.

Which neatly brings me to another problem. Putting a lot of properties on a piece of armor (or other gear) results in serious challenges when it comes to communicating to the player what the gear does. This is primarily a result of RPG Maker MV providing very limited UI space, both in engine (I'd need to adjust resolution to get more, and that would have a lot of other impacts to everything) and in editor (the description box for things is only so big so as to accurately communicate space in the engine's UI).

Simply put, I've struggled to set up systems to enable the player to compare overly complicated gear against other pieces of overly complicated gear. I've also struggled to clearly communicate the impact of weight systems.

Gear and Skills

This is yet another area where I have often gotten myself into trouble. You see, RPG Maker MV provides several ways of giving characters new skills. They can be learned on level up as part of their character class, they can be taught to them through an event, or they can get them through Trait Objects, of which equipment is the most prominent type (Class, Enemy Type, Actor, and States are other Trait Objects, for those curious).

I've often made it so that equipment grants the wielder skills. Usually, I've done this with weapons and rings. After several iterations of these systems, I've come to appreciate some very real design problems this sort of pattern can create.

The first problem is that skills on gear can contribute to the "too many skills" problem I talked about previously. Of course, this is especially true for me, given how I've tried to make it so that things aren't strictly outclassed, but even ignoring that, depending on how many skills gear gives, it can (and has for me) contributed to greatly increasing the number of skills the player has access to at any given time. It also creates a lot of design overhead to try and make weapons distinct from each other.

The second problem, and one that is in some ways more serious from a pure design standpoint, is that it results in identity erosion. You see, characters need distinct mechanical identities to feel different from each other in gameplay. This is like how colors in Magic: The Gathering need to adhere to the color pie—the more you spread effects around, the less distinct each color (or character/class/etc.) is, and the more interchangeable they become. This is also why, for example, learn sets in Pokémon are so important. If every Pokémon could learn every move, then mechanical distinctions would be greatly diminished.

To put it another way, when mechanical identity erodes, everything feels more and more similar to everything else. I do not like this, as it runs counter to my sensibilities, and often counter to my goals as a designer. And yet, due to how I frequently implemented these systems, skills on gear would result in this very thing happening.

Now, it is possible to avoid this mechanical identity erosion by being very careful about what types of gear get what effects and which characters can use which types of gear. However, this is something I've historically been very bad at doing. It also took me a startling long time to realize this was happening, and it wasn't until I'd done a particularly egregiously bad job with mechanical distinctions between the weapon types in Astria that I truly realized it.

Healing

Healing deserves its own category because it is fraught with so many pain points. In general practice, there are three categories of healing I want to talk about: skills, potions, and inns. Skills are, well, skills that heal (usually restoring HP, sometimes MP, cleansing from debuffs/conditions, etc.). Potions are items that heal. Inns are NPCs or locations that heal (usually for a fee, though sometimes for free, like Pokémon Centers in Pokémon)—the critical thing here is that the healing occurs at a static location, rather than being something the player carries around with them.

Pain points with healing occur because these things all compete with each other for player use. In general, skills are the "cheapest" option for healing, so players tend to gravitate to using healing skills first. This can render healing items functionally worthless. This means they can cease to be meaningful rewards or useful shop items.

A solution I've used is to disallow healing skills from being used out of combat, but that often feels bad to players who expect to be able to use healing skills outside of battle. It does serve the goal of making healing items useful, though.

A simple example of things going poorly here comes from Ocarina of Time. While I wouldn't classify this classic Zelda title as an RPG, it does have potions that I've basically never used. This is because healing can be readily found in grass or pots, but also because potions use a bottle, which fairies (that restore all of your HP and can also revive you on death) also use. Fairies are also freely available in many locations, while potions aren't. This is yet another way in which Ocarina of Time undermines its economy.

The Pokémon franchise actually does a really good job here! Healing items are highly relevant because most Pokémon don't actually even learn healing skills. They also tend to not be able to heal others, and even if they can, PP (Power Points, the number of times a skill can be used) are also fairly limited for such skills. This means healing items are far and away the primary method of healing your Pokémon in combat, and they're also very useful outside of combat. That said, because items to restore PP are very limited (usually—Leppa Berry farming can change that, of course), Pokémon Centers remain very useful for healing, too. Of course, the fact that they're free adds to that.

I think it's important to overall recognize that healing is one of the more effective ways of creating something that the player will regularly pay for, which can be important for the game's economy. Finding a good balance here is therefore important on many fronts.

Conclusion

I have several significant takeaways from writing this. The first is one you might have picked up on, and that's just how important worldbuilding is to me, but also, how much I see mechanics as a key aspect of worldbuilding. Another one is that I need to do more mechanics-first design, rather than narvisaud-first. As a modifier to these, I also need to be careful about a few specific things relating to RPG Maker MV development: first, I need to work with the tool instead of trying to circumvent it, and second, I need to embrace points of flexibility. Let's dig into these!

I've known for quite some time now how important worldbuilding is to me. It's part of why I really loved Lord of the Rings when I finally read the books (and a notable part of what elevates the books above the movies for me, despite having loved the movies for decades). What caught me off guard when writing this is just how important I see mechanics as a worldbuilding tool. So many of my issues with things I've mentioned here are areas where worldbuilding and mechanics clash. My takeaway from this is that I need to figure out my mechanical worldbuilding pillars early on, as they'll be integral to supporting the rest of the game.

Another thing that writing this has made clear to me is that my love for worldbuilding has often led to me designing narvisaud-first, though other aspects of RPG Maker MV (the art assets provided to me) have had an impact on this as well. The end result is that I get narvisaud ideas that I then struggle to figure out how to implement mechanically. Additionally, this tends to result in a lot of mechanical minutiae and chaff; many of my "this is too complicated" issues derive from this. If I instead focused on mechanical needs first, then figured out narvisaud to explain those mechanics, I think I'd create much cleaner, less complicated designs. There is room for narvisaud-first design, but I'm doing too much of it—especially when it comes to equipment.

RPG Maker MV is good at certain things and bad at others (like flavorful item or spell descriptions, since there's so little space for them). Also, the engine is quite easy to modify thanks to plugins and the flexibility of JavaScript (which the engine is written in), but the editor is very rigid. As a result, I've often found myself fighting with the editor in any number of ways, from the way enemies work, to the name and meaning of stats (there's editor fields to rename them for the engine, so I really don't understand why that renaming doesn't apply in the editor itself...), among many other things. At this point, I've messed around with what I can do enough to have something of a feel for what I shouldn't do—at least, I hope this is the case! I think working in RPG Maker MV will go a lot smoother if I lean into the things it does well, such as a more linear story.

That said, one way I've gotten myself into trouble is trying to use everything RPG Maker MV has to offer, or following along on certain rails it provides (notably, things involving icons or tilesets). I can change up some of those elements where RPG Maker MV does make it easy to be flexible, and doing so is a good idea if that helps serve my greater mechanical purpose. At the same time, the editor isn't forcing me to use every little thing, so I shouldn't try to fit in things that don't meaningfully contribute to my design.

One final thought is that I need to spend more time playing games I haven't played before. Anything can be a source of inspiration, whether for core ideas or as a solution to a problem I run into. I've generally struggled to prioritize this high enough because "playing games" doesn't feel like "being productive," but no one said important research can't be fun! I really would be benefited by doing more of it.

Thank you for reading!

You can support Sientir in his creative endeavors by subscribing to his Patreon or sharing his work.