Inner Circle Update for March 29 2018! (Patreon)

Hey guys!

So, we’re a few days away from the monthly update already, but I wanted to at least give you the drop on what we’ve been working on aside from the battle test, as well as a little preview of the updated Battle Test 3 (which I’m calling Battle Test 3.5).  

Battle Test 3.5 Progress

Your feedback was really valuable for Battle Test 3! Not only did you find a few bugs but we received some good feedback on the graphics also. Here’s a brief rundown:

• The chromatic aberration effect (the retro VHS look as AltairPL calls it) wasn’t very popular for battle since it made the portraits less clear. I’ll probably look into it again once we’re in full HD and more of the game’s art elements support the retro cinematic theme I’m tinkering with. 
• The wet skin looked more shimmery than wet, so I’ve already improved that. 
• There were some comments about the portraits being too dark, but I think people are getting tunnel vision from looking at a single (dark, night-time) scene. It's probably not the best scene to be using for this but doing another right now would just cost more time. 

I had planned to release the updated BT3 sometime today. I have however made what I think is a significant enough improvement to the light textures that it merits re-rendering all the portraits in preparation for the monthly update as opposed to just the ones with the wetness textures. 

A problem with Battle Test 3’s lights was that the side and front lights for the character lighting rig were using the same textures as the rim lights. This resulted in big, broad lighting that killed too many of the details on the characters. Calming down the highlights was actually a goal, but I overdid it I think. I think what I’ve got so far for Battle Test 3.5 is an improvement, combining the strong points from BT2 and 3. I'll try and post some more of the new portraits as I complete them :D.

The reason this is important is that even though we can change the color and intensity of the lights in post with Uber’s new system, we can’t change the texture of the lights without re-rendering. So, getting this correct now is pretty important.

Anyways, here are the planned changes for Battle Test 3.5:

• The ATB "During Action" speed setting was incorrectly being used for the remainder of the battle after the first action was performed. It is now only used while an action is in progress.
• In very rare circumstances the game could crash listing invalid file permissions as a reason.
• Improved wet skin material.
• Removal of chromatic aberration (the “retro” effect). 
• Re-lighting portraits with better(?) light textures. Let me know what you think of the above previews!
• Identified a couple minor issues with the holsters (clipping) and Malise’s suit zipper tabs (floating in space). Obviously, this is really minor; we fixed some but the real fixes won’t appear until later releases.

Procedural Automation Network

Since BT3 was first released a few days back I’ve been working on a procedural automation network that will vastly cut down the time I need to prep and process portraits (new ones or changes to old ones). Changing to the new art style means some of my automation stuff isn’t compatible with the new workflow, but I never had automation for most of this stuff to begin with. I also didn’t have to deal with quite the volume of images as we’ll be getting into shortly, so it’s a necessary step. 

I have the network functioning and I’ll be using it for Battle Test 3.5. I also ended up automating a lot more than I was thinking I could. I still have to connect Uber’s post-process light mixing system (which I’ll be testing for BT4 probably), but currently it handles all other post processing, positioning and scaling of portraits, and auto-cropping of portraits -- for all the game's portraits -- in a single click :D. It also allows me to plug the processes happening to one portrait into another instantly – something ideal for additional variations of portraits. And it's modular/scalable to boot! I’ll be adding enemy light mixing to it as well, meaning it will end up being a one-stop script for all things battle and portrait artwork related. I had to keep a bunch of notes and a mess of Photoshop PSDs for this previously, so I’m pretty happy with it. It also outputs in a way that I just have to run a batch script in order to rename files so they can be used by the game.  

Ubercharge’s Map Progress

Ubercharge has made some stellar progress with the latest map. Not only do his procedural shaders look great, he’s also made some big steps forward with working in 3D volumetric fog. This is made possible by the ability to separate the fog out in post in order to use it to layer in our 2D assets. We already have a plan for how to make our sprite blending system compatible with it, but I still have to clear it with APL :D.  

Splicer Overhaul Progress

Uber has enlisted the help of a new sculptor who is really good with Marvelous Designer—currently the best software around for making clothes. Up till now this is a skill we’ve been severely lacking. Her help gives us the ability to custom model clothing from scratch instead of relying on assets, so we’ve therefore been working on designing new clothes for the Splicer gang.

I have in mind a couple different major variations for v0.06, and in addition to that we want to be able to mix and match their clothing for story scenes so that they all don’t look like clones. The one you see above is a concept I pieced together from a combination of licensed assets and a concept jacket by the sculptor.  So far she’s created a bunch of concept designs, but we’re beginning to narrow it down.  This lower body get-up is the first work-in-progress design that she’s moving forward with.

Alas, worry not, the old gas mask version from the early versions of the game will be around, and he will have a couple design changes :D (thanks Ubercharge for the concept drawing). Instead of a mechanical probe he’ll now have a tentacle that extends from his mouth… hole… thing… which is revealed when he removes his respirator. 

AltairPL’s Coding Progress Report

This was a really long and hard two weeks for me. The majority of things I did required a lot of testing, and TBH, I can't look at the battles anymore or I'll go crazy. Other than that, I think I've managed to make some pretty good progress.

Most, if not all, of known and unknown battle engine issues from Battle Test 1 and 2 and are now fixed. The only one that keeps eluding me, especially since I never knew sure-fire way to trigger it, is the one when characters sometimes use non-idle pose on battle results screen. Haven't seen it in a long while though, so with a bit of luck, fix for something else managed to fix this one as well.

This one was waiting for a long time, and I've finally started dealing with it. As I've already said on numerous occasions, till now, enemy holds were the least stable aspect of battles. The whole flow and data structures of holds were revised and recoded, and it's now much more clearer and cleaner. Part of the structure changes were made with double-teaming in mind, which is slowly becoming reality. There's still a lot of work to do to make double-teaming fully functional though. One of the most convoluted things will be related to adding new action triggers, states, and few other database things. I also didn't take into consideration a few more or less minor things while designing double-teaming, so I will need to deal with it as well. Last, but not least is the actual display of all character holders in the battle UI, but this will be a part of upcoming battle sprites overhaul.

The battle sprite class is a mess and requires attention sooner rather than later. Not only is it based on the vanilla RPG Maker class, but there's a lot of old test stuff, and even more crazy stuff... pretty much chaos all over the place. This will probably take me a while, so I didn't want to start it right before the Battle Test 3, but I was able to make some initial work and preparations. With some vanilla functionality moved to dedicated classes, like action animation and results, I was able to get rid of some obsolete vanilla stuff already. With this out of the way I could change the base class to my custom sprite class, which has some nifty functionality we could surely use for battle sprites, like automated positioning, automated sprite-sheet animation, etc. A lot more to do, but it will have to wait for after the Battle Test 3.5.

Since I still had time before Battle Test 3 and there was nothing left required of me for it, I decided to make some organizational changes. The first one was with the game proper in mind. Till now, all files saved by the game were stored in different folders, which was a bit of a mess. Now all such files, like saved games, options ini, and logs, are all stored in "User" subdirectory. Not only is it more neat that way, but will also make bug reporting easier - instead of picking files to send from a few different places, just pack up and send us the "User" folder and we'll have all we need to figure out what the problem is. Remaining changes are for us (dev team) only and are mostly meant to minimize amount of data sent between us. The exception from this is optimization of release build creation. I had a great idea of how it could be improved, but that idea kinda backfired. Thankfully I was able to make other improvements that minimize the amount of disk writes and dramatically decrease release build creation time, so I'm still happy with the results. And as a bonus, I made some notes about trying to move parts of this code to URGE C code, which should result in huge speed boost, but I don't want to that just yet, since I need to think about some related things first.

I was hoping for a day or two off from the work after Battle Test 3 release, but unfortunately some bugs were found that required my attention. Ain't no rest for the wicked ;). First one was causing ATB speed to be stuck at action speed after first action was performed and pretty easy to fix. Second was causing game crashes in very rare situations... quick and dirty fix wasn't enough, so I had to recode small part of the related code.

While testing the fix for the second bug, I accidentally launched the game in URGE and was greeted with a nasty error. Since I had nothing more important to do, I dug a little deeper and fixed this problem as well.

I honestly don't know what I will tackle now that the Battle Test 3 is released and all patched up. I should probably make this battle sprites overhaul and make double-teaming reality, but I really need a break from the battle stuff, so I'll probably try to find something else to work with first.

Remodeling Ven’s Armor

Unfortunately, Ven’s armor has the same issue that required us to remodel Neon’s armor – and that is that it uses displacement mapping for all of its geometry details.  TK has therefore begun the remodeling process for Ven’s armor, starting with her leg armor.  He’s able to use the same process he did for Neon’s, which involves extracting the displacement details to geometry and then modeling a low-resolution version around it. I was hoping to get some material tests done on it to show off, but they’ll need to wait for the monthly update.