FeniXEngine - Development Log 6

Rollup plugin, a new branch, and a fresh beggining.

I have been so busy in the last month working on FeniXTools and setting up the base FeniXEngine project. A lot is changing while I work and I need to adapt and make tweaks as I progress. The good news is everything seems to just fall into place effortlessly and that does not happen often.


We all know about FeniXTools by now and if you don’t, have a look at the introduction or beta release page. Basically, FeniXTools gives plugin developers a set of common utility methods that help with plugin development. At the moment it’s in beta but it’s pretty stable so far and it’s only in beta because I have plenty more ideas to include before calling it an official release.

Putting it on hold

FeniXTools has made great progress over the last month and the documentation was the most important step. FeniXTools was never supposed to be where my focus was. My main focus always has been resurrecting all LTN Games plugin to be open source and get others involved in the project. My focus has changed a lot during development and FeniXTools will be on hold while I develop FeniXCore and set up the plugin CLI and development environment.

Easy Plugin Development

How about a drag and drop plugin building tool sound like to you? While drag and drop is not my main focus, making plugin easier to develop is my new focus. Making things easier for those new to plugin development can be a tough task and it’s even tougher when you want to still keep things advanced for those pro plugin developers.

So a lot of planning is involved to ensure things are as easy as can be for those new to plugin development but, if an advanced developer wants to take control, then they have the option to do so without breaking everything.

The approach

My approach to making plugin development easier is to make a few small tools which all work together effortlessly and all compliment each other in some way. At the same time, I don’t want any of them to be dependant on one another but totally self-reliant on themselves. It’s not a tough job but it takes a lot of planning and tweaking throughout development. It took me about 2 days just to set up a plugin development environment and build process.

The Environment

You’ve probably heard me talk about the workflow and environment in previous dev logs. Since I’ll be using pure ES6 and the module workflow, those new to plugin development may be turned off from the building required to get a plugin as the final output.

For example, writing in ES6 modules requires you to use a bundler library like Webpack or Rollup. For a new plugin developer, they’re not going to want to learn how to install Rollup, configure it and then include it in the build process so the final output is a compatible RPG Maker MV plugin. This is where FeniXEngine comes in, I am automating all the build tasks so that newbies aren’t frightened of something as majestic as a CLI tool.

Remember, for the more advanced developers they will have the option of taking control over all of this automation if they so choose too.

Rollup plugin to internalize exports

During my work on automating the plugin building process, I noticed a small nuance which would have drove me to my grave if I let it slip by. When developing plugins with ES6 modules there will be times you need to export a variable or class so that other files or modules can import it and use it.

Unfortunately, rollup has no way to explicitly tell it that a variable you’re exporting is only to be used within the plugin or library being developed and should not be exposed. So I developed a small plugin that allows just that, you can find rollup-plugin-internal-exports if you’re interested.

Luckily, an internal export plugin for rollup will not be required by most users who make plugins using FeniXEngine. Everything will be exposed via a plugin API so while It does effect plugin developers who want to make a Core plugin or library that will be consumed by other plugins it won’t affect users who are making a normal plugin.


FeniXCore will provide an easy to use plugin API to easily access important plugin information and methods. The core will also help with common tasks that occur often in normal plugins to more advanced plugins. Saving data, calling and handling aliases, creating plugin commands, converting parameters, these are all very common in every plugin.

All of these easy to use methods will be accessible in the plugin API and you can retrieve this API by registering your plugin.

Register the plugin

// Let's register a new plugin
  name: 'TimeEngine',
  author: 'FeniX Contributers',
  version: '1.0.0',
  required: ['Required Plugin']
}).catch(err => console.log(err))

Retrieve the plugin API

// We export for use within our plugin
export const _Plugin = FeniX.require('TimeEngine') // => returns the Plugin API

The FeniX Plugin API

The plugin API will be responsible for basic tasks such as adding and calling an alias. As well as fetching the plugins parameters and saving data. While it won’t be necessary to do any of this, it will be best practice with FeniX plugins and will ensure things are kept easy for new plugin developers.

How to use the Plugin API

All subject to heavily change during development

Adding an alias:

_Plugin.addAlias('DataManager.onLoad', DataManager.onLoad)
_Plugin.addAlias('DataManager.setupNewGame', DataManager.setupNewGame)

Calling an alias:

_Plugin.callAlias('DataManager.onLoad', this, object)
_Plugin.callAlias('DataManager.setupNewGame', this)

Calling and adding an alias through the plugin API will ensure that there a minimum conflicts and alert you when a function is aliased more than once.

Retrieving the plugins parameters:

Contains all plugin parameters ready for use with no conversions required

_Plugin.parameters // => {param: 255, param2: [], param3: true}

Adding to save data, which is saved to file when the user saves the game:**

const myData = {}
_Plugin.addSaveData('myData', myData) // => Saves the data next time user saves progress

If you’re creating an extension for another plugin then you can export important methods and variables and require them in another plugin later on.

Early in development

// TimeEngine.js
const myFunction = () => {}
const myClass = new MyClass()
const myString = 'String'
// export for use in other plugins
_Plugin.export({myFunction, myClass, myString})

Then to retrieve and use the functionality of your plugin to create an addon

Early in development

// ExtraTimeHuds.js
const TimeEngine = _Plugin.import('TimeEngine') // =>
//  {
//  myFunction: () => {}
//  myString: 'String'
//  etc....
//  }

// Or

const myClass = _Plugin.import('TimeEngine', 'myClass')

Next Up TDD For RPG Maker MV

Before I make this post an 8-minute read that may bore the heck out you. I’m going to stop here and share my new progress after the weekend.

I’ll be focusing on test-driven development for RPG Maker MV, meaning more time testing and writing stable code without having to load an entire game to do it.

See you for now!

Published by in development and general and tagged development, rollup and tools using 1180 words.