Inner Circle Update for January 10 2019!

Hey guys!

Now that the holiday stuff and Patreon page update is out of the way, I’m back to making steady progress on artwork. We have some previews of the first Splicer Thug H artwork (horray), as well as progress on the boss poses, Splicer animation, and the underpass map. I’ve been trying to trim down our posts and not go too deep into the tech stuff, but we’ve had a lot of requests for an update on the MATM engine, so I bugged APL and he put together a post that summarizes the work he’s been doing :D.

Boss Artwork

Even though this guy is way more detailed than our first enemy, he’s coming along a lot more quickly due to us having a better grasp on how to layer elements for Spine. Limbo still has to go through and refine some lines and correct some perspective issues before we do shading, but overall, he’s looking great.  Here's the full size version of the above image.

Boss Artwork Progress Full Size 

H Artwork Preview

We're closing in on halfway finished with the frames we need for the first Onyx vs Splicer Thug H scene.  Apologies for their unfinished state, but hopefully you enjoy the preview :D.

• Onyx vs Splicer 1-1 WIP 
• Onyx vs Splicer 1-4 WIP 

Stage 1-2 Map Progress

Ubercharge made a lot of progress on map stuff this week. He’s discovered some better ways to manipulate the geometry into our game perspective that have sped up the process, as seen in the foreground for this map. He also found the magic bullet for helping us pull off maps with realistic perspective by way of linking multiple cameras so their FOVs line up virtually seamlessly. This will enable us to render big scenes like the boss map in chunks as opposed to needing a render farm or something ridiculous.

Here are a couple screens I captured from the new map, as well as the full map preview (25 MB, so slow internet beware).

• Underpass Map Screen 1 
• Underpass Map Screen 2 
• Underpass Map WIP Full 

Animation Progress

So, just to remind everyone, what you saw in the latest Pure Onyx release isn’t an example of the final animations.  The actual animations will be more dynamic, readable, and detailed. This is illustrated in the above comparison!  Kitsune had to go out of town early this month, but she was able knock out the punch animations for the Splicer Thug. I made a little comparison showing one from the last release on top, which is entirely generated by Spine’s automated animation blending. The one on the bottom is the completed animation.  

As far as H stuff goes, we’ll be working on animating it as soon as we get Onyx’s moveset pose artwork consistent and broken down and rigged in Spine (we did the Splicer first since he’s a simpler character and easier to learn with).  This will be a major task this month, so we’ll definitely still be working on it by the next IC update.

APL’s URGE Engine Update!

Hey guys, long time no see ^^. After few months of no progress updates from me, Ero finally decided to post update of my work on MATM and URGE.  Problem is that going into details with every single thing I did would take pages and pages of text and nobody would want to read it... not to mention writing it ;). On the other hand, chosen bullet-point approach doesn't give enough info and I think it diminishes the work I've done since you've last heard from me, especially since December is always extremely busy month for me, which results in little time for work like mine.

Not counting some bug fixing, and some other more or less minor stuff, most of the work on URGE was spent on learning and coding shaders and stuff related to them. Since it was something I was doing as a break from Ruby coding, I was using separate application, and even though everything seems to be working, I still need to actually implement all the new stuff in URGE. Here's the break-down:

• Designed and prototyped custom shader structure and a cost-efficient functions to switching them in URGE;
• Coded Gaussian blur shader - compatibility with RM and probably some custom stuff as well
• Coded outline shader - was meant for text, but can be probably used for many other things, like the new UI Ero started showing some time ago
• Coded universal text shader - custom effects (simple shadow or outline), color for text and effect, and matrix shearing for italicization, which is broken in underlying library;
• Experimented a bit more with text shader - it will make things more complicated, but it is possible to use gradients and even more crazy ways to color the text and the outline (separately of course);
• Coded wave shader, which was a sprite functionality from RM I wasn't able to figure out last time I tried - I did it mostly to gain experience than to improve compatibility with RM, but I think it will be useful down the road;
• Coded shader for map-based transitions (map as in image containing opacity values);
• Thought about and considered coding some kind of shader interface for Ruby side of the engine, but initial research revealed it would take too much time, and since we have access to engine's C source, we can get by without it.

Rest of the time since my last update I've spent on Ruby code closer to the game. I was supposed to stick to bullet points, but I think the biggest time sink deserves some explanations. Let's get other Ruby stuff out of the way though:

• Overhauled game options structures and handling - adding new or changing old options is now a breeze, which will be nice when I start adding them;
• Overhauled options screen - thanks to the changes above it's pretty much automatic now - just add an option symbol to the respective list, and screen code will do the rest;
• Coded interface between C and Ruby for passing controls mappings;
• Coded parsing controls mappings to and from string for ini saving and loading;
• Considered coding controls mappings configuration screen, but in the end I decided to leave it for later, since in-game windows have an overhaul planned sooner or later and in case of this screen it would be a major pain to (re)do - emergency mappings changes may be done directly in ini now, so it should lessen the blow;

Aforementioned biggest time sink is something I should probably do a long time ago... it would certainly save me some grief now. As some of you may know, RPG Maker uses exactly the same database for editor and the game itself, which results in a lot of issues. Most important one is that most of the game database data is in a form better suited for the editor, and not the game as it should, so there's a lot of unnecessary processing during the game itself. I've implemented pre-processing of such data a long time ago, which pretty much removes all the editor-only stuff and optimizes the rest, so that the data used by the game is as ready to use as possible, which in some places made a really huge performance difference. I made one mistake though that now comes back to haunt me - instead of making my own classes for use in-game, I've been adding, removing, and changing stuff inside vanilla database classes and objects. Another issue with this is that some things are all over the place, which makes me and my IDE confused. Since we need to yank original classes out for URGE anyway, I've started the conversion of built-in database structures to the custom classes which will be used only by the game. Everything will be in one place, variables and values purpose will be much cleaner and clearer, and things will be optimized as I process them.

All in all, 41 out of 45 database classes were processed - either converted with optional notes about their future, or replaced with something more suited for the task. Remaining 4 classes are related to items and skills, since they are extremely convoluted and some parts depend on other stuff I still need to figure out, so I don't want to process them twice. Listing all of the changes would be too long and pointless, so I will just mention three a bit similar things that made a lot of difference in code's speed and maintainability.

First one was something I wanted to do for a long time and was always annoying me in the RPG Maker Editor. Hard to explain it to someone who hasn't had any contact with RPG Maker editor, but in most of the places in the editor, where something has to be conditioned based on something in the game, those conditional options are very limited and I had to make some nasty hacks to make things work how we wanted them to. My idea was to implement something I call unified conditionals, which in a nutshell is an expandable set of conditionals that can be used to replace and/or extend editor's limited set for a given purpose. Beauty of it is that adding new conditionals is very easy, so it will save us a lot of problems later.

Remaining two were done in a similar way and are both related to how various command lists (map/battle event or forced move progression) are handled. All such lists are completely converted to something completely different than original, and all the necessary processing is performed during development and not in the game itself. And again, adding new or modifying existing commands is now pretty easy, and I'm sure it will be used a lot.

My next and current task was kinda triggered by the move route conversion mentioned above. Long story short, characters' and objects' positions on map are done in a really weird way, and my previous meddling with it only slightly alleviated that problem... and added some new problems as well. After thinking about it, I decided to do something that was long time coming, and it's as big, if not bigger, as battle engine overhaul - map overhaul. Thankfully, a lot of stuff I did previously will make some things a lot easier, but there's still a ton of stuff to do - positions, movement, collision, activation, camera, and many, many more. I'm still compiling design document for this overhaul, and trying to figure out some stuff that eludes me, so I don't want to go into details. Hopefully I will have some good news next time Ero decides to post my update ;).

Have a Happy New Year guys, APL out.