• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5


Positions
#1
I'm making a thread for this to try and explore the topic of sex positions.

Currently, the game only cares about the position of the receiving partner. The receiving partner is you if chose "Get Fucked", and the other character if you chose "Fuck". (Note that this will change a bit in the future. One option, and the ability to switch who leads during the scene. ) Oh, and group sex will be handled differently, so that's a different topic all-together.

Current valid positions are:
-Standing
-Standing while facing away. (That means the active partner is standing behind the receiving partner.)
-On all fours (Active partner can be both behind and in front of, depending on which orifice is being used.)
-Bent over prop. (Prop being a crate/table/rock/etc)
-Back on prop. (The receiving partner is laying down on a crate/table/rock that is elevated to about crotch level of the active partner.)
-Stomach on floor/ground.
-Back on floor/ground.

Suggestion 1:
Present transitions between positions to the player, rather than the positions themselves. That means if if the receiving partner is in the position "Standing facing", they can choose "Turn around" which turns the receiving partner around to the position "Standing facing away". Or you could choose "Push down/Lie down(Depending on which partner you are.)" which would result in the position "Back on floor" OR "Back on prop". I'm not entirely sure how to separate between those two outcomes though. Does "Push down" end up on the table, or on the ground, basically. I'm open to suggestions on what to call an action that goes from "Standing" to "Laying on their back".

I suppose I could use the prop name for the "Back on prop"/"Bent over prop". So you click the "Change Position" drop-down, and select "Table" and you get the description "You give her a push and she falls back on the table. " I'm not entirely sure what the best solution for this would be.

Suggestion 2:
Sub-positions. Or variations of positions.
There are many positions which have similar aspects. You can stand facing each other, but you could also do the same but one partner is sort of burying their face in the other's neck. Both of those would behave the same in the genital department.

When writing scenes, I often use a switch statement to provide variations based on for example position.
Example:
switch(receivingPartnerPosition)
case StomachOnGround:
"Her juices run down between her butt cheeks and pool on the ground. "
case BackOnGround:
"Her juices drip off her clit and pool on the ground. "

In the case above, the description could be the same for "StomachOnGround" and "OnAllFours", and I would write it like this:
switch(receivingPartnerPosition)
case StomachOnGround:
case OnAllFours:
"Her juices run down between her butt cheeks and pool on the ground. "
case BackOnGround:
"Her juices drip off her clit and pool on the ground. "

Where the two first cases result in the same.

The simplest way to implement this would probably be to just add a whole bunch of positions, even if they are almost the same. The player could then choose from a lot of positions, and get more variations.

The main problem with this is; More positions add more complexity to every scene. Every position MUST be accounted for every time the position is relevant, in EVERY scene. That is in addition to every skin color, genital variation, hair, leg-type and so on.

Suggestion 3:
Splitting positions so each partner have their own position.
I'm not sure how to implement this to be honest. There are so many possible combinations. (receivingPositions x activePositions) I would have to map which are compatible, and which allow what scenes. Not to mention taurs and genital combinations. I chose the current format so the author of each scene would have the freedom of placing the active partner, and allowing that partner to move around within the scene. This could get real complicated real quick.

Anyways, feel free to comment if you have thoughts and ideas.
Reply
#2
Yeah, posting here really sounds nicer...

Position's list
I just wanted to say you haven't mentioned sitting position at all Angel

Suggestion 1: transition
Mmh, concerning the transition from "Standing" to "Laying on their back", it may lack a "sitting" position in the middle. Maybe. Anyway, apart from "push down" or "crouch [seductively]", I'm don't know.

The transition could be made less brutal by integrating them in some scene
(example : a kissing scene, which may lead to a "push down [while kissing]", which trigger a scene when the target is (gently?) pushed down during a big kiss).

As for prop, I'm not fond of simply using the prop's name. If I see a "Table" button, I'll probably expect it to bring a menu with "push target on it", "sit on it", "push target under it" instead of having the action trigger directly.
I don't think adding a lot of menu is really user friendly, through the same can be said with too much button...


Now, question, if you add transition, will you keep the current position list ? (The idea being transition was to totally replace that list, but since you talked about ""Change Position" drop-down", I'm curious Smile)


Suggestion 2 : sub-position
(I'll probably repeat a lot of what I said on the comment, hoping to make it a tiny bit clearer to eventual other readers ^^")
First thing first, I talked about sub-position more as an add-on to transition, through separating them will work too.

That mostly mean sub-position are here to be part of a scene, or to add continuity between some scenes. That mostly mean they are the result of some scene (ex: the kiss scene give the headOnCollar sub-position (... I really feel old for always using the same example Smile))

And, I also see them as something optional, which eventually add detail to the position, but can be entirely skipped.

For exemple, let's say the "standingFront" can have the following sub-pose (sorry for the flagrant lack of inspiration) :
- pressedTogether
- targetOnNeck

It would be (in pseudocode)
Code:
switch(receivingPartnerPosition)
    case standingFront:
        if(sub.targetOnNeck)
          [text for an added forehead kissing]
       endif
        [the scene]

    case ......:
        .......

Please note the lack of change for targetOnNeck. Let's just imagine it wasn't really adding anything interesting in that scene Sad

Sub-positions could be a start to some scenes too. Something like if the actual subPosition is targetOnNeck, it could unlock a neck kissing scene. (... sorry for the lack of inspiration again *sigh*)


It may add a lot of imbrication (if we add different body part and so on top of it), but it stay optional and easily skipped. Sure, some scene may lack in variance of sub-position, but the overall system sounds lighter.


Suggestion 3: both partner's position
Compared to the second suggestion, I find that one pretty heavy.

IMO, the sub-position give at least the added detail of the "active" partner position when needed, and probably more (need to know if the "active" is sitting ? A sub-positon can do. And why not "sittingOnLap", "sittingOnSide", or every other way of sitting that could add some spice in some scene (I'll just remind I see sub-position as something that can be purely ignored if it doesn't add anything to the current scene, so the worse than can happen is to never use some sub-position))

And sub-position aren't as hard to implement/represent than that, so I'd say suggestion 2 > suggestion 3.





.... Yup, long posts are better on the forum. At least, there is a preview !
Reply
#3
Ok, let's see. If we ignore suggestion 3 for the time being, and focus on 1 and 2.

Sub-positions need to be represented in some way, and I'm a little unsure about the best way to do it. I could create a data structure that holds two positions. The main one, and the variation.
Code:
enum MainPosition { StandingFacing, StandingFacingAway, BentOverProp, BackOnProp, SittingOnProp?, SittingOnFloor?, OnHandsAndKnees, BellyOnFloor, BackOnFloor}
enum Variation {  }
struct ReceivingPosition
{
    
}

On the topic of transitions. In the background (the code) there has to be positions. Positions are states. You have to be in a state, as they are the only static, if that makes sense. What is presented to the player is a different matter, and they don't have to see the state itself, only the option to click and the description of getting into that position.
I made a state diagram to try and picture what transitions would be needed. http://imgur.com/ucmAGg9
This is without sub-positions and sitting is not included. (I ran out of space. heh)

I'm still thinking about this. Maybe making what direction the receiver is facing a variable on its own. I'll make another post in a bit. I need to draw some more Tongue
Reply
#4
Ok, so here's another iteration. I've made facing/facing away a separate variable, which will in some cases change the transition text.
http://imgur.com/1vxyPet

I'm still unsure about some of the transition names. But I'd say this could work if I can figure out those names.

Also, this is not including sub-positions yet. But I did include sitting in the lower one.
Reply
#5
Code:
enum MainPosition { LyingOnProp, SittingOrLeaningOnProp, Standing, KneelingOrDoggy, Sitting, LyingDown }
enum Variation { }
class ReceivingPosition
{
    bool facing; //Facing away when this is false, otherwise facing the active partner.
    MainPosition position;
    Variation positionVariation;

    string getChangePositionDescription(){}
    List<MainPosition> getPossiblePositionsToChangeTo(){}
    List<string> getTransitionOptionsFromTheCurrentPosition(){}
}
Something like this should work.

I still need to figure out how the sub-position can be solved though. My main issue is that many sub-positions will be invalid in many of the main positions. For example; You cannot nuzzle someone's neck in... Actually, I think maybe you can. Might be a bit awkward in a couple of the positions though. But as long as you allow it from behind as well I suppose it would be logically consistent in all the positions. Not during all penetrations though, so I need to keep that in mind.
Reply
#6
Presenting the options to the player still makes sense like it is done currently right? The "Change Position" dropdown? The only difference being it would list what you do, rather than the resulting position. The sub-position options need to presented too though. How to present that without confusing the player?

Possible sub-positions:
Active's Mouth: Nothing, NuzzleNeck, BitingShoulder
Receiving's legs: Nothing, Together, SpreadWide

"Nothing" just means that it will not be mentioned. It's just unspecified. Basically where you start out before choosing a sub-position.
Reply
#7
Wow, I wasn't expected to see 3 replies before I came back O.O

I'll try to extract the most revenant part of what you said and answer to it :3


(06-15-2016, 02:27 PM)Helix Wrote: [...]I still need to figure out how the sub-position can be solved though.[...]
I think having sub-position as a direct child of some position will resolve some conflict.
I mean, position A can have sub-position 1,2 & 3, position B can have sub-position 4, 5, 6, 7, position C can have sub-position 8, position D...

Through adding that notion directly in the code won't solve anything. Putting that detail aside, I don't have a lot to add to the code you proposed (and was to say something similar, I trimmed down that post instead Big Grin )


Continuing on the same quote
(06-15-2016, 02:27 PM)Helix Wrote: My main issue is that many sub-positions will be invalid in many of the main positions.
I'm not sure the fact that many sub-position is an issue. Taking as granted you'll check relevant sub-position of a scene when needed (with conditionals), you'll only use sub-position if needed, or if you have time to implement the scene.

I'm really struggling to find a good example, so let's continue Dodgy


(06-15-2016, 02:05 PM)Helix Wrote: Ok, so here's another iteration. I've made facing/facing away a separate variable, which will in some cases change the transition text.
http://imgur.com/1vxyPet
I'm pretty unsure about using the facing as a flag. It reduce the number of states, but I think it's not as clear.

- I don't think every position should offer the same scene if the target is front/back to you. I mean at least a lot of anal scene should be unavailable if you're face to face, and anything involving eating breasts sounds pretty hard from behind.

- (on the continuation of the previous point) Instead of taking time to bend every scene to have a front/back, I think having more different scene (even if some are pretty similar to others) will be interesting.

- You're loosing the lying on belly/back notion. In that situation, the facing flag could represent either the lying on back/belly or the fact that the "active" person is near the head/lower body of the target. I find it pretty confusing :3

On the graph itself, I would be in favour of adding more transition. For example
Code:
Standing -> LyingOnProp
Standing -> LyingDown
Standing <-> Sitting
Kneeling/doggy <-> LyingDown
Kneeling/doggy <-> LyingOnProp (asuming it's pretty close)



(06-15-2016, 02:05 PM)Helix Wrote: I'm still unsure about some of the transition names. But I'd say this could work if I can figure out those names.
My main concern about the name you put in the graph is the repetition : the same name is used in multiple transition, I guess that can be a bit confusing.

Apart from that, right now, I'm also lacking inspiration for better names :-D

Anyway, an silly example on what sub-positions could be
Code:
switch (userAction)
    case "suck pussy"
    if(sub != headOnGenitalia) {//first time sucking
            if(sub == subPositionsList.headOnNeck) //here is an optional additional transition
                print "You gently nimble on ${target}'s neck"
            print "you lower yourself on your victim, kissing and nibbling "
            print "you bite ${target}'s tight"
            sub = subPositionsList.headOnGenitalia
        else
            print "[sucking description]"
        printChoices(); //displayed choice will be suck pussy (again), and relevant choice for the position
        break;

    case "grope chest"
        if(sub == subPositionList.headOnGenitalia)//scene addon due to alternative position
            print "you grin at ${target}, breathing on her needing part."
        print "your hand crawl on ${target} skin, reaching her mounds"
        if(sub == subPositionList.headOnGenitalia)
            print "you wink at ${target}, still ignoring her needs"
        if(sub == subPosiitonList.headOnNeck)//alternative addon
            print "you press yourself on ${target} breast"
        print "[grope grope grope]"
        printChoices();
Of course, each scene doesn't have to include sub-description description at all. They are here only if they are relevant.



(06-15-2016, 02:34 PM)Helix Wrote: Presenting the options to the player still makes sense like it is done currently right? The "Change Position" dropdown?
The only difference being it would list what you do, rather than the resulting position.
I don't know, it totally depend if you keep the transition instead.

Let's review the changes induce bu the transitions, in order :
1) You can't transition from any scene to any other, so the transition list only contain relevant transition -> transition list get trimmed down

2) Some scene could include automatic transition (okay, that's mostly for sub-position), or offer a transition choice relevant to that scene at the end of it (again, it can be linked to sub-position) -> some button (action) result in a change of position

3) Since a transition is an "action", same as clicking on a button and doing something/requesting from your target ; I think it would be logical to replace the transition menu (which should be trimmed down) by the relevant action/transition button. Eventually adding a color-code if the action result in a position change could be an idea.



(06-15-2016, 02:34 PM)Helix Wrote: The sub-position options need to presented too though. How to present that without confusing the player?

Possible sub-positions:
Active's Mouth: Nothing, NuzzleNeck, BitingShoulder
Receiving's legs: Nothing, Together, SpreadWide
I must admit I haven't really got that one. Seeing the "Possible sub-position" part, I guess we see it in a different way :3 Anyway, having more detail to what you mean by "present the sub-position" would be great.

I saw sub-position as something unique, but your list make me wonder how you see them. Your list looks more closer as a precise system detailing the position of every body part, my vision of sub-position was more something like "more detail on the position". I guess both work anyway.

If I understood correctly, you're wanting to add sub-position for every body part. Sure it give way more freedom, but it's sounds a bit complicated.

Anyway, I see 2 alternatives (not mutually exclusive) :
- Give 2 sub-positions : one for the target, one for the active protagonist. It needs twice as much choices in the scene, but it allow to do something like
Code:
target.subPosition = "legTogether"
active.subPosition = "nuzzleNeck"
I see a downside too, you can't really express "nuzzleNeck" + "handOnGenitalia" as a single sub-position (or you'll have to create way to much of them*), and I don't thin having a list of active sub-positions instead of some variable a good idea, it seem too easy to create a mess of it...

- Add flags on top of the sub-position (okay, that's mostly an another idea...), which add more details.
Through I think the flag system can be used to manage some general detail, not related to the position (like isWet, isCoveredInSweat, isCoveredIn[anything, isHandcuffed]) (okay, lacking inspiration here too :p)


* : sub-position concatenation As I said above, it could be interesting to have a mix of sub-position. Just wanted to say it's doable with some binary operator.

If I remember the syntax right, it should be something like that :
Code:
enum subPosition {
    "handOnGenitalia" = 1,//0001 <- binary representation
    "handOnNeck"       = 2,//0010
    "headOnGenitalia" = 4//0100
}

switch(action)
    case "kiss":
        ....
        sub = subPosition.headOnNeck;
        break;

    case "finger":
        if(sub & subPosition.handOnGenitalia) // already fingering ; testing if that sub-position is set
            //finger continuation
        else
            //description of putting hand to genitalia
            sub |= subPosition.handOnGenitalia //adding the sub-position the actual sub-position.
        break;

    case "eat genitalia"
        if(sub & subPosition.headOnGenitalia) {//already doing it
            ....
            if(sub & subPosition.handOnGenitalia)
                //aditional flavor text, the hand is there too
        } else
            .....
            sub = subPosition.headOnGenitalia //replace every part of the old position
I'm not sure it's really a good idea to be able to merge sub-position, but if it's done, I guess that solution will be the hardest to mess with... Through that won't be that hard Tongue

.... One day, I'll make shorter posts :3
Reply
#8
(06-15-2016, 11:43 PM)LizAardt Wrote: I'm pretty unsure about using the facing as a flag. It reduce the number of states, but I think it's not as clear.
It's not as different from the current implementation actually. The player will never see that data. They will just see the options "Turn", "Push", "Pull", and when they click one of those, they will get the description "You spin her around so she's facing you." or "You pull her up so she's standing in front of you, facing you. ". The flag is just a way to make the code more readable. As for what action is available in each position, that is already filtered (I.e. no anal from the front) today, and it would not be any different with the facing flag.
(06-15-2016, 11:43 PM)LizAardt Wrote: My main concern about the name you put in the graph is the repetition : the same name is used in multiple transition, I guess that can be a bit confusing.
Keep in mind that the player would only see the relevant choices for the current position. They would not have two duplicates in the dropdown list. But selecting "push down" twice would bring you from standing, through kneeling to sitting or lying down. Yes, potentially some repetition, but I don't see why it would be confusing.

Also worth mentioning, I can make all the indicators of current position to the player more human friendly. Like "She is standing, facing you.", which is what would be printed if "facing" was true, and the position is "Standing".

(06-15-2016, 11:43 PM)LizAardt Wrote: 3) Since a transition is an "action", same as clicking on a button and doing something/requesting from your target ; I think it would be logical to replace the transition menu (which should be trimmed down) by the relevant action/transition button. Eventually adding a color-code if the action result in a position change could be an idea.
I don't think getting rid of the dropdown is a good idea, unless you want to drown in buttons Tongue The number of options will only increase with time, as more content is added, so trying to categorize them and reduce the amount of visible buttons at any one time is a must. The "Change Position" button would have it's choices changed to transitions like "Flip" and "Stand up", and the amount of options available when you click it would be reduced a bit.

I've been planning on combining the "Penetrate" and "Ride" buttons into dropdowns as well. So you click "Ride", and can choose "Cock", "Face", "Pussy?". This is in an effort to reduce clutter.

(06-15-2016, 11:43 PM)LizAardt Wrote: I must admit I haven't really got that one. Seeing the "Possible sub-position" part, I guess we see it in a different way :3 Anyway, having more detail to what you mean by "present the sub-position" would be great.
By "present the sub-position" I mean that the option must be shown to the player somehow. I need to figure out where the button would be and what it would be called.

(06-15-2016, 11:43 PM)LizAardt Wrote: If I understood correctly, you're wanting to add sub-position for every body part. Sure it give way more freedom, but it's sounds a bit complicated.
The body part thing was just to allow having two or more sub-positions active at the same time. Basically what you suggested by using binary operators. The only problems with your suggestion is 1) It would become cluttered when I inevitably end up with 20+ of them. 2) How would I handle exclusive sub-positions cleanly? By that I mean you have some positions that make sense to have at the same time, like "Hand on throat" and "Legs spread". But you will also have positions that do not work together, like "Hand on throat" and "Hand on pussy". Unless you start separating hands, in which case you could end up with situations like having 1 hand on her tit, 1 hand on her pussy and 1 hand on her neck. That's 3 hands Tongue

At some point I wonder if it is just simpler to leave the sub-positions up to the scene itself. There are just so many considerations to make here, I find it difficult to see any obvious "best" solution.
Reply
#9
(06-17-2016, 03:56 PM)Helix Wrote: The flag is just a way to make the code more readable. As for what action is available in each position, that is already filtered (I.e. no anal from the front) today, and it would not be any different with the facing flag.
Well, I guess you know your codebase the best, so if you say it's the best, it's good Smile


(06-17-2016, 03:56 PM)Helix Wrote: Yes, potentially some repetition, but I don't see why it would be confusing. [...]

Also worth mentioning, I can make all the indicators of current position to the player more human friendly.
Let's say, confusing for people who tend to, sometimes, skip a bit of dialogue and don't remember what's the current position ? Big Grin (or simply read too fast, can happen too)

That being said, with a human-friendly indicator sounds always good !

(06-17-2016, 03:56 PM)Helix Wrote: I don't think getting rid of the dropdown is a good idea, unless you want to drown in buttons Tongue
That's up to taste I guess, having 8~12 button isn't that disturbing IMO, and a dropdown with few button doesn't sound that good Angel Okay, if you really plan to add a toons of button, I guess dropdown are good then

I guess the best of both would be a "responsive" UI that either display dropdown or button depending of the number of available choices, and in bonus an user parameter which change the maximum number of buttons. I'm not sure it's worth implementing it through, at least not right now.

I guess the main trouble I have with dropdown is the lack of visibility of current choice - you have to check every drop down menu, and scroll/read it fully to see all available options. In that regard, a lots of button, even if you have to scroll, sounds nicer to me. Again, it's mostly taste-dependent.

(06-17-2016, 03:56 PM)Helix Wrote: The number of options will only increase with time, as more content is added, so trying to categorize them and reduce the amount of visible buttons at any one time is a must. [...]
I've been planning on combining the "Penetrate" and "Ride" buttons into dropdowns as well.
Grouping relevant choices together sound really nice !

Since I've confirmed my drop-down phobia, I must say I see as alternatives tabs (instead of drop down, you create tab with every button, that group relevant content together and may be more easily readable).

That being said, even a big ugly list of button could use to be sorted by categories, with a separator between each of them.


(06-17-2016, 03:56 PM)Helix Wrote: By "present the sub-position" I mean that the option must be shown to the player somehow. I need to figure out where the button would be and what it would be called.
Still haven't really got that. Do you mean "present to the player to swap to a specific sub-position" ? Or "show current sub-position" ?

I must admit I through of sub-position as more a hidden flag (automatically set by your current actions), which alter some scene, and is eventually visible in the current position description.

(06-17-2016, 03:56 PM)Helix Wrote: The body part thing was just to allow having two or more sub-positions active at the same time. Basically what you suggested by using binary operators. The only problems with your suggestion is 1) It would become cluttered when I inevitably end up with 20+ of them. 2) How would I handle exclusive sub-positions cleanly? By that I mean you have some positions that make sense to have at the same time, like "Hand on throat" and "Legs spread". But you will also have positions that do not work together, like "Hand on throat" and "Hand on pussy". Unless you start separating hands, in which case you could end up with situations like having 1 hand on her tit, 1 hand on her pussy and 1 hand on her neck. That's 3 hands Tongue
1) well, I agree
2) It's not that hard actually, just annoying (btw, I agree it's totally less clear than a part based sub-position, I forgot why I proposed that)
A) For every position that move a hand (like fingering), check if there is a hand already used in the previous scene (say, hand on breast). If so, add additional (the hand move from breast to pussy). Okay, that's actually more complicated if you really want to have 2 active hands, and doesn't always move the same.

B) Another way would be to create a "main hand flag (like handOnPussy | handOnBreast)" and "sub hand flag (like handOnThroat | subHandOnBreast | subHandOnTight)". When you move a hand, when you want to move a hand, check if that flag is already set.

C) Same as B, you could have the sum of every hand flag, AND that to your active sub-position, then count the number of active set bit.


(06-17-2016, 03:56 PM)Helix Wrote: At some point I wonder if it is just simpler to leave the sub-positions up to the scene itself. There are just so many considerations to make here, I find it difficult to see any obvious "best" solution.
Mmh, wouldn't that defeat the possibility of having sub-position carry between scenes ? (same example as always, kiss (sub pos -> rest on shoulder), in the scene following the kiss, the fact than the target has her/his head on shoulder could be carried away in the next scene).

At least, that was mostly to handle that kind of cases I through about sub-position.
Reply
#10
(06-20-2016, 06:51 PM)LizAardt Wrote: Let's say, confusing for people who tend to, sometimes, skip a bit of dialogue and don't remember what's the current position ? Big Grin (or simply read too fast, can happen too)
Ah, yes. I do that myself. Fair enough. hehe.
I was thinking maybe the status fields on the right and left of the screen could reflect some scene-relevant things. Like what position either you or your partner is currently in, and whether someone is currently erect. (That's a flag on penises currently. You'll notice the first penetration you do describes gaining an erection before any penetration actually happens. I've been considering adding a sort of "female erection" as well, where it would be getting wet instead. That would also fit in there if I decide to add it.) Currently, these status fields show what body parts you/they have, but you can already check that for your partner by selecting "Look".
Edit: Forgot to mention; In the future (If I can afford an artist), I'll be adding avatars that show what your partner(and you) looks like. Expanding on that, positions could also be shown visually, using outlines or black figures most likely.

(06-20-2016, 06:51 PM)LizAardt Wrote: I guess the best of both would be a "responsive" UI that either display dropdown or button depending of the number of available choices, and in bonus an user parameter which change the maximum number of buttons. I'm not sure it's worth implementing it through, at least not right now.
That's not a bad idea actually. I'd just implement a generic dropdown control that splits into buttons when it reaches a certain threshhold of elements. Then allow the user to set the threshhold in the menu. I'll keep that in mind for later. The alternative is that I can hide more specific options inside another option, so you click one choice, and then you get the other buttons. Maybe with a small paragraph of text. "You decide to ride him/her. But how?" Then you can select "Face/Cock/Whatever". That's a little more work though, and maybe more error prone or difficult to manage. I'll have to consider it when I get there.

(06-20-2016, 06:51 PM)LizAardt Wrote: Still haven't really got that. Do you mean "present to the player to swap to a specific sub-position" ? Or "show current sub-position" ?
I meant giving the player an option of setting the sub-position, which would then enable any sub-position specific options. There is currently nothing that "shows the current position", only a description when it changes.

(06-20-2016, 06:51 PM)LizAardt Wrote: 1) well, I agree
2) It's not that hard actually, just annoying (btw, I agree it's totally less clear than a part based sub-position, I forgot why I proposed that)
A) For every position that move a hand (like fingering), check if there is a hand already used in the previous scene (say, hand on breast). If so, add additional (the hand move from breast to pussy). Okay, that's actually more complicated if you really want to have 2 active hands, and doesn't always move the same.

B) Another way would be to create a "main hand flag (like handOnPussy | handOnBreast)" and "sub hand flag (like handOnThroat | subHandOnBreast | subHandOnTight)". When you move a hand, when you want to move a hand, check if that flag is already set.

C) Same as B, you could have the sum of every hand flag, AND that to your active sub-position, then count the number of active set bit.
It's not that I can't do this. I'm just weighing the pros and cons. Time to implement vs benefit to the scenes. Keep in mind that adding sub-positions will affect every scene I write in the future as well as every scene I have already written. That's why I'm being cautious until I have a 100% clear picture of how to do this and what exactly the consequences will be. And I've been doing a lot of thinking out loud here in this thread. ^^

(06-20-2016, 06:51 PM)LizAardt Wrote: Mmh, wouldn't that defeat the possibility of having sub-position carry between scenes ? (same example as always, kiss (sub pos -> rest on shoulder), in the scene following the kiss, the fact than the target has her/his head on shoulder could be carried away in the next scene).

At least, that was mostly to handle that kind of cases I through about sub-position.
Yes, it would. I would probably solve it by always having characters return to the base position, if it is even worth mentioning.

All in all, I might benefit from expanding the "Current Position" data to be more detailed. (It's currently just an enumerator. ) There are a few things I could do that might make position management more fluid from a writing standpoint though. Maybe making a class that is solely responsible for position management, and thus contains all descriptions of transitions, sub-positions, restraints, etc. Then I'd just tell that class to change position when I'm writing a scene, and it would return a description of that for me. I also have to tackle the issue of group sex at some point, which will be a real hoot. Aaand, I'm thinking out loud again. Tongue

I'll refrain from implementing this stuff for a bit, just to let the idea mature. Don't want to make any mistakes I'll regret later in development.

Edit: Added comment on Avatar and artwork.
Reply

Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  




Users browsing this thread:
1 Guest(s)

   
ABOUT US
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s