eromancer
patreon
Inner Circle Update for January 10 2019!
🕑 Added 2019-01-11 02:28:41 +0000 UTC
Hey guys!
Now that the holiday stuff and Patreon page update is out of the way, I’m back to making steady progress on artwork. We have some previews of the first Splicer Thug H artwork (horray), as well as progress on the boss poses, Splicer animation, and the underpass map. I’ve been trying to trim down our posts and not go too deep into the tech stuff, but we’ve had a lot of requests for an update on the MATM engine, so I bugged APL and he put together a post that summarizes the work he’s been doing :D.
Boss Artwork
Even though this guy is way more detailed than our first enemy, he’s coming along a lot more quickly due to us having a better grasp on how to layer elements for Spine. Limbo still has to go through and refine some lines and correct some perspective issues before we do shading, but overall, he’s looking great. Here's the full size version of the above image.
Boss Artwork Progress Full Size
H Artwork Preview
We're closing in on halfway finished with the frames we need for the first Onyx vs Splicer Thug H scene. Apologies for their unfinished state, but hopefully you enjoy the preview :D.
Stage 1-2 Map Progress
Ubercharge made a lot of progress on map stuff this week. He’s discovered some better ways to manipulate the geometry into our game perspective that have sped up the process, as seen in the foreground for this map. He also found the magic bullet for helping us pull off maps with realistic perspective by way of linking multiple cameras so their FOVs line up virtually seamlessly. This will enable us to render big scenes like the boss map in chunks as opposed to needing a render farm or something ridiculous.
Here are a couple screens I captured from the new map, as well as the full map preview (25 MB, so slow internet beware).
Animation Progress
So, just to remind everyone, what you saw in the latest Pure Onyx release isn’t an example of the final animations. The actual animations will be more dynamic, readable, and detailed. This is illustrated in the above comparison! Kitsune had to go out of town early this month, but she was able knock out the punch animations for the Splicer Thug. I made a little comparison showing one from the last release on top, which is entirely generated by Spine’s automated animation blending. The one on the bottom is the completed animation.
As far as H stuff goes, we’ll be working on animating it as soon as we get Onyx’s moveset pose artwork consistent and broken down and rigged in Spine (we did the Splicer first since he’s a simpler character and easier to learn with). This will be a major task this month, so we’ll definitely still be working on it by the next IC update.
APL’s URGE Engine Update!
Hey guys, long time no see ^^. After few months of no progress updates from me, Ero finally decided to post update of my work on MATM and URGE. Problem is that going into details with every single thing I did would take pages and pages of text and nobody would want to read it... not to mention writing it ;). On the other hand, chosen bullet-point approach doesn't give enough info and I think it diminishes the work I've done since you've last heard from me, especially since December is always extremely busy month for me, which results in little time for work like mine.
Not counting some bug fixing, and some other more or less minor stuff, most of the work on URGE was spent on learning and coding shaders and stuff related to them. Since it was something I was doing as a break from Ruby coding, I was using separate application, and even though everything seems to be working, I still need to actually implement all the new stuff in URGE. Here's the break-down:
- Designed and prototyped custom shader structure and a cost-efficient functions to switching them in URGE;
- Coded Gaussian blur shader - compatibility with RM and probably some custom stuff as well
- Coded outline shader - was meant for text, but can be probably used for many other things, like the new UI Ero started showing some time ago
- Coded universal text shader - custom effects (simple shadow or outline), color for text and effect, and matrix shearing for italicization, which is broken in underlying library;
- Experimented a bit more with text shader - it will make things more complicated, but it is possible to use gradients and even more crazy ways to color the text and the outline (separately of course);
- Coded wave shader, which was a sprite functionality from RM I wasn't able to figure out last time I tried - I did it mostly to gain experience than to improve compatibility with RM, but I think it will be useful down the road;
- Coded shader for map-based transitions (map as in image containing opacity values);
- Thought about and considered coding some kind of shader interface for Ruby side of the engine, but initial research revealed it would take too much time, and since we have access to engine's C source, we can get by without it.
Rest of the time since my last update I've spent on Ruby code closer to the game. I was supposed to stick to bullet points, but I think the biggest time sink deserves some explanations. Let's get other Ruby stuff out of the way though:
- Overhauled game options structures and handling - adding new or changing old options is now a breeze, which will be nice when I start adding them;
- Overhauled options screen - thanks to the changes above it's pretty much automatic now - just add an option symbol to the respective list, and screen code will do the rest;
- Coded interface between C and Ruby for passing controls mappings;
- Coded parsing controls mappings to and from string for ini saving and loading;
- Considered coding controls mappings configuration screen, but in the end I decided to leave it for later, since in-game windows have an overhaul planned sooner or later and in case of this screen it would be a major pain to (re)do - emergency mappings changes may be done directly in ini now, so it should lessen the blow;
Aforementioned biggest time sink is something I should probably do a long time ago... it would certainly save me some grief now. As some of you may know, RPG Maker uses exactly the same database for editor and the game itself, which results in a lot of issues. Most important one is that most of the game database data is in a form better suited for the editor, and not the game as it should, so there's a lot of unnecessary processing during the game itself. I've implemented pre-processing of such data a long time ago, which pretty much removes all the editor-only stuff and optimizes the rest, so that the data used by the game is as ready to use as possible, which in some places made a really huge performance difference. I made one mistake though that now comes back to haunt me - instead of making my own classes for use in-game, I've been adding, removing, and changing stuff inside vanilla database classes and objects. Another issue with this is that some things are all over the place, which makes me and my IDE confused. Since we need to yank original classes out for URGE anyway, I've started the conversion of built-in database structures to the custom classes which will be used only by the game. Everything will be in one place, variables and values purpose will be much cleaner and clearer, and things will be optimized as I process them.
All in all, 41 out of 45 database classes were processed - either converted with optional notes about their future, or replaced with something more suited for the task. Remaining 4 classes are related to items and skills, since they are extremely convoluted and some parts depend on other stuff I still need to figure out, so I don't want to process them twice. Listing all of the changes would be too long and pointless, so I will just mention three a bit similar things that made a lot of difference in code's speed and maintainability.
First one was something I wanted to do for a long time and was always annoying me in the RPG Maker Editor. Hard to explain it to someone who hasn't had any contact with RPG Maker editor, but in most of the places in the editor, where something has to be conditioned based on something in the game, those conditional options are very limited and I had to make some nasty hacks to make things work how we wanted them to. My idea was to implement something I call unified conditionals, which in a nutshell is an expandable set of conditionals that can be used to replace and/or extend editor's limited set for a given purpose. Beauty of it is that adding new conditionals is very easy, so it will save us a lot of problems later.
Remaining two were done in a similar way and are both related to how various command lists (map/battle event or forced move progression) are handled. All such lists are completely converted to something completely different than original, and all the necessary processing is performed during development and not in the game itself. And again, adding new or modifying existing commands is now pretty easy, and I'm sure it will be used a lot.
My next and current task was kinda triggered by the move route conversion mentioned above. Long story short, characters' and objects' positions on map are done in a really weird way, and my previous meddling with it only slightly alleviated that problem... and added some new problems as well. After thinking about it, I decided to do something that was long time coming, and it's as big, if not bigger, as battle engine overhaul - map overhaul. Thankfully, a lot of stuff I did previously will make some things a lot easier, but there's still a ton of stuff to do - positions, movement, collision, activation, camera, and many, many more. I'm still compiling design document for this overhaul, and trying to figure out some stuff that eludes me, so I don't want to go into details. Hopefully I will have some good news next time Ero decides to post my update ;).
Have a Happy New Year guys, APL out.
Comments
Jade Golem
Are the splicers going to have group sex with Onyx?
Yup, our first release with H content will be next month
Is this game sex/nudity heavily featured ?
MangoFishSocks
The scope of the project is definitely something that should be on the forefront of every decision made.
Venus
Have to agree with the above. MatM handled this really well, though technically another game that Ero is making. If you get grabbed you've messed up and should be punished for it. But in MatM it didn't reward you with a instant banging, instead you had the opportunity to play a mini game (which should be harder) were you fight to break free. Yes there are other titles that do this bu MatM included multiple phases that gradually teased/taunted you and finally punished you with a H-scene and a lengthy stun as enemies continued to damage you. i.e. the level of punishment was also baked in. This system built tension and made for some real sexiness! The problem I personally have with this request is its asking for 3x more renders (perhaps even animations) that require quiet a bit of work. I personally, really want the team to focus on MatM as soon as possible. Hell, what am I saying more sex scenes, but I'm just insatiable when it comes the H content that this title drops!
Not your bussines
Heimwerk sounds ok to my austrian ears. If you want to the correct german translation to handyman it would be Handwerker. But i would keep Heimwerk has a nice ring to it.
MangoFishSocks
I agree wholeheartedly with transitions like her shorts being pulled down. That's at least 1/3 of the quality of the animations, IMO, maybe even creeping towards half of it. One of the best parts about the H system in MatM is the progression, both in the scenes themselves and with the lust meter. The visuals just keep getting more and more gorgeous too. The stretchy Splicer torso looks a bit odd, though. The MatM update is highly appreciated, even with the work being fairly dry.
MangoFishSocks
Words of wisdom.
I'm at a PC now. Seriously though, fuck the Patreon mobile app :X. EDIT: Also, if Heimwerk doesn't work out, maybe we'll just name him Wraxe :D. Tried saying that in initial response >_>
Ero says suggestions like this are good, we're still figuring out how to best for transitions and what not for H stuff.
PhatsM
With that H preview let me just say that I hope you guys include an animation of her shorts being pulled down instead of them just suddenly being around her thighs. It's the little things, nah mean? ^_^
AltairPL
Ero says he's thinking of naming him Heimwerk, as a play on Handyman in German. But he needs to double check that it doesn't sound stupid to Germans >_>. Also, Ero says fuck the Patreon mobile app :D.
Can't reply on my phone >_<. a="" be="" but="" check="" considering="" doesn="" double="" german.="" guy="" handyman.="" heh.="" heimwerk="" him="" i="" in="" it="" just="" maybe="" meant="" name="" naming="" on="" play="" should="" sound="" stupid="" that="" the="" to="" wanna="" wraxe="">
You know, come to think about it, even if you kept the boss's name to "Splicer Wrench-Axe Guy" it would make for a bit of light humour... Like you know how in SimCity, some buildings (if you zoom in down to street level) you see the shops/factories given literal names. Just an idea lol
