May, much like April and March, ended up being a big month for stability. A number of small features (some of them which will be largely unnoticed, unless you were profiling/tracking it) have been making their way into the engine. Let’s dive in.
The battle system got some more, much-needed love. We released the 2.5D sample this month, as well as numerous updates for resources, courtesy of our own Jason Martin (noob). Camera panning/transition for on current map battles is finally in and working nicely. Please note that the camera pans from the side because of how it is configured — a more natural approach would (and will be for most users) to pan from the party’s current position.
Map Configuration (in the database) now boasts a Battle Transition, which can be set to whatever you like.
In addition, I finally implemented a gradient wipe transition effect. The long and short of it is that a gradient wipe moves from either dark to light or light to dark, and gradually adds opacity to it. This is used frequently in a lot of games, like Octopath Traveler, where the screen peels away a little piece at a time and vice versa. The optimal method for this would be to implement it with a shader, but since the goal is to remove and allow for transitions to be a bit more portable, this is 100% software driven. It still has some hardware support, but it isn’t optimal. The end result is that it’s not quite a true gradient wipe (since it’s an opacity filter, rather than blending two surfaces together), but it’s very, very close.
Several new commands were added. An entire grouping of Picture commands are now available, wherein you can display images on the screen independent of user interfaces. In previous makers, you had to use pictures to render “custom” user interfaces. Obviously, your better workflow for this would be a user interface (an Overlay, most likely), but there are still some uses. This will be extremely useful for things like mini-games, wherein you may need to rotate an image to align things, show “god rays” on a 2D engine (though Overlays would probably be a bit more useful here), occlude an area around the user by making a picture that follows the position of a character to darken the rest of the screen, and so forth. There are a ton of possibilities and it has been requested frequently. In addition, Pictures have no upper limit — much like everything in RPG Architect. You’re welcome to make as many as you like (and drive them with variables), but if you kill the performance of the engine from being overzealous, that’s on you.
There’s also a new Get Tile Information command that will assist in finding information about a tile, given a set of variables and whether you want to look up, down, or to the closest layer. This will let you find things like collision, tile tags, region, height, and so forth.
Another “missed” detail (which hopefully closes out a majority of the battle system) is that external map battles flat-out did not work. That was literally discovered and fixed yesterday. Up until now, the focus had been to try to make battles that occur on a user interface (much like the SNES era Final Fantasy, Dragon Warrior, etc) games. We had worked thru adding “Current Map” battles this iteration (the 2.5D sample has one), such as Chrono Trigger, Lost Sphear, etc. “External Map” battles are now working and emulate the idea of something like most PS2 and PS3 era Final Fantasies, wherein a battle takes place in a 3D scene, which can be designed on a map (similar to a User Interface-based battle, but the 3D elements and camera prevent it from being a user interface).
Further performance enhancements were added, which are largely unseen. If you’re familiar with .NET, garbage collections occur much less frequently and have much less memory being freed (due to it being managed manually/better). To everyone else, it results in the engine running roughly about 5% faster. It’s not a lot to write home about, but it will eventually help the engine scale to be a bit stronger/better. That 5% may allow for more visual items to be added. There are still more optimizations to be leveraged and written, so expect it to climb. My anticipation is that it will be roughly a 10% performance increase and micro-pauses (usually imperceptible to the player, where one frame may take 30ms to render instead of 10-15ms) will hopefully almost all be gone.
The caterpillar system did not make it, nor did annotations, nor did projections. I’ve been a little zealous in my predictions for these so far, especially with life and work ramping up. I would commit that one of these systems being “finished” at the end of June. There will likely be more than just one of those, as well.
Next month, I’m going to commit to getting RPG Architect on the next version of AvaloniaUI, version 11 (the framework I use to build the editor). There are a number of “adjustments” that I made locally that are no longer needed with version 11. This will be a large endeavor, but will open up more settings for things like map parameters, camera control in battles, and so forth. I’m actually working on this now, so there will not be updates for a little while.
On an extra note, there were three entries in the RPG Architect Game Jam, which will be covered in another post later in June. The goal was to show off something RPG Architect could do that other makers couldn’t, and I think we saw a very brief idea of what that looks like. In the future, I’d like to open up a much longer game jam, so that some of these can be explored better.
That’s it for May!
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!
