Inner Circle Update for Oct 16 2016! (Patreon)

Be forewarned that this post is going to be kind of a monster.  Not only do I need to recap a few subjects from the old Inner Circle forums (where IC posts were made previous to the campaign overhaul), but I’ve been thrown off of my usual updates for the past couple of weeks due to the campaign transition. 

Firstly I want to point out for new members that I use Google Drive to share content for the Inner Circle.  I usually have a link on each post that when opened in your browser will take you to a folder where you can view/snag the content.  Keep in mind that the same rules for other digital rewards go for the Inner Circle posts/content.  It’s meant for you guys and posting it elsewhere would make us sad pandas.  Regarding the content, some posts are more technical and game development related (which some of you may enjoy more than others), while others are more boob related.  In general, these posts are meant to give a more in-depth look at the development process than the regular Patreon posts and to serve as a platform to get previews and high res artwork to you ASAP.  Click below to access the Drive folder for this week, and read on for in-depth descriptions of the content and what we’ve been up to recently.

Images and Content for this Post on Google Drive

High Res Artwork

Sorry old Inner Circle crowd, you saw these previously :(.

I’ve uploaded some artwork of Neon’s new outfit that, while in the game, didn’t have high resolution versions in the most recent PDF (yet).  I’ve gotten some questions recently regarding whether we’d have the updated version of v0.05 with the remaining artwork for Neon’s outfit ready for this month as I had hoped, and this leads me to…

When will V0.051 Be Released?

We still plan on releasing v0.051 this month, meaning that as talked about it will theoretically be free for patrons who pledged for v0.05 before the campaign transition.  It’s going to be toward the end of the month, but I promise the wait is for a really good reason (at least in the long term), which takes us to…

Malise and the Machine Render Manager for Daz Studio

I had posted about this for the old Inner Circle crowd, so apologies for having to rehash the basic details.  That said, the design is now pretty much complete, and I’m going to get pretty technical here because I’m really happy with how it’s turning out.  Note that there are some example work-in-progress images with visual descriptions in the Google Drive link above.

One of the biggest drawbacks to using Daz Studio for character art is that its rendering configuration is by no means optimal for a complex render setup like what we have going on.  For whatever reason, no one has attempted a solid render management and batch render solution for Daz.  What this boils down to is that with the exception of animations, I have to do renders by hand.  This means I manually set the lighting / load any material presets / change the output file name / whatever and click "render"... sometimes up to 25 times or more per final image (in the case of this last story H scene, for instance).  I checked the time stamps on the renders for some of the Vorepup artwork I just did for Neon, and saw that on average there was about an hour's worth of time wasted per image manually pushing out renders. 

The good news is that this will no longer be the case, because early this month I determined it's now possible to create the render manager / batch renderer I've needed since the start of this project.  The bad news is that I have to code it myself.  MORE good news however is that I already have a prototype working, and since I originally posted about this in the old Inner Circle forums I’ve actually completed a lot of the more advanced features that I figured would need to wait awhile.  It’s safe to say that aside from the campaign overhaul and all that things that came with it, this project is where my time has been going so far this month. 

So, here’s the technical description.  The MATM Render Manager is a GUI-based render manager and batch rendering plugin I’m creating for Daz Studio customized for Malise and the Machine.  The tool dynamically builds options that allow for complex pre-configuration of renders, giving the user the ability to click “render” once and let it run in the background.  The tool is expected to save anyone working on character artwork for the game anywhere from 20 minutes to hours per image based on the complexity of the scene.  

Here are some of the features for it that I’ve already implemented:

• Automated batch rendering using scripts to load proper material presets and set up the scene for any given necessary render type.
• An improved output file destination browser (Daz’s default one is clunky as hell for big projects) that remembers the output destination on a per scene basis and names the output files appropriately based on the render type.
• Detects lights and MATM-specific objects/characters within the scene and dynamically builds lists of available render and lighting options based on the results.
• A functioning (though basic) dynamic user interface to support the above features.
• Plays a sound when rendering is finished (Daz’s default renderer does not have this much needed option).

There are still a number of features that need adding before it can handle the more complex scenes effectively, but right now it’s perfectly capable for single character portraits.  I had put the following things off so I could knock out some other features, but the last things left to tackle before it will work with H skill portraits is to revise the naming scheme in my material preset database to work with automatic character detection and to add support for batch rendering with multiple characters simultaneously within the scene. The remaining artwork for v0.051 will serve as a great test run for the plugin.

AltairPL’s Progress Update (Programming)

Our programmer, AltairPL, has written up a list of some main points of things he’s been up to the past couple of weeks. 

• One of my HDDs started dying on me, so I had to spend some time on damage control, data recovery, and system re-installation after replacement HDDs has arrived. Don't worry though - MATM related stuff was never in any danger.
• Implemented internal gallery mode, which will be used by us for debugging purposes (enemies animations, H chains progression, artwork existence, etc.), and maybe with time it'll become the base for a proper in-game gallery.  It's too quick and dirty for now.
• Added functionality for an additional turn indicator to battle UI.
• Overhauled the engine’s base sprite class used by battle portraits, animated enemies, and map character sprites.
• Fixed an RPG Maker animation related bug that’s been present since RPG Maker XP and was never fixed by the developers!
• Made some preparations, both theoretical and practical, for the upcoming, and hopefully last, battle engine overhaul.
• Improved handling and processing of some database elements called "Features", which basically are modifications to actor/enemy stats, parameters, resistances, etc. Groundwork for it was laid down long time ago, but I never had the time to push it forward.  Since it will be useful for battle engine overhaul, I did it now.  Long story short - a bit more work for me, but better performance and easier to read/modify code.

TK’s Progress Update (Map and Environment Art)

TK’s been primarily working on map artwork replacements for the Access Tunnels area, which you can check out progress screenshots of in the Drive link above.  For the new folks, the reason for this is that during the last development cycle TK designed a whole new map editor using Maya that allows us to create maps entirely in 3D as opposed to using 2D tilesets.  It’s a much faster solution that provides way better results, but to maintain consistency we will eventually need to replace most of the map artwork we had done previously (thankfully there wasn’t tooooo much of it). Earlier this month TK spent some time performing a workflow experiment that he’s given us his description of below.

Hi again, Tikkler & Krotch here!

For map building, I had been looking into ways to keep my scenes clean while the number of assets grows. Since I do all the layout work in Maya, I don't have the streamlined benefits a typical game editor does. Until now, I've been keeping all the models, textures and shaders in a couple scenes to use as a palette I can pull from. On one hand, it allows me global control over simple things that I use often, but on the other hand I end up needing to maintain a few "master" scenes. Maya however does have a Scene Assembly workflow which would allow me to split the tilesets up into smaller scenes that I can easily import without the mess of an actual import.

So after much research, customization, and swapping a part of the tileset over to this system... I found it very easy to work with, with less worry about corruption in the master scenes! Unfortunately I found some aspects very restrictive and exhaustively time consuming to make changes. In particular: shader assignment and the ability to make tiny corrections to models on the spot, as well as losing the "global" effect of the texture projections (suddenly everything looked very very tiled, the very very thing I try to combat by using them in the first place!)

So, that was a wash I think, but a learning experience at least. The option of scripting this system further is still there but I'm not optimistic about that at the moment. Until then, it's back to my usual ways.

Battle Customization

If you’ve been hanging around the ULMF forums or the old Inner Circle forums you’ll have seen there was quite a bit of recent chatter regarding balancing.  Since then the ULMF thread has kind of turned into a soup of people throwing ideas out there, but the whole thing led to a couple days of thinking. 

I think the most important thing I determined is that everyone plays H games differently, and thus value certain balancing/mechanics qualities drastically differently.  I’m not looking to rekindle that particular discussion, but what I found is that what I viewed as “bad balancing” was really just someone else’s way of enjoying the game.  I was using solely what made the game fun for me as a compass, and it’s not that simple. MATM is already a niche game in a niche market, and restricting players to my vision of “fun” would make the game inaccessible for a lot of people.  Thus, we’ve decided that MATM could definitely use additional battle customization features.  Right now however I’ll admit I’m really perplexed as to how I want to present these features, because the last thing I want is for people to be turned off by what is intended to make the game more accessible.    

Balancing Changes

Regardless of the above mentioned customization, the battle system is very much considered a work in progress.  Notwithstanding future goals such as adding a shit ton of skills and gear related stuff, we’ve been taking a hard look at things that would make the battle system better for everyone, and are ready to begin investigating some possible improvements. Here are a couple of things we are investigating.

Knockdown States: We’re very likely going to change how Knockdown works sometime soon.  Currently the only time it’s used in game is after a finisher.  In this context we plan on removing the freeze that the state causes to the affected character’s ATB gauge.  Instead, the character’s gauge will begin filling immediately after the finisher, and the state will display the artwork associated with the finisher up until the character has either acquired their turn or some other higher priority state causes it to change.  Right now it’s simply too easy to get locked down in a series of grapples after a finisher goes off.

Lust System Changes: We’re currently looking at changing how the armor damage system and Lust system are tied together.  Note that this doesn’t refer to exposure caused by Lust, but actual armor damage caused by enemy attacks (and subsequent exposure from that).  If you haven’t noticed or didn’t read the tutorial messages, armor can currently only break after a character has reached a certain level of Lust Sickness. The upside to this is that we can make this battle system work with a lot fewer artwork variations than would be required otherwise.  The downsides are that the system is kind of confusing, and that it makes Lust very rigid as a parameter.  As an example, if Lust was to be (hypothetically) removed in battle, armor damage would have to be as well (now you see why ARIS units work the way they do). Right now all design choices that would allow for this are off limits to us, so we think it’s worth looking at. The fact that a whole lot more artwork variations would be required sucks, but improvements like the forthcoming Render Manager and previous workflow optimization have really sped up the character artwork process since I first designed the Lust system, and therefore it’s a lot more feasible now than it was then.  I’ve yet to crunch the numbers, but expect some more info on this in the next couple posts.

Conclusion

Welp, there’s my essay for the week.  Hopefully you are enjoying the new campaign format, and if not please let me know what I can do to improve it!  I also really want to thank those of you that are sticking with your old pledge tier even though we’ve changed to monthly!  While it’s still too early to gauge how the campaign overhaul affects us financially, I’m very optimistic that we’ll soon be able to expand the team further!

Thanks again guys!

- Eromancer