February 2019 Progress Update (Part 1)! (Patreon)

Hey everyone!

We’re still working on the next release, but it will be available later this month for sure.  Here’s a brief list of the major additions it will contain:

• H scene(s) for the Splicer Thug
• Full animations for the Splicer Thug moveset (example video tomorrow)
• Rebuilt animation and physics layers of the engine. 
• Collision/hitbox/physics visualization overlay accessible via F1 key

I’m breaking this update into two parts :D.  We’ll show off some H artwork previews tonight, the latest boss artwork, and one of Ubercharge’s maps. We’ve also got an update from APL on his work on the MATM engine :D.

Tomorrow night I’ll post a video showing updated Splicer animations, reveal a couple of new enemies, and show off our work on the latest environment. Mr. Kittyhawk will also have a big update to go over his work on rebuilding the animation and physics layers of the game, and he’ll show his physics visualization overlay that will help us set up hitboxes/collisions/projectiles and whatever else.

Contents for Tonight’s Update

• Onyx vs Splicer Thug H Artwork Previews
• Onyx Edits
• Boss Artwork
• Stage 1-2 Map Progress
• APL’s MATM URGE Engine Update

H Artwork Previews!

The H artwork for the next release is in various stages of completion, but I want to show you an example of a completed frame! I’ve posted a few different versions to show off the work that goes into getting these things Spine-ready (also because I just wanted to show off some boobies).

This is the most complete in-game character art to-date, and is what you can expect in the future. Up till now, TK has been doing an initial shading pass by referencing 3D models, but now Limbo and I are doing a further pass to make it more natural-looking – the difference is especially noticeable on the Splicer I think.  Check out the full/high resolution versions below.

• Onyx vs Splicer Thug 1-2 Preview 
• Onyx Spine Breakdown Example 

More H Artwork Previews :0

Check out some additional preview (WIP) frames from earlier this month :D. The H sequences will include a grapple stage, transitions, finished poses, and sometimes extended scenes that play after the initial one is finished. Full images are below:

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

Onyx Edits

For a big chunk of this month I’ve been occupied with cleaning up and breaking down Onyx’s moveset artwork for Spine. Lesson learned, it’s far easier to draw characters in layers from the start (which we do now) than it is to break them down later. That said, it’s giving me the opportunity to improve on shading and faces since I’ve gotten better at both.

I figured I’d run some of these changes by you guys to see what you think!  Among other stuff, I’m working on making Onyx’s face more attractive where possible. What do you think of this change to the idle pose? I’m also considering removing the animal print from the shirt simply because it’s very detailed for this style and makes the folds in the shirt unreadable. I may make the shirt color brighter though so it's still the focal point. Yes/No? 

Boss Artwork

Even though this guy is way more detailed than our first enemy, he came 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 

Stage 1-2 Map Progress

Ubercharge made a lot of progress on map stuff this month, even with his school finals in the middle :X. This is one of the two maps he’s made a lot of progress on. 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 one of the new maps, 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 

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.

*EDIT: Fixed some missing preview images.