Inner Circle Update for March 9 2017! (Patreon)

Hey guys!

Work’s been progressing mostly as planned this month, and despite some setbacks on my side of things I have positive things to report! 

Story Overhaul 

March started off with a dropkick to the face for me. On the night of the 1st I came down with the Type A Flu. This was actually the first time I’ve been legitimately sick since 2013, as I came to realize when I found that all my cold medicine had expired in 2014. However, after sleeping off a 104-degree fever for four days I was back at it. While being sick did put me behind, on the night of the 5th I was able to make a really significant step forward with the story. 

The game’s story is composed of two major storylines with a few arcs that connect the two in some crucial ways.  The second storyline has, up until now, received relatively little attention, and filling in the details for it has been one of the few remaining major story topics that require immediate attention. As mentioned above, a few days ago I was able to pop that cherry and have since banged out about 10 rough pages of new story content. As expected, I’ve identified quite a few significant changes I need to make to the rest of the story in order to merge the two successfully (which basically sums up the importance of knocking this out now rather than later), and so I’m currently in the process of massaging all of that into place as I continue to refine the new sections further.  It’s a ton of work though, as the actual story document is up over 50 pages now and is mostly still fluid enough that I’m having to move chunks around pretty often as things fall into place. Luckily, I’ve so far only had to make a few dialog changes to the V0.051 content 😃.   

Anyhow, one really interesting thing that’s come about as I’ve been working on the second storyline is that I’ve decided to attempt to make some of what were originally going to simply be story cutscenes into playable sections.  These areas will be using characters you haven’t met yet (in a similar way as to how the player’s party is changed during segments of some Final Fantasy games, especially 6 and 8), bringing the total up to 5 playable characters throughout the course of the game. Hopefully this all pans out, but so far so good!

AltairPL’s New Engine Status Report

APL here!  Before I start my progress report, I feel like I need to clarify few things since it's getting a bit confusing!

For most part, engine progress mentioned in last IC update was referring to interfacing SDL/GPU directly from the game ruby scripts. For the sake of clarity I'll refer to it as "RM_SDL" from now on. Then there was this line from the last update:

"Currently APL is investigating ways to simplify the interfacing between Ruby and C, which has been causing him a lot of uh, mental trauma." 

This line from the last update is referring to an entirely new approach which is covered in more details below. The confusing part is that the last monthly progress update mixes information about both approaches, and even though all of that information is still valid, I want to make a clear and definite distinction of what was and what is.

RM_SDL showed a lot of promise, but to make it work I had to, and would constantly have to, either make some changes to SDL/GPU library or create and maintain a proxy library of my own.  Another problem was that no matter what I did, RM was throwing wrenches into my gears.  Those and other problems (e.g. uncontrollable memory leaks and other "fun" stuff) were getting old pretty fast, and it was really getting on my nerves... so I made a kind of extreme decision to make a similar game engine of my own. This is the new approach vaguely mentioned near the end of my section of the last IC update and in the monthly progress update. 

Here’s an update on that!

The codename for new engine is URGE (Universal Ruby Game Engine). I had a few similar names in mind, but URGE kinda fits the H nature of the first (and hopefully not last) game based on it - MATM.

First thing I had to do was to learn a boatload about the C language, application/library development in general, compilation, linking, Ruby C API, and other boring and convoluted crap. I'll skip the gory details... suffice to say, this was the reason for aforementioned mental trauma.

I then had to actually embed the Ruby interpreter into the application. This will require a lot more work down the road, but the most crucial stuff like executing ruby scripts from files/memory, exception handling/reporting, etc. are already up and running.

With basic stuff working, I moved to the next stage, which is the current work in progress: actually making URGE compatible with RPG Maker and in turn be able to use all the work we did for MATM from the start.

This image is an excerpt from the RPG Maker help file. All of the stuff visible here has to be implemented (with few exceptions) to make both engines compatible.

* RGSS Built-in Functions - contains 6 methods/functions available from any place in the script.

• Two functions for loading/saving data from/to files or game archive (.rgss3a file). Both functions are working, except the game archive part which will be coded much later (custom archive structure, with multiple files, possible compression, etc.).
• Two functions for outputting information to dialog windows. Dialog windows are already working, since I'm using them for reporting errors, but for now we have no need to output other information in that manner, so those functions were left for later.
• Two functions for script flow handling. These are not used in MATM and probably never will be.

* RGSS Built-in Classes

• Rect, Color, Tone, and Table classes are loaded/saved along with various game data. They required a bit of reverse-engineering and analyzing saved data structures, but all four are up and running and are almost 100% compliant with RPG Maker. The “almost” part being a bug from RPG Maker (which allowed for setting incorrect values to some parameters) that was fixed.
• RGSSError and RGSSReset are exception classes used under the RPG Maker hood only, so they can be safely omitted... not that it's hard or something, just obsolete.
• Window - I'm not sure how to deal with this one, TBH.  Even before joining MATM dev team, I made my own implementation of in-game windows, which rivals built-in Window class in both speed and resource usage, but is much more versatile.  The problem is it's not 100% compatible and some vanilla windows that are still using built-in Window class.  Considering that sooner or later all in-game windows will use my implementation, I will probably skip this one and just switch vanilla windows out to use my implementation, which will be hard in some cases, but it's still better than coding class that won't be used for long.
• The Tilemap class is extremely complicated, and we're not using it excessively, so I would like to avoid coding my implementation... a stub to prevent exceptions will still be needed though.  Dunno, maybe I'll code it as an exercise, for a more definite comparison of RM and URGE, or something else.  It is very useful for test maps... decisions, decisions.
• The remaining classes represent graphical objects and will be coded to work directly with SDL/GPU.  It would seem that Ruby scripts made for RM_SDL were working just fine, so at least I know what I want to achieve. It's just a matter of porting parts of Ruby code to C.

* RGSS Built-in Modules

• Audio, Graphics, and Input modules will be fully implemented down the line, but stubs for them, their methods, and their parameters are already prepared. It’s only a matter of adding functionality to them.
• Additional Input Note: The good news is that my earlier overhaul of the Input module in preparation for input customization will pay off here, since it made keyboard handling independent from RPG Maker. This will make the transition much easier.
• The RPG module is a special case, since it's actually coded in Ruby but hidden from the prying eyes of inexperienced devs. It contains definitions of all game database elements (Actors, Maps, Enemies, Items, etc.), and so I extracted it to a file a long time ago and have been using it as a reference ever since. That said, I already tested executing this script and loading game data containing database elements and I had no problems with it.

There’s still a long and curvy road ahead, but it's a very good looking start if I can say so myself!

TK’s Artwork Progress 

As mentioned in the last update, TK has shifted focus to working on environment assets for future areas of the game. 

Toward the end of last month and the beginning of this month, he had actually taken a break from this to attempt an experiment that would have helped me a lot with armor damage artwork. The goal was to come up with a system that would enable us to create Malise’s armor damage artwork completely in 3D, meaning much less post work in terms of painting. Unfortunately, it didn’t pan out, and we came to the conclusion we’d need to create a much more in depth system to avoid deformation/stretching when her hips and thighs are animated. Since this isn’t a priority at the moment I’ve had him jump back onto environment work.

He’s currently focused on a sewer area that will make an appearance a few updates out. This area was originally intended to be much earlier in the game, so there was some design work done in terms of figuring out enemies and what not. Here’s an excerpt from the development notes document regarding the design of this area.  

Currently, TK is figuring out a solution for creating realistic water graphics that we can implement for the new map upgrades we’ve been using since V0.05. The possibility from the new engine of vastly improved load times and ability to use GPU memory opens some doors in this area, so hopefully I’ll have some things to show you next week!