November Progress Update! (Patreon)

Thanks for being patient! Between a late monthly update last month and the whole Patreon debacle we needed a bit of extra time to finish up what we wanted to show off. I therefore decided to forgo a video for this update to save some time, but believe me when I say we’ve gotten a lot done!

Malise Overhaul!

Obviously, this is the big deal for this update. We’ve completed the base overhaul of Malise for the new art style! Check out the finished images below.

Full Resolution Close-Up

Finished Front and Back Body 

I say “base overhaul” because there’s still a laundry list of work to be done on her. First though, let me explain the details for those that didn’t see the Inner Circle post a couple weeks back where we showed off an early version of her. 

Unlike Neon, Malise has been completely recreated using the Genesis 3 body system.  I started by figuring out a technique for transferring her old face to the new geometry, and then started reworking it from there.  Her body's shape has been completely revamped, and she has all new textures.  The most obvious change besides the suit is probably the hair.  It's a new model that I carefully edited to get the vibe of the old one, but with some class.  And yeah, we've changed the hair color some since the old one simply looked really strange in this new style.

Now for the suit!  This is an entirely new suit made from a customized Genesis 3 asset that we've put a lot of work into to resemble the style of the old one.  After getting the materials to look approximately how we want them, TK and I deconstructed the suit by adding a working zipper, and then generated a bunch of new morphs to make that lovely cleavage compatible with Genesis 3's pose-able tatas.  Having a custom-rigged model means we can do a lot more with it, so we will be attempting to do armor damage entirely in 3D with this one (as opposed to painting it by hand).  That's for another post though :D. 

Since initially showing her off a few weeks ago, I’ve reworked and finalized materials for all her clothes and her hair. Regarding the hair specifically, I spent a day testing subsurface scattering techniques in an attempt to accurately recreate the effect of light passing through darker hair. I’m happy to say I was successful! After trying out a whole bunch of different options for headgear, we finally settled on custom glasses that Ubercharge modeled this past week and helped me nail the materials on. 

So, now onto what’s still left to do! TK ended up having to rework the unzip and open morphs for her bodysuit, so unfortunately I don’t have those to show off today as I had hoped. We’ve also got to do some rig editing on the holsters to ensure the straps don’t deform when her legs bend (like they are in the back in the full body image above). At some point soon I’ll be adding new genitals to both Neon and Malise, so those should be fun to show off :D. Lastly(?) and probably the most difficult, we’ve got to get armor damage in 3D working. We originally weren’t intending to do this until we move over to Maya, but we’re pretty certain with everything we’ve learned we can get it looking good in Daz.

Malise’s Gun Overhaul

When I showed these off to the Inner Circle crowd the other week I was pretty sure we’d ruffle some feathers, but we definitely needed an overhaul for Malise's old revolvers.  While I initially wanted to cyberpunk-ify them with a design similar to the Syndicate guys' revolver, Uber felt semi-automatics were more her style.  I was skeptical, but after he landed on this particular concept I was sold.  It ended up becoming one of the most detailed props we've created.  You can check out a mess of images here! 

Weighing in at a whopping 3 million polygons, Uber’s currently finishing up a low poly version that’s compatible with Daz (and has virtually no quality loss). I’ll need to texture that at some point soon, so tack that on to the list of things to finish up :D.

Corruptor Overhaul

Malise isn’t the only one that got reworked this month! 

The guy shown above is the revamped version of what I call a "Corruptor"; AKA the dudes from the scene at the end of v0.05. He was my project over most of the last week as TK worked on morphs for Malise’s suit. 

Even to a greater degree than with Malise, I rebuilt this guy from scratch using the Genesis 3 body system.  This is my first creature that I’m really proud of honestly.  When we showed him off to the Inner Circle earlier this week there were some suggestions to go wetter with the skin, which I want to mention is super easy to do with physically based rendering (it can be done with a single slider :D). For more viscous slime we’ll need liquid simulation, which we intend to get working in full once we port everything over to Maya. Anyways, Here’s a new shot I haven’t shown off yet, displaying his lovely skin in extreme detail!

Hopefully once you compare this guy to the old version, any remaining skeptics regarding the necessity of this art overhaul will be converted :D. 

AltairPL’s Programming Progress Report!

If you're Inner Circle member, feel free to skip the first part of my update, as you've seen it in one of the previous IC updates. I’ve added my report for this past week below though!

I've started this month with a plan and an early prototype for map GFX handling overhaul. It was supposed to be pretty simple and quick. I was on a roll, so it was quick, but far from simple ^^ - I've managed to do much more than planned and anticipated, which surprised me a lot and makes me really happy and proud.

The main reason for this "small" overhaul was a messy map GFX file naming scheme related to a long gone 3rd party script. Since then, map data handling was recoded and could handle much more and in better way, but for few reasons, cleaning up the filenames was always left for later. No more. I've actually changed my plans in the middle of the work, but now all files are neatly named, ordered, and grouped, and everything is much cleaner and easier to work with.

Another reason for the overhaul was to make the map layers system much more universal and versatile. The old system had internal division of map images to traversable map layers and extra images, like tiled backgrounds, pipes, etc. Pretty much everything related to map layers was hard-coded and only extra images were a bit more configurable. New approach is a huge step forward - now all map images are handled in the same way and configuration options are not limited by the type of the image. Traversable map layers are still partially hard-coded, but it’s more like an automation saving time instead of a limitation, and those default parameters are very easy to override. We can do a lot more with the new system, and every newly implemented parameter will be readily available to use with all map images. One of the most notable features allows for using cropped map images, which in turn will decrease disk space usage, memory usage, and map loading times - probably not much, but every bit counts ;).

At first, all map images' settings were stored in hashes and most of the processing was taking place in the game proper, so I started wondering about making a new object class dedicated for map layer data. Had mixed feelings about it at first, but as it turned out later, it was the best I could do. First of all, most preparations are made during pre-processing phase of the development, so only few things have to be processed in the game itself, which makes it a bit faster, which is good since added functionality added some overhead. Using dedicated class also allowed adding internal methods to it, which dramatically decreased clutter in the code. I kinda realized it much later, but there's one more great thing about it that I hadn't taken into consideration earlier - considering how I chose to do things, it's also extremely easy to save and load map layers' settings along with the game, which means that all transformations will be remembered and then restored, which till now was not possible.

During the overhaul, I had to edit preferences of every map used in game. Since I was already there, I've cleaned it up a lot. I removed few obsolete things, renamed few others, etc. While doing this, I've noticed something peculiar about built-in RM parallax: most of its functionality could be replicated with my new map layer system, so I've decided to spend some time to analyze it and make it a part of my system. That way we can have as many vanilla-like parallaxes as we like, and they'll be much more versatile than the vanilla one. Not to mention that some neat vanilla parallax functionality, like automatic scroll, was extended to every other map image.

Since I was already knee deep in map entrails anyway, I've decided to include in the processing something needed by 4:3=>16:9 conversion. The main problem with RPG Maker is that a lot of graphical things are hard-coded, and in such a way that changing it is virtually impossible. With a lot of luck, I was able to fix the built-in Plane class which is used for tiled images, but there's a lot of things I had no luck with.

This includes the way in which RM handles/draws tilemaps. Basically, every tile exceeding 4:3 width was not drawn. Fortunately, full tilemaps are used only by my test maps, but majority of Access Tunnels maps were using animated tiles functionality. I've yanked out every use of animated auto-tiles and replaced them with simple animated events... required compiling animation spritesheet and few small changes to events code, but it was well worth it. On top of few FPS I've gained thanks to overhaul, maps that were using animated tiles got another dozen or two of extra FPS after disabling tilemap use. That's one of the best examples of how inefficiently RM does some things - 30-40 FPS lost on basically nothing!

Another hard to fix graphical features limited by 4:3 aspect ratio are various transition effects, including fade-in/out, freezing the screen and performing transition from frozen screen to current scene. Thankfully, my recent work on similar stuff for URGE, and long done fade-in/out related to loading screens scripts, both made my life much easier here and I was able to code replacement from scratch in Ruby. The only thing that wasn't implemented is special kind of transition using black and white image as transition opacity map - it was used only just prior to the battle, and I'm not sure if Ero agrees with me, but IMHO we can live without it.

With this out of the way, the only stuff that needs conversion to 16:9 aspect ratio are some images and UI. Former is not really my department, but whenever I can, I do process some simple images, like UI, by myself to save time. Latter however, is a bitch, since conversion to wide-screen results in much wider (1024=>1280), but also lower (768=>720) area to work with, and some things were already a very tight fit vertically. That said, I've already converted everything that was looking weird, causing clipping, or outright crashing the game. It is only temporary, since we'll need to revisit/redesign parts of UI, but this will have to suffice for now. Nasty cold and the new Patreon guidelines stuff hit while I was in the middle of it and it seriously slowed me down.

Well, last thing planned for this month was getting back to battle engine overhaul, so I can proudly say "mission accomplished". This battle overhaul was left unfinished when I took the break resulting in URGE inception, so I have a lot of catching up. Unfortunately, not only list of known issues was already long, but recently it got even longer. That said, no matter what happens, I just need to finish it before 0.06. Only like 90% of its functionality will be needed for now, but I would really like to reach whole 100% and convince Ero to allow me to do some things my way... at least as a preview... just to blow you guys away :D.    

[Begin New Stuff for IC Members]

For some reason, even though I have extensive notes, I was unable to replicate most of the bugs in the battle engine I had before switching to URGE development some time ago. I did find one or two new ones during additional tests, however, which didn't help with my declining mood. Let me tell you, this battle engine stuff is seriously convoluted. So much that I actually subconsciously did everything to do something else. It means that not counting many, many tests, followed by making extensive notes on all battle engine bugs, new and old, I haven't progressed very far with it. It doesn't mean I was sitting on my hands, though.

The main detour from battle stuff was making menu scene dedicated for all ARIS processing, which will replace processing using the map event. In case you don't know/remember why it is/was necessary, see "ARIS Scene Revamp, Graphics Conversion, and Concept Map" section of "October Progress Update!" (https://www.patreon.com/posts/october-progress-14814203). 

The ARIS Scene looks like this at the moment - basically a full recycle of all menu assets for now. Functionality is also pretty rough - pretty much the same as previously used map event. I have a lot of ideas about how to improve its functionality and make it more eye-candy, but doing this now would be a waste of time, since sooner or later some related stuff will change and then I'll need to do all ARIS stuff almost from scratch.

Besides the above, I've fixed few random bugs, and optimized text caching performance a bit... a very small bit, but still ^^.

Ubercharge's Finished Car Design!

Ubercharge finished his first car design not long after our last monthly update.  You can check out images from his progress here!   

This one took a little while since we had to work with the original asset vendor to acquire the proper formats for what we needed.  In addition, Ubercharge developed a technique using displacement mapping that should carry over to the other car designs as well.  Now that the process has been figured out, the remaining cars should go more smoothly (we need at least one more for v0.06).  

While we eventually plan on making a few different base designs, Uber will be able to create multiple paint jobs for each, as well as change up options (tails, rims, etc)  so that we can recycle the models a few times.  

Ubercharge's Monster Test Sculpts

Recently Uber has been doing some sculpts to test out techniques for the custom monsters we plan on eventually designing.  You can check them out here! 

Ubercharge's 3D Scan Tests

Ubercharge has been learning 3D scan techniques for converting photography into usable 3D assets.  I really don't know much about the process (feel free to ask, I'm sure he'd be glad to fill you in), but the results are really impressive!  There will be a couple of areas later in the game where nature assets will be required, so this will be particularly useful once we get to that point.