Inner Circle Update for May 10 2017! (Patreon)
Content
Hey everyone!
Apologies for being a bit late on the update! We did some testing today that I wanted to include the results from. Enough chatter though, I'm going to get right into it this week!
Story Progress
I’m beginning to feel relief here! I’m well into the second half of the story summary write-up and I’m pretty sure at this point that the pieces fit! The summary contains a huge mess of updates and edits that I simply didn’t have time to write into the more detailed story outline, so seeing it all work out is great. There are a couple of story arcs I haven’t fully explored that I’d like to as I write the last chapters of the summary, so hopefully those go well too. It’s also worth noting that the main story has (so far) grown from the 20 sub-chapters shown off previously to 25.
Something I’d like to share with you is the current idea for the introduction text when starting a new game, which you can find in the image above. It’s not really a spoiler since, well, you’re going to see it at the beginning of the final game.
Clearly, this is a whole lot of information that hasn’t made an appearance in the playable versions yet. Also relevant is that contrary to the plan awhile back, it’s likely that the Access Tunnels section won’t be the immediate start of the game.
Oh, and consider “First Contact” a placeholder name… I can see Star Trek execs at my door already.
On the Subject of Animations…
First off, nobody get too excited 😲! But, as part of the upcoming artwork overhaul, I’m really investigating the plausibility of adding character portrait and H animations to battle. There are a lot of things that need to work out in order for this to even be technically viable, so don’t get your hopes up yet! However, since this is by far the most requested feature for the game I think it should be fully explored. And, since I spent the last couple of days racking my brain over it, I figured I’d talk about it some here.
Basically, the following things need to happen before we can even consider character portrait animations in battle:
1. We need to guarantee that the game can load the animations without lag, without long loading times, and without a ridiculous overhead RAM expense.
This may sound like an easy thing, but when you look at how we have to do the animations it becomes a more challenging task. A lot of times 2D animations for large scale graphics in games are done using 2D armatures that rotate/scale. This would be an impractical process for us, and would be especially goofy since we’re using 3D to create our art. The benefit of it however is that it takes very few (if not one) images to make an animation. Since we use pre-rendered art, we would use spritesheets, and since we intend on upgrading to HD this means that these will be some big freakin’ graphics.
After a day of testing with APL I’m somewhat optimistic, however some compromises may be required. We’re pretty sure we’ve come up with a solid method for avoiding load times and lag through means of smart caching, however RAM usage may still be a problem. The biggest issue is that we need all the basic battle poses available on the fly, meaning the character’s full set of basic pose animations for their current outfit’s exposure/armor damage states must be cached (big RAM overhead). There’s a chance that this can be avoided if we get the load times low enough to where there will be no lag when dynamically loading a sheet. One way to accomplish this would be to make some compromises with regard to the number of frames for some or all of the basic battle pose animations. Ultimately however, it’s the H animations that are the most important, and I’m happy to say I think those should be technically viable using the aforementioned caching method.
2. All armor damage needs to be done in 3D as opposed to painted in post.
Quite simply, there’s no way I’m hand painting and manually animating armor damage for X frames for every piece of artwork 😲. It’s simply not viable. We’ve been experimenting with solutions for this for quite a while, and the only plausible ones we’ve found aren’t easy. While we’ve been able to accomplish this with Neon’s second outfit, the best example of our plight is Malise’s bodysuit. It will no doubt be an issue with other characters’ outfits down the road, so figuring out a solution for this one is an important first step.
After having TK run tests for about a week straight awhile back (I even mentioned this in a previous update), we’ve begun looking at changing Malise’s base body from Poser’s Victoria 4 (V4) to Daz’s much newer Genesis 3 (G3). When I started working on the game I chose V4 because it had by far the most licensable assets available for it. In this case however, the poor joint deformations really screw with what we are trying to do. We need our armor damage setups to look good in any pose, and so far that hasn’t been possible with V4. This is especially true when posing around the pelvis area. I made a bunch of comparison test videos yesterday and it’s pretty clear that Genesis 3’s superior geometry deforms much more naturally when bending (the fact that G3’s butt cheek isn’t halfway down her thigh after bending summarizes this pretty clearly).
I also did some tests with displacement maps in order to replicate the hentai-esque skin bulging effect that I hand paint . It worked well on Neon’s chest, but that was pretty easy since her boobs (thankfully) don’t have joints. Ultimately, TK’s solution would mean using displacement maps could be avoided for obtaining this effect, however the tests still show that getting this behavior right in all possible poses is especially tough. It’s likely that the armor damage will need to be more, uh, extensive so as to get possible creases away from joints (as shown in the test images).
A third issue is the geometry of the current bodysuit. Since it’s not proper for what we need to do, TK would create a new bodysuit asset from scratch for Genesis 3 with geometry tailored to our requirements. All in all, this would be a big task, but since this outfit occupies a whole lot of screen time it’s arguably worth it even without the concept of battle animations looming.
3. I need an efficient way to animate painted liquid effects for all the juicy goodness.
Last month I bought a Surface Book so that I can actually join digital artists in the 21st century. It’s pretty ridiculous that up until now I’ve used a mouse for all painting thus far, so this will no doubt improve the speed and quality of my painting. By far, the most time-consuming thing that I paint for this game’s artwork is the liquid effects. Unfortunately, these are something that will need to be animated in post no matter what. Since Photoshop doesn’t really have great tools for this I’m looking at learning After Effects. I’m pretty sure I’ll need to do this anyways in order to create battle FX animations for the new engine.
So, again I’ll mention all of the above is entirely to establish whether or not animations in battle are even technically viable. There’s still a lot of work to be done to answer that, but I can at least say “maybe” for now 😃, which is a whole lot better than I could have said before.