The HypnoTits Ride Again

I got a new tablet and wanted to try it out, thus I bring you the HypnoTits Mark IV. Enjoy at your own risk.

My old tablet was slowly succumbing to wear and old age, and I succumbed to Amazon shopping. :P  Not a lot new to report otherwise. I started working on some other code and fixes for the upcoming release today, yesterday was more work on the AI and writing game code for utilizing the AI. (The creation/training framework is external to the game, obviously.)

I also plopped this in there real quick, as it seems to be the way the poll is going:

Just a simple picture of GLADyS' camera, which is totally not from HAL 9000. 

The actual feedback menu and such isn't in, of course. I'll be working more towards actual release material over the next couple days. I've reached a good point with the AI, so I'm going to work mostly on content-type stuff up until the release. I'm looking forward to it :D

Until next time!

o/

Education System

Hello everyone, tonight's post isn't terribly long as for the most part it's been more of the same (AI work). Generally it's progressing well, though I do need to create a standardized set of training data which is a bit of a pain. Overall it's quite effective, and more capable than a manual simulated neural network. I even figured out a way to include testing/learning inside the game itself, so players could click "yes, makes sense" and "no, fail" and back propagate that for learning, but then realized that approach has some noticeable drawbacks (namely instance issues).

I did have another idea, however, which is to essentially do the same thing as far as player feedback on the AI goes, but instead generate a report containing the information that can then be used to train the AI all at once in a controlled fashion. This also has the advantage of being smaller/easier to send back, and it also gives me the chance to review the data for a quick "second opinion" on the AI decision.

The downside of this plan also happens to be pretty cool; namely that it depends on you to help train the AI into what you want it to be. This is pretty neat, I think, in a way your feedback lives on essentially permanently in the game AI. The downside is that the quality of the training is limited by the quality of the people creating it, so someone making random choices in regard to AI performance--or deliberately making screwy feedback--could cause more harm than good if it isn't caught. 

The extra work to add this education system to the game isn't a ton, especially if it's kept on the simple side as far as the interface goes. Let me know what you think on the poll!

Here's a look at the mostly-done training setup, which also shows the main subject tags:

These are all fairly general, but the hope is that they can be sufficiently expressive when combined with the 8 modifier tags and other tags in the group. Rape, for example, would be violence, sex, and negative morality, with the NPC as the actor, probably with increased kinkiness based on the NPC's kinks. Trying to create a generalized set of tags wasn't easy or all that fun, but it seems to be workable so far. 

also, since the last preview showed a somewhat more "stacked' Kazuna Ai, and I got a couple questions about that, I figured I'd show this preview of the "current status" of the art. I'm not sure if I'll be able to completely finish it by release, but I think I'll have Ai-Chan done, at least. :D

AI Testing Initiative

(no, AI sperm are not going to be in AW. This was for testing purposes)

Hello everyone, I'm back!

Not that I was ever really away. During my vacation I did cut back on my work time significantly, though I did end up exceeding my "four hour limit" several times.

Most of that time was working on the improved website, as well as working on the game AI. The AI work has been progressing well, and I've been successfully creating neural nets and doing some basic training. I've set up an AI framework to work with the AI outside of the game, and utilizing JSON files to store the networks. The networks will later be included in the game directly. The JSON setup is quite handy, as it allows saving discrete states of the learning network weighting, and also allows others to work on training the network.

Here is a look at the training framework:

I've covered the AI a little more extensively in past posts, but the general design layout is to have 8 networks that interpret the 8 nodes in the personality core. The output from these 8 networks is put into a larger network that also includes predetermined strength values for each core, as well as the NPC's primary mental stats.

The basic node network is comprised of 1,083 neurons with a total of 169,670 connections. This may change of course, if this size proves to be inadequate. 

However, the utilization of the AI in the game is set up in such a way that changes and refinements to the AI won't require changes to the game code. The early AI is going to be quirky, especially given what we're asking of it, so it's important to be able to make refinements and perform additional training as development progresses.

I'll probably be sharing this training framework with you in the next release. It's not terribly user-friendly, but it might be interesting to play around with.

I'm going to get going. I'm trying to avoid creeping back into the 13+ hour/day zone that I was in. For now, I'll leave you with a little sneak-peak at what I was working on for the next release image:

Ai-Chan is getting some upgrades and training from GLADyS ;)

The Story Thread System

It's about time...

Hello everyone, it's finally time to go into a little more detail on what the story thread system is, what it means for game play, and how it'll work! Before I dive in, I figured it'd share a couple updates. 

First, the obvious one: the website is seeing some pretty significant changes. While not horrible to the point of being unusable, it was pretty bad... A lot of it was my fault, simply from rushing to get things set up. The new site is significantly more light-weight, and should work much better than before. I'm transitioning the blog to be hosted on blogger, with a display of the recent posts on the website. This will enable some better features for posts, particularly when it comes to search and labels. It also will help with the bandwidth issues that seemed to happen during spikes of activity (usually after a post/release). 

Getting all (200+!!!) blog posts transitioned over will take a little time. It's fairly easy and straight-forward, just tedious. Aside from working on the website during this vacation, I've also been doing some more work on the AI as planned. It has been difficult to stay within the four hours-per-day time lime limit I set for myself during this break, but it has resulted in me feeling better physically in addition to some extra creativity. 

Story Threads

The idea for story threads came to me when considering the issue of how NPCs can seem very shallow unless they have their own unique story. In RPGs, it's usually just certain special NPCs that have any sort of story, while the rest just follow a basic schedule and emit a line of dialog when prompted, usually from a random pool. The TES Skyrim "arrow to the knee" meme happened because one of those random lines of dialog was rather noteworthy, so it was quite odd when everyone and their uncle was shot in the knee.

When you have all custom characters, you can write their content in a way that gives them the feeling of depth. You can take time to change their content with the time frame of the overall story, and do some neat things. Unfortunately, this is a very time-intensive approach. Games that use this approach can be quite compelling, but often feel somewhat "empty". The Mass Effect series for example used custom characters quite well, but still suffered from having supposedly busy areas feel quite empty or lifeless. 

The opposite is having no custom characters, but populating a world full of people that have schedules and other tricks to make the locations feel lifelike... but the dialog is often quite shallow, and many NPCs pull from simple pools of dialog or say the same thing for the entire game. 

Most games of course use a combination, some "real" characters mixed with the very simple background cast. 

I want to bring Appletree to life

However, it's totally infeasible to write custom stories for ALL the NPCs. Even attempts where certain traits change a few behavior items really fall short of the mark, as most NPCs end up feeling essentially the same with that approach.

Most H-games go with the approach of having a small cast of custom characters, and perhaps a few random background characters. This doesn't really work for a life sim type game. Thinking about all the tabletop RPG games I've DMed for over the years, I realized that the trick DMs use to bring their worlds to life could work quite well in a game. The issue comes down to player agency, and how the characters the player choose to interact with can't be simple one-line NPCs. 

Given that the NPCs have detailed procedural generation to make them unique, and AI to give them something of a personality, they are quite similar to how generic NPCs in a D&D game would be run. The trick is to give them depth of character, a story, when appropriate. In a D&D game, the DM can think up a story on the spot, or perhaps draw from a set of nameless "characters" set aside for just an eventuality. For some reason when the players get attached to a local wench at the tavern, and want to bring her along as "a travel ho for stress-relief purposes" you can roll with it. (Yes, this actually happened in one of my games.)

Because we have detailed information on the NPCs thanks to the procedural generator I built, including a whole set of background information like number of siblings, parents, wealth, job, marriage(s) etc. we really have the information we need to give these characters story... 

So in comes the concept of the story thread. We have a piece of background story, say something about a brother or sister, or how they like their job, or how they are their uncle's son. By itself, it's just a little tidbit of detail. But put together with other threads, we "weave" a story for the NPC. We sprinkle those bits of story into dates and other events as you get to know them. The story thread system is what connects the threads to the characters.

How it Works

We create a bunch of story thread objects. Objects are a recurring theme in this project. :D It allows for more to be easily added in development, and by players. Each thread has information on the group it fits into (such as early life, school, past relationship, etc.) and also has some checks to see what sort of NPC background fits. This may be that the character has to have, or can't have, certain attributes or background values. They also contain a simple summary of the information they contain. (for menu / character display purposes)

We create a bunch of these threads. Some of course are fairly normal, some erotic, some odd or dramatic. Story threads also include general opinion items and things relating to current events, though these tend to be more constrained in terms of possibility. I'm planning to try and commission writing, and hold contest-type things to help expand the total pool. This will really improve the replay factor with the game, and help increase the uniqueness of each character. 

When it's time for some story reveal, a random story thread that matches the group for the reveal, and the NPC doing it, is "pulled from the deck". We don't just assign threads to characters when they are created, because of this deck of cards concept. A stranger you meet doesn't reveal their whole life story when you first meet. On a date maybe you learn a thing or two about them. This allows us to pull threads from the deck (and not reuse them) as they are needed. This maximizes the uniqueness of the characters on a play-through. If we run out of cards, we shuffle the discard pile and start over.

Things that you learn about a character will be viewable in their character profile, for example "Bob Jones: product of incest" because each thread relates to a small part of the whole, characters are going to have unique overall stories, though with enough time and socialization you'll see an individual thread again.

Because threads are based on the NPC's background and personality information, they'll generally line up with the type of character they are. Unique "fixed" NPCs such as Lily and Toby have fixed story threads that don't change, but the majority of characters--semi-random such as the pharmacist, and fully-random--will use random story threads that give them a unique story that matches their data.

The end result

The story thread system is sort-of the counterpoint to the AI and personality core. The latter makes them behave a certain way programatically, while the former provides the story that matches that behavior. Together they allow us to have a town like Appletree populated with NPCs, and have those NPCs be capable of interesting interaction and engaging in things like romance or friendship with, despite just being a random cashier at Hole Foods.

It should be obvious that we still won't have a real world to play in, but the idea is creating one that feels much more real than what we've seen in the past. 

Like many things I've done for AW thus far, or plan to do, it isn't the easiest way to do things. Making things expandable and modifiable adds considerable work, for example, over simply coding things to behave a certain way. In the long term though, that pays big dividends in adding content and play value. Story threads in particular are something I feel are really going to add a lot to AW, because interacting with NPCs (be it sex, friendship, romance, or coworker rival) is such an important part of a game like this.

Slut

I'm told this is Swedish for fin.

I think I've went well over my time-limit for the day, but I'm glad to be able to share the story thread system with you. It's one of the more innovative parts of AW, so I'm really looking forward to seeing it in action!

I'll be back in a few more days for another post, I'm still planning a release as normal at the beginning of the month. Until then, ciao o/

Building NPCs to Sleep With

Originally Posted: October 27, 2017

Complexity & Chaos Theory in Procedural Generation
(AKA: My Approach to NPCs)

First of all, I want to say thanks for all of your kind words, I really appreciate your support. It's hard to express the kind of effect it has on me as a creator, but it means a lot to me. A big part of my anxiety has been worry about possibly letting people down, so your reassurances really help me deal with that too!

Before I get started on NPCs, let me share this, which is a result of your feedback on setting attractiveness settings. I think it'll be a fast and clean way to handle those complex settings. ^_^

So I'm not going to talk to much about the technical aspects of generating NPCs today, I'm going to save that for later posts when I can show/demonstrate things. This is more about my immediate plans.

I was going to wait until after the prologue was structurally complete to start working on NPC generation. But, I recently realized that there isn't really a functional reason to do so, at this point it's more about organization. (and if anything, a few pieces will be a bit easier without having to anticipate what doesn't exist just yet.) Also, I think most of you want to get to the sex parts, and I want to get to the sex parts, so why not start getting to the sex parts already?

Plus, I've been really looking forward to the technical challenge of making these NPCs, so that's a good motivational boost as well. I'm going to keep to my light-load schedule for a day or two and set up a proper working schedule as some of you have suggested. I'll do a release with part of the putting-together done, and then start working on the NPC generator.

For fun, here's two of the pages from my planning notebook on NPC generation:

188,974 Steps

Originally Posted: October 27, 2017

Into the grave! Insert creepy Halloween laugh here

It's slowly sunk in over the last few days that I'm heading towards a burnout. The problem with burnouts is that they're often a lot of fun until they suddenly aren't. I've been having fun working on Accidental Woman; passion and the community have been driving me forward. It's too easy to get sucked into something you're passionate about though, and that's a particular weakness of mine.

To be clear upfront: I'm not stopping work or doing anything drastic.

To be perfectly honest, I expected that I would start approaching burnout, and that I would have to take steps to prevent what would otherwise be inevitable. What I didn't expect is that it would happen quite this soon. Maybe it's all the crazy extra things that've happened the last couple months, or maybe the rapid increase in support made me push harder than I expected. Whatever the case, I thought I'd make it to the end of stage 1 before I had to start forcing a work schedule on myself.

I've also come to realize that the people who support me and follow the work I do know how much effort I'm putting in. And the people who don't will continue to make comments on various websites about me not putting in enough effort. I'll probably continue to get occasional Patreon exit surveys with "creator doesn't deliver as promised" no matter what I do. (I recently got one where the person took the time to write about 100 words of comments stating essentially the same thing.) 

Results from a chronic stress/burnout test:

Let me take you through the last couple days. Wednesday morning I woke up at 9am, and worked on AW until 2pm. I spent about 30 minutes of that time with my son. At 2, I got ready for work and went in. While at work, I spent about 6 hours working on AW. I got home at about 12:15, and after a shower and getting ready for bed, spent until 1:30am on AW. Spent an hour winding down (fapping), and went to sleep. Today, I woke up at 8am, started working on AW at 8:30, and repeated the process until 2pm, then went into work and spent another 6 hours on it. Right now I'm at home, and it's 1:15am as I type this.

This has been pretty regular for me. I carve some time out on my days off from work, but I usually work between 8 and 12 hours a day on AW, often closer to 12 than 8. I'm not complaining, because it's something I want to do. But I also realize that if I keep it up, I won't want to do it anymore. This post is basically about taking the steps to make sure AW succeeds.

There have been a few clues, and some helpful warnings about burnout from supporters. Probably the biggest I've noticed is that while the amount of time I spend working hasn't changed (it's actually slowly increased), my productivity has fallen markedly. If I work 12 hours but only get 8 hours of work done, I might as well be working 8 but doing it in a healthier way. There have been some other signs, declining health and plenty of new grey hair. (That I'm too young for, damnit!) I think the biggest factor recently was that I was trying to write dialog with Lily, and I just couldn't "connect" with the characters to write it.

So, I need to fix this, because AW is too important to me to not fix the problem. It's also just not worth it to lose sight of living life, which I haven't been doing much of for quite a while now. 

Plan: I'm going to force myself to scale back to 4 hours for the next two days to recover a little, and then try to set up a schedule with no more than 56-60 hours per week.

Effect: Hopefully minimal. I'm still ahead based on my development schedule, and increased productivity will hopefully make up for the lost time (That doesn't seem to be doing much good right now anyway.) We'll have to see how it balances out exactly.

Progress Thus Far:

So I thought it'd be fun to see how much work I've done on AW so far, so I used the strictest word count method I could to count the words file-by-file of all my code and writing in the game.

188,974 words.

By this counting method, this counts as 3 words:

<<set $status.addictMax = Math.max($status.addictSex,$status.addictAlc,$status.addictHeat,$status.addictSatyr,$status.addictFocus,$status.addictCum,$status.addictZone,$status.addictCream)>>

The standard counting method puts me at 239,895.

And that doesn't really factor in revisions and improvements. I have to say, I'm kind of impressed with myself. The average words-per-week of successful authors is between 5,000-7,500 per week when they're writing. Very prolific pulp writers might write 15,000. 

Based on these numbers, I've written 11,116 to 14,111 words per week, and also did regular posts, answered questions, made some art, and plenty of other side tasks. Not bad for someone that already has a job and everything else going on!

And with that, I'm going to try and get some sleep. I'll see you on the flip-side.

A Giant Pile (of To-Dos)

Originally Posted: October 25, 2017

So there's plenty to do before the next release, but nothing terribly exciting. It's mostly small tasks, and the rest are annoyingly-complex small tasks. All towards tying everything thus far into a working whole. On the bright side, when I'm done we'll have reached a point of open play. After the upcoming release, I'll be putting a little more time into the prologue story and mechanical elements. After the next public version, I'll be starting on the giant hydra I'm nicknaming the NPC generator.

Before I start this list of things to work on, I thought I'd share this image of Muschi Valley. It's already built into the game, and functions as an overview map. The image should give you a little better idea of what the Appletree area looks like :)

There's also a really rough map of Appletree itself. I don't care for it all that much, particularly the woods, but it works okay as a placeholder to distinguish between the different areas in town you'll be able to visit. 

And on to the to-do list: 

To be honest, part of the reason I'm sharing this list is to make sure I'm not forgetting anything!

1. Use week planner outfit settings to get dressed automatically in the morning.
2. Properly deposit player in the correct home when waking up.
3. Test system of getting ready in the morning, particularly for correct time usage.
4. Complete task details for three primary jobs, and properly display in prologue.
5. Have job system properly display tasks, replace current placeholder display.
6. Put in work effort option, with skip setting.
7. Place end-of-week job events, and route to week summary if last day of work is missed.
8. Have week planner properly return player to sleep system prior to waking up.
9. Create basic home activities for using the bathroom, going to sleep, and placeholder recreation activity for killing time.
10. Create basic version of home menu.
11. Put together apartment shopping menu for the prologue
12. End of week finance items processing to collect work pay and pay bills.
13. Build schedule view to see planned activities.
14. Have job system return player home after work.
15. Properly link maps and have them calculate travel time.
16. Create placeholder downtown map.
17. Remove demo portal from Bullseye.
18. Create actual prologue exit, and deposit player in their new home.

I've got plenty to do, so I'm going to get back to work!

NPC Face Portrait Artist Vote

Originally Posted: October 24, 2017

It's finally time...

The vote to choose the artist for the NPC face portraits. I'm going to go over some of the details here just so it's clear what kind of art we're talking about. The artist chosen will be drawing face and shoulders portraits of NPCs (quite a lot of them, in fact). They will also do a small number of full images with background for special scenes in the game. Beyond just the quality of the art, it's also important to have an artist that can perform over the course of the project.

Three Choices:

1. AlexW95
2. Arteria Criteria
3. Justinian Knight

AlexW95:

AlexW95 has been great to work with. He's been quick and reliable with communication, his rates are quite reasonable, and we already have a good rapport for the work ahead. If I was simply choosing by myself, he'd be my pick. As far as art goes, his anatomy work is the best of the three, his detail and rendering is superb, and his facial style really fits my vision.

Arteria Criteria:

Arteria is a nice guy, and he certainly has a unique style of art. I do appreciate the more realistic look of his work, though it would make any potential recolors a bit more difficult. The more realistic style would lend a more serious tone to the game. My main concern is the number of changes I've had to request, though Arteria has been quick and willing to make them. The issue may be part of the language barrier, or I may not have been as clear as I could have. 

Justinian:

To be honest, I haven't communicated much with Justinian, and replies have been slow or required a follow-up email. To his credit, he's been apologetic, and I certainly understand what it's like to be busy! He's had a large commission/RL workload this month, but he worked to get this in for us. He says that a more regular schedule of production for the game shouldn't be a problem after this busy patch. I do like his style, which has a certain cartoon-like element.

I'm looking forward to seeing what you all think!

Back to the Mines

Originally Posted: October 24, 2017

"By god, I've hit the slutload."

So the website is 90% up-and-running, and I can finally get back to the AW code mines. There's a bunch of little things to do to get ready for the prologue exit. I'm going to start with adding the code to the morning to get dressed before work. There are some connections to be made, and arriving home after work, and I want to get the downtown and Muschi Valley maps at least usable.

There are several little things and some more complicated small function doodads to get the existing systems tied together... and we'll technically be out of the prologue. (I say technically, because the prologue story text won't be done, and there won't actually be much to do yet. 

After this chunk I get to start working on the NPC procedural generator though, which is pretty exciting. We're talking the detail level of a slave from Free Cities, but with many more variables that control behavior, schedule, and relationship. Once the NPCs are sorted out, I can start in on the sex scene system! (hooray, it's been too long since I've worked on something erotic!) The NPC generation will be done in javascript, which is going to make it a bit more complicated for anyone attempting to alter the game down the road, but is necessary to handle generating a slutload of NPCs without long loading times.

When I launched AW publicly, I made several promises to anyone supporting development. One of those is being honest and straight-forward when I make a mistake. On that note, I figure it's time I share that I may have made a mistake with how I handled the time system thus far. I was looking at the processing time, and it's longer than I expected. It's nothing that impacts the game right now, but looking ahead towards everything that will be going on for each 15-minute 'tick' of the clock, I may have miscalculated where asynchronous processing should start. My goal is to have passage transitions take no more than 1 second, but for activities that use more time (and thus process more ticks), it looks like I may not meet that goal. I'll keep an eye on it and see. It won't be something that affects development at this stage, and isn't a huge deal in any case, but I want to keep my promise to be forthright with any screw ups. 

With that out of the way, I'm going to get to work!

Website Buildin'

Originally Published: Oct 23 2017

It's been awhile since I've had to mess with a public webpage, intranet pages don't count because the standard for what's acceptable for those is waaaay different.

Hopefully you all like what I'm doing here so far, though I've not been spending a lot of time to make everything as nice as it could be. (I want to get back to AW!) Still, it does provide a better platform for doing a lot of the things that Patreon isn't great at (like anything involving text...), and I think the "About AW" page will be a better way to demonstrate what Accidental Woman is about than the narrow strip on the Patreon creator page. 

Probably most importantly, it gives a bit of independence from the Patreon platform in regard to content, and provides a means to communicate besides Discord.

And now, I'm going to try and get some sleep, I have to wake up in about 6 hours.

Simulated Cities

Originally published: October 20th, 2017

This is a long post, but I think that it will be a good read. It's hopefully not boring, and definitely informative; it talks about the design of Accidental Woman.

I wanted to take a moment to talk a bit about games, and why I'm going into detail in many areas (like the PC's budget) that aren't exactly erotic. I wouldn't blame you if you were thinking something along the lines of "This is supposed to be a porn game, why is he working on X?"

A good portion of the answer lies in the nature of simulation games and porn themselves. People play simulation games--and watch porn--for different reasons, and they're interested in different things. People are interested in different kinks and different gameplay elements, and they play or watch for different reasons at different times.

The best example that I think most people will be familiar with is the SimCity series. (Pictured above is SimCity 1, play for free here!) SimCity is one of those games that makes a perfect example of how people play simulation type games. (A modern variant of the simulation genre is the sandbox game, though I won't get into detail on what distinguishes the two.) When someone plays a simulation game like SimCity, they can do it for any number of reasons, many of which they create themselves. In SimCity, some people are interested in the challenge of building a city. Some are interested in making a "perfect" city. Some people like being creative and building an interesting city, while others like testing the limits with really strange cities. The list goes on and on when it comes to simulation games.

Porn, and porn games in particular, share this multifaceted nature in regard to the way they are experienced. The amount of variation starts to get crazy when you throw in the various sets of kinks that players are into!

There's an often-unrecognized aspect to erotic games that have a wider scope, and that's detail. This element is even more critical to simulation-type games, though often players don't realize what exactly is wrong when it's missing. Freedom and imaginative gameplay demand it, but it's easy to overlook when we think of games as porn. That feeling that a game is too shallow can be pretty obviously attributed to a lack of detail, but it can also result in a game feeling repetitive, grindy, limiting, restrictive, or slow, among others.

Often in porn games we attribute this to a lack of sex scenes, or another obvious element, but I think that the root cause comes down to detail. If you've ever been playing a game, tried to do something, but found that you either couldn't or that you could but that there was no result, you've run into a lack of detail. It really takes the fun out of a game.

Erotica, particularly story-driven games like AW and countless others, has a strong element of fantasy. It gives you the opportunity to experience things vicariously, try things you wouldn't in real life, and generally just cater to your own personal kinks. This also leads to some disappointment. I'm sure many of you have played an erotic game that really grabbed your attention, but then suddenly found yourself disappointed, or wishing that there was more somehow. Even when a game lets you do parts of your own fantasies, it quickly becomes a let-down when there is no detail behind it. As an example, how many games let you get your character addicted to something, only to find out that the addiction doesn't really have any consequences or impact beyond some inconvenience to gameplay?

It's a bit difficult to recognize, in part because people's expectations and fantasies are different, which leads to a different experience of that same "missing something" feeling.

This issue has been a major part of my thought process while designing Accidental Woman. In fact, I didn't start work on planning or designing AW until I had a solution. That solution is why I've been adding detail routinely to everything. While this is also partly because different people are interested in different aspects of a simulation (some people care a lot about clothes perhaps, while others couldn't care less), the biggest factor is creating a structure that allows detail and consequences to happen.

Why do you have to clean your house? So that NPCs can notice that it has become a hoarder's nest because you've been too busy doing X to clean. Why is there a budget? So that losing your job, developing an expensive habit, being conned, etc have degrees of consequence beyond a simple "end of the month, can't pay rent, game over" bad end. These non-erotic aspects of daily life, like waking up in time for work, cleaning, bills, etc aren't there to be erotic by themselves. They also aren't there out of some attempt to be a real-life-simulator with some sex thrown in. They exist to provide meaning and detail to the erotic aspects of the game, giving them more depth and providing room for those fantasy scenarios we dream up. They also open up opportunities for other scenarios. Why else would a sane person sign up for shady drug trials if not because they need money?The important sticking point is that all this detail can't bog down play and take away the fun. That was another major part of my thought process with AW. Most of the mechanics you see are designed so that they are skippable and automatic, taking up very little time if the player isn't interested, but allowing more control if they are. The key point with my design is that most of these processes are automatic and mostly out of sight... until they aren't. And when they aren't, they're part of one of those aforementioned consequences. You won't have to give much thought to having your character go to sleep at night, until your late nights partying starts making you late to work, and your rushed mornings lead to a slovenly appearance that annoys your employer.

This sort of reward and punishment use of increasing complexity has been used pretty successfully in some mainstream games (particularly sims), but I've never seen it in an erotic game. I can't point to an erotic game and say "Look, that's what I'm doing, the concept works!" Despite that, the fact that it works in other games is a good indication that it can work for an erotic game. I also really believe that it might be a solution to that "missing element" that so many of us have noticed in other erotic games.

This kind of detail isn't easy, but I'm pretty confident I can do it thanks to all your support. For all of you getting worried about me focusing too much on non-erotic aspects of the game, you can rest assured that it's all for a very erotic purpose! ;)

Extensible Style

Originally Posted September 11th, 2017

Unlike clothing, it doesn't make much sense to randomly generate things like hairstyles, makeup styles, and jewelry. 

The most common examples of style options I've seen usually involve some code that allows the player to select from a few different options, and then set the game's variables based on that choice. The problem with this is that it often requires new code for each instance where the style might be affected, or simply reusing the same menu/location/process each time. (An example of this can be found in Girl Life, where a "mirror" location is reused to set makeup, and is presented as a link to the location from any bathroom.)

Depending on how it's done, this method can work quite well, and even save some time setting up (depending on the complexity). Girl Life's mirror, to follow the earlier example, works perfectly fine. A common limitation of this methodology, and what I'm trying to avoid in general, is the difficulty or extra time needed to add to it (for either function or variety). Rather than make a hard-coded set of styles for any of these categories, I think it's much more practical to make an extensible set of styles and jewelry. 

Object-Based Styles
One of the strengths of JavaScript, at least to my mind, is the ease with which it allows the use of objects. I've been coding all the "grooming stuff" in an extensible object-based manner. Individual hairstyles, for example, exist as part of a larger hairstyle object, and contains all the information needed to use them in the game. As a variable, they can be used anywhere, and adding a new style is as simple as declaring a new property; no extra coding required, and definitely no chasing down various portions of code that need to be updated to use the style.

The image above is a picture of the code that determines which hairstyles are available to the player. It iterates through all the different hairstyles, checking for a simple Boolean to see if the player knows that hairstyle. If so, the name is wrapped in apostrophes and added to a string that is used to print a drop-down macro call. This has the added advantage of making it very easy to utilize the style, as the player is essentially choosing the object index that they want when using the drop-down.

In the future, should new styles be needed (or wanted), adding them is a simple matter of working out their stats, putting them in the variable declaration passage (and backward compatibility), and adding them to the list of one or more shops/salons in Appletree. The clothing system supports ad-hoc addition of clothing items as well, but operates differently because most clothing is procedurally generated.

Ambition and Adventure

Originally Posted August 3rd, 2017

First of all, I want to say thank you to all my early supporters on Patreon, you've exceeded my expectations!

Ambition & Adventure
Accidental Woman is an ambitious project to be sure, but I believe that it's ambitious in a good way. Everything I've proposed is completely feasible, and the scope is constrained with a plan to get to the finish, so it isn't ambitious in terms of what is possible. I think it's ambitious in terms of making a really good game. I want to make something that people enjoy playing, that captures a certain narrative spark that happens when a game and its players interact to create an experience.

Before ever writing a word of code or story for Accidental Woman, I took a good amount of time to do some preparation. Thinking about how the game should be structured, what sort of features and mechanics should be included, and the fictional environment of Appletree and the individual stories of its inhabitants. This planning gives me a road map of how to get to the finish line, and informs how I go about building each piece along the way.

Experiencing Adventure
As far as time goes, I've known from the beginning that development wasn't going to be over in a few months, but instead was going to take two or three years to finish. The game will certainly be playable well before that, but the narrative content will take time to flesh out.

I've worked on long projects before, professionally and for fun in the game modding community. I think the most relevant experience I can liken to Accidental Woman is playing Dungeons & Dragons (or Pathfinder and other tabletop RPGs). I've been GMing campaigns in one way or another since 2000, and quite often these campaigns last for more than a year, and some have lasted for two or three. Working on Accidental Woman is very similar in a few ways: It requires dedication and forethought to seeing it through, it weaves a lot of story threads together inside a larger fictional world, and it depends on working together with players. (Also, it's fun to work on, and I'm sure there'll be drunken shenanigans at some point.)

My plan depends on building a community of players, and listening to them. Interacting with people who enjoy what I'm doing helps me improve, but most importantly it's what motivates me to keep going and put in my best effort. The support so far is extremely encouraging!

Error Checking by Design

Originally Posted August 2nd 2017

It's a common scenario: a promising project grows, but then devolves into a quagmire of bugs seemingly overnight. Development progress slows, and supporters get fed up with late releases and declining content. 

I want to avoid that scenario!
I'm not a professional programmer, and I'd never claim to be some kind of expert, authority, or even someone particularly good at coding. I have written plenty of code though, and I do work in IT, so I'm not completely clueless. I also happen to have a pretty good idea of what's going on with that scenario. It's a simple truth that coding practices that are workable for small projects end up being a nightmare for larger ones.

When a program is small, it's easier to remember details and variables without comments, or you can quickly take a look at another portion of the program to refresh your memory. You don't have to pay special attention to error checking, reporting, or validation. This is because the program is small enough to test fairly thoroughly yourself, and the code brief enough that you can read through it quickly to find a problem. It's not ideal, but bad coding habits won't kill a small and simple project.

People make mistakes, and I most certainly do, and that contributes to creating bugs. As the complexity and size of the code increases, it becomes easier to make mistakes and harder to find where you made them. Bad programming habits make the problem exponentially worse. I'm not saying that other game developers are bad or lazy here; often times good habits were never necessary for them before, and it can be hard to anticipate how tiny problems will snowball.

To avoid the bug quagmire, I've already been implementing several measures to prevent it, and there hasn't even been a public release yet.
Designing the structure of how things work before I start coding it

Using regular data validation methods, and making their use consistent

Avoiding hard-coding by using functions and variables to determine behavior, or using hard-coding only in universal function code (that isn't repeated, so can be easily changed).

Implementing a debug information screen so that users can provide the game state along with a bug report.

Adding error reporting code to data validation. (Info that includes the location that sent bad data!)

And plenty of other minor measures.

It's true that doing all this takes longer. It seems so much easier to just write some code and get some working content... but that comes back to haunt you in the long run. Ever seen a developer seemingly working forever on a simple addition of a new mechanic, expanding a mechanic to be less simplistic, or even just adding some new content with existing mechanics? That is NOT something that I want to see happen to Accidental Woman.

Building A Parser

Originally Posted: July 30th, 2017

There are two big challenges when it comes to writing a text-based adult game.

(Well... More than two, but I'll just cover two for now.) 

When characters have a lot of variables, it can quickly become a nightmare to write content. Making use of appearance variables can dramatically increase the time it takes to write even a relatively simple scene. Throw in personality variables and it becomes a nightmare. This usually results in either: a. simplistic and/or repetitive scenes, b. scenes that don't seem to take character customization into account, or c. a combination of a and b. 

Erotic writing in general suffers a problem with repetition. When you write about a few specific pieces of anatomy over and over, the word choice can quickly become repetitive. This is true even with effort to try and rotate words. 

For Accidental Woman, the solution is using parser functions. Parser functions help to manage each of these problems. For the first, a parser can turn a variable into a meaningful bit of text. Rather than writing an if/then or switch statements each time you want to describe something, you use a parser function instead. Let's say you have a variable describing how hungry a character is. Because you want to regularly add and subtract hunger, it would be a pain to have the variable be a string. At the same time, if you use an integer or float you have to interpret it when you want to describe hunger in words to the player. By building a parser function, you can simply call the function whenever you want to describe the hunger variable. In Twine Sugarcube, this would look like: "your stomach is <<hunger>>." The parser function reads the $hunger variable, sees that it's 1.4, and outputs "nearly empty". Players will see "your stomach is nearly empty."

You can probably imagine how a parser function can help with repetitiveness. Instead of writing "cock" you type <<cock>> and call the parser to pull up a random word for penis. You can put a whole army of words, and prevent words from being overused. Of course, this won't always be very lyrical, and you can't use it for dialogue, but it works. Even better, you can combine variables together into the description. A parser function called "pussy" can look at variables such as looseness, wetness, and arousal to pump out an appropriate description. This is really helpful when you don't know what the state of the character will be in, as is the case often in games. A passage where an NPC is fingering the PC could be described differently based on the situation when it comes up. This adds some immersion and flow to otherwise disjointed writing in many life sim type games.

By using parser functions, I'll not only be able to add content faster, but I'll be able to add the type of writing found in CYOA style games to the mechanics of a life sim. It'll also make it much easier for contributors to write content as well.