eromancer
patreon
March Progress Update!
🕑 Added 2017-03-01 20:24:05 +0000 UTCHey everyone!
There’s a whoooole lot of stuff to catch you up on since last month’s update. To be up front, V0.06 did not take the spotlight as was initially planned. While I’m certain this will disappoint some of you, we’ve made a ton of progress this month, and I think it’s for the better in the long term. That being said, you guys absolutely deserve a playable update as soon as possible, and trust me when I say I feel the heat to get it to you! To soften the blow, I’ve come with a bribe in the form of H artwork concepts :D. First though I need to make you suffer through pages of development related stuff!
Story and Development Notes Overhaul
It started innocently enough! My main goal for the first week of the month was to put together the remaining details for V0.06, with the end objective being a completed design document to use for the remainder of the cycle as I’ve done with the previous two major releases. I’d honestly been dreading this because the last major revision to the main story was at the beginning of last year, and I had compiled a crap ton of notes on the subject since then. So many in fact that it quickly became a bigger chore than I envisioned due to them being mixed in with other development notes. So, I took a step back and decided the first thing to do was to get organized.
While I had originally planned to just scour my notes for story content, I ended up merging and refining content from over 80 files down into a tagged and catalogued 22-page document (now 34 pages) that will be used from here on out to store and organize literally any development related note. This is something I’ve needed for a long time since I often get random ideas and have no way to properly organize them other than to create a separate note file (that I’ll never find again when I need it down the road). The way I’ve done this is I’ve created a tagging system in which I can search entries by general, predefined tags as opposed to content. This means notes and ideas don’t have to be stored in any specific order, and any content that falls into multiple categories can still easily be found since I can just tag it with multiple tags.
This new system has already paid off in huge ways, as having everything in one place has already allowed me to heavily refine some significant gameplay and mechanics changes that we have envisioned for post-V0.06 (not including what you’ll see later in this update). While these were relatively minor tangents, this whole process opened up Pandora’s Box when it came to the story. Revisiting and organizing all the story notes I had piled up gave me a week-long case of projectile vomiting awesome ideas on how to improve the story. I seriously couldn’t write fast enough. Basically, leaving it to marinate for a year was great, because I was then able to approach the rough draft that I had with a clear and critical outlook as opposed to the tunnel vision I developed when I banged it out originally.
When I began that process at what I think was the beginning of week #2 in Feburary, one of my first obstacles was remembering all of the critical details hiding in the then 32-page story document. One of the things that helped me to do this was to visually plot the story. While trying to think of how to properly do this, I remembered these xkcd comics from awhile back that showed visualizations for the plots of some popular movies.
Well, as it turns out, someone actually created an application called Plotweaver for generating these “narrative charts”. It took a day, but I hammered out one for Malise and the Machine. This was meant entirely for my reference, but I made you a relatively spoiler free version highlighting only the part you’ve played through (up to V0.05). It’s actually already severely outdated at this point, but it should at least show you the scale of the main story of the game. (It should go without saying, but in case there are misconceptions: the rest of the game is going to be completed at a faster rate than the early parts… so don’t be afraid of what’s left to go :D)
After working through it and being able to visually see the story with the chart, not only did the details come back to me quickly, but solutions to previous problems I had (as well as ways to improve weak points in general) started to become clear. Unfortunately, the solutions involved some major story surgery. At that point, I could have chosen to put off making these changes in order to get v0.06 out a couple of weeks sooner, but the obvious choice for me was to go ahead and get it done now so that there are no conflicts later. So, there’s my huge-ass explanation for working on story for two weeks straight. Unfortunately, without driving you straight to spoiler town I can’t elaborate too much, but I’m really excited by what I’ve done so far, and by extension I hope you’ll trust me that it will pay off.
Gameplay / Mechanics Changes
While I don’t want to spoil the story, there are a couple significant changes that have been motivated by the story rewrite that I can talk about. The biggest one is the likelihood of a third playable character :D. We’ve tossed around the concept since I wrote the original draft, but pulling the trigger on it allows for some of the major story changes that weren’t viable before.
A second thing I’ve been looking at is changing the way skills are tied to body armor/outfit. I went through a couple different ideas when overhauling this concept. The first idea was actually to tie skill loadouts to the character’s equipped weapon type instead of armor. This would alleviate an issue we were having with story segments where the lovely ladies are… indisposed. By that I of course mean we would be making battles a possibility during story events where the characters aren’t armed. I thought that tying all skills to weapon types would work, but it revealed another major problem due to future plans for characters to be able to switch between weapon types in battle (see #3 in the below list). I identified three distinct problems with the current relationship between armor types, weapon types, and actor skills.
- 1. The actors may be disarmed during some story scenes. Currently, combat while the characters are unarmed can’t really exist, thus it really limits what role combat can play in some story scenarios. This is especially disappointing since H content is so engrained in battle, and could make for some great interactive H events.
- 2. The actors may be forced into new outfits during some story scenes. Tying armor type to all skills means that all a character could do in combat in these situations is attack, guard, or use items since the character would have no skills equipped for the “non-combat” outfit type.
- 3. A balancing issue exists due to the concept of changing weapons in battle. A character could utilize the 4 extra glyph slots entirely for non-weapon based skills such as Reconstruct, which in my opinion is not only super strange but also hard to balance against without overcomplicating stuff.
I came up with two solutions. One is to remove the idea of changing weapon types in battle. This however simplifies my vision for combat down the line a lot (think of weapon types as how some games use “stances” … basically they offer different strengths/weaknesses for a given battle situation). This solution would also limit characters to a whopping grand total of four skills in battle at any given time. I like the other solution better, which adds a new layer of depth to the combat system. Here’s the rundown of proposed changes… it’s big and intimidating since it’s super detailed, but it’s actually quite simple since what we have now is sort of a stepping stone in this direction.
- Add an ‘Unarmed’ or ‘Fist’ weapon type for all characters. The game will default to this weapon type if the character has no weapon equipped.
- Separate skills into ‘Weapon’ and ‘Class’ skills. Weapon skills would be in the left position on the command tetrad, while Class skills would be in the down position. ‘Guard’ would essentially just become a ‘Class’ skill (available to every class), and could be swapped out if desired.
- The skills in the Weapon Skills tetrad would be entirely dependent on equipped weapon type. The ‘Weapon Skills’ icon would be different depending on the currently equipped weapon type. It would show a silhouette of the weapon type in front of a tetrad panel.
- Give armor/outfit types an associated Class that determines what skills can be equipped in the Class skills tetrad. Armor types would be colored based on the default Class they offer. Note that some skills can be compatible with multiple classes. This is, essentially, exactly what we have going on now, however identifying “class” as an independent feature from armor type would allow for the player to potentially change the class granted by a piece of armor through some process later in the game if they wanted to keep the visuals/H behavior of another armor type. This would also theoretically allow for a character to assume a class granted by another character’s armor types without the need for a literal shit ton of different artwork varieties.
- The class that an armor type assigns would be shown in the tooltip popup for the armor (these aren’t implemented yet… think Borderlands / virtually any MMO / Diablo). The character’s current class would be displayed in the Status menu, and would be identifiable based on the color of their Class Skills tetrad in battle / the Tetra menu.
- Give the Weapon Skills tetrad a neutral color for all characters. The Class Skills tetrad would assume a color based on the character’s current class.
- When a character is wearing an outfit (or lacking an outfit entirely) that does not offer a Class, the Class skills tetrad is inaccessible in battle.
- There may be an ‘Unarmed’ weapon skill for defending to mitigate the lack of a Guard skill, or Guard could simply replace the Class Skills glyph (down position on the command tetrad) when wearing a non-Class outfit.
- Consider adding passive skills directly into the Class and Weapon skills tetrads due to the number of extra glyph slots available with this idea. It was previously thought that there would need to be a separate menu for these so as to not take up space in the battle tetrads.
Since I assume that this solution will be implemented, I’ve gone through and re-written a lot of story scenes to make them more interactive by including battle situations where there previously couldn’t be any.
I want to mention that both of the above ideas weren’t really up for consideration a year ago because of how much busy work it took to render out and process a single character portrait. Because of the optimizations we made earlier in this cycle, additional weapon types and event-specific battle outfits are much more plausible now.
AltairPL’s New Experimental Engine
Your eyes aren’t tricking you! The goal of this experiment was initially to remove as much reliance on RPG Maker as possible, and to replace it with more modern libraries for video, memory management, input and so forth. AltairPL began experimenting with this concept a few months ago and has been working on it intermittently since then. It has since developed into the possibility of an entirely proprietary engine. Obviously, this is exactly as complicated as it sounds, so keep in mind that this is a long-term goal and not something to expect any time soon. That said, there have been some amazing early results that merit sharing. To guard against misconceptions though, I’ll say that the awesome features mentioned below aren’t promises, but for now are simply possibilities we are working toward.
It's probably no surprise by now that the game has been growing out of its skin. The primary reason we’re looking at this now however is that RPG Maker has some problems that will require significant work to get around for a project the size of Malise and the Machine. Secondarily, our access to things like video, audio, input and how we package the data are all heavily limited. Therefore, since reason #1 means a lot of work has to eventually be done anyways, we’ve been looking at alternatives that will not only solve these problems but also provide other benefits such as performance and improved visuals.
What’s grabbed our attention is a library called SDL_gpu, which is an open source library for high performance, modern 2D graphics that utilizes OpenGL and is based/dependent on SDL. The most obvious benefit here is that it’s hardware accelerated, meaning it actually makes use of your graphics card as opposed to only the CPU. What other benefits could possibly merit such a big change? Here are just a few off the top of my head (this is the part where you shouldn’t get too excited too soon… but that won’t keep me from doing so anyways):
- HD resolution
- Variable aspect ratio (widescreen, yay)
- Customizable resolution settings
- Fully configurable key/button mapping for controls
- More freedom in how we implement things
- Native builds for Linux, OSX, and with time probably many more (e.g. Android, iOS, etc.) – no web bullshit like RPG Maker MV is using.
- The possibility to use advanced shaders and visual effects
- 64-bit version
Now for the fun part! During the third week of February, AltairPL actually got the game running using the aforementioned SDL_gpu graphics library. I personally wasn’t expecting this to happen for some time, but since it has we’ve been able to run a whole set of performance comparison tests. The results are, in short, extremely promising, and in my opinion completely validate the effort required to carry this experiment to completion. I’d like to share some of those results with you :D. These tests were performed on APL’s computer, which has the following specs:
- AMD Phenom II X6 1090T 3.2 GHz
- 8 GB RAM
- Radeon HD5970 2GB Graphics Card
Here are the frame-per-second results for basic image rendering:
SDL/GPU (new graphics library):
- 4 images – 1550 FPS
- 53 images – 555 FPS
- 277 images – 200 FPS
RPG Maker:
- 4 images – 110 FPS
- 53 images – 36 FPS
- 277 images – 26 FPS
Ten to fifteen times better performance! Obviously, the graphics card acceleration is a big help. Here are results for a basic test pertaining to rendering the largest map we currently have in the game (the containment pen):
4 basic images + 2 Containment Pen parallax images
- SDL: 1220 FPS / 109.8 MB RAM
- RM: 74 FPS / 159.8 MB RAM
Loading time of those 6 files:
- SDL: 2.207126 seconds
- RM: 4.152238 seconds
From this we can see that the new graphics library also shows significantly improved RAM usage and much fast loading times for big images like maps.
The above results are from simple rendering tests; however, I’ve taken some screenshots showing the performance of the actual game running. We consistently experienced a 4-5x performance gain throughout all scenes we tested. Keep in mind that even though basic rendering works, there are a lot of things that don’t yet, so text and windows aren’t displayed. Also, positioning is off for some objects. You can see the FPS in the top left corner of each screenshot.
- Title (1024x768)
- Title (1080p)
- Menu
- Battle
The big takeaway here is that performance will virtually be a non-issue after this is complete. Not shown are some other tests we did with 1080p, all of which showed a similar drop in FPS (only 25-30%), meaning that the possibility of HD in the future will not be restricted by performance. We’re obviously really happy with these results, but there’s a deceptively long way to go to make the switch happen. Currently APL is investigating ways to simplify the interfacing between Ruby and C, which has been causing him a lot of uh, mental trauma.
By the way, I want to point out that this switch will in no way diminish the work done up to this point in RPG Maker. The Ruby code and databases for the game itself will still be used, so virtually all of the work that had been done on optimizing performance will directly carry over. As far as artwork is concerned, I've been rendering almost everything in high resolution all along, so we have that as well.
Artwork Progress
We’re finally to the fun stuff!
If you remember, last month’s update had us finishing up some test maps for V0.06. TK was hard at work at the beginning of the month figuring out and putting together the render setup for the new environments. It took a full day of testing on his part to figure out the new render setup process, as we are now doing shadows and lighting somewhat differently (even from the recently completed Access Tunnel revamp maps). I was able to sneak in some time to do a test run for processing the shop area map, and I’m incredibly pleased with the results. It almost looks like we know what we’re doing now!
Since APL and I have since been working on other things, TK plowed ahead and started creating tilesets for future maps that we will need down the road. You can check out his progress here!
The last few days of the month however I spent entirely on making some concept poses for skills for the Police enemies.
March Goals
I still have a few key topics I want to flesh out with the story overhaul, but after that we will be hitting V0.06 harder than ever. AltairPL finished up the majority of his work on the battle overhaul early this month, so he’s in a really good position for v0.06 and will likely be continuing his efforts on the new engine. Audio guy has been focusing on sound effects the past few weeks, which is more important than ever since a new engine will mean we can no longer use RPG Maker stock sounds (this is no skin off my nose though, since I know we can do better).
As always, thanks for your continued support!
Comments
great idea!
lolred
Handcuffs. Hawt.
stormbunny
Hi, a suggestion for the H-attack progression: thematically, I think it would fit better and I'd find it a lot more enjoyable if the "finishing" wasn't entirely about the enemies but rather, the really bad things happen if the girls are forced to climax. This might sound like a huge re-write but I think it could just be a slight alteration to the existing mechanic - the first couple stages work the same where low-level attacks add lust and try to destroy armor. When H-attacks start, they continue to add lust (not as extreme as they do now, but you were probably going to tone that down anyway) and then a new orgasm bar starts up (could be the reverse if you liked that better, like a resistance bar), so H-attacks add some lust but are mostly trying to force the girl to cum. At the final H-attack stage, the attack could either repeat until the girl either escapes or cums, or perhaps after a limited number of tries, the enemy finishes as it does now, imparting a large dose of lust, but no big finishing animation. The point here is the real "finish" is if the girl is forced to cum, which would then trigger the animation, and then trigger the major debuffs - things like, a stat or level drain (I'd LOVE this, like if the enemy got stronger somehow while the girl got weaker for the rest of the battle, losing str or defense or some such), pregnancy, temporary brainwash or charming, or even armor destruction (as opposed to damage, where it gets completely destroyed so the character is fully nude, and must be replaced/repurchased because it's not repairable by ARIS - would be an extreme and rare kind of debuff).
I would like to see victory poses. Little things like that can go a long way.
Estimate time for next update ??
Elaymidoray
If I may be so bold as to speak from a designers perspective, I have and idea or two that might interest yeh. First, the weapon tetrad, each weapon could give no more then three skills, and the forth slot could be filled by a generic combat skill. I don't know what direction you're taking this in as they progress, but ye could have anything from a weak stunning kick, to an erotic styled skill. (Don't know if ye're putting in offensive sexual skills or not, I could see the game doing just fine with or without them, just mentioning it in case yeh considering them) As for armor, assigning each class a passive skill would add a little more depth to your choices. Furthermore, being unarmored, though undesirable, would not necessarily mean classless. Without armor, one might not have the ability to guard efficiently, but they could attempt to dodge easier without the extra weight, move a little faster in initiative, etc. As for outfits forced upon a character mid battle, they might have some negative skills, or ones with unfortunate side effects. They could also attempt to be creative with varying degrees of success. On that note, actually, you could offset a class with powerful skills by giving it a weakening passive skill. As I said, more depth, if it's mandatory, and it hurts yeh a bit, it begs the question of whether the reward outweighs the cost. Anywho, just some musings from a tired mind. Night World.
You should see more of Ven either toward the end of V0.06 or at the beginning of V0.07 I think :D.
I have similar ideas in my notes, but most of them will require ideas to be implemented from the lust system overhaul that we plan to begin working on after V0.06 is released.
Possibly :D. Given everything mentioned above, there will now definitely be areas with actual gameplay where they are forced out of their combat attire.
Nice writing, just make sure that some of the things you mention get estimating. I see you juggle with ideas which is very well for the type of game we can expect. I would give you more but I haven't the funds for it. I would say good work but this will be estimate able with v. 0.06 or v. 0.07. Good luck for the usual stuff!
Jondude
Will their be any 'nude areas'? Areas where Neon and Malise might be naked for a mandatory bit? Areas like those are super fun!
Is masturbation as a way to reduce lust in combat a possibility? Or maybe high risk abilities like the ladies performing H-Attacks on the enemies but being vulnerable in the process: as in losing health, taking armor damage, gaining lust and/or being defenseless to H-Attacks from a second enemy? What about a taunt, example: enemy is casting an H-attack and you would prefer it land on one character over the other... you could use "taunt(or seduce)" where the character strikes a pose/throws herself down/opens her legs or whatever. Just some ideas.
They changed the engine so it's most likely going to be a clean slate.
I second this. There should be a "Dirty" version of the ARIES unit in the game where as it's not exactly an ARIES machine but instead like a Character that you can talk & in exchange for sexual Favor they will repair your armor and clear off your lust meter. Pretty much exactly like an Aries unit except for the fact that it will always trigger a (skippable) H-scene. Tbh I'd be fine with a recycled H-scene as this character can also be the same type as some of your enemies, if making new H-scene for the sole purpose of this costing too much Dev resources.
Victor Alvares
+1 to Ztuck's idea, I really hope that the new release will be out before the end of this month, coz its almost half a year without a game update.
AAAAARRRGGGGG!!!!!!! Love the hard work/hate that v0.06 is not out yet. Can't wait :) Look forward to the new release, it looks really good!
Happy to see human dick for a change. Also agree with Ztuck on the prostitution ideas.
Question. Will it be possible to continue with our saves from v.0511 in v.06, whenever it arrives - or is it a clean slate?
Kilra
I love this project and i ll continue to support you but, i have to admit, the new kind of tier, until now, isn t a great deal for us. For the future versions I hope in a (just a little bit) more quick releases ;)
Progress looks good. Any news on when V0.06 will be out?
Super excited about the new engine having native Linux support!
Needs some sort of repeatable prostitution/consentual/favour gain somewhere down the line. Mabey to take the heat off for a bit or something similar, it's sorely lacking in many game. Could be as a healing mechanic in an area without an ARIES unit? Fuck for a few hours of rest, be mutant kennel bitch for getting a safe haven. Or not, up to you guys, but I aleast crave some repeatable stuff. Anyways great work so far!
Instead of a new animation, why not a use a mechanic such as: Weapon jam, weapon overheating, etc .. for the story bits.
lul
Will we get to see more on what happens to Ven when she falls into the weird pit?
CrocoKyle
Are we to assume that we're seeing an anal position in the new police pose? Can we also assume this could randomly be a vaginal h-attack or oral one? Can we assume lust values will change the girls' cuffed graphics? So many things to assume!!! Haha
Dashiell
For weapons, can't you make that first time we enter armor changing machine (forgot name) we will have to register and get brain implant (sci-fi as fuck) with ID which will serve as skills' host, skills then might require different weapons/armors to equip which means you're free to do whatever with girls' items in meanwhile and also add perks to items? As for engine change, I'm all for it, we're in 1440p age with 2160p pushing through so that low res capabilities of RPGMaker are really insulting and make everything more complicated.
