eromancer
patreon
December Progress Update!
🕑 Added 2017-12-10 03:35:20 +0000 UTC Hey everyone!We have a lot to report on our progress with the art overhaul this month. A lot of groundwork has been made in terms of getting battle ready as well as developing a procedural environment and workflow for fluid simulation (for H scenes and whatever else), To top it off, I have new genitals and nipple grafts working with our character bodies. We’re at the point where you can begin to see it all coming together in the update video, and can probably start to get a gist of what v0.06 will look like.
Before I get started I wanted to shout out to the $40 and $50 tier patrons to send me a message if you’d like one of the current print designs. Alternatively, if you’d like to wait for a new design (I’ll be making new designs using the new artwork style once things are finalized and we get closer to v0.06), please let me know that as well and I will make a note of it to message you once they are ready. Lastly, apologies if you’ve sent me a message in the last week or so and I haven’t gotten back to you – I’ve been troubleshooting these boobies hardcore to get this update ready and will be responding to my backlog within the next day!
Police Overhaul
The first thing TK and I did this month was knock out basically the entirety of the police enemy overhaul for the new art style. As I mentioned in some of my comments on the last monthly update thread, this guy will serve as our test enemy as we make adjustments to battle visuals for the new style. You can check out the high res images of our work here:
This guy posed a few challenges, and may yet require some more work. We had created the original version of him at the end of last year, and at the time I was experimenting with the first iteration of the Genesis body system. I had originally intended to convert him over to Genesis 3, but at this point I’m not sure it’s necessary (I think he looks pretty good :D). That said, if we make the move over to Maya later we will probably need to convert him at that point, but even so it should only take a couple of days.
The biggest issue we had with him was probably the helmet. It looked okay with our old style, but upon making physically based materials for it I realized how bad the geometry was. TK put probably three days into redoing the geometry topology, as well as improving the UVs and adding bevels for realistic corners. The result is pretty huge improvement!
Another thing we’ve considered is dirtying him up to add to the realism. I really liked the look of the judges’ armor in the 2012 Dredd movie, so I was using that as a reference when discussing it with TK. He’s made a bunch of dirt and damage textures for the helmet and baton in Substance Designer, but I’ve yet to merge them into the existing textures. Not sure if we want to take the time to add it to the entire outfit, as it’d take us a couple of days.
Assuming we don’t take on any of the above, the only thing left aside from some rigging issues with his pants is to create his “exposed” version. I should be able to use the new Genesis 3 genitalia I picked up for the Corruptor (even with his Genesis 1 version), so that should go smoothly.
Malise Progress Update
In a perfect world Malise would have been finished when we showed her off last month, but alas, she’s a complex lass :o. That being said, what’s been done this month and has yet to be done is largely groundwork for the revised character art workflow for the new art style.
The first major accomplishment this month was succeeding in pose conversion from the old Victoria 4 character body type to the new Genesis 3 body. All of Malise’s old poses need to be converted to the new body. The good news is that I now have a working system for doing so, and have already completed half the steps for all of Malise’s poses. The bad news is the remaining steps require manual edits, but it’s probably for the best since I get to give all the poses a bit of attention and correct any weirdness. From this example image you can see hair and facial expressions aren’t automatically converted, but I at least was able to fix the issue with positioning shown here.
Accomplishment number two is that TK’s morphs and rigging for Malise’s suit are finally done! By morphs, I mean that we now have the unzipped and “wide-open” versions of Malise’s suit working perfectly. This was a big stepping stone for further clothing development, as this is the first full outfit we’ve rigged and created a joint correction/morph set for from scratch in Maya/Daz. Not only is it rigged way better than the old suit, but it also responds correctly to breast movement (meaning far fewer manual corrections will be necessary). Here are the high res shots from the video that were meant to show this stuff off:
Also shown in the above image is the reason I took approximately an extra week getting this update posted: new nipples! These new nips are what’s called grafts; basically, extensions to the Genesis 3 body. Not only are they fully poseable and provide for a ton of different shapes (all of which are better than the amorphous lumps that Daz’s bodies have for nipples), but they allow for fun stuff like nipple penetration! Unfortunately, Malise has such a unique character shape that I had to work for three days with the asset creator to improve compatibility and overcome some challenges, then another two days on my own of making the fixes. The good news is I now know how to add them to any character. Perhaps more importantly, we now have excellent genitals for Genesis 3 females that are far easier to work with than the ones for the previous bodies :D. Regrettably, I didn’t have time to perfect the look yet for Malise’s, so I’ll show it off next time ;(.
The last thing to report is that Uber has revamped the revamp of Malise’s gun in order to dramatically reduce the polycount (while retaining the quality). Due to an issue with how Daz processes geometry, it was impossible to get the old model to behave properly without being ridiculously high poly. Since we’ll be using the gun model a crap ton, it made sense to attempt to resolve the issue now. To achieve this, Uber actually learned the basics of how to develop game-ready low poly assets (for real time 3D game engines like Unreal / Unity) from existing high-resolution assets (CAD models, movie assets, or most of the assets we use).
AltairPL’s Programming Progress Update
November was extremely boring and taxing for me. The reason for it is simple – the majority of it was spent on battle engine testing/fixing. You have no idea how tedious this process is... especially if there's an issue requiring specific conditions to rear its ugly head... ugh. That said, most critical and problematic issues were resolved. Not counting one possible crash in certain conditions, the remaining issues are more or less minor. Since nobody but me knew about those bugs and the prior battle engine state, listing them would be kinda pointless.
Some of you probably want to ask: "why the hell testing battle engine takes so much time?", which is a fair question. To answer it, I need to go a bit in depth of how the new battle engine works. It probably was mentioned in passing, but it was probably pretty vague and a long time ago, so a refresher won't hurt. The current battle engine iteration is much more advanced than previous one... some parts of it were simplified, but most of it became a lot more complex. In the end, however, the new version is much more manageable and customizable then previous one. I shit you not.
The first major change was the battle time flow overhaul. Previous MATM versions had a few time modes, which were implemented to allow players some level of customization, and in turn make the game more accessible to people not into games requiring high reflexes and dexterity. The idea was good, but the difficulty gap between some of those modes was pretty big, without anything in between. Also, the way it was made prevented us from easy expansion if needed. The new system is a bit similar to the old, but a few boolean flags representing battle situations where time flow should be paused were replaced with time flow speed multipliers. This means that the player will have better control over how battles are played. For example, there’s now a multiplier value that determines battle speed when a character is waiting for action input:
- 0%: time flow paused - same as "Wait for input" or "Wait for input and action" in previous system.
- 100%: time flow unchanged - same as "No wait" or "Wait for action" in previous system.
- 1-99%: respective in-between speed value - not attainable in old system.
On top of that, the new system also allows for changing the base battle time flow multiplier, which can be set to value between 50% and 150%. So now no matter whether the default speed was to your liking, was too slow, or was too fast, you should be able to make battles more enjoyable for yourself.
The time flow overhaul also allowed us to unify how escape and manual struggle works. Also, the latter is no longer restricted to any time flow modes. If the player triggers escape or manual struggle, all multipliers but the base speed are ignored and battle time progresses at normal speed while escape/struggle is active. The same thing applies to the SHIFT key, which was, in previous versions, used to force time to pass in a situation where time was stopped.
Now for the fun part. Someone suggested it around v0.05, and my answer then was something like "I would love to, but I'm too inexperienced to do this at this time". When I started planning/implementing battle time flow overhaul, however, it started bothering me and I even started considering it as possibility. What is it? You need to be patient for a little while, because I need to go back to MATM's RM (RPG Maker) roots first... you should figure it out pretty quickly, though.
So, vanilla RM battles are entirely turn based; every turn, all battle participants perform their actions based on stat-based order... rinse and repeat. This approach is very simplistic and very limiting, e.g. if enemy is two times faster than PC (player character), it should be able to perform twice in the same time PC can perform once. This assumption became the base of first MATM battle engine (before my time), but even though much better than RM version, it still had one of its major limitations: only one action could be performed at any given moment. We needed a battle engine capable of real-time/full action concurrency. To put it more simply, battle participants can now perform actions at the same time (here are some images showing just that). This is the main reason why so much time was spent on the battle engine overhaul before URGE development, and why so much time is needed to test/fix it now. Thankfully, the battle time flow overhaul simplified some things in the battle flow itself, so changes to it needed by full concurrency were relatively small. On top of it, however, a lot of existing structures had to be modified, including some rewritten almost from scratch, and a few new structures had to be implemented. Even without full concurrency, MATM's battle engine was extremely complicated, so it was a lot of hard work to make everything play nice with this new addition. It was a long road already, and there's still a long road ahead, but I'm really proud of what I've achieved so far and it's already paying off. I'd say that 90% of full concurrency stuff is implemented, but the remaining stuff is not as important as stuff already done. It's still hard to say if and when full concurrency will find its way into MATM releases, but considering how the battle engine is structured now, the more stable full concurrency is, the more stable the non-concurrent mode becomes.
The hold/grapple system is now the least advanced and most problematic battle engine sub-system. It needs an overhaul as well, but not everything related to it is properly planned and I have no idea if I'll manage to squeeze it in v0.06.
Back to the current update. Around the last IC update I had to take a break from battle engine testing. While fixing battle stuff, I've noticed how shitty some aspects of battle sprites display are. Well, they were working, but my paranoid obsession with performance (in RPG Maker, every bit of performance counts) made me do some things in a very hard to read and maintain way. I've been playing around with custom sprite class and in the process I've managed to improve their functionality and readability a lot while maintaining basically the same level of performance. With URGE on the horizon, I'll probably have to revisit some other similar pieces of code and restructure them to make them more manageable and readable as well... for the sake of my sanity at least.
Battle and Portrait Lighting
One of the major things that was bugging me at the beginning of the month was how we intended to make the character portraits and enemy sprites look good in battle. We learned when we had to create a new sprite lighting system for map sprites that the new art style demands that things be lit properly else they look completely out of the scene-- obviously not a good thing at all for pre-rendered graphics. Unfortunately, a system like our map sprite lighting system won’t work with portraits or enemy battle sprites; they’re just too detailed and faking it would look bad.
Well, APL and I spent half a day discussing it and we’ve decided to pull the trigger on an idea of mine. The solution is very low tech, but will look great. Basically, we intend to expand the sprite versioning system we started using back in v0.03 (originally a system for making the map sprites fit with the color of the maps) to enemy battle sprites and character portraits. What this means is that for each different environment, there will be an appropriately lit version of necessary character portraits or enemy battle sprites. I made a few basic examples just to give an idea of what I’m talking about (see the battle mock-up section below for an example of what it may actually look like in battle):
Shitty Character Portrait Lighting Examples (not actual in-game environments)
Shitty Enemy Battle Sprite Lighting Example 1
Shitty Enemy Battle Sprite Lighting Example 2
The good news about this method is that It won’t tax system resources in any way over what we already have… oooother than hard drive space, which it will consume a lot of. To counter this, we’ve decided to use a PNG compression plugin that we scoped out awhile back (I think I even showed some results from it). The visual quality loss is really minimal (only really noticeable on smooth gradients), but the disk space savings are fantastic. Here’s a set of example images: Uncompressed, and Compressed. The compressed version is 70% smaller, and I personally can’t tell the difference without zooming in. Even with this however, I still think MATM will have the largest file size of any H game once it’s completed (potentially up to 15 GB).
This does lead to some bad news, however at the same time it’s kind of a weight off my chest. We’ve basically been scrounging for resources to poooossibly, maaaybe one day be able to do animated portraits in battle. Given the above, I simply don’t think it’s realistic with a pre-rendered game of this size, so I’ve officially decided we won’t pursue that route. Honestly though, this is as much a production decision as it is a technical decision (we’d simply need more people to even consider pulling that off). Instead, we’ll use those resources to make what we’ve done all along look amazing.
Obviously, all these versions of portraits/sprites will require a lot of rendering. Luckily, that won’t really add a lot of work. Since we don’t have to post-process our renders anymore I can create a relatively simple lighting rig and rendering automation system and let it go to town (which I’ve already started working on, and you can read about in the next section). The downside (of course there has to be one), is that we really can’t do much post-processing if we need to since we’d have to do it like five or even ten or more times to fit with the various lighting situations. What’s that mean? Well, for one we can’t paint all our juicy liquids by hand, since fluids look way different under different lighting conditions. Therefore, I’ve tasked Ubercharge with developing our 3D liquid simulation system early so that we can use it for v0.06. You can read about our progress there in the last section of this update!
Battle Mock-Up and Art Workflow
Above is the mock-up battle image I’ve worked on over the past week. This is very likely what v0.06 will look like in every aspect (minus the fact that it’s in 1080p… v0.06 will be in 720p).
I’ve made a small gallery to give some details about the changes you see in the image, as well as how our workflow has to change and potential improvements we are considering for down the line.
A big thing I was worried about was whether the user interface would mesh with the new art style, largely due to the UI being kind of cartoony. While I can’t say it fits great, I think it will actually be okay for v0.06. We don’t have the money to right now, but I’d really like to hire a legitimate UI designer to help improve the aesthetics of it to better match with the new look of the game. Besides, it would make more sense to do this once we’re in the new engine, have a better grasp of what we can do with shaders, and are looking more closely at 1080p graphics.
One last thing I want to bring up is that while it’s important for us to get v0.06 out soon, I want to remind everyone that it’s important we get this foundation correct for smooth sailing once we start pumping out content again. We had a lot of inconsistencies with battle artwork in the previous style that were bound to create issues later, and I don’t want that happening here.
Fluid Simulation
To start off here, you’ll find a short example in the video above showing our fluid simulation working in Houdini (actual simulation time was about 5-10 minutes… this is playing back a cached version). We’re finally to the point with our simulation and processing workflow where we can begin integrating it into the new art style. (check here for a full resolution version of the finished Malise test from the video)!
After pulling the trigger on scene-specific lighting for battle, we had decided we needed to put maximum priority on getting 3D liquid working in order to have it for battle portraits for v0.06. One of Ubercharge’s primary goals this month has been to create a procedural system and workflow that will allow us to, as simply as possible, pop a scene from Daz or Maya into Houdini and start spraying buckets o' jizz errywhere.
Houdini is a node-based program for procedural generation of 3D geometry and effects. Fluids, smoke, and explosions are some popular uses, but it's a very extensive and flexible program. I've also spent a lot of time this week learning as much as I can, not only because I'll be the one using Uber's system, but because I intend to create battle FX animations (skill / damage FX, etc.) for the new art style using it. TK, Uber, and I have a huge video tutorial course we're plowing through, but the fluid stuff has proven to be our trial by fire.
There have been a number of challenges we had to overcome to get to this stage, and a few more on the horizon still to get it really good looking. The first was the jizz material, which after literally days of experimenting in different lighting situations and sending it back and forth Uber and I have it looking pretty good (it will no doubt be improved more over time). The second challenge was collision for the fluid simulation. Uber discovered that for proper behavior, the collision model needs to have actual volume (most clothes for characters are just planes, meaning they are infinitely thin). Currently we're fixing it on a case by case basis by extrusion, but an ideal solution would be to have a process for creating closed models similar to what's required for 3D printing. Daz has to rear its ugly head somewhere in everything we do, and here's no exception. We found a lovely little bug with the rendering engine where when a refractive object (like, pretty much every liquid) clips with another object you get nasty shadow artifacts. This is, of course, bad when you want to cover your characters in goop. Uber's solution was to add a boolean component to his liquid system that carves out the liquid geometry in the shape of the collision object, meaning liquid perfectly fits on top of whatever it's covering (and thus, no more clipping :D).
Here's the culmination of Uber's efforts so far, complete with a procedural bubble generation system! Please mind that there are still a bunch of experimental nodes and dead-ends in that diagram.
A couple of things that you aren't seeing in the example scene that we plan on improving upon are general wetness and stringy/drippy/elastic liquid. For the former, we are considering using an alternate set of "wet" materials for characters/clothes and using the render manager I made awhile back to simply pump out a wet and dry render when necessary, then blend between them in Photoshop (this is basically what I did with the old art style). For the latter, we decided that using actual elastic liquid simulation to get the drippy effects we want in some cases is simply way too time consuming. Not only does simulation time explode, but it's really tough to get right on the first (or first dozen) tries. Instead, Uber plans on modeling a set of shapes that we can simply merge into our simulated liquid meshes and easily edit to perfection. He created this test model in just a few minutes, which could easily be edited for use over and over when we need an effect like this.
That's about all I have to say about splooge for now :0.
What’s Next!?
For the immediate future I personally need to finish up with Genesis 3 genitals and continue working on the battle artwork workflow overhaul. Now that Malise’s suit and guns are finished (and once her genitals are), I’ll be able to start creating actual battle portraits. I’ll likely create a second battle background soon so that we can begin work implementing the battle lighting system (which I’ll need help from APL on, so whether he’s at a good stopping point with his work on battle will play a role in whether we get that done sooner or later). This system will also work for portraits on the map and in the menu, so we’ll knock that out at the same time. For this month, Uber is doing a sort of a concept art apprenticeship, so he’s only working on critical stuff until he finishes that up, and then he’ll likely be back to working on maps with TK. At some point I’ll also need to work with APL to make any necessary adjustments to the menu / ARIS scene for the new art style and remaining adjustments for the new aspect ratio. I’m absolutely positive I’m missing some stuff here, but once the remaining artwork overhaul related stuff is out of the way we can really make progress on finishing v0.06 content.
Comments
Carter Parks
By monthly update, does that mean that you should have v. 06 ready by February?
Unless you're primarily interested in getting news updates early it may not be worth it to you quite yet. We will begin making test releases with the new art style in January, but the first one will be for all patrons $3 and up since it will fall on the monthly update (hopefully). The support would absolutely help though :D.
CherryBlossomStorm
Thinking of becoming a $10/month member. Have any builds been posted to the inner-circle google drive? when was the last one posted?
I'll definitely try to set up multiple sources to download it from :D.
Freaken sweet
ZeashSkirata
in that case perhaps a torrent or something similar would be nice
DCLXVI
when the game is completed will we have to download from mega? the reason i ask is because when i try to download the art pdf which is 1GB it will take me 8-12 hours so i can only imagine how long 15GB will take.
Verdonator
Understood. Thanks for replying and keep up the good work!
Overhauling the Access Tunnels (and its enemies) will be a big job and will likely be its own version sometime after v0.06. Currently we're still trying to get the basic mechanics of the game overhauled for the new art style (main characters, battle poses, battle backgrounds and lighting, etc), so there's not much to release until that's done. After that we'll be be making a small test release featuring some battle (in the new art style) for the Inner Circle and will release it for $3 patrons in the monthly update that follows that release.
dd209
Don't touch those tiddies!
Verdonator
Could we get a playable version soon? Like one where the current map is overhauled? If it's possible, when would it be available? Sorry for being impatient, but your work looks so good it got me all hyped.
It's a hard choice deciding which body shape I like best when put side by side like that. I do like her new nipples better though.
There were a few big posts about story earlier this year when most of it was written. There's this thingy from earlier this year, which gives some hints: <a href="https://imgur.com/a/FedmV" rel="nofollow noopener" target="_blank">https://imgur.com/a/FedmV</a> There's also this, which will be the actual introduction text when you start a new game (not sure if I've shared this outside the Inner Circle group yet :o): <a href="https://i.imgur.com/nWWtvkQ.png" rel="nofollow noopener" target="_blank">https://i.imgur.com/nWWtvkQ.png</a>
Nice update, thanks. I'm looking forward to the point where you guys can get cranking on brand new playable content with the improved framework you've been working so hard on. The sudden Malise boob controversy is pretty funny--she looks amazing and well-proportioned to me. I might have missed this somewhere, but I'm kind of curious if there's an overarching plot/premise you can share without it spoiling the story?
For people that didn't like the boob size on the previous version I wouldn't really expect them to like the new version. But if you're worried thy grew since the new version was shown off I think it's just an illusion due to how that shot was set up. They are actually smaller than on the old version of Malise, but proportionally still pretty similar since the new one has a shorter torso and smaller rib cage. Here's some comparison shots with less exaggerated camera set ups / no perspective: <a href="https://i.imgur.com/M8m1Hca.jpg" rel="nofollow noopener" target="_blank">https://i.imgur.com/M8m1Hca.jpg</a>
For people that didn't like the boob size on the previous version I wouldn't really expect them to like the new version. But if you're worried thy grew since the new version was shown off I think it's just an illusion due to how that shot was set up. They are actually smaller than on the old version of Malise, but proportionally still pretty similar since the new one has a shorter torso and smaller rib cage. Here's some comparison shots with less exaggerated camera set ups / no perspective: <a href="https://i.imgur.com/M8m1Hca.jpg" rel="nofollow noopener" target="_blank">https://i.imgur.com/M8m1Hca.jpg</a>
Will definitely add it at some point. We aren't planning on having lines read or anything, just sound effects for H scenes and combat. Regarding sound effects we're more focused on replacing RPG Maker sounds since they can't be used when we go to the new engine (admittedly, this is really a good kick in the butt for us since most need to be improved). We've got a pretty big pile of interface sound effects and what not waiting to be tested out already.
Shriekykite
Don't mind the haters. Malise's boobs are perfect.
PhatsM
Slapping something together that too closely resembles previous builds after all this time would be an exceptionally bad idea for the MatM team to make. There are already quite a few ignorant and incredibly vocal critics who think this project has turned into some sort of scam so it really is in their best interests and in ours as fans to wait until they can release something that is entirely different. If people see the new release and it looks like an entirely different game it will bring in more fans, while a release that is all too familiar will leave people who have been outside of Patreon waiting to see something new incredibly disappointed. It would only increase the critical voice and hurt the project. After all this time, I don't want to see something that is "slapped together". I want to see the result of what each of these update posts teases.
Meldrich
As someone with a well-endowed girlfriend, I think she looks great!
Yeah, I think they should make her boobs smaller tbh. Tired of human cows in h games.
Faithel
Malise is soooooo much more pretty now mmmh !!! OMG. If i can say a comment, I find that Malise's boobs, especially her tits, are a bit too big. But that said. Your update is completely amazing. The fluid rendering that you showed is soo promising. I see the potential and what you'll be able to do with that ;) It's gonna be an amazing game ! GJ guys!
I dont want to be rude or anything but i think Malise's boobs are kinda over sized. Also will there be multiple outfits and H-content (for the same enemy) in 0.06? Mainly asking for Malise, since I've seen her with a Black Police-like outfit (on screenshots) but never managed to find it in game and Neon already has 2 (with her starting one). Anyway love the update and progress cant wait for 0.06 :D
AltairPL
Oh, no, no, no. You misunderstood me. Grapple system is still in the game and it's going nowhere. What I said I'm not sure I'll be able to squeeze in 0.06 is hold/grapple system overhaul, which will be needed, among other things, for double-teaming, which for various reasons will be used for things like handcuffs. Till hold/grapple is overhauled, handcuffs will be only a part of cop's H-chain. Sorry for confusion and hope this explanation clears things up.
Aronax243
Nice progress, but it would be sad if the grapple system could not make it to v 0.6. It make the battle so much more stimulating. Is the handcuff condition effect still a thing for the police? I hope so.
Justa Badge
Nipple penetration?! Yesssssssssssssssss
Battle animations are out but what about voice acting?
I love the work youre doing and the effort youre putting into this.. But i feel like youre trying to make this an AAA production. Which is great! Given the number of people you have financially supporting this, I believe we all want to see that become a reality. Developing your own engines and modifying graphics software certainly takes alot of time and effort.. But i find myself wanting to be able to play a bit more of the story.. Even if its in the older format. I feel like i want an update to the game that isnt nessicarily the absoloute perfection you are clearly trying to create here. Just.. Some playable update. Please.. I also would also like to see animation in H finishers for end release, even if it is only 5-15 frames.. It makes a huge difference. But really.. In the meantime, slap together a playable update. I was really disappointed when going up the elevator and it just ended.. I hoped i was going ro some town. See what the rest of the workd was like.. Report to my boss and slap that useless runaway robot around a little, as well as have access to shops!
Jon P
I'm with you: hopefully animation (in all possible forms) will make a triumphant return someday, it just adds a whole different level of immersion. Trading animation for super fantastic graphics and liquids like I've never seen are worth it I suppose.
Not one that I wanna say publicly because approximations always turn into promises on the internet :(. Hopefully in January though we'll have the artwork overhaul stuff sorted and be on easy Street with just content remaining. Stigmata needs a rework because I realized recently I had no idea what I was doing when I converted him to PBR. Ven needs converted to Genesis 3. I want to improve the female cop for the same reason Stigmata needs a revision. Splicers also are getting a redesign... Also the Syndicate guys. Lots of work left :(
Mav
Always look forward to your wall of text every month. Shame to hear we've lost all hope for animated H content in combat. Does that shut out H finishers as well? Still hope for animated cut scenes outside of combat? Either way, the overhaul is looking pretty impressive. Hope we see a new demo soon.
It's way easier for me to take a day and hammer out a book than it is to do it every few days. Personal preference probably :x but it helps orient my goals for the week/month.
Is there an approximate ETA on when .06 will land?
Renmaru
Man we don't hear from you guys very often but when we do at least we aren't left wanting for updates. Keep up the good work everything is looking beautiful so far :D
Yeah, hard drive space is the least offensive resource to abuse nowadays IMO. The only thing is if we want a mobile version at some point then 15 GB is really huge. That said, we could always use 720p for mobile if we had to. Well, whatever the equivalent would be for mobile.
Jon P
I agree with PhatsM, I'm happy with all the progress and more excited for v0.06 with every monthly update! I'd just like to add that for some folks (including me) our systems are more than capable of storing hundreds if not thousands of gigabytes, so 15GB is by no means a demanding filesize. Perhaps room could be left for an optional high-res patch for those of us with the space, power, and 4k screens to appreciate it? I know I would...
There will still be enemy animations :D. This is just referring to that idea of animating character portraits and battle H scenes.
PhatsM
Very impressive laundry list of changes. One thing I'd like to clarify: when you say no more animated battle portraits are you referring to the former idea to animate our heroines? Or do you mean that there will be no more animation at all, enemies included? I'm going to assume the former since in this post there was an animated portrait of the new cops.
