House Dominae
I thought I’d share how it looks when I write activities for House Dominae.
On the left is an xml file containing (among other things) the activity strings, in this case a blowjob, written in the game’s simple syntax.
On the right is the resulting text in the game, given a certain outcome for an arbitrary customer.
Sorry about the lack of updates. I just don’t end up posting as much as I probably should but development-wise I’m pretty much on the same pace as always. Maybe a little bit slower since work has been pretty hectic this fall.
Looking back at what I’ve done most of it have been focused on various systems in the game, which makes for really poor screenshots so bear with me.
Characters can now be defined with a personality trait. This is actually a very minor addition but it should be helpful when creating characters. Personalities work just as any other trait, but a character can only have one. I realized that a bunch of the psychological traits would serve better as personality traits, like “Shy” and “Slutty”.
I have a small confession to make. I stole this system from SoldGirl Town, almost in its entirety. In short, slaves now have two new stats: Loyalty and Reason (previously Mental health). These attributes are then used to determine the slave’s current state of mind or “mood”. Slaves generally start out with low loyalty and high reason resulting in a hateful mood. By slowly changing these stats through their actions, the player can alter the mood of a slave to successively make them more compliant and eventually
submissive and obedient.
It’s worth mentioning that this completely obsoletes the slave leveling system, which I’ll remove at some point. But I think I like this system better because it’s more nuanced and it adds a secondary way to affect a slave’s obedience besides the insubordination/punishment system.
This is another small change. I redefined the skills and categorized them in groups; a primary group (Manual, Oral, Anal, etc.) and a secondary group (Elegance, Perversion, Technique, etc.) The point is that every sexual activity will require a skill in the primary group and (optionally) some skill from the secondary group.
The primary skills should be self-explanatory but you can have vaginal sex in lots of different ways and I wanted the game to reflect that. So if a customer walks up and wants rough sex, it’d require the slave to use both their vaginal sex skill and their rough sex skill. An aristocrat might want a more elegant experience. You get my drift.
This also leads into some future work where I want to add some non-sexual services like strip dancing.
These were previously called “Techniques”. I wanted a way to clearly indicate a character’s skill growth. But I kind of solved that when I switched to a level based skill system over the previous linear one. Level 2 is clearly better than level 1.
So I changed techniques into be something a bit more interesting, I think. Characters will now occasionally learn special skills (I needed the word “Technique” for something else) and these are effectively buffs. Some special skills will be learned from books while some will have to be learned spontaneously. They should hopefully help with slave specialization and to differentiate slaves from one another.
You can now inform the game, via the character creator, if two or more characters are connected or related somehow. Characters can be brothers and sisters (for that incestuous hotness), husbands and wives or just canonical friends or enemies. I believe that if the player knows that two characters are canonically related, the game should be able to know that too.
This will come into play later when I revisit the relationship system. I believe there’s a ton of gameplay potential to be had there.
I added an option to allow the game’s text engine to refer to the player character as “you”. [Name] [is] tired will produce either “Chun-li is tired” or “You are tired” depending on the setting. Pretty neat!
I added an [a] command that will correctly output “a” or “an” based on the succeeding word. This is incredibly useful when referring to unknown things like names of customers – which now have randomized prefixes for variety.
Finally, I added [if], [elif], [else] & [endif] commands to do conditional statements. You could already do this but the existing syntax is more suitable for individual words whereas this will work better for full sentences and paragraphs.
I moved the project from Unity 5.3.4 to Unity 2018.1.6. Unity 5 is getting pretty long in the tooth and I really want to implement TextMesh Pro (alternative text rendering plugin). Experience tells me that you should always avoid upgrading engines or APIs that your project is relying on but I figured I had the time and if I was ever going to do it, it’d be now. If you’re lucky nothing breaks but you can’t ever expect that. Truth be told, you never know until you try.
Technically, only one thing broke. Unity removed MSAA from UI canvases rendered in Screen Overlay mode (default camera). It made some screens, like the building blueprint screen, really, really ugly and unfortunately the solution to that issue was to change the rendering of every single screen in the game and that cause a whole mess of issues. It was a domino effect of shit. It wasn’t hard to fix but incredibly tedious. Eventually I was able to put everything back in order. #NeverUpgrade
It’s a really good text rendering engine but the feature I wanted the most is its ability to insert arbitrary sprites in text.
If you squint really hard, House Dominae is almost like an RPG, where your slaves are party members and customers are enemies to battle and defeat. That’s honestly pretty close to how I’ve been looking at it. There is a system in the game where slaves encounter customers and attempt to defeat them, except not with swords and magic but with their bodies and skills.
Inspired by these ideas I made some changes to how the customer-slave encounters play out. Previously, slaves would roll dice based on the amount of experience points in their relevant skills. Those rolls would be modified by various circumstantial modifiers like gender/orientation compatibility, tiredness, etc. until finally tallied up and compared to the difficulty of the requested act.
That system worked well enough but while playing the game I observed that it felt really binary. Your slaves would either fail every time, or they’d succeed every time and it just wasn’t very interesting. I tried making the limit more fuzzy by allowing slaves to soft fail, i.e. get the job done but poorly.
The new system is closer to an RPG battle in the sense that every customer has a climax limit (health) and the slave gets multiple attempts (attacks) to reach that limit. If a slave can’t immediately satisfy a customer they can make an additional obedience check to see if they want to continue. Customers will do a similar “patience” roll to see if they’d want to continue. As long as both agree the slave can keep swinging. The result is the climax ratio the slave delivered divided by the number of attempts made. This means that a slave can “succeed” by 30%, which would be considered a poor result. They can also succeed by 200%, which could be interpreted as the customer cumming twice.
This level of granularity means that the progression of each slave’s performance will feel much less binary. Additionally all these values are fed into the text generation system so you can write really creative and detailed descriptions.
The service phase has been removed and is replaced by a foreplay phase. Unless they fail an obedience check a slave will always perform some kind of foreplay at the start of a customer encounter. They will maybe flirt or do a little striptease dance before moving on to the main event. This will cut off a small portion of the customer’s climax limit, making the encounter slightly easier.
A slave’s performance in a skill used to be based on the precise value of experience points for that skill. That’s been changed to a more typical leveling system. Skill rolls are based on the level for that skill.
Obedience dictates whether or not a slave will do as they’re told. They can either accept a task, resist it, or refuse it entirely. I had a similar issue with obedience rolls as I did with customer-slave encounters where the rolls felt really binary. Either a slave would refuse everything or they’d agree to everything.
Thankfully, this didn’t need as big of an overhaul. I changed up the math to a much simpler (and to me, more predictable) look-up table. It gives me better control and I can tweak it as I go along.
It’s a tricky balance because I want Obedience to matter while not making it so that a slave can constantly disobey and drag the game down. This should work for now though.
Finally, this past week I’ve made some good progress with custom activities, scripted in LUA. Most has to do with exposing the necessary functions to the scripting environment, writing helper functions and sample scripts.
So far I’m very happy with how it’s turning out.