Inner Circle Update for September 28 2018! (Patreon)

Hey guys!

I promised an update on MATM progress and meant to post this a few days ago, but I simply didn’t get around to it ;( . Since it’s been a few days there’s already quite a bit of new progress on Pure Onyx, so I’d like to give you a preview of what we have planned for the monthly update there as well.

MATM Progress 

So, most of the info in this update for MATM was going to be posted with our Pure Onyx announcement, but I decided to get that out of the way first. We’ll have more up-to-date info for the monthly post!

Ubercharge’s Map Progress

Ubercharge spent some time working on some ways to make the streets look more lived-in for our city maps, and one of the obvious ways was to add obscene amounts of trash :0. He came up with a system that works great for making it blend with the wet surfaces. 

Here’s a look at the final version of the map we showed off in the monthly update, including the rest of the details he’s added!

AltairPL’s URGE Engine Progress

In case you don't remember it from monthly, at that time I had two things planned:

• Implementing the positional audio stuff, on which I was working.
• Making a bit of an input overhaul, including adding support for game controllers.

Dunno how to say this, but I kinda finished both in the first week... and then some more. But let's start from the beginning.

At the time of the monthly update my notes and preparations were good enough to make implementation of positional audio almost a breeze. Almost, since I had to change few things along the way, and I'll probably need to tweak some things some more sooner or later. Anyway, after implementation and testing, I needed something to test this stuff on. Most logical choice would be the maps, since positional audio was implemented mostly with them in mind, but for some reasons, explained later, I decided not to. So, battle became my testing ground, and if I can say so myself, it's working just great. Needed to change and tweak some things to make it work, but so far so good.

While I was at it, I also wanted to move everything related to volume control and some other stuff to C as well, but considering how deeply it's integrated in Ruby game scripts, doing it now would create a lot of chaos, which I would like to avoid, so I'll wait with this for a time when I'll feel ready to cut all ties with RM, which is still not possible/feasible for a few reasons at this moment.

Implementation of game controllers was next on the agenda. Whole input module was one of the very first thing I did in C, so it was somewhat clunky and used a lot of stuff meant for full compatibility with RM. I learned a lot since that time and I started veering away from RM approach a lot lately, so game controllers handling implementation was merged with slight input handling overhaul, which is kind of an ongoing process, since I can't just change everything at once. Long story short, a lot of stuff was already overhauled and optimized, and few more things are waiting for their turn.

Input actions a.k.a. virtual buttons (can't seem to find a good name for it, that could be short and descriptive enough to use both in code and in game itself) to which keyboard keys and controller buttons are assigned were severely improved. In RM you could only check if such virtual button is being held, if it was pressed just now, or if it's repeating (periodic tick). Also, in RM, only last pressed key was checked for said repeating. After the overhaul each button has its own timer representing how long it was held down, which is nice in itself, but also repeat check can be performed separately for every button now. Aforementioned hold timer can be checked at any time which is great to check how long button was pressed or for how long it was held before being released - with release check being another new thing as well. In both RM and URGE, all such virtual buttons are kinda hard-coded, but I've already taken some steps which will allow me adding new ones on the fly from Ruby scripts, which will also be utilized by the upcoming controls configuration.

I also added basic handling for mouse, but since it's completely unsupported by MATM Ruby scripts and since there are some tricky stuff involved, I'm gonna leave it for much later.

Controllers are now supported, including possibility to fully utilize controller's analog stick for movement. I had to make some workarounds for library, like adding treating controller triggers as buttons, but I was also forced to make some hard decisions - main one is to hard-code assignment of left analog stick to the movement. I can't say I'm all to happy about it, but it's the best solution for now.

Anyway, possibility to utilize analog stick value will be great to make controls on map much less clunky. This is second map feature that I'm leaving for a bit later, and I think it's as good time as any to explain why.

Since I (re)started working on URGE, ideas revolving around map visuals changed a lot, and I never had the time to actually replace old systems with prototypes of or actual new versions. On top of that, for a long time additional map functionality was hanging over my head. Most important one is the need to completely change how movement is processed, including per-pixel movement and some other stuff buried deep in my notes. With this and extra stuff added lately for audio and input sub-systems, I decided to put all map related work on hold, gather all the new stuff and notes, and "simply" redesign and recode the whole thing from scratch... erm, map stuff, that is.

With controller stuff up and running I needed to dive back into ruby scripts and code something which in RM was part of the application - options for internal stuff like visuals or input. Options screen was in MATM for a long time now and it already had some of this functionality, like ability to mute music via volume control coded by me along the line. Since it was finished last, I started with implementing some controller options. Since I now have the ability to monitor controller connection state in real-time, options screen is using this to enable or disable controller-related options. It's now also possible to enable/disable controller without the need to physically disconnecting it. Another option some may found useful, is the ability to adjust controller analog stick dead-zone.

That's as far as I got this "week". For now, I'll keep updating the options screen - still need to interface some internal URGE stuff using separate ini file with it, and I need to figure out the details of controls mapping configuration, which probably be huge pain in the ass on its own, but will also require some changes to existing stuff.

TK’s Rigging Progress

It turns out that interfacing UI and python in Maya is more complicated than I thought. Over the past 3 Maya releases, they've changed the methods each time. I didn't know this at first, so I just picked the first few documentation bits and examples that I found and started trying to make sense of everything. Errors everywhere! Now I'm on the right track and have some working examples that are even a little close to what I want to do, so things are going a little bit better. A lot of the script concepts are beyond the level I've been working at, so it's been a struggle, but I'm catching on, if not a little slowly. I keep thinking that I should really just sit down and work through some tutorials, but I've always learned best by picking apart examples and diving right in.

My mockup screenshot of the UI at the moment, I need to redo it with proper resizers and layouts, but it'll do while I work on the scripting side. The top box will have category and pose columns, left box will contain quick selection sets, and the namespace dropdown is for picking characters in the scene. The buttons are for grabbing a selection from the selected pose, Blend/Add/Sub are different methods for applying that pose with the slider acting as their strength multiplier. Later, I'll add the file menu for loading up tabs with additional pose presets, saving and probably reloading. Oh and a button to save a pose, I suppose that might come in handy, yeah?

PURE ONYX Progress

We’ve decided to make a push to try to get some video footage of a Pure Onyx functioning in Unity for the monthly update, as we think it could help dispel any notion that the tech could bog us down. We’ll be using sketches to represent the characters while we experiment with attacks and work on combat flow, so it may not be super pretty but it will be something. The video will utilize frame-switching animations instead of full skeleton-driven ones, since obviously those take more time to set up and rig. In doing this however we are getting a chance to hook up and test our skeleton system—we’re just using a very basic skeleton to send events to the engine.

Animation Prototyping

We’ve had a nice little assembly line thing going these past few days for animations. Limbo has been banging out sketches left and right, and I’ve been filling and prepping them for the engine while Mr. Kittyhawk implements them. Here’s just a portion of what we’ve done so far! We may not use all of these, but there are some fun ideas in here, as well as a lot of clues as to what sort of moves we’d like to experiment with.

Game Environment Test

I’ve also had a lot of success (we think at least) in making a test environment that fits our perspective and stylization requirements with relatively little post processing / manual work required. As with the environment in the teaser video, this is a 3D scene pre-rendered in Redshift and post-processed for stylization. There are some obvious flubs here that look artificial still, so it’s definitely a work in progress, but please give any feedback you can so we can improve the look.  

To boot, Ubercharge has also been working on his own edge detection and materials system that more closely resembles modern manga, which we will likely do some integration tests with as well.

Another test I did was a sprite blending test, to ensure characters look good within the game. This image also is a representation of the screen layout, including sprite size and zoom.  The obvious thing missing here is some rim lighting to separate the characters from portions of the background (Onyx has a lot of dark colors, so she’d melt right into dark backgrounds). Let me know what you think otherwise, though!  

TK’s Onyx-Flavored Rigging Update

While most of my time will be going toward MATM, Ero needs some initial support to get things rolling.

Our current workflow for the final sprite artwork in Pure Onyx means more work in Daz for a little while longer, since we're using some of the original shading method from the earlier style of Malise and the Machine. The coat Onyx wears is currently a bit of a mess to actually use-- it was originally a concept piece for render tests. So, I'm doing it up proper from the original asset, extra sculpting, and adding joint chains to pose it. I forgot how abysmally horrible the process of making new bones from scratch in Daz was. What's that game we used to play as kids? Something like "don't sneeze or your bones will exfiltrate", or "Jab sticks in your eyes and see who can run across the street first"? It'll come to me. Anyway, full Maya workflow can't come soon enough.

Typically clothing in Daz relies on using morphs for this additional control, but in my opinion, half of them are too situational, or not as helpful as originally intended. With joint movement and rotation, you get much more control, much better bang for the buck. Especially when the base shape is something organic like this wrinkly coat, compared to something straighter, like a tight t-shirt. The trick is having just enough and placed strategically; having too many is a chore, too few is worse than some targeted morph.