Page 2 of 2

Determining Victory or Loss - Fightoutcome

PostPosted: Tue Dec 17, 2013 6:20 pm
by TigerStripes
ORIGINALLY POSTED: Aug 21/2012 (updated and edited when reposted)
As I'd mentioned earlier, I've completed and put the new fightoutcome variable into effect. The way this will work is it will read the various outcomes of a fight: win/lose/libido overload/flee/etc... and be given a specific code for it. As well, I've altered the few spots where combat is forcibly ended by a creature and set the fightoutcome variable accordingly.

The main breakdown of these values are as follows. These values are recorded at the top of the Alt Combat extension:
Plaver Victory: 10 through 19
10 * victory
11 v. (submit to player master)
13 v. (player vores foe)
14 v. (player ub's foe)
18 v. (monster flee)
19 neutral peace

Player Loss: 20 through 29
20 * loss (dmg)
21 * loss (libido)
22 * loss (submit)
23 loss (vored)

Player Flees: 30+
30 * player flee
100 * starting value (assigned automatically)

Using this variable when making scenes (situations or quest-induced fights), you can track the outcome of a battle in much greater detail without recoding the monsters involved. This will also let you do this for random creatures from the 'fight' command without resorting to 'lost'. The 'lost' variable has remained unchanged, letting it function as normal for content already using it.

The values with an asterisk are the only ones which the combat system will apply unless a specific creature trait or alt-combat attack dictates otherwise. The base value of 100 is treated as fleeing in case something forcibly ends the fight w/o assigning a new fightoutcome value. This should not happen unless there is an error of some kind or a combat abort was initiated without assigning a value.

It is worth noting that the general player vore and player UB content is programmed to not occur during situations due to the possible plot holes that could occur in scenes after the fight if the enemy was consumed. They are mainly there for completeness, though victory/loss scenes directly within the creature which result in vore/ub should result in the appropriate fightoutcome being set by that scene for accuracy.

To use this variable:
After your fight/challenge has occurred, you simply need to check the ranges of results to classify the outcome. The most basic method of this is as follows:

Code: Select all
    challenge "Feral Wolf";
    if fightoutcome >= 10 and fightoutcome <= 19:
         say "The player has won.";
    otherwise if fightoutcome >= 20 and fightoutcome <= 29:
         say "The player has lost.";
         say "The player has fled.";

If you only care if the player has won or lost/fled, this can be simplified to:

Code: Select all
    challenge "Feral Wolf";
    if fightoutcome >= 10 and fightoutcome <= 19:
         say "The player has won.";
         say "The player has did not win.";

Where this gets more useful is once you start doing stuff like this:

Code: Select all
    challenge "Feral Wolf";
    if fightoutcome >= 10 and fightoutcome <= 19:
         say "The player has won.";
    otherwise if fightoutcome >= 20 and fightoutcome <= 29:
         say "The player [if fightoutcome is 21]gave into their lusts[otherwise if fightoutcome is 22]gave up[otherwise]was beaten[end if].";
         say "The player has fled.";

One could also make specific results for certain outcomes by dealing with those specific values before examining the ranges:

Code: Select all
    challenge "Feral Wolf";
    if fightoutcome is 22:
         say "The player gave up and submitted to his enemy, with a different result.";
    otherwise if fightoutcome >= 10 and fightoutcome <= 19:
         say "The player has won.";
    otherwise if fightoutcome is >= 20 and fightoutcome <= 29:
         say "The player has lost.";
         say "The player has fled.";

It is strongly recommended that you not bother making specific outcomes for most values, but the possibility exists if needed for storytelling purposes or if you have the player challenging a creature which uses an unusual value and you need to specifically watch for that result. For most events, just using the basic two or three categories will be sufficient. And as demonstrated, tweaks can easily be applied using an [if] to slightly alter the text.

I hope this will be useful for everyone to better track fight outcomes. Let me know if anything's unclear.

Using More/Less Anal

PostPosted: Tue Dec 17, 2013 6:30 pm
by TigerStripes
As can be seen in the blog, we've got a new feature open to you to use to add more targeted M/M fun (and anal fun in general) for players interested in it.

First off, are you required to use it?
While I do hope you'll consider doing so from time to time to improve the experience for the players, it is your choice to use it or not use it.

Why only More Anal and Less Anal instead of all M/M?
This is a sex-ridden world the players are experiencing and the males out there want satisfaction just as much as they do. It would be completely out of the game's character for none of the males to do anything sexual with the player, even when having beaten them. Anal sex and anal play has a higher squick factor than M/M interplay, so reducing it will considerably improve their play experience. If the player's cannot even accept some M/M content then they need to either play with guy banned or this is not the game for them. On the other side of the coin, some players want and prefer the M/M and anal content and want to see more of it. This allows more herms to pick M/M action with a male player instead of going for vaginal sex which they may have little or no interest in. This means more creatures and scenes can be opened up to more players by giving them more enjoyable fun with creatures they would otherwise have to avoid due to the content they provide.

What this means for you?
Because the player can now give an indication of whether they'd like to see more or less anal play in the game content they experience, that leaves you free to include or expand upon anal sex scenes in ways you may not have felt comfortable in doing so before or make anal scenes only for those who specifically want them instead so your creature can be more M/F in general play. If you have a scene in mind were a defeated player is subjected to anal sex, but are worried about displeasing players who don't enjoy M/M content, you can hide it behind a 'Less Anal' restriction. Want to make a random player victory sex result be anal sex, you can make 'Less Anal' block it or have 'More Anal' make it more frequent. If you want to make an in-depth sex scene with lots of anal play, tacking on a requirement for 'More Anal' means only those truly interested in getting it will see that content. Want to drop in a some quick rimming to an M/F fellatio or cunnilingus scene, hide that part behind a requirement for 'More Anal' and there you go. In the mood to write an F-anal or F-dom scene with pegging? Slap 'More Anal' on it and go to town.

As you can see from these examples, you can use this as a means to control the amount of additional anal sex you want to add to content you're making. If you want less, but feel you must include something, then put it behind 'More Anal'. If you want to let straight players avoid the anal scenes for your new male creature while still giving them the chance to freely experience the rest of your creation, then restrictions based on 'Less Anal' are the way to go. To a large degree, it will be to your own discretion as to how you wish to implement this in any given situation.

The use of this is not just restricted to your own new content. You can use it to add or control M/M and anal content for existing content as well, helping players get more of the experience they want out of the game by tailoring the scenes or sex acts chosen to suit them. If you feel a creature where a losing player's forced in the M/M anal sex should have a non-anal result for those with 'Less Anal', then make an alternate scene and put it in. If you feel a victorious creature should mount a male, but they don't, then make an alternate scene for that and make it require 'More Anal'. If you think an existing scene would be a little kinkier with some added anal play thrown in, then slip it in with a requirement for 'More Anal'. Similarly, if a scene already includes some added anal play going on, you can restrict those with 'Less Anal' from seeing it. It is important to consider the nature of the scene involved and the original author's intent.

Should I use this for all anal and M/M content, or try to use it everywhere?
Certainly not. There are many situations in the game where it would be inappropriate to include features for one or both of these settings. Do not feel you need to invent M/M or anal content for those who want it into every scene and situation. As well, there is no need to restrict M/M or anal content from situations where it would be inappropriate to do so. As stated, it's More and Less, not Always and Never.
You do not need to add anal fun to a female character or creature just to have something for those with More Anal to find if you don't feel it's appropriate.
If a male player's solicited sex from a male NPC, they should expect anal as a serious possibility and you should not restrict by checking against Less Anal.
Similarly, if a male player solicits sex from a straight male NPC, do not feel you have to give the More Anal players an M/M scene unless you feel it's appropriate (they're a little bi).
If your event/quest/encounter involves the player witnessing anal sex as part of the plot, don't feel you have to rewrite it all for version where that never occurs for those with 'Less Anal'. (Though you could opt to hide some details for those players or have a normal, generalized version and add an x-rated uncut version with all the juicy details for those with 'More Anal' instead as a fun option... if that floats your boat. :) )

How are these implemented?
You have two options when calling upon the More Anal and Less Anal data. Primarily, they are saved among the player's feats so that they'll be easily visible for the player to see their setting. As well, since lots of other content is checked via feats, it is easy to do so. At the same time the feat is set, the anallevel variable is adjusted between 1 and 3. 1, the lowest value, represents Less Anal and 3, being the highest, is More Anal. 2 is the standard value and represents the normal level of anal and M/M content the game provides. Whenever the player changes their assigned value, it will remove the opposing feat (if present) and put in the new one (if applicable) and also save the new value for anallevel.

How do I call upon them?
The main reason this feature is saved as both a variable and a feat is to allow you an easy means to check it while built into say statements (because the " marks around the feat name would break a normal say statement). Outside of that, I would recommend using the feat name method, as it makes scanning through the code much easier to read and see what is going on as well as spotting where something may be working opposite to what was intended.

Here's a series of examples on ways to make checks on these settings:

Is a player set to get More Anal?

Code: Select all
    if "More Anal" is listed in feats of player:
    [if anallevel is 3]

Is the player set to get Less Anal?

Code: Select all
    if "Less Anal" is listed in feats of player:
    [if anallevel is 1]

Something those with Less Anal shouldn't see:

Code: Select all
    if "Less Anal" is not listed in feats of player:
    [if anallevel is not 1]

Something those with More Anal may randomly get:

Code: Select all
    if "More Anal" is listed in feats of player and a random chance of 1 in 3 succeeds:
    [if anallevel is 3 and a random chance of 1 in 3 succeeds]

Something that will occur more frequently for More Anal:

Code: Select all
    let analchance be 2;
    if "More Anal" is listed in feats of player, increase analchance by 2;
    if a random chance of analchance in 10 succeeds:

The same as above, but those with Less Anal don't get it either:

Code: Select all
    let analchance be 2;
    if "More Anal" is listed in feats of player, increase analchance by 2;
    if "Less Anal" is listed in feats of player, decrease analchance by 2;
    if a random chance of analchance in 10 succeeds:


Code: Select all
    let analchance be 2;
    if "More Anal" is listed in feats of player, increase analchance by 2;
    if a random chance of analchance in 10 succeeds and "Less Anal" is not listed in feats of player:

Another way to make it more frequent:

Code: Select all
    if a random chance of 1 in 5 succeeds or ( "More Anal" is listed in feats of player and a random chance of 1 in 3 succeeds ):

Something those with More Anal get always, standard gets sometimes and Less Anal gets never:

Code: Select all
    if ( "More Anal" is listed in feats of player or a random chance of 1 in 3 succeeds ) and "Less Anal" is not listed in feats of player:

Slipping additional anal play details into a scene for those with More Anal:

Code: Select all
    say "This is some sexy stuff going on.  Oh my god, it is so hot.  And then they go and [if anallevel is 3]start rimming you on top of it.  They do that for a while before switching[otherwise]switch[end if] to do some other kinky stuff.  Blam!  Sticky mess!";

Skipping additional anal play details in a scene for those with Less Anal:

Code: Select all
    say "We have some kinky tentacle action going on here.  The creature's got a tentacle stuffed in your pussy[if anallevel is not 1] and another in your ass, squirming them[otherwise], squirming it[end if] around inside you, making you moan.  You have lots of hot, sticky fun together.";

You can take the above, mix and match them or include them as part of other checks to create even more variety.

These and many other creative possibilities abound with stuff like special 'Easter Egg' scenes, opportunities to let more players enjoy your creations, vehicles for special customizations to scenes, opportunities for new characterization from NPCs or creatures and many others. I look forward to seeing what fun things you create using this new mechanic.

New Inventory System

PostPosted: Tue Dec 17, 2013 6:43 pm
by TigerStripes
Now that we've gotten the last of the files updated to the new inventory system, I thought it would be best to make a quick summary for developers on how to use it. It's quite straightforward, actually.

But before we begin, I must ask that you all ensure that you update your files from the Git Hub at your earliest opportunity. Changes were made to most files, especially those involving quest items, fetch quests, trading/giving items, etc... As well, some typos, fixes and tweaks were made while performing this update, so making sure you have the new version is very important even if you don't plan on making further updates or you believe a file may not have been affected. Once you get them, activate them in Inform as well.

Ok, with that said, let's move on to the meat of it:
Where in the past, a list was used to keep track of a player's inventory, the size of this list and the increased number of items in general has required that this system be removed. The new inventory system is remarkably simple, with every item in the game now possessing a numerical property called 'carried'. The 'carried of food' is the number of food the player has in their inventory. Lists for items will still be used for all locations.

Basic Manipulations:
Because the inventory is contained in numerical values for each item, these can be directly manipulated to add and remove items from the player's inventory. Nuku has made substitutions to allow the previous 'add/remove [x] from invent of player' to still work, but the more direct route is to now adjust the 'carried of x' value.

1> Knowing if the player possesses a given item:

Code: Select all
    if food is owned:


Code: Select all
    if carried of food > 0:

While both are pretty much equivalent, using the 'owned' method is recommended for general use, since it is more straightforward and you'll most often be checking for a single item. The second will become useful when you need to check if the player possesses several of a given item (fetch quests, etc...). This is far simpler and faster than the searching and counting method which was previously required.

2> Adding an item:

Code: Select all
    increase carried of food by 1;

This command can also be adjusted to give more than one of any given item to the player with a single command line. It should be noted that 'add "food" to invent of player;' will still work, but it not as efficient for everyday use. Systems that use the loot entry from monsters (or some other text), must go through the 'add loot entry to invent of player' system.

3> Deleting an item:

Code: Select all
    delete food;


Code: Select all
    decrease carried of food by 1;

The first of these is recommended for general use, as you'll usually only be removing one item at a time. Deleting an object also comes with an error message should the code attempt to delete an item that is not in the player's inventory. The carried of that grab object will then be set to 0 to avoid negative values. The second option is only really recommended when you must delete several of a given item from the player's inventory at one time. In this case, it is imperative that you correctly ascertain if the player has enough of the given item before proceeding (see 1 above).

4> Running the effects of an object:

Code: Select all
    process food;

This command is unchanged and will be rarely used, but I am including it since it deals with manipulating items and inventory. Inclusion of this will cause the given items normal 'use <item>' effect to be activated. Since this will often expect the item to be in the player's inventory, it is again imperative to make sure the player possess the item in question, especially if this is a temporary or otherwise consumable item.

5> Dropping an item:

Code: Select all
    try littering food;

This will force the player to drop an item into their current location (if possible) as if they'd typed "drop <item>" with any of the appropriate messages appearing. Alternatively,

Code: Select all
    add "food" to the invent of the location of the player;
    delete food;

This will remove one food from the player's inventory and add one food to the inventory of the room without any of the normal messages from dropping. It is imperative in cases like this to ascertain that the item in question is not the player's equipped weapon (wielded) or equipment in use (equipped). It is also imperative to make sure the player has a copy of the item to drop at all before going ahead with this as well, otherwise you'll cause an error and generate a new item without the player losing one.

Advanced Manipulations:
6> Repeating effects for multiple items:

Code: Select all
    while carried of soda is not 0:
       delete soda;
       <effects of each individual soda>;

The above example is taken from the Sugar Ferrets who will drink away all of a player's carried soda, each time adding to the overall effects. This code is considerably faster and simpler than the previous method required. This sort of manipulation will rarely be required, but this is how it can be done if the item is being consumed or otherwise removed from the player's inventory until they're all gone with an effect for each one.

Code: Select all
    repeat with y from 1 to carried of garlic:
       <added effect for each garlic currently possessed>;

The second example is the sort of thing which would be necessary if the items were not to be removed from the player's inventory through this process. While I don't think there is anything that uses this sort of set up currently and just made something up, this is how you could go about doing it. Often though, you could just multiply the effect by the 'carried of <object>' to the same effect.

7> Referencing a grab object when starting from text:

Code: Select all
    repeat with Q running through owned grab objects:
       if the printed name of q matches the text chosenmilk, case insensitively:
          delete q;

The above example is taken from Elijah and the Kitty Cat. Having earlier obtained the text "chosenmilk" (containing the name of a grab object in text form), the actual grab object can be found. In this case, that sample of milk is then deleted (since it was chosen for use in the above scene and now we're just cleaning up). A manipulation like this can be used to go from text to the grab object you seek so you can then do whatever you need. Usually, this sort of thing will not be necessary, since you can almost always just deal with the object directly or will be only dealing with one specific object and can deal with it by name.
NOTE: This has since been reworked without needing to function in this manner and also display the number of various milks in the player's inventory when making the selection.

Grab Object Properties:
The grab objects in the game possess several properties and attributes which can be handy to know if you want to create more interesting effects. These have not changed with the new inventory update, but I felt it best to cover some of this information here as well.

8> Grab object adjectives:
Grab objects can possess several adjectives (which represent qualities they possess). These ore usually set when the object is created by the game, but some can be defined by definitions to vary during the course of the game.
Potential attributes include:
owned - at least one of these in the player's inventory
temporary - deleted after use
fast - can be used in combat
infectious - in infectious when used (as set by its strain).
milky - an attribute which can be given to drop items to designate them as a form of milk.
wielded - is assigned to be the player's current weapon. Only one can be wielded at a time.
present - is in the inventory of the player's current location.
fiveowned - the player possesses 5 or more of this object in their current inventory.

These indicate to the game when and how these objects can be used, but can also be used to narrow down searches or otherwise limit a selection of items. For example, in part 7, the code searched through only the 'owned game objects' because we know we're only dealing with items which the player has in their inventory.

9> Types of grab objects:
Some grab objects in the game belong to one of two subsets with their own assigned variables, attributes and so forth. I will not go into detail of these past covering the two basic categories and including their potential adjectives in parentheses. These sets can be used as part of code manipulation to further narrow down searches, avoid deleting equipment in use, etc... Examples of these checks can be found in the code dealing with dropping items and using items, among others.
armament - a weapon object which can be wielded for combat (improved, wielded, ranged/melee)
equipment - a non-weapon item which can be equipped into various slots on the player's person. See the post on equipment and armour. (improved, equipped)

If I think of more examples, I'll likely insert them later. I know there were more tricks I used when making the update, but cannot think of them all at this point.

Clothing and Armour

PostPosted: Tue Dec 17, 2013 8:21 pm
by TigerStripes
EDITED: July 5/2015 - Trial increased to shield stopping power (from AC / 5 to AC / 4).
At Nuku's prompting, I have reworked by update to the armour system. It is somewhat fancier, but I think it does a pretty good job of balancing the armour items, the feats and their overall effectiveness. Most of the complication is held in the background numbers. Coders need only be aware of the values used in the table guidelines below or to pick the appropriate absorbancy subroutine when building an alternate attack (there are lots to pick from). There is a thorough explanation of the system and the meaning behind the numbers, so I'd like for people to please try to stick within this. This has been a rather frustrating update to create and I don't want to have to redo it again or chase after items that break the rules. If you can't follow the guidelines, don't make armour. *grumbling in advance* Please keep an eye out to see if there's any unusual bugs or if the armour provides too much defense or not enough.


With this fixed and updated, we can once again start creating the occasional armour item as well as clothing items w/o game effect. Most clothing items are going to be purely cosmetic and not provide any significant protection. They are meant to allow players a means to customize the character's appearance. Remember, the starting player is not typically going outside nude, but is implicitly understood to be wearing clothes with nothing noteworthy about them. Normal clothing provides no armour bonus - so set their AC and effectiveness values to zero.

Clothing items, while not providing any combat benefit, may provide more esoteric bonuses or effects in certain situations. This could be stuff like constant infection, situation specific bonuses, a means of entrance to otherwise restricted areas, etc... These would either have to be managed with 'everyturn rules' or with direct checks in events to see if the player is wearing that specific item. This sort of thing would be uncommon, but ideas are possible.

Equipment in this game generally means worn/carried clothing items, but can also represent some equipment held somewhere on your person. When created, they must be assigned a location where that item is placed. These include 'face', 'body' and 'head' currently, but other placements could be made. A player may only equip one item in each location.

Code: Select all
    Table of Game Objects (continued)
    name   desc   weight   object
    "combat helmet"   "A basic army helmet. It should provide some minor protection while worn."   1   combat helmet

    combat helmet is equipment.
    It is not temporary.
    The AC of combat helmet is 25.
    The effectiveness of combat helmet is 60.
    The placement of combat helmet is "face".
    The descmod of combat helmet is "A green and brown camo army helmet rests atop them.".
    The slot of combat helmet is "head".

- The AC and effectiveness values apply to armour and are discussed below.
- The descmod value is the snippet which will be included in a player's description when they look at themselves. It should probably be confined to short sentence to keep the player description from getting too large. More detail can be seen by looking at the item on its own.
- The placement value dictates where in a player's description that item's snippet will be inserted. The current options are "face", "body" and "end". "face" will show after a player's face is described. "body" will be shown after the body. "end" is included after the player's tail, but before their genitalia. "end" is the default value. Other placement points can eventually be added.
- The slot value dictates which slot it fills on the player's person. Currently, only "face", "head" and "body" items exist, though others can be used. Just be careful not to invent new slots when an existing slot could be used. Players are only allowed one item per slot.

Armour may only be: head or body. No other armour locations are currently allowed. This exists to maintain some modicum of game balance and to keep me sane.
Armour has two values which affect how useful it is in combat: AC and effectiveness.
AC: This factors into how much damage a given piece of armour can potentially block.
Effectiveness: This represents how effective the armour is, resulting in how likely it will block a blow coming at the player. A check is rolled to see if the armour is effective. If so, it gets its full defensive (AC) value. If it fails, it may still grant partial protection.
This provides a little more variety in the results of outcomes and helps represent partial armour vs full coverage armour, armour with gaps or weak points, etc...

- Currently, we will be starting with a maximum AC value for any piece of armour to be 50, but will later expand this out to 100. The effects for values up to 100 are listed here, but that's for future reference. As you can see below, an AC of 50 can provide up to 34% protection, a very sizable drop in damage.
- This value gets combined with a player's natural protection, which has a base value of 10 and can be boosted by feats. (see below)
- Shields protection happens before armour protection is calculated. (see below)
- When the player's armour (body armour or helmet) blocks a blow, it will block a percentage of the damage to the player. The type of blow (head or body) will be selected at random for the determination of armour protection. The exception to this will have some special attacks which target one or the other.
0 - Normal clothing with no appreciable armour value.
10-15 - ~12% damage reduction for 10, ~15% for 15 - provides minimal to low protection, but could take the edge of some blows, but not a very effective as armour. Heavy leather jacket or life jacket.
20 - ~18% damage reduction - provides some protection. Protective padding, leather armour.
25 - ~21% damage reduction - provides good protection, equivalent to the "Toughened" feat.
30 - 24%
40 - 30% - Chainmail
50 - 34% - very good protection. Bulletproof vest.
60 - 38%
70 - 41% - great protection
80 - 45%
90 - 47.5%
100 - 50% - excellent protection, half damage

The effectiveness of a piece of armour dictates how often it will provide full protection, thereby approximating a direct hit to that armour. The main factor in this is the amount of coverage they provide to their area, though other factors could be used as well, such as gaps, weak points, poor fitting, coverage of vulnerable or vital areas, etc...
If the effectiveness does not succeed, it will still provide a fraction of the protection, meaning all but the weakest of armour has a chance to do something even if the effectiveness fails. This helps represent glancing blows across the armour or slashing attacks that only get blocked in part by the armour. The maximum effectiveness of any piece of armour should be about 80% and that's when they provide total coverage to their area (either a full helmet and neck guard for the head, or full armour suit covering all the body, limbs and extremities.) This is to allow the chance for some blows to still get by and for feats and upgrades to improve these numbers a little further (see below).

Head gear: The head will be considered the target for 25% of the blows to the player, necessitating a check to their head armour. Here a breakdown of effectiveness values for head armour. This does not say anything about their damage absorption capabilities, just how likely they are to block the blow to their full AC value.
Top of the head: Typical biking helmet, magic baseball cap: ~40%
Full face only: Hockey mask (à la Jason), welding mask: ~50%
Cranium: WWII helmet: ~60%
Full head, no face: Motorcycle helmet: 65-70%
Full head and partial face: Football/Hockey helmet w/grill, aviator's cap w/goggles: 70-75%
Full head and face protected: Riot helmet with face guard, knight's helm w/full visor: 75-80%

Body Armour: The body will be considered the target most of the time, being selected 75% of the time, necessitating a check to the body armour. Something that provides complete torso coverage has an effectiveness of about 60% and full coverage of the limbs is needed to reach the full 80% max.
Here's a breakdown of some examples of effectiveness for body armour, which again doesn't say anything about their damage absorption capabilities.
Minimal, mostly useless coverage: Single shoulder pad: ~10%
Minimal (but useful) coverage: Knee and elbow pads: ~20%
Minimal torso coverage: Chainmail bikini: ~25%
Partial torso coverage: Life jacket, baseball catcher's pad, ~40%
Good torso coverage: Football pads: ~50%
Full torso coverage: Bulletproof vest (55%), chainmail shirt w/o sleeves (60%).
Full torso and arms: Chainmail shirt w/sleeves, upper body plate armour, leather jacket: 65-70%
Full torso, arms and legs: Full body armour: 80%

- As mentioned, the player has a base value of 10 natural protection, which has little effect on its own, but has the advantage of always being considered as having been effective. This value allows smaller value armour (10-15) to have some effect when combined with this, but makes little difference once stronger armour is worn.
- The "Toughened" feat boosts this value to 25, making it more effective on its own as the player gains a toughened skin and body, making them naturally damage resistant. A toughened player will still gain minor benefit from weak armour pieces, but he's generally considered to have better natural protection than they provide. A toughened player will be able to provide some additional effect to stronger armour as well. They will also get more consistent protection since they're toughened hide always gains its full protection (basically 100% effectiveness since it covers the whole of the player).
- A second feat may be added later, "Armoured Hide", boosting this natural protection even further. It would probably put the natural armour up to 45, almost as good as if their skin were a bulletproof vest.

Shields in this game are anything held or used in the player's off hand to block or deflect blows from enemies. This can range from an armoured bracer or a catcher's mitt, to bucklers, knight shields, riot shields or even an energy shield. Clearly some of these would be better than others, but they all might help.
Shields provide an improvement from 5 to 20% removed from damage based on their AC value provided they pass their effectiveness check. But as well, if they pass their effectiveness check, a minimum of one point of protection is provided. This means that there's always some gain from a successful block, and more for higher damage attacks.
A failed block has no effect.

This value will not have much variation, ranging between 20 and 100, depending on how much protection it may be able to give. The percentage of damage blocked will be equivalent to the AC / 4 for an effective block. Most shields will be in the 40-60 range ( 10-15% ) and we should probably not exceed 60 for the moment, but they can be made later. The capacity for more extreme values exist for poor shields (catcher's mitt) and exceptional ones (energy shield). This range should not be exceeded, otherwise weak ones would be too low and strong ones would be too high. A block from a shield reduces damage from attacks, as blows which would be completely blocked or deflected are part of to-hit roll.

Effectiveness is a shield's main value and it should go up to a maximum of 80% as with other defensive equipment. This represents how likely the shield is to be useful in blocking to obtain its full defensive value. Smaller or clumsier shields generally have lower effectiveness values, meaning they'll only help some of the time. Larger shields will work more often, but may get to be cumbersome as well. As with armour, flimsy or poorly constructed shields may also have poorer effectiveness values.
Little coverage, low ability to block: Armoured bracer (25%), Catcher's mitt (30%), Garbage Can Lid (30%), Buckler (35-40%).
Good coverage: Medium round shield (45-55%), Kite shield (55-65%)
Great coverage: Riot Shield (70-80%), Tower shield (70%), Large tribal shield (65%). These would likely come with some form of dexterity penalty (maybe something from -2 to -4) as they obstruct your ability to fight in return for their added protection.

Armour and shields should be designed with a balance of AC and effectiveness in mind, and the effort for obtaining such items should be balanced in this regard. A couple of weak armour pieces could just be found lying around, but more valuable ones should require some work to obtain (or someone would have already have taken them). Higher value armour can be used as rewards for events with mid-to-tough fights or short quests. The greater the value of the item, the more time/effort that should be required, in general.

The process of calculating the armour will work as follows:

Shield check: If the effectiveness check is successful, reduce the damage based on the AC at a rate of AC / 4, to a minimum of 1 damage prevented. If the effectiveness check fails, there is no partial block. The remaining damage is then dealt with by the player's armour and natural protection.
Armour check: The target location (head or body armour) is decided and then the armour is tested against its effectiveness. If the effectiveness check succeeds, it gets its full protective value. If it fails, it only gains a random percentage thereof (up to its effectiveness). This is the effective armour value. The amount of protection is then calculated according to the following formula.

100 * dam
------------------------------------------------ = reduced damage.
100 + √ ( effective AC^2 + natural AC^2 )

EDIT: Upgraded Armour: Snow has been tweaked to provide a small boost to armour by upgrading it. The upgrade results in:
- A 5% increase to its original AC, to a minimum of +2 AC to ensure even the low ones get something.
- A 10% increase to its original effectiveness value.
Defensive Skill: A feat to allow a player to better use their armour and shield may come as well. It will probably let the player get a bonus to their effectiveness rolls, showing their increased awareness of their armour and their ability to ensure that blows hit armour instead of player.

Currently, only 2 armour items exist, the leopard suit (created by helping Omio) and the combat helmet shown above (found in an army surplus store).
- The combat helmet is a very average helmet, providing a protection of 25 AC with an effectiveness of 60, as it only covers the brain case and not the face or neck. This is good protection and alright effectiveness for a helmet. Even on its own, it should save the player from considerable damage over time. If effective, it will block 20% of damage if successful.
- The leopard suit is an alchemical creation and has some pseudo-magic powers, making it unusually tough for fabric. Between that and its almost full-body coverage, it is actually good armour with an high effectiveness of 70 to go along with its 16 AC value. It will be effective at blocking 15% of damage quite often.
UPDATE: A few others have since been added.

Here's a bunch of example armour pieces and given rough figures. We may need to adjust these values a little over time, but it'll help give you a starting idea.
Bulletproof vest: Find where a cop made his last stand, perform a difficult stat check or two to gain entry (locating an entry point, climbing to it, forcing a door open...), then fight the creature he became to obtain his bulletproof vest. AC 45-50 at 55% effectiveness, given that it only covers most of the torso.
Chainmail: Valerie wants you to give her a hand with a few things (does not open until the player's a minimum level). She asks you to retrieve some stolen Museum items. After that, she asks you to locate a wayward exhibit (creature), etc... eventually culminating in being given a chain mail shirt/vest from among the items in storage. Typical effectiveness, but weighs quite a bit. (ADDED - Wereraptor by Stripes)
Wolf Armour: Wolfskin pelts that act as armour, which you obtain after a short quest and a fight with the Alpha Wolf (with boosted stats) wearing them. It's a combo of wolf's head helmet and body armour. Each grants about 20-30 AC due to its 'magic', but it's actually cursed, infecting the player with the Alpha Wolf infection every four turns if wearing one item and every three turns if wearing both. There's a chance for some humanity loss as well each time that occurs (0 - 5 points?). Not much, but enough to help wear you down or drive a regular person to succumb even faster. The headpiece and the body armour would have an effectiveness of about 45% due to its piecemeal coverage and overall weaker nature.
Centurion Helmet: Obtainable as a prize after a pair of events in the museum. The first event involves some situation or fight where you see the creature grabbing/wearing the helmet, but it leaves before you can confront them. The second has you finding them again and fighting/stat-checking/trading/etc... to obtain it from them. Somewhat higher effectiveness due to more head coverage (65%?) but a lower protection of about 15-20 AC.
Football Helmet: Obtainable somewhere on campus. There's something odd about it which allows it to always fit your head despite your constant changes. Good coverage results and designed to pad blows makes it very good. AC of about 25-35 with 70-75% effectiveness.
Football Pads: Obtainable somewhere on campus, possibly separate or with the helmet. Provides ~20 AC with good coverage (~50% effectiveness), since it covers less and is made for sports and not combat.
Motorcycle Helmet: Similar to the football helmet in values. I might save this for a gift from Grant for helping him.
Zephyr Field Armour: Padded armour pieces for the shoulders, back and chest with adjustable straps so you can fit it to your changing body. It is normally reserved for their field staff, but they'll add it to their store list after you complete some tasks for them. You'll still have to buy it, but they'll let you get one. Given how some people look at you while wearing it, you quickly find some dark paint to cover the company logo. Probably pretty good values, depending on how strong you'd like to make it. AC of 30-50 (maybe more) and an effectiveness anywhere from 50 to 65, depending on how good (and expensive) you wanted to make it for the player. :)
Single Shoulder Pad: Taken from the corpse of a beefity guy with a grizzled face who clearly had too many muscles for his tiny feet to balance. You know it's not really going to help much, but it's better than nothing and isn't doing that guy any good. 13 AC, but a very low effectiveness (13%) due to minimal coverage. This one's been written up and will be added soon. (ADDED - Scavevents by Stripes.)
Garbage Can Lid: This will be reworked into a crappy shield with an effectiveness of about 30% and an AC value of 28 (5.6%) making it occasionally useful if you've got nothing else. I'll aslo be sending this one along shortly. (ADDED - Odd Weapons by Hellerhound)
-And so on...

The calculations for armour in combat have been split into their own subroutine ( normalabsorbancy ) which will require that the damage to be checked against the armour be updated in a variable called 'damagein'. It will update and output the variables 'damageout' and 'absorb'. Several variations on this subroutine have also been created (all with the same in and out variables) to potentially be used as part of alternate attacks if armour protection is somehow affected. The list of those I've created are listed here:
normalabsorbancy - normal absorbancy, used most commonly
highabsorbancy - increased chance to block better
weakabsorbancy - only partial absorbancy
headabsorbancy - automatically calculates using head armour
bodyabsorbancy - automatically calculates using body armour
areaabsorbancy - weighted absorbancy that covers both the head and body for area of effect attacks
noarmourabsorbancy - boosted natural toughness only, ignores armour and shield
noshieldabsorbancy - ignores shield protection, armour and natural protection only

I have spent a lot of effort planning, changing, re-planning and re-changing this thing. There is a very, very thorough dissertation and should provide you with plenty of direction on how to use this armour feature correctly. Please don't make me hurt you by breaking it or ignoring what I've written here. :evil:

Re: Images/Artwork in Game

PostPosted: Thu Feb 27, 2014 2:42 pm
by TigerStripes
This help guide is in response to this thread: Subject: About Pictures in FS
femtoAmpere wrote:A wonderful day there fellow wasteland survivors!

Lately I've been asked if I'd like to include a picture of my character, Ammy, in the game. So I was wondering..

- Which formats and sizes are actually supported?
- Will there be a difference if using different interpreters?
- Will the game scale images down or is the size constant?
- How about half-transparent PNG or transparent GIF files?
- What about animations in GIF files?

- Is it possible to get an example of how the code with an added image looks like?

Maybe some tail can help <3
Thank you!

Inform can deal with either JPG or PNG. I don't know about half-transparency stuff though. I believe the size is kept constant when viewed in game, but Nuku may better be able to answer that. I don't have a mobile platform on which to test it. Wahn chose to restrict his images to a maximum height of 450 pixels, which I also chose to follow in general. This is to keep the images from spamming/bumping the game text too much and to keep the game file size from getting too huge. I don't think there'll be a significant different between interpreters unless they don't allow images, in which case they'll skip it. Since GIFs aren't allowed, neither are animated gifs. It is also worth noting that images can only be shown in line and without any formatting, zoom in/out, resizing, etc. The text cannot be formatted around them either.

To add an image to the game:
1> Open the FS Graphics file in Nuku's directory.

2> Add the image as a figure:
Code: Select all
Figure of <name>_icon is the file "<filename.ext>".
in either the [infection icons] or [npc icons] section.
This assigns the filename to a specific game object called 'figure of <name>_icon'. Please note that the _icon is just the naming convention we've chosen to prevent the code getting confused between the icons and the objects. Please do not stray from this. Also, do no create objects, variables, etc... that are similarly named to avoid accidental conflicts.

3> If it is for a creature and is meant to show up whenever it's encountered, also add it to the table of infection graphics.
Code: Select all
"<creature name>"   figure of <name>_icon

4> If it is meant to appear with an NPC's description, it needs to be designated as their 'icon'. It is worth noting that this method can also be used for any other 'thing' in the game, though none have yet been given art.
Code: Select all
the icon of <NPC name> is figure of <name>_icon.

5> If you want the image to appear as part of a scene, special event or at some other key point, you need to 'project' it.
Code: Select all
project <name>_icon;

6> In all cases, add another line to the 'carry out artistcredits' subroutine in either the infection or NPC sub-section.
Code: Select all
   say "     <creature/NPC> by <artist name> @ <website>[line break]";

7> Adding/altering the image during gameplay:
Should you have a creature or NPC that changes during the course of the game and you wish to add an icon or alter their present icon to one suitable to their present state, you must assign/alter their above value. The figure should always be assigned to a file from the beginning even if it may not be in use until later in the game.

A - Adding a creature image later:
Code: Select all
add a blank row to the table of infection graphics;
choose a blank row in the table of infection graphics;
now title entry is "<creature name>";
now icon entry is figure of <name>_icon;

B - Changing a creature image later:
Code: Select all
choose row with a title of "<creature name>" in the table of infection graphics;
now icon entry is figure of <name>_icon;
Please note, the creature name must be identical and must already be within the table or a run-time error will occur when attempting the swap.

C - Adding/changing an NPC image later:
Code: Select all
now icon of <NPC name> is is figure of <name>_icon;

D - Removing a creature/NPC icon later:
Follow the same procedure for B or C, but use 'figure of pixel' as your new figure. This is the designation for a blank pixel, thereby removing the image and replacing it with essentially nothing. By default, all objects are treated as having an icon of figure of pixel.
Code: Select all
choose row with a title of "<creature name>" in the table of infection graphics;
now icon entry is figure of pixel;
Code: Select all
now icon of <NPC name> is is figure of pixel;

8> Send your file to Nuku, either through the drop box if you have access, emailing it to him or by some other means. Once you know he's got access to it, send along your update to the FS Graphics.i7x file.

Location Creation

PostPosted: Sat Aug 02, 2014 8:56 am
by TigerStripes
Location Creation:
As you create content to the game, you may wish to add a new location or simply add a new room onto an existing area. Doing this is fairly straightforward, with some of the basics explained in pages 3.2 - 3.4 of the 'Writing with Inform' manual (found under the documentation tab within Inform7). As such, this guide will only go over a few basic points before moving forward with the particulars of rooms, navigation and hunting areas within Flexible Survival.

Basics of a room:
We'll start with the example of a basic room on its own, without any adjoining rooms.

Code: Select all
Kristen's Hideout is a room.  It is fasttravel.  It is private.  It is sleepsafe.
The description of Kristen's Hideout is "[krishideoutdesc]".
the scent of Kristen's Hideout is "[krishideoutscent]".

To start, you must create a room by naming it. This is done on the first portion of the first line in our example. The room's name should be unique and not match/duplicate that of any object/NPC/room already in the game. Because Kristen exists as an NPC, her room is named as "Kristen's Hideout" and not something like "Chez Kristen", which might cause confusion for Inform when trying to decide which of the two "Kristen" is being referred to. Similarly, a room's (or anything's) name should not contain prepositions, such as 'on', 'over', 'in', etc, as they can confuse Inform.

Rooms within Flexible Survival can have some special attributes to designate what type of room it is, whether you can nav to it and so on. Some are shown on the latter half of the first line of our example. I'll discuss them in more detail below.

A room will require a description, as set on the second line in our example. This is the descriptive message seen when the player arrives or looks around the room. You can either write the description directly between the quotation marks or, as above, call a say statement. Calling a say statement is useful should your room appearance change due to circumstances in the game or to provide a 'first time' description and then an abridged one for subsequent visits, but either method works fine.
NOTE: While code can be inserted into this to make stuff happen when the player arrives or looks around the room, that is higher level stuff and should only be attempted by seasoned FS devs.

A room will require a scent and is handled much like the description, appearing whenever the player smells their surroundings. These are brief, usually single sentence messages to provide a little background flair.

Connecting rooms:
Generally speaking, rooms are connected to each other by designating their cardinal position (e.g. north, southeast...) next to one another. In addition to cardinal directions, 'inside', 'outside', 'up' and 'down' can also be designated as directions. Unless specifically manipulated, such connections are two-way by default.

Code: Select all
Private Booths is a room.  Private Booths is east of PALOMINO.

This makes a connection between the Private Booths and the Palomino. The player can now go east from the Palomino and end up in the Private Booths room. Going west from the Private Booths will bring them back to the Palomino.

Code: Select all
Grey Abbey Library is a room.
Bunker is a room.
Inside of Grey Abbey Library is Bunker.

This creates both rooms and places the Bunker room as 'in' from the Library.

Fasttravel, (un)known and private rooms:
These three special attributes a room might have are all related and deal with finding and navigating to rooms, so they'll be discussed together.
- fasttravel: This designates that the room can be used to navigate to and from using the 'nav <room>' command (provided it's known). Any new fasttravel room created will have to be manually added to the listing in the 'nav' command by editing the 'destinationcheck' action in the file. By default, a room is not fasttravel.
- unknown: This designates that the player does not yet know the location of this fasttravel room. It cannot be navigated to and will not appear in the nav list. Its opposite, 'known', designates that the player now knows how to reach the room and so it can be navigated to. By default, a room is unknown.
- private: This designates that this fasttravel room cannot be found through normal exploration or hunting. The player instead needs to be given access to this room via a situation, scene or special event. When that occurs, the room's is then designated as 'known'. By default, a room is not private.

Code: Select all
Entrance to the Red Light District is a room. It is fasttravel.

This sets the Entrance to the Red Light District as a navigable room. It will also start out as unknown and not private. This means the player can find this room through random exploration (not private), but cannot navigate there until it is found (currently unknown).

Code: Select all
Sven's Place is a room. It is fasttravel. It is private.

This sets Sven's Place as a navigable room. It will start out as unknown and is private, meaning the player cannot initially navigate there (unknown) and cannot find the room through random exploration (private). They will instead need to be granted access to the room via an event of some kind. When that occurs, the room is then given the 'known' attribute.

Code: Select all
Instead of resolving a Hidden Kitty:
   <assorted stuff happens as part of the event>
   now Sven's Place is known;

Hunting areas:
Some rooms have access to a hunting area. While only senior devs should be creating new hunting areas and only when needed, it is possible for a new location to connect to an existing hunting area. In these cases, you'll need to create what's known as a 'dangerous door' which has an 'marea' value to designate which hunting area it represents.

Code: Select all
Library door is a door. "Solid oak doors lend a stately appearance to the library.". Library door is dangerous.
East of 7th Street & Main is the Library Door. "Solid oak doors lend a stately appearance to the library.".
East of library door is Grey Abbey Library.
The marea of library door is "Outside".

This creates a door (Library door) between the Grey Abbey Library and a room called 7th Street and Main. This door is assigned as belonging to the "Outside" hunting area by its marea value. While the '7th Street and Main' room is never entered, there does need to be a room on the other side of the door for the code to work. This room should always be a placeholder only and never be one that receives any actual activity. It does not need a description or scent as the player should never be allowed to enter it. Do not use a dangerous door to connect to active rooms.

The game contains code that checks for the presence of any dangerous doors while trying to explore/scavenge/hunt and will also circumvent normal attempts to move through a dangerous door and trigger exploration instead. When any of these occur, the marea value will be used to set the 'battleground' variable, which is then used for comparison against the sarea value of situations and the area entry of creatures to decide what might be encountered.

The final attribute a room can have, this one designates whether the player (with a cot) can safely sleep in this room without risk of creature interruption. At present, this is only applicable in rooms with a dangerous door and/or fasttravel rooms. By default, a room is considered not to be sleepsafe. In this post's initial example, Kristen's Hideout is designated as sleepsafe because it is secure against monsters wandering in. Rooms like the Entrance to the Red Light District, the Hospital and so on are not sleepsafe because the player's only finding a secluded spot in the ruins of the city where they hope not to be interrupted.

<...more to come...>

Various Sex Scene Templates

PostPosted: Sun Sep 21, 2014 10:19 am
by TigerStripes
There's a wide variety of ways the kinky fun in FS can be arranged to properly select scenes. This can be based on factors such as gender, player choice, player traits (feats/infection/etc.), random chance and many others. The method and/or factors you use for determining which scene to show is a subtle but important way you can convey the overall feel of your creature/NPC/situation. The selection process helps reinforce such details as gender preferences, sexual kinks, loss of player control, infection-specific urges and so on. As such, at least some thought should be placed into how you're going to prioritize the scene variations.

The creature template file provides some basic examples of this, but there's much more that can be done. While the options are too varied to list all here, I do want to cover a few basic arrangements as well as show how you set up systems with multiple player options. In general, the examples I will do could be used for victory/loss/NPC or even ending scenes, though some are certainly better suited for some of these than others. For example, player choice is rarely used during player loss and never during endings. As well, random variations are rare during endings and less desirable during player victory, but they can be used if the situation calls for it.

Before we begin, if you're unfamiliar with the various variables, statuses and properties, you can review them here.

Part 1 - Basic Selections

Here are a variety of basic ways to break down scenes based on factors, generally only focusing on one at a time. These are all pretty basic, but they can be built up into each other or extended with greater complexity by including several factors during the conditional check. After the first few examples, you'll see "otherwise if..." used to denote that the remaining scenes would go here, either as a basic single outcome via 'otherwise' or through continuation of conditional checks. Please note that these examples can be used to make a selection of scenes or to partition such a scene with sub-variations. Fuller examples of doing this will be done in Part 2.

Code: Select all
to say sceneexample01:
   if cocks of player > 0 and cunts of player > 0:
      say "Scene variation for herms.";
   otherwise if cocks of player > 0:
      say "Scene variation for males.";
   otherwise if cunts of player > 0:
      say "Scene variation for females.";
      say "Scene variation for neuters.";

Code: Select all
to say sceneexample02:
   if cocks of player > 0:
      say "Scene variation for males/herms.";
   otherwise if cunts of player > 0:
      say "Scene variation for females.";
      say "Scene variation for neuters.";

Code: Select all
to say sceneexample03:
   if cunts of player > 0:
      say "Scene variation for females/herms.";
      say "Scene variation for males/neuters.";

Code: Select all
to say sceneexample04:
   if cunts of player > 0 and cocks of player > 0:
      say "Scene variation for herms.";
   otherwise if cunts of player > 0:
      say "Scene variation for females.";
      say "Scene variation for males/neuters.";

Code: Select all
to say sceneexample05:
   if a random chance of 1 in 3 succeeds:
      say "Random scene variation.";
   otherwise if cocks of player > 0:
      say "Alternate scene variation for males/herms.";
      say "Alternate scene variation for females/neuters.";

Code: Select all
to say sceneexample06:
   if cocks of player > 0 and a random chance of 2 in 5 succeeds:
      say "Random scene variation only open to males/herms.";
   otherwise if...
      say "Remaining variations continue from here.";

Code: Select all
to say sceneexample07:
   let zz be a random number between 0 and libido of player;
   if zz > 50:
      say "Random scene triggered by high player libido.";
   otherwise if...
      say "Remaining variations continue from here.";

Code: Select all
to say sceneexample08:
   if libido of player > 50:
      say "Scene guaranteed to trigger for high libido.";
   otherwise if...
      say "Remaining variations continue from here.";

Code: Select all
to say sceneexample09:
   if bodyname of player is "Critter Name":
      say "Special scene variation if the player has the 'Critter Name' infection on their body.";
   otherwise if...
      say "Remaining variations continue from here.";

Code: Select all
to say sceneexample10:
   if bodyname of player is listed in infections of FelineList:
      say "Special scene variation if the player has a feline infection on their body.";
   otherwise if...
      say "Remaining variations continue from here.";

Code: Select all
to say sceneexample11:
   say "Intro to the scene.  Do you want to proceed?";
   if the player consents:
      say "Scene variation for the player agreeing.";
      say "Scene variation for the player refusal.";

Code: Select all
to say sceneexample12:      [Specific to player loss scenes]
   if hp of player > 0:
      say "Scene variation for losing by submitting.";
      say "Scene variation for the player defeated in combat.";

Code: Select all
to say sceneexample13:
   if the player is submissive:
      say "Special variation if the player has the Submissive feat.";
   otherwise if...
      say "Remaining variations continue from here.";

Code: Select all
to say sceneexample14:      [Specific to player loss scenes]
   if the player is submissive or hp of player > 0:
      say "Special variation if the player has the Submissive feat OR submitted during battle.";
   otherwise if...
      say "Remaining variations continue from here.";

Code: Select all
to say sceneexample15:
   if cunts of player > 0:
      say "Scene variation for females/herms.";
   otherwise if anallevel > 1:
      say "Scene variation for males/neuters open to anal play.";
      say "Scene variation for males/neuters when anal is undesired.";

Note: More examples of the usage of 'More/Less' anal (anallevel value) can be found in this guide. This can similarly be done for wslevel (watersports), vorelevel (vore) and ublevel (unbirthing). In all cases, a value of 1 means low/none, 2 means normal and 3 means more.

Code: Select all
to say sceneexample16:
   if cunts of player > 0:
      if player is impreg_able:
         say "Scene variation if the player is female/herm and can be impregnated at this time.";
      otherwise if gestation of child > 0:
         say "Scene variation for females/herms that are currently pregnant.";
         say "Scene variation for all other females, probably sterile or otherwise infertile at the moment.";
   otherwise if...
      say "Remaining variations continue from here.";

NOTE: More details on the pregnancy-related variables and statuses can be found in Part 2 of the Descriptive Elements post.

Part 2 - Full Examples

In this section, we'll use a mix of the above to create full scene selection trees which might be useful for different situations. These are by no means the only variations possible, but they represent some common ways the scenes can be broken down depending on what best suits the creature/NPC in question.

Player Defeat

Code: Select all
to say playerdefeatexample01:
   if hp of player > 0:
      say "Intro to defeat scene if player submitted.";
      say "Intro to scene if player lost in combat.";
   if cocks of player > 0 and bodyname of player is "Critter Name":
      say "Special variation if the player is male/herm and has the same body type as the monster.";
   otherwise if cocks of player > 0:
      say "Variation for all other males/herms.";
   otherwise if cunts of player > 0:
      say "Variation for females.";
      say "Variation for neuters.";

The above variation is typically suitable for a female foe interested in straight sex. This scene has an alternate lead-in depending on whether the player submitted or lost in combat before transitioning into the same main scenes regardless. During the scene selection, because the foe is more interested in player cock, that gender characteristic is checked for first and foremost. Some foes may react more strongly or in a different manner if the player matches their own infection, in the above case resulting in a special sex scene w/male/herm players if they have the same body type. This could be a more vigorous sex scene or may also be the only means to fuck them during player loss at all. Alternatively, a another creature name could be checked for if the creature has a special affinity or negative reaction to a different creature type. Next comes a scene for all other males/herms - this might be a standard fucking scene or some other form of M/F sex. Next come variations for F/F and F/N outcomes.

Code: Select all
to say playerdefeatexample02:
   say "Initial scene after player loss.";
   if cunts of player > 0 and a random chance of 3 in 5 succeeds:
      say "Potential (60% chance) scene variation for females/herms.";
   otherwise if cunts of player is 0 and a random chance of anallevel in 5 succeeds:
      say "Potential (20/40/60% chance) anal scene variation for males/neuters, depending on More/Less Anal setting.";
      say "Catch-all scene variation if the others don't occur.  Ex: forced oral.";

This second example is geared towards a bisexual male foe with a random variation to his potential choices during player loss. Being bi-, the creature may opt for vaginal sex first. If the player is instead male/neuter, their next option is to check of anal sex, with it being more likely the higher it is set in the player preferences. If vaginal/anal does not occur, the scene defaults to one where player gender does not play a direct role. This is typically making the player perform oral sex, but could also be masturbating onto the player, foot play, frot, etc.

Code: Select all
to say playerdefeatexample03:
   if cockname of player is listed in infections of Caninelist and cunts of player > 0 and inheat is true:
      say "Special scene variation for females/herms with a canine-infected cunt while in heat.";
   otherwise if cunts of player > 0 and a random chance of 3 in 5 succeeds:
      say "Potential (60% chance) scene variation for females/herms.";
   otherwise if cunts of player is 0 and a random chance of anallevel in 5 succeeds and anallevel > 1:
      say "Potential (0/40/60% chance) anal scene variation for males/neuters, depending on More/Less Anal setting.";
      say "Catch-all scene variation if others don't occur.  Ex: forced oral.";

A setup like this would be a good one for a straight male canine intent of impregnating females. It starts off with a check if the player has a canine cunt and if they're in heat. If so, a special variation would occur which would probably be heavily focused on breeding and the player's lack of self-control/need to be impregnated. A more general variation would follow by checking for a player cunt, probably again resulting in vaginal sex. Similar to example 2, a check for anal sex follows that, but this time it fully excludes those who opted for Less Anal. Lastly comes a catch-all scene should the other scenes not occur.

Code: Select all
to say playerdefeatexample04:
   let analchance be anallevel + 2;
   if player is submissive, increase analchance by 2;
   if "Kinky" is listed in feats of player, increase analchance by 1;
   if "MPreg" is listed in feats of player, increase analchance by 2;
   if anallevel is 1, now analchance is 0;
   if cocks of player > 0 and a random chance of analchance in 16 succeeds:
      say "Potential anal scene for males/herms with odds variable based on several feats - Ex: primarily gay foe rides player's cock.";
   otherwise cunts of player is 0 and a random chance of analchance in 16 succeeds:
      say "Alternate anal scene for males/neuters with same chance out of remaining odds - Ex: gay foe opts to ass fuck the player";
   otherwise if cocks of player > 0 and a random chance of 1 in 2 succeeds:
      say "Potential scene for males/herms with 50% chance of remaining odds.";
   otherwise if cunts of player > 0 and a random chance of 2 in 5 succeeds:
      say "Potential scene for females/herms with 40% chance of remaining odds.";
      say "Catch-all scene variation if others don't occur.  Ex: forced oral.";

This example might be used for a primarily gay foe that enjoys being the bottom over being the top. Rather than using the fairly simple methods for determining if anal occurs that were shown above, this one uses the anallevel variable as a starting point, but then increases the odds if other feats apply. After that calculation is done, the value is dropped to zero if the player has chosen the Less Anal setting. Since the foe prefers receiving, the player is checked if they have a cock during the first anal sex check. The second check verifies that they don't have cunt before picking to fuck their ass. If anal sex is not chosen, another check is made for players with a cock for another form of sex the foe might enjoy with the player's cock, such as sucking/jerking them off. Once the more gay options have had their chance to occur, a scene for players with a cunt (possibly vaginal sex) could occur. Should none of the above succeed, the scene defaults down to some catch-all scene.

Player Victory

NPC Scenes

Ending Montage

Part 3 - Complex Selections

Below are some more complex scene organization structures, many of which deal with player choice systems. These arrangements are more specialized and each will have some notes explaining keys points on them, but it is important to note that the more basic factors (such as gender selection, etc.) can be adjusted as needed using variations based on the examples from Part 1.


<More to come>