General Discussion

[Thewlis]

You could make talents unknown but visible. Say you go to buy a slave and one of them has "Unknown Talent" in the skills/traits area (wherever would fit best). You know she's good as something, but you still have to find out what. You could then have some girls who's talent is known 'cause they found out what it was before being enslaved / with an earlier master / whatever.

Also on the point of talent vs. training I prefer the idea of talents being a starting bonus to a skill. Say all girls start with Art 0, a girl with a talent in art (once discovered) would get a level in Art once they find out.

[Xela]

Yeap, that would be very good.

Talents can be displayed after they're discovered. I was thinking that they should also lower training time and give production bonuses where sensible.

[DarkTl]

Ok this is my first attempt to draw a map. It isn't finished, simply laid out to collect your wishes and councils.

I have a feeling that such a design would be better for quarter map rather than city. The city is supposed to be big enough to be independent, while at this map it seems quite small. Maybe it's just me.
Also I think it's too bright, you could try to make it a bit darker.

I'll try to take a look at girlsmeets/interactions code to figure out how a common system can be created.

About that, I wonder if we could try to increase the number of topics while making them generic with AA2 type of reactions (bad, normal, good, very good). AA2 calculates the outcome depending on personality and mood, we could do something like that with traits (and we have mood too).
As for mood flags you mentioned, during girlsmeets it could be more or less random, I guess. And MC's actions could change it.

[Xela]

I have a feeling that such a design would be better for quarter map rather than city. The city is supposed to be big enough to be independent, while at this map it seems quite small. Maybe it's just me.
Also I think it's too bright, you could try to make it a bit darker.

Brightness didn't bother me for some reason but I've submited a whole list of *notes to Gismo

We'll never get "large city scale" with a map like that, I've googled some maps and noone seems to be getting it right with this type of design. I think the objective here is to create distinct area (quarters) and locations. We can describe the city in intro to the game and lore.

About that, I wonder if we could try to increase the number of topics while making them generic with AA2 type of reactions (bad, normal, good, very good). AA2 calculates the outcome depending on personality and mood, we could do something like that with traits (and we have mood too).
As for mood flags you mentioned, during girlsmeets it could be more or less random, I guess. And MC's actions could change it.

I'll look into that as well, having a really bad day coding here, just deleted (on purpose) in HG work I did for the past four hours cause it wasn't going anywhere reverting to public version. Don't know if I am going to make another attempt at this tonight...

But I'll give it some further thought. Some answers would prolly have to become more general for this to work.

[DarkTl]

I didn't mean that we should use AA2 girls reactions (it's impossible actually, they are not general enough). However, when you try a topic, the game let you know how successful it was (like "you have a long, deep conversation").
In fact, we could use any topics like science, art, policy as long as we use such reactions, providing that we use a decent algorithm.

Also, I believe we should use more icons and less strings in interactions gui. Take a look at AA, they used there a lot.

[Xela]

I didn't mean that we should use AA2 girls reactions (it's impossible actually, they are not general enough). However, when you try a topic, the game let you know how successful it was (like "you have a long, deep conversation").
In fact, we could use any topics like science, art, policy as long as we use such reactions, providing that we use a decent algorithm.

Also, I believe we should use more icons and less strings in interactions gui. Take a look at AA, they used there a lot.

We need to write a base concept for interactions. Not really sure on the icons front, that may cut off some important options and possibilities. Let me put some thought in a text file and we can discuss options after I post that.

[DarkTl]

After awhile player gets used to gui, so he doesn't even need strings to know where to click. Also we have tooltips, unlike AA, where you actually must remember what icons mean (and even that is not a big deal, surprisingly).

[Xela]

After awhile player gets used to gui, so he doesn't even need strings to know where to click. Also we have tooltips, unlike AA, where you actually must remember what icons mean (and even that is not a big deal, surprisingly).

We could in theory use icons for main interactions menu but I'd prolly like to avoid even that... in any case, here are some thoughts for a coherent interactions concept that doesn't have to be rewritten again and should answer to all our/modders future needs:

=====
All interactions are handled by a Python class, menus and dropdowns should be constructed by it and it should be possible to add options to them by modders (similar to a way it is possible to add options to actions and events right now).

Every option that causes an option (button) to appear in the menu or dropdowns should appear on conditions.

Interactions should consist of chatting:
*Dark proposed different response labels (like bad, normal, good, very good) which may fall back to normal if bad/good/very good do not exist.
and actions like:
*Touch
*Sex
*Give money
*Assault
etc.

To make it more coherent, a system if “mood_state” needs to be created to pick replies. Normal replies can be determined by disposition, stats, traits and etc.
Special replies will override of mood state is set, for example if you just beat or seriously insulted a girl, her replies should reflect that even if disposition is still reasonably high.

All this will mean that current girlsmeets concept and interactions concept will have to be scraped (in code) while labels created by Dark/CW can be reused exactly as they are. It will prolly make sense to rename the labels themselves.

All chats and actions will consume interactions points (converted APs).

This system will be manageable and will have to be balanced once. It will also allow to remove some options from the menus (like some options may be appropriable only when player first meets the character while other only after some relationship has been established). Also options can be set to be displayed only in some specific areas.
=====

[DarkTl]

I feel like we're moving towards a sim game with an adult approach (that doesn't conveniently forget about matters like slavery/sex/war/death just because it's a game). There is a hentai edge, obviously, this is how it got started and we'll keep to that in our concepts/designs whenever it's sensible.

I'd say, just like most of indie dev teams without funding, we make a game of our dreams in the first place, and its genre is secondary.
Btw, you might want to check brothels.im, they improved the game a lot. It even has a map now.

I have trouble with envisioning decent gameplay in a game of our size if a character can be trained to do anything in 50 - 100 days... Balancing that out to make it of any interest seems like a lot more work (if possible at all).

If skills will be rare and actually useful, it's not a problem.
Also we could add here magic, it doesn't seem like a common thing to me. Spells could be more useful and more difficult to learn, or we could add levels of magic or something.

I'm going to take care of girls social levels, including concept and images for rooms.

[Xela]

Btw, you might want to check brothels.im, they improved the game a lot. It even has a map now.

Is there anything specific that you liked? Game is built around a concept of a few customized characters. Something along those lines is already possible in PyTFall.

If skills will be rare and actually useful, it's not a problem.

I am suggesting to build half a game around that, ofcourse they will be of use.

[DarkTl]

Rooms management is kinda cool, with intuitive gui. We could use it for MC house at least, maybe even for other places.

[Xela]

Look like a very basic Drag&Drop interface.

Doubt we'll do advanced MC housing any time soon with all the other stuff at hand.

[Thewlis]

We could in theory use icons for main interactions menu but I'd prolly like to avoid even that... in any case, here are some thoughts for a coherent interactions concept that doesn't have to be rewritten again and should answer to all our/modders future needs:

Been thinking about this and I have some ideas.

I shouldn't be too hard to modify the current actions code to work for girl interactions as well. It stores the actions under a key (currently the location name) so passing the full name of the girl to the system would work for handling access. As the systems doesn't (or shouldn't at least) save the actions and are rebuilt when the game is restarted / loaded it wouldn't take up too much space to have a unique set of actions for each girl. We could however just create 1 set of actions under "girlsmeet" or something and use it for everyone.

Adding dropdowns / submenus to the system wouldn't be hard, just create a custom action to specify what menu to show and pass that as the action's action.

Maybe add a new dict to girls that can be set in their xml/json files to add custom actions to the menu that can then call up girl-specific labels if authors desire. (If we use a global menu instead of char-specific this could still be used, just require a different function/label call to ensure it has everything needed).

As for skills, we could either:
1) create a new dict to ensure no overlap between the current stats and their new skills (maybe move sex/service/strip over as well). Then have the accessing function return 0 for any skill request that doesn't have a key. This would allow easier creation of skills and provides less clutter on the screen as only skills that have training are visible. Probably use a structure like {"skill": {"level": 0, "hidden": True, "talent": 1}}.

2) place the new skills into the current stat store and use the existing systems. Would force all skills to be visible on the girls screen. Would also need a new dict for talents however, something like {"skill": {"talent": 1, "hidden": True}}.

[Xela]

Been thinking about this and I have some ideas.

I shouldn't be too hard to modify the current actions code to work for girl interactions as well. It stores the actions under a key (currently the location name) so passing the full name of the girl to the system would work for handling access. As the systems doesn't (or shouldn't at least) save the actions and are rebuilt when the game is restarted / loaded it wouldn't take up too much space to have a unique set of actions for each girl. We could however just create 1 set of actions under "girlsmeet" or something and use it for everyone.

Adding dropdowns / submenus to the system wouldn't be hard, just create a custom action to specify what menu to show and pass that as the action's action.

Maybe add a new dict to girls that can be set in their xml/json files to add custom actions to the menu that can then call up girl-specific labels if authors desire. (If we use a global menu instead of char-specific this could still be used, just require a different function/label call to ensure it has everything needed).

What would we an advantage of having girls specific access? It's prolly better handled with flags and buttons (actions) conditions.

Otherwise, if you want to expand your actions class to girlsmeets, you're more than welcome

As for skills, we could either:
1) create a new dict to ensure no overlap between the current stats and their new skills (maybe move sex/service/strip over as well). Then have the accessing function return 0 for any skill request that doesn't have a key. This would allow easier creation of skills and provides less clutter on the screen as only skills that have training are visible. Probably use a structure like {"skill": {"level": 0, "hidden": True, "talent": 1}}.

2) place the new skills into the current stat store and use the existing systems. Would force all skills to be visible on the girls screen. Would also need a new dict for talents however, something like {"skill": {"talent": 1, "hidden": True}}.

Yeap, sounds exactly what is required...

[DarkTl]

Look like a very basic Drag&Drop interface.

Yup, and it looks very good. Instead of menus just drag and drop characters icons into rooms.