RPGMaker: Good Idea Generator

Years ago in my day job, we had a senior manager who kept coming to us with new things he wanted us to work on, clearly higher priority than all his previous requests.

“I am a good idea generator!”

“Well, you’re a powerful generator of ideas…”

Let’s see which one I am today.

Plugins and Other New Stuff

This last week I’ve been looking over plugins, including those that come with RPGMaker MV (the Kadokawa plugins), DLC from Steam (I haven’t actually found any yet, but I’m confident they exist — I mostly got DLC for expanded tile sets and media), and free offerings online.

Some of these have sparked ideas. I’ll note them here so I don’t lose them, but I don’t think I’d include all of them in a single game.

It’s possible that plugins exist already that address the ideas I have. I haven’t started a specific survey to see if this is so, but if I find things have already been done I’ll update below.

Monster Lore

The Kadokawa plugins include one called ‘EnemyBook’. It has a very simple interface containing a list of all the monsters in the game (that aren’t marked ‘not in enemy book’). Each is initially in the list as ‘??????’, with no information about the enemy.

After you encounter a monster, though, it shows up in your enemy book and you can see its stats. This can include up to two brief lines of description.

I’m thinking something more like Moria (roguelike from years ago), where there was ‘monster memory’ that accumulated as you played. Each time you encountered a particular creature type you could learn different pieces of information. I can imagine doing something similar, where instead of learning all the stats you might look at the minimum amount of damage needed to defeat a monster, and the maximum that did not. Me being me, I can imagine I’d randomize the number of hit points; you could end up seeing ‘has been defeated by 195; has withstood 210’.

It could also track special abilities (‘can breathe fire; highest known damage 80, lowest known damage 55’, ‘resistant to fire’), item, drops, regions or maps the creature has been observed. Tallies could be kept of met and defeated creatures.

The knowledge gained at any time could be based on observation (you learn the creature breathes fire because it breathed fire on you, you know they can be found in the Forest of Tir Banon because that’s where you met them, and so on). Other lore might be gained randomly, or based on the encounter tally.

Probably a later refinement, the lore might become more nuanced. “Can breathe fire” might become “sometimes breathes fire” or “does breathe fire”, depending how many times you see it. If there are variations between creatures of the same type, “some wield swords, some have poisoned claws”. The lore about the creature could be gated by tally as well.

The tallies could also be used to gate player abilities. If you encounter certain creatures many times, you could gain abilities specific to dealing with creatures of that type.

It occurs to me that monster abilities could be similarly gated. At the start of the game a creature might have only a certain set of abilities available, but as the game progresses new abilities come online. If you want, this could be explained as the creatures learning about you, too. If you often use fire attacks, the goblins might start taking steps to become resistant to fire, or to counter with cold attacks.

Implementation

I think implementation actually would depend on having kill tallies. They open up a lot of options, and make many of the above ideas easy to implement.

• I expect a plugin for kill tally exists already.
• Once a kill tally exists, adapting an enemy’s action selection to take it into account likely is not hard.
• Having player skills gated by kill tally similarly should not be hard, especially if there are other prerequisite mechanisms.
  • Considering how much I dislike these in Pathfinder, I might want to not look too hard at this.
• Details coming online is probably not too hard: if you see the creature breathe fire, you know they breathe fire. If you encounter them in the Forest of Tir Banon, you know they can be found there.
  • The more nuanced “can”/”do”/”often”/etc. actually becomes easy to build. Compare the number of times you’ve seen something to the number of times you’ve encountered the creature, and you can gauge the approximate frequency.
• Lore coming online based on kill tally is easy to build also. If you’ve run into goblins three times, you don’t know much. If you’ve run into goblins a thousand times you probably know everything there is about them. And likely have issues and should stop grinding weak monsters.

At least, this should all be easy if I can store the tallies with the monsters (i.e. object-oriented programming) rather than consume tons of general counters. If I have to manage it through the equivalent of global variables I’m not going to bother.

Data Extraction, Reporting, and Manipulation

The database is presented in the editor entirely on a single-item basis in a form. This is fairly convenient for editing, but there other views that can be useful. RPGMaker MV stores data as JSON files, which makes it very convenient to read, and with care edit, outside the editor.

The first is a list view of all entities of a type. All weapons presented in a list with the stats broken out, all armors presented in a list, and so on. This could be an extract into a spreadsheet, or just a table. If nothing else, having a page (or spreadsheet) listing all of your entities and images and events and whatnot would be a help do the developer.

A static view is simplest, but with a bit of effort an HTML page with embedded JavaScript could be extended into an editor that allows bulk manipulation. I imagine this could be developed into something even more capable (including lookups based on other data types to ensure referential integrity and the like) but I expect this is beyond my skill right now.

The second (or third, I suppose) is a catalogue-style view. For each entity type, present the formatted entries, such as you might find in your favorite tabletop RPG handbook. You might still have tables to summarize stats, but the real payoff is there being an entry for each weapon or skill or enemy.

This second view could be of greatest value in developing a user guide for players. The information could be as complete and detailed (or incomplete and vague) as you want. Perhaps ‘basic entities’ (weapons and armor you start with, monsters from the first zone or lowest level, and starting skills all present a fair amount of detail, but ‘higher level’ entities are presented with only a name and the first lore entry. “According to charred survivors, there are fire-breathing dragons in the Shimantu Mountains.”

Third actually could be an in-game option, an ArmorBook or WeaponBook or similar. This could obviously be comparable to the EnemyBook plugin, or its expanded version above.

I see the following entities (in order of presentation):

• Maps
• Events
• Switches
• Variables
• Resources
• Actors (PCs and potential PCs)
• Classes
• Skills
• Items
• Weapons
• Armors
• Enemies
• Troops
• States
• Animations
• Tilesets (catalogue version could include a picture, and each tile could even be detailed enough to show passage, damage floor, and other tags)
• Common Events
• System (game settings)
• Types
• Terms
• Character Generator elements (maybe)

I expect that many of these would really be of use only to a developer, and that’s okay: I think they could be very useful to a developer.

Implementation

On its face, implementation of the basic behavior is straightforward. HTML page containing JavaScript that reads the JSON data and presents for consumption. Making it an editor would be more effort, but not out of reach. Outside my skill right now, though.

To extract the data into an Excel or Word document I would likely use a different tool (Perl most likely, but possibly C#). This would not be as portable as an HTML-based extraction tool.

One caution about creating an editor, it appears RPGMaker MV reads the JSON files once, and saves them every time you save the project. You would want to be very careful about editing outside the RPGMaker editor.

Wandering Monster Tables

Each map has an ‘encounters’ table that identifies troops that can be randomly encountered on the map. I can see myself replacing this with a richer set of wandering monster tables, such as we had in the old days (tabletop RPGs, that is).

Each wandering monster table would probably look much like the ‘Encounters’ list in the map, identifying the troop, its weight (how likely it is to be chosen compared to others on the table), and the range (the entire map, or up to three regions present — which should be chosen from those on the map).

I’d want to allow NPCs to appear on the encounter tables. When triggered the encounter doesn’t necessarily have to be a fight.

Each wandering monster table could include references to other wandering monster tables. For instance, each map could have ‘neighbors’, like with older Zelda games. Just as the PCs can move from map to map, perhaps only 60% of the random encounters in a particular map are from ‘this table’, and 10% from each of the 4-neighbors of this map (i.e. the wandering monster tables from the maps north, east, south, or west of the current map). Similarly, a table for an outdoor map might refer to tables for other connected maps (the dungeons and even the towns), or the table in a town or dungeon could refer to the outdoor local outdoor map.

This lets us have (and reuse) random encounter sets with high variability without having the manually create them each individually.

I’d be tempted to incorporate the tallies as well. I can imagine at least some creatures having an upper limit to how many can be encountered.

Implementation

Potentially more difficult than some of the others. The data management doesn’t worry me, but I think this would need to integrate more closely with the map/movement internals. It might be pretty easy if I can simply hook ‘encounter happening now’ and replace the encounter selection logic.

First cut of the encounter selection logic wouldn’t be too complicated, but I can see having increasingly sophisticated elements. First would be some kind of filter for appropriateness, such as making sure you don’t encounter a kraken in the desert. Another might have to do with the tallies (go home, Goblinslayer. Your job is done.)

Improving System Documentation

This one is a tar pit.

The first part isn’t hard, just big: build a catalogue of plugins. As a start identify them by name and publisher, include links to download, to documentation if available (often the same link, if it exists), and often to YouTube videos (both from the publisher, and tutorials using it).

I’d want to expand on this to include explanations of why and how to use it, if such does not exist. It feels like many are quite simple but just not documented. For instance, it doesn’t take much to understand what to do with the Kadokawa plugins, but I cannot for the life of me find a reference document that describes what they are and what to do with them.

Second, the internals of the RPGMaker JavaScript files. This is of primary use to plugin developers. There is Kino’s API Reference, of course, but that looks primarily of value to someone who already understands and just needs details. This is valuable! But not so good for someone coming in cold. I’m talking about expanding on that to explain why and how to use items in the APIs.

Closing Comments

Those who know me, know that I rarely take small bites. I think the ideas above have merit, but expect they are going to be a lot of work.