eromancer
patreon
Inner Circle Update for Oct 16 2016!
🕑 Added 2016-10-16 21:23:55 +0000 UTC Welcome new Inner Circle members!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
Comments
It will be at the end of October :D.
Not sure about this one yet, but I'll say it's not a priority.
The elevator at the end of V0.05 actually leads to the surface :D.
It's very specific toward MATM, so unless people had our exact development setup it wouldn't work out. The format is very nice and flexible for our internal use, but having to make the inner workings abstract for general purposes would be a much bigger project that would take away from development time. I can definitely post the code for you to check out, but without our databases (which we can't share due to asset licensing), it wouldn't be able to recognize any characters to perform operations on.
Regarding #2, see the section on Battle Customization above. Having to balance the game twice or more would be a nightmare, so what we've decided on is to balance the game for the original vision and offer extensive customization to players. Obviously, presentation here is important, since right now (and judging by your comment for instance) I think people expect the Wait Modes to be balanced similarly to Active, when in fact they change the experience significantly. EDIT: Was thinking about it, and I'm not sure I finished my point :D. In essence the new goal is to offer additional battle customization, but present it so that players recognize features that may deviate from what the game may have been balanced for, and thus that they are changing the experience on their terms (without making them feel bad for having fun with the game in their own way). In case anyone may be wondering where I'm thinking of drawing inspiration from, my shining example for this right now is the game Pillars of Eternity.
AltairPL
Thanks for the feedback, quick reply cause I need to go out, so Ero will make proper reply later (if necessary): 1) Reported and fixed, but it was minor enough that we decided not to make a hotfix for this alone and include it in 0.051 instead. 2) Battle engine will be my main task for 0.06 and this includes balance stuff. We have an idea for it, but it's hard to say how good of a solution it will be until it's actually implemented. 3) Old maps are being reworked, so they'll be more user friendly - see example renders from Google Drive folder linked in the post and new maps already in 0.05 (Observation Deck and Containment Pen). 4) This is Eromancer's call... who knows, maybe he has some plans for walking. 5) Missed one :P. 6) Probably will be, but it has kinda low priority for now. 7) We want to, but there's never enough time :(.
First af all, great work, guys! Enjoyed it very much. And now, wall of text incoming. I don't know about you plans and priorities, so I'll just list things that I think are worth mentioning. 1) A bug to begin with. You can trigger Doc's "fuse description" dialogue before restoring power if you go to an A-circut door straight away. This leads to listening the same dialogue twice. 2) Regarding "time wait" vs "realtime". I think it is impossible to have single diffulty level that will work in both modes without one of them being either cakewalk or nintendo hard, simply because playing on "time wait" is effectively the same as playing on "realtime" with perfect skill. I think the only (reasonable) option is to balance both modes separately. "Realtime" should be more reaction-based (avoid as much anal rape as you can), while "time wait" should be more strategic/resource-based (avoid anal rape right now or massive HP blow later). What comes to mind is active mitigation mechanics from WoW where proper cooldown/resource management is key to minimising damage. But that will require enabling cooldown on abilities, making resources scarce and upgrading enemies have more diverse set of attacks. 3) Visual map design. I think it's a mess right now. Maps may look cool and easy to navigate in an isometric view but in an oblique top-down projection used by RPGMaker they become impossible to navigate. A lot of times I found myself in a very confusing situations where I try to go somewhere only to realise that it is on another floor, or I am trying to figure how to get to another floor only to discover that map is totally flat. In some places one floor has completely different textures, in other there are two floors with the same texture. It is compounded by not having pronounced borders between elevation layers. Oh, and add lack of lighting at the beginning of the game and you get a very frustrating experience. As a guideline I think you should: a) Walls should have textures and colors different from floors. b) Places where elevation of the map changes should be clearly visible. c) Use different textures or different shades of same textures (as apropriate) for different floors. And some minor things: 4) Map movement speed. It feels quite right if you are exploring for the first time. But if you are doing second run or want to backtrack for some reason it's somewhat slow. Replacing "walk" button (I don't really see why we need it) with "sprint" button seems in order. 6) It would be really nice to have a map name (e.g. "Access Tunnels") written somewhere on the screen. As it is, you can only see it after you save the game on save description. 7) Quest log. Or at least simple goal list. Even simple records like "explore facility" can structure experience and remove a lot of head-scratching.
Panthear
since I am working with Daz Studio myself, are there any plans to publish the MATM render manager (Daz3D / renderosity / renderotica) or give access to inner circle members?
and one more question sorry for bombing you with them im just wondering how many builds or demos will take place in the underground facility or whatever its called. ps sorry for the improper grammar
oh and is there going to be a option to walk/run around naked? but keep the stat of wearing armor or will that be lost while being naked?
Hello Ero question about the V0.051 is it going to come out at the end of Oct or the end of Nov?
Mav
Keep up the good work, Ero. Each update sounds like you guys are doing a lot of backend stuff (...pun?), which is important. Once a lot of that is smoothed over, we can't wait to see what stuff you guys put out for us. :)
for me, its very interesting to read how the devolp goes and what issus it can make
There are base models for each character in each major outfit, and among those there are base models for each major outfit configuration. Poses can be transferred between them as a base when working on a similar state for a new character, then adjustments are made on a per character/outfit basis, sometimes resulting in a new pose entirely. It doesn't necessarily scale as badly as you may think, and this is due to a lot of conditions requiring new art being mutually exclusive from one another. The killers are anything that could cause exponential scaling (outfit + armor damage + visual state), but even then there are a lot of elements that can be reused to lessen the workload (almost to the point that it decays exponentially per image really). For example, the brunt of the work for Neon's upper armor damage was making the model. After that, it took maybe 10% of the time to create each armor damage variation as it did to create the non-armor damage version. And her non-armor damage of that outfit took maybe 30%-50% of the time that it took to do the original pose, and so on. In most cases, the more artwork we do the less work is required for new artwork. In addition, we're continually optimizing workflow, software performance, and methods to reduce any non-creative work. This new Render Manager is one of the biggest gains in that area since the start of the project, so I'm pretty excited about it.
Kevin Zogg
I'm not sure if this is the right place to ask. Ignore it otherwise, but since it's a more technical post, I'd like to comment here. As a developer and avid gamer, I'd like to know something. Seeing the artwork PDF for the first time, I was honestly a bit shocked how many single images and states there were. I guess I had never realized how many different images per character there are (though I have certainly seen then in the game). Now, I think there are a few different approaches how design/animation is done and implemented in a game. From the looks of things, you are doing the battle states per character, per outfit etc. Maybe I'm wrong, but I imagine this is a lot of work. How do you create those different states? Do you have basic models in all states and then just apply an outfit and render them? Doesn't that take a lot of time? The reason why I'm asking is, adding enemies or clothes does in my opinion not scale well. You'd need to create artwork for all combinations, which would take more and more work with every enemy or outfit there already is ingame. Maybe I'm totally wrong here and you are doing it differently. If, however, this is something you thought about, I would really like to hear your opinion or experiences. Do you think this is easily manageable, especially if the game gets a bigger variety of enemies/outfits? Edit/ Thanks for the detailed reply. Not only was it very informative for me to know how you guys handle it, but I also am glad to hear that this is not such a deal as I initially thought.
Alastair Crowley
I'm glad I've evened out in terms of income, because this is the sort of post that originally got me to pledge to you guys. I love seeing the development perspective and hearing about the background processes, even when I don't necessarily understand all of the jargon or context. I'm not much of a programmer or artist or developer myself, but I am a huge nerd when it comes to seeing systems come together. It's fascinating to me to read about all the little things you guys do to make your work easier. Keep up the good work!
Wuumaster
Glad to see it all come through the Patreon pipe. Hopefully all these workflow optimisations lead to quicker content releases! Here's hoping you nail the battle system changes relatively quickly - it's an important system and deserves as much time as you can throw at it, but hopefully it doesn't get bogged down anywhere.
