I apologize for this being so late — life has a way of catching up with you and I was too busy to get this out on time, though I did make a note of things that I had updated to post here.

January was a time to focus on bugs, but I still added in a few features. I didn’t quite get time to make a video either, so I had to ask Bert to help me out.

There were a ton of bugs fixed — I think somewhere around the neighborhood of ~60-70 — but these were only the ones that I publicly announced. There were roughly 100 bugs in total fixed that weren’t disclosed that I found in my testing and work. But who cares about bugs? Where are the meat and potatoes — that’s what you really want!

Two big adds in January — Functions and Tags. Let’s dig into those.

Tags are primarily going to be used in User Interfaces, but will likely eventually extend to other things (I probably need to add it to the Save Value command and respective Data Sources) beyond what is normally entered in the editor. For example, say you want a “Title” for your Hero, Galahad. You want to display “Sir Galahad” in a user interface, but you don’t want to put it in the actual name. With Tags, you can now create a tag and refer to it in a User Interface, e.g. Tags[title].

This will allow for a lot more opportunities to do custom status pages, wherein you might want to write Sir Galahad’s origin story, display his favorite color, birthday, and what kinds of underwear he likes to wear.

This update is important, because it allows for you to also add the same to Save States — so you have more flexibility in storing things in a save — like the “Chapter” you might be on, or something else that might be a little more freeform. Remember, RPG Architect is about removing limits — and this is my way to help set you free in that regard.

The next big update are Functions, and oh, have they been requested for a long while. Functions are a new entry underneath Global Scripts in the database, and they allow you to write reusable logic, pass data in, and pass data out. If you’re a programmer, you probably already understand what they are and how useful they will be — but I’m going to try to explain for everyone to use.

Suppose you are building an action battle system, and you want an involved/calculation system to figure out damage. You could create a global script, assign global variables to certain stats of the hero and the enemy being hit, then call a global script to calculate damage, and use that in your handler for the enemy/entity. However, what if your attack hits more than one enemy? You can’t use global variables to store two enemy/entities stats AND the hero’s — one might get overwritten, etc. This is assuming that you didn’t write the “calculation” into every script page for the enemy, as well, which would be a real nightmare to update if you ever wanted to change something.

The solution? Functions. Functions allow you to specify input/output parameters. Functions have “local” variables and switches to them, wherein the first 100 are reserved for “input” and the second 100 (100-199) are reserved for “output.” You can add more local variables, if you like, but you are limited to 100 input and 100 to output at a time. Anything at 200 or above can be used as you would a “traditional” local variable.

Let’s revisit the sample above. Suppose you want to calculate damage. You want to pass in the attacker’s “attack” statistic and the defender’s “defense” statistic. You’d define those as two input variables (and name them — whatever you name this is what shows up). So, if it was defined (I’ll show it in a minute), you can call it via System \ Call Function:

You can place values (if you want to hardcode an Attacker’s Attack) or use variables that were captured, prior. Notice that Outputs do not allow you to place a “Value” in them, because the result is expected to be returned.

When you pass data in, they immediately get pushed into the Function’s own local variables — so when it is called, you are guaranteed to get the exact results you expect, without overwriting the source variables/switches (except for what is specified as an Output).

Functions are also not constrained by time — for better or worse. All scripts, generally, are capped at an execution time specified under System \ General \ Maximum Script Execution Time per Frame (of which, I believe the default is 500 microseconds). If you have a really complicated function that spends a lot of time, it could potentially bog down your game. The engine is pretty fast, so I think it’d be unlikely. That said, I’ve been proven wrong many times before — you guys get creative!

One other thing that I didn’t mention — RPG Architect got a big update that changed the data storage layer (sorry for breaking some of your projects, but I think they all got patched into working at this point) that makes us even more lightweight/performant, but would have been an obstacle for deployment to consoles and mobile. We’re not ready for either of those just yet (but hopefully one day — and I’ll make the commitment to the first one to want to “ship” a completed game, to assist in making sure we get you to your platform), but it’s good for the prior reasons of being “faster” and smaller in file size. Most of the projects I’ve “upgraded” are about 60-70% of their prior size, so a savings of roughly 30-40% disk space. Not shabby!

I also shadow-dropped the 2D RPG Sample in its (mostly) completed state. I think the only outstanding issue on it is the save system. If something is broken, please let us know.

A quick sneak peek as to what else is being worked on…

I’m always trying to keep our content creators busy. Jason is always working on spriting, and Bert is always working on videos/tutorials or music for y’all. Mondune, however, is working on our first 2D Template. This template will have a game’s worth of content already defined, much like the Maker series has done. We have a battle system already setup in it with some skills and items. All you would need to do is customize it to your liking. This will be the first of many — and I expect that once the community starts to see it, they’ll be making their own templates and distributing them as they see fit.

My goals for February are more bug-fixes, per usual, but also to build in Classes/Jobs, as well as start creating a visual preview of Action Sequences.

That’s it for January!

As always:

Thank you so much for your support so far. I’m looking forward to building this community further and giving you the engine you may not have known you always wanted!