Saturday, 30 September 2017

Newlife 0.4.12

Hello everyone!

Newlife 0.4.12 has been released. Early-access Patrons can find it in the creations section here. The changelog is below.

The previous version is now public. You can download it using the links on the right-hand side of the blog. The public version's changelog is here.

As usual, saved files & templates from older versions probably won't work with newer ones. 

For new players - just use one of the links to the right to get a zipfile containing Newlife. Once unzipped, you'll see a folder containing .jar and .exe files. Either one of these will run the game. 

For either version you'll need to have Java installed. A lot of programs use Java so you might well already have it. If the jar shows up as an unrecognised file type, then you probably don't. In that case you can get it from
The exe should tell you if you don't have the right version on your computer, but you'll still need to install java to run the game.
There's a guide for new players here which includes some troubleshooting tips for installation & downloading.

This verson adds the blackmail scene from the custom scene example. I know that the example blog posts aren't finished yet: my keyboard time has been a bit limited this past week due to a (hopefully minor) injury so I'm putting them off for next month. You can see the finished version in the additional_scenes/official_content folder and it's hooked and playable in the game itself without using the testing scene.

Writers should be aware that this version makes a lot of changes to the custom scene system - things like renaming methods to be more consistent. This should make writing easier in the long run but for now you'll probably need to run a find & replace over any scenes you've written to update the names that have changed.

Major changes & additions:
  • Added a new random event: the cheating-blackmail one from the custom scene example blog posts.
Minor changes & bugfixes:
  • Fixes to text issues. Thanks to Jason Montana, OrangeJuice, Saur, Ammut, Classique75, NewFace, Saint Destiny, Death25, Antage, Megh and NoName for reporting some of these.
  • Doormat and Likes_to_share traits are now enabled for custom NPCs, thanks to Megh for reminding me of this.
  • Fixed an issue where custom scenes with invalid yaml could fail without returning a useful error message to the player.
  • Updated some logic around old pc feeling bad about cheating text that hadn't been updated with 0.4.11 changes, as reported by blog commenter “Nobody”.
  • As suggested by FutureSight, the blackjack game will now let you hit even when you have 21, for players who are deliberately trying to lose.
  • The makeout scenes are now a bit stricter about what counts as cheating: if you're with someone other than your partner and you want to not cheat then you need to end makeouts immediately, even if this means using the harsh “stop touching me” action. If this action is disabled due to a failed willpower test then you may have no possible actions that will not count as cheating – this is a consequence of getting into compromising situations with other men as a low-willpower character.
  • Relaxed the conditions for your partner demanding rough-mode after he finds you cheating.
  • Following a request by FutureSight, female-start character creation will now randomly set work experience. This does not happen for male-start as their work-experience is set in the male template before feeding into female-character-creation. Work experience relates to the character's past life (which is implied to represent the player themselves in the near future) so it shouldn't be changed by Ivy's machine.
  • Relaxed the conditions for NPCs demanding the PC get pregnant as a way of proving her commitment when they discover her cheating. Previously this wouldn't happen if they already had a child together, but this condition has been removed now.
  • Increased the event weight for the event where your bf catches you cheating, as suggested by Blargan.
  • Beating up the pervy client now checks the characters' strength values instead of just requiring a fixed fitness value.
  • The NPC browser now sorts NPCs, first by sex and then by name.
  • Fixed a case where the cheating confrontation scene wasn't ending immediately when the PC's partner dumps her.
Changes for user-submitted content:
  • Important: While writing the custom scene I found the inconsistency in method names was annoying for writing. As such they've been standardised so that e.g. enjoy changes now use addWEnjoy instead of addPCEnjoy and medium-scale modifiers now all use “medium” instead of “med”. E.g. addArousalMedium. Method calls using the old names will now be invalid and will need to be changed.
  • Additionally, the methods using Btm as an abbreviation for bottom have been renamed to use the full word.
  • The methods to get and change liking levels all now use “liking” instead of some using “liking” and some “like”.
  • The following methods have been renamed to work better with Velocity's property lookup rules (i.e. starting with “is” or “get”) or for consistency with other changes:
hasLaceTop → isLaceTopped
likesPlayersBreasts → getLikesPlayersBreasts
dislikesPlayersBreasts → getDisikesPlayersBreasts
dislikesNpcBreasts → getDislikesBreasts
hasCheatedWith → getCheatedWith
hasAnxiety → isAnxious
  • Some methods still start with other prefixes (e.g. hasCondom), if I felt their names wouldn't make sense if replaced with get- or is-
  • Rigel created an awesome user-defined language file for notepad++ that does syntax highlighting for Newlife's vm text files of velocity text within tags. They've kindly given permission for this to be included in the release and it can be found in the documentation folder. If you find this useful then be sure to give Rigel a thumbs-up if you see them online!
  • Updated the example for adding items to a list, based on some feedback from Rigel. The old example would send unwanted text to the output because the list.add method returns a boolean which needs to handled (by assigning it to a variable) or it'll end up in the output text.
  • Added the makeFriend and endFriendship methods to NPCs.
  • Added the isAllowedMoreFriends method to the PC.
  • Fixed an issue reported by Eulexia where the $scene context item couldn't be referenced in action short- or long-descriptions, even though some methods like capitalise and addPossessiveSuffix have obvious potential uses there.
  • Added getCheatingSeverity() method to male NPCs.
  • Added clearCheating to male NPCs.
  • Added a method $isNpcHidden to the Scene object that lets writers test if an NPC has been hidden via the hideNpc method.
  • Added the getStrength method to all characters, returning an integer value.
  • Added the getGirlOrWoman method to the PC.
  • Added 2 new testing traits to NPCs, for situations where a scene needs more than one.
  • Added isNpcRough and isRoughAgreed methods to the scene object.
  • Added isClothesDisarrayed to the PC object.
  • Added getOrgasms to the PC.
  • Added getCockDesc to male NPCs – not sure how I missed that one in the previous version, but it's in there now.
  • Added setActiveMaleNpcNoArousal along with updates to the documentation for this method and the similar setActiveMaleNpc one to clarify when each should be used.
The new method is intended for use in the intro for sub-scenes whose parent has already used the male NPC's attractiveness to modify arousal. This lets the writer have them stored as active without double-counting the modifier.
  • Writers can now check and set relationship flags on NPCs.
  • Added clearPostSexFlags method to the scene object. This is important for clearing down post-makeout flags after they've been handled in a returning section, so they don't confuse the situation if the player transitions to another makeout later in the scene chain.
  • Added a list of commonly-used scene flags to the enum reference (although they technically aren't an enum, as a flag can be any String). These may be useful to control how sub-scenes work, or to handle specific situations on returning from them.
  • The custom scene testing scene now sorts NPCs by alphabetical order when they're being chosen, so you can name your custom NPC “Aardvark” if you want him top of the list.
  • As suggested by Rigel, text is now trimmed of trailing and leading whitespace before being sent to the UI. This will not prevent unwanted whitespace within the text (e.g. mid-sentence line breaks) so watch out for those in testing.
  • Improved the error message returned when a condition from the yaml file fails evaluation in Velocity.

Enjoy the new version, and let me know if you find any bugs! 

Monday, 18 September 2017

Custom Scene Example part 4: Filling in the action text

Hi all,

My last post went over defining the first part of the blackmail scene's actions. At that point the actual text in the .vm file was mostly just todo comments. The next stage is to actually fill that in.

This also involved a few adjustments to the yaml file, so you should download both of the new ones before running the scene: the yaml and the velocity.

It's important to run tests as you go. I found issues in almost every single action while testing, although these have all been corrected in the above files - let me know if you spot any undetected bugs.

In my next few posts I'll be putting the spotlight on certain specific parts of the text and discussing them. Let me know in the comments if there are any you want to focus on.

Thursday, 14 September 2017

Custom scene example part 3: Starting with the YAML for the first part of the scene

Hi all!

This is the 4th post in this series about making new scenes for Newlife. For the earlier posts see: Intro, Overview &Preconditions, Planning.

A quick warning: there are some changes to things like method names coming in 0.4.12. As such, the examples given here will not work properly in older versions.

After planning a scene, the next step to actually making content. There are a number of ways to do this, and you might find your process is different from mine – that's fine.

One approach I sometimes use is to simply write out a key path from the scene in a text document and then convert it into actions.

For this scene though, I'm taking the opposite approach: I'm going to define the actions first and then I'll fill them in with actual text later. This has the advantage of letting me run tests early on while the files are quite simple.

I'm also splitting the scene up into sections. To start with, I'm just doing the parts in the Part1 diagram from the planning stage. This makes sense for this scene because part1 covers the path where the PC complies with blackmail while all the other paths split off from a single action: the one where her partner finds out about her cheating.

You'll see some slight changes from the planning stage such as the new "agree meekly" action and in later posts you'll see that I end up making some changes to the yaml files as well.

That's normal. Scenes usually get refined as I work through them and come up with new ideas. The plan is supposed to help organise my thoughts and understand how the scene will flow: it shouldn't be an inflexible commitment.

I've uploaded these first-step files: YAML and VM. You can run them the normal way, by copying them into the newlife/additional_scenes/user_custom_scenes folder, enabling custom scene testing in the game options and then choosing the test custom scene weekday-evening action. 
You'll need to use 0.4.12 or later for this to work - that isn't possible at the time of writing, but I'll try to get a dev version out with these custom-scene changes soon.

Saturday, 9 September 2017

Custom scene example part 2: Planning the scene

Hi all!

For the earlier steps in this example see the intro and part one.

Once you've decided on your scene's overview and preconditions, it's time for detailed planning.

This isn't something you need to share on discord, although of course it's fine to do so if you want feedback. Instead, it's a final step to make sure you yourself have a good idea of how your scene will be structured.

This can also help notice any issues where your scene might not be supported by the custom-scene framework. In this case you can raise the issue on discord, patreon or another site I read. I might be able to make addtions to support your scene. If not, you may have to work around limitations or maybe take a different approach to a certain path. This will vary on a case-by-case basis, and it's good to know early on before you start serious writing.

In my design stage I came across a number of issues. For example, version 0.4.11 did not allow custom scenes to un-friend an NPC. So, I ask the dev to add a method on discord. Fortunately they were willing to do so:

How you plan your scene will depend a bit on its overall structure. Turn-based scenes, despite usually being larger, have a simpler plan: just lists of key actions for each character.
Flowchart style scenes such as this example one can be sketched out as graphs of nodes representing the PC and NPCs actions.
Usually flowchart scenes don't use the NPC-action system. Instead, the NPC's actions will be rolled into the PC ones. For example, the PC action "answer the door" will automatically be followed by the jerk NPC making his blackmail demand.

For this example I've used software to make a proper flowchart, with circles representing PC actions and rectangles for everything else.
This isn't what I always do. I usually take a less formal approach to planning – I'll sketch out the design in pen on the back of an envelope.
You don't need to spend this much time on your scenes. Your plan doesn't need to be an example on a blog – it just has to help you understand how your scene will work.

It's also fine for your scene to vary from the plan as you work – in fact it usually will, as you come up with new ideas while writing. Still, I think having that initial overview is very helpful.

Here's the plan for the jerk blackmail scene. It's split into 4 files. I'll also use these to work in stages, making the scene in chunks that can be tested before the whole thing is completed.

Wednesday, 6 September 2017

Custom scene example part 1: Overview and Preconditions

Hi all,

Step 1: Overview

The first step when making a new scene is to write an outline. It's a good idea to post this to get early feedback from me or from other writers.
A good place to do this is on discord. Use the general-scene-creation channel and tag me to draw it to my attention.

This is important because it might let you catch issues early on before you start dedicating much time to the scene - for example if someone else is already working on something very similar.

The outline itself should be short: just a few sentences.
It'll also be helpful to follow it with a summary of key paths through the scene – those that are likely to be most interesting to players.

Here's a screenshot of how you might report a scene idea on Discord:

Step 2: Preconditions

The next step is to decide on the preconditions. You don't necessarily need to report these to me, unless you're unsure if they can be implemented in the game.
It's helpful to decide on them early though because they'll affect your writing.
For example, this example scene requires that the jerk has the "jerk" personality, which means there's no need to write content for other ones. Choosing your preconditions before you start work might help avoid wasting time writing content that'll never be seen by players.

You can also write comments about scene frequency in your precondtions. This isn't important for your writing, but it'll be helpful when I connect the scene up to existing Newlife content.

My preconditions for the blackmail scene are as follows:

The PC has a partner.
A male NPC exists for whom all the following are true:
- Is not the PC's partner.
- Is not a restricted special NPC (i.e. does not have the no_random-appearance trait).
- Has the Jerk personality.
- Does not have max liking (close level) towards the PC
- Has not been TROUNCED by the PC, and has not had a negative outcome from previous blackmail attempts.
- The PC has cheated on her partner with this NPC, and that cheating has not been discovered or timed out.

Any severity of cheating is valid (other than NONE, obviously), but the scene should perhaps be more common at higher severities.

The overview and preconditions should be added to the top of your YML file, in a comment. You should also add the username you want to be credited as in the changelog, unless you want your submission to be treated as completely anonymous.

Tuesday, 5 September 2017

Custom scene example: Introduction

Hi all!

For the next release I'm going to work through a new scene for the game using Velocity & Yaml as an example for scene-writers. I'll be showing the full process, including non-writing steps.

This will probably take longer than adding content in the Java, especially as I'll be documenting the process, but I think it'll prove valuable for getting other people's work into the game in the future.

Unlike the existing example scene, this one will be a proper in-game scene that'll be fully included for everyone to play through as a random event.

This will be the only major change in 0.4.12, so it'll be a smaller release than usual: hopefully this means it'll also be quicker, although it's hard to be sure how much overhead doing this as an example will add.

There's a few things writers should know about this new scene:

It's a narrative scene structured in a flowchart-style. As such I don't expect to make any use of NPC actions or the default PC action functionality. These are primarily used for turn-based scenes, which are often larger and more complicated than the scene I'll be adding.

It's difficult to be certain of the scene's size, as I have a tendency to go off on writing tangents and make things bigger than they need to be. However, the intention is for it to be a mid-sized scene. Not so big that it's confusing to read, but not so small that it's trivial as an example.

The writing process will involve new functionality being added to the custom scene system. For example, I've added a new method to retrieve cheating severity.
This isn't ideal, but it's necessary because it's quite a new system and because I'll be working with some new game mechanics that haven't been fully fleshed out yet for custom scenes.

You might find yourself in a similar situation if you're a writer. If you're making a scene and find that you need a certain transition or method that exists in the main game but isn't available for custom content then you should just make a post, comment or discord message (flagging me to get my attention) and ask me to make the change. I expect to be refining the custom scene system over several releases before it reaches its final state.

In the long-run, once the system gets more mature I expect it should reach a point where changes only need to be made when new game mechanics get added. That'll make things a lot easier, and it's a place I want to get to before I start comissioning paid writers to work on the game.

Wednesday, 30 August 2017

Forum replies and other communication with players

Hi all,

For 0.4.12 I'll be using the custom-scene system to add an actual scene to the game itself and writing a series of step-by-step blog posts to show how that's done.

Before I start posting those, I think that I should probably talk about something that's a bit of an "elephant in the room": my terrible record at replying to people.

When Newlife began I answered almost every forum post, PM and blog comment. As more people played it, I started receiving more and more feedback, and my efforts to reply to everyone fell more and more behind.

Part of this is a bit of a character flaw I have. I'm perhaps not the most outgoing of people and I especially don't relish writing posts that might make someone unhappy.
The bulk of my backlog involves requests for additions to Newlife, especially the grey-area ones where the request is something that reasonably could be added, but that isn't part of my core plan and I therefore don't feel comfortable making a binding promise about.

I can't reply with a yes because I get change requests through much faster than I can add content so it's simply impossible to do everything. I don't want to reply with a no because that makes me feel bad, especially when there's a chance their request might make it in at some point in the future. Replying "maybe" feels a bit like a lame cop-out. So, I just ignore the issue and let it languish for ages on my "to-reply" list.

What's worse, I often let this stop me answering people whose posts I could easily respond to. If there's a post earlier in a forum thread that I don't have a reply for then I feel like it needs to be handled first, and so later posts stay in purgatory until I come up with a proper reply.

I was beating myself up a bit over this a while back, when I came to an epiphany: when someone posts a change request for Newlife they aren't really asking for a personal reply to their post. What they actually want is just for me to read their request and consider implementing it.

So, I'm going to officially put an end to the "I attempt to reply to everyone" policy. Here's my new one:

First, I want to be clear: I do like it when people post and make suggestions. You should absolutely do so if you have an idea you think I should read. Just because I can't reply to everyone doesn't mean I don't like you posting!

Posts with change requests usually will not get a reply unless it's trivial to decide on a yes or no answer. However, I will read them and consider adding the request to the todo list. If I implement it then I'll make an attempt to credit whoever made the suggestion in the changelog. I might sometimes miss someone, but I'll do my best.

The same goes for bugfixes that don't need follow-up questions to fix. I might post a quick "thanks" comment, but I'm not going to feel obligated to do so. Again, people who report bugs that get fixed will generally be credited in the changelog. If you aren't a patron and you've found a bug that needed to get solved then you can PM me (on the forum where you originally reported the bug so I know it's you and not some credit-stealing internet joker) and I'll hook you up with the patreon version as a reward. This only applies to bugs and not change requests: for the latter the reward of seeing your desired content in the game should be enough!

Change requests phrased as rhetorical questions will usually get treated the same. E.g. "Will this game ever have x?"
Some players might want an answer because they're considering supporting the game on Patreon on the condition that it'll at some point include their favourite content. Do not do this.
My view of Newlife on Patreon is that you should only support the game if you enjoy it in its current state and want development to keep going, not because you're hoping it might become a game you'll enjoy in the future. I'm proud of never having gone a month without releasing an update, but nevertheless, like any single-person project Newlife is just a serious injury or bullshit anti-porn law away from cancellation or "indefinite hiatus". If you're supporting the game then you should feel that even if it was cancelled tomorrow you'd still have got a game you enjoyed playing out of my time developing it.
On a personal note, I also don't like the pressure of feeling that there are patrons who won't have liked the game unless it ends up with specific content. My request: only support the game based on how it is at the moment, not on how it might become in the future.

So, that's the new plan for communications. As for the blog, I'll be posting a lot more soon: not only is there the user-submissions stuff but I'll also be running the next PMW vote in September, and I also have a half-written post about nonconsent content to finish up.
Hope you're all having a good week :)