Inner Circle Update for October 28 2017! (Patreon)

I've put together a proper IC update now that things have settled down after all the recent Patreon craziness.  I showed our progress on the Malise overhaul a few days ago, but there was also a lot going on otherwise.  While TK and I worked on Malise, Ubercharge and APL were working on projects of their own.  I have that to show off, as well as recent progress on Malise's new gun model and headgear concepts.

Ubercharge's Finished Car Design!

Ubercharge finished his first car design not long after our 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.  

AltairPL's Progress Report

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.    

Malise's Gun Overhaul

I'm sure this one will 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, and despite it being super high poly (as a measure to counter Daz's lack of support for vertex normals) I'm really pleased with the design.  You can check out a mess of images here! 

Concepts for Malise's Headgear

We're currently working on some options for headgear for Malise.  I overhauled her glasses, but Uber is working on a custom headband/optical module that could be a better fit.  He just started on it today, but you can check out the various options we've put together as well as his progress here! 

Ubercharge's Monster Test Sculpts

Recently Uber has been doing some sculpts to test out techniques for the custom monsters we eventually plan on 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.