General Discussion

[DarkTl]

Besides errors I posted in the errors thread, there are unnecessary menus when you press on cursed forest or forest entrance panels.

[Xela]

Besides errors I posted in the errors thread, there are unnecessary menus when you press on cursed forest or forest entrance panels.

We'll leave it like that, there is little point in removing defaults.

[DarkTl]

If someone wants to add some more locations to json, feel free to do so, might be good for testing.

I wonder how. It seems that EE isdivided into several files. I found Forest Entrance and Cursed Forest in the classes-locations, but since there is no link to the forest picture, I guess it should be somewhere else.
Also, explain the difference between focus_area and focus_gen_area.

[Xela]

I wonder how. It seems that EE isdivided into several files. I found Forest Entrance and Cursed Forest in the classes-locations, but since there is no link to the forest picture, I guess it should be somewhere else.
Also, explain the difference between focus_area and focus_gen_area.

There is only one relevant json atm but you can add more files as long as they're named correctly.

gen = general, it's something that will bind a number of areas together.

I am not sure about the files... Some backgrounds may be reusable and we may use them for expansion later as well.

[livingforever]

Hey everyone!
So... this project has been around for a while and since I had a lot of free time in the past month I guess it's time to give some feedback. I'll put it in one post although I am aware that some of the topics have own threads. If you don't like that, feel free to tell me.

Disclaimer
Many people don't like criticism (especially programmers) - therefore I'd like to mention that everything written here is meant in a productive, non offensive way and is just my personal opinion.


Concepts

Traits

Problem
Currently, most traits are just attribute modifications that don't have a meaning at all, especially since there are three other ways of gaining attribute points (experience, training and equipment).

Solution
The easiest solution would be to remove the whole system. I don't think it's a good solution though. Instead, the stat modifications should be replaced by a unique mechanic for each trait - the "Virgin" trait is a good example for that. Other ideas could be "Nymphomaniac" letting the character gain joy when working as a prostitute but lose joy otherwise or "Broken Will" allowing the character to be treated like a slave without losing anything. These are just samples, I'm sure you and the community can come up with a lot of creative stuff. All other traits - especially the very generic ones (like "Great Figure", who would create a pack for an ugly character anyway?) - should be removed.


Slaves

Problem
Slaves have very few things that distinguish them from normal employees. APs are replaced by money to hire them, wages are replaced by the slave tax to pay them - in both cases it is essentially the same outcome for the player.

Solution
The current system could be replaced with an interesting risk vs reward mechanic like slave riots or government raids (which is implying that slave trade is illegal, but that bit of lore should be easy to change), causing the player to lose all slaves working in a particular brothel that aren't loyal or happy enough. To make this more interesting, slaves should start with very low happiness when bought (would you be happy to be sold?).


Tagging

Problem
Redundancy, duplication and the same thing multiple times. Seriously, I don't mean to be offensive, but the current tagging system is horrible. You essentially store the exact same data three times - in the name (currently not used as information source for whatever reason), the XMP metadata (a really bad way to obfuscate information) and the json files (that aren't even sorted for fast access).

Solution
Completely remove the tags.json and the metadata - use the file names instead. The only reason to not use the name for such simple information encoding would be because the names are user defined and therefore immutable, but as the user never sees the image names (except when he wants to change the tags) that is not the case. Chose single numbers and characters that encode each tag (or two if there are more than 36 tags). That way a user can change the tags of an image within a second without the need for an additional tool.
Optionally, keep the json files but reorganize them. Storing the tags for each image doesn't make much sense (for efficiency), store a list of images for a given tag instead so you can access them faster.

Problem
Bloooooooooating. Yes, I mean the amount of tags. I (kind of) followed the discussion on the tagging concept thread and I disagree with the common opinion that more tags are better than less tags, at least with the current system. You talked about introducing categories which is a good step, but it's not far enough.

Solution
Why don't you use a hierarchical system for tags with fallbacks to the parent tag instead of a category or a profile picture. This would be the first step to make many tags a viable option. But even then you should consider which tags you actually need and which just increase the amount of time and pictures that a pack needs to be complete (where complete means that every tag is present at least once).

• One for each sex type? Yes, definitely. These are the most important tags, but what actually counts as sex type? I used a statistical approach: "Vaginal", "anal" and "blowjob", followed by "handjob" and "titjob" - those five have the highest number of hits (using various search engines) and should definitely have their own tag. All others are very similar to one of them so it's a good start. Propably "footjob" should be added as well, because it's quite different from the others.
• An own tag for lesbian activities? That's a sexual orientation, not a sex type. Licking a woman as a woman can be considered a blowjob, fingering equals handjob and so on. No need for a discriminating tag (side note: I'm a straight male, I'm just trying not to ignore other peoples' sexual orientation). That would also allow you to make customers gender-neutral, reducing the effort for the writer significantly. If you don't want gender neutral customers, add a tag that defines what gender the partner has (male, female, futa, group).
• One for every little detail in the image? Well, having an image that exactely matches the text is nice, but my honest opinion is that if this is a problem then you should get a better writer instead of more tags. General descriptions don't have to be boring and the game doesn't need insanely detailed descriptions or image tags.
• One for each location with a generic location as fallback? Well, I can see the point why you would do that. But the image is supposed to show the character, not the background and therefore the only area that is really different from the others is the beach.
• One for each mood? Really? Is this even used in the game? Does it matter? Who cares about the mood of the character? Conclusion: These are way too specific and add more effort than they are worth. The same goes for the different costumes (bunny, cat, dog and cow).
• One for each occupation? I guess this makes sense, but you should differentiate between different jobs (like stripping or cleaning) that need an own tag and general freetime activities that can definitely be unified as such.

Result (note that this is just a concept)
> Profile
  -> Freetime
    --> Beach
    --> Rest
      ---> Masturbate
  -> Job
    --> Waitress
      ---> Bartending
      ---> Cleaning
    --> Stripper
    --> Arena
> Prostitute
  -> Sex
    --> Vaginal
    --> Anal
  -> MakeOut
    --> Blowjob
    --> Handjob
      ---> Footjob
    --> Titjob

And there you go. All tags I've seen while playing the game in a hierarchical order. Of course more can be added, but always keep in mind where the focus of the image is - there is no need to describe what color the tree in the background has. And if it actually isn't detailed enough then try generalizing the description texts.


Balance

Save Scumming

Definition
For those who don't know, save scumming means to create a save point before every important event (e.g. a fight in the arena or a new day) and reload if something bad happens.

Problem
Not only does the game allow it, I'd say it encourages it, especially in the arena. There are so many random things (rewards, enemy selection, critical hits) that it can get incredibly frustrating.

Solution
There are two things that need to be solved here: The ability to save scum in general and the frustrating RNG on a per-case basis.

First, the saves: There is a simple solution that many game developers use: Select one save slot at the start of the game and autosave to that slot after certain events. Do not allow the user to save the game to any other slot. This method doesn't make save scumming impossible, it just increases the effort so much that it's no longer worth it.

Second, the random elements - let's start with the arena.

• The rewards should be further split up into tiers based on the item value (e.g. stimulant in tier 0, big mana potion in tier 1 and ultimate health potion in tier 2). The rewards could then be readjusted to reward one random item from each tier.
• Something similar should be done for the enemies. I don't want to get into details here because the chainfights don't seem to be very polished so I assume it's still a work in progress.
• Critical hits are a problem because most games that use critical hits have a high amount of hits per fight, reducing the randomness by applying the law of big numbers. In PyTFall, some fights are over after a single hit - that's not a good environment for random critical hits. If you want to keep the mechanic you should introduce items that balance it, e.g. a full body suit that prevents critical hits on the player.
• The training also is quite random. The amount of stat points that a character gets should be more consistent.
• Events like the prostitute violence or the above proposed slave raid are somewhat difficult to adjust. I think a pseudo random system would be the best approach here - which basically means that the chance for an event to happen increases until it happens and then gets reset.
• Finally, the shops could get a button that refreshes the inventory for a small fee.

Arena

Problem
I know this is kind of a work in progress, but currently it bugs me very much that fighting in the arena is so much more efficient than anything else in the game. I consider it a good thing to make the game more than just a brothel sim, but in the end all activities should be equally rewarding.

Solution
First of all, balance the randomness and prevent save scumming, see the points above. The most important next step would then be to limit the boss reward (maybe to once a week). After that you can start adjusting raw values and maybe even introduce things like a difficulty setting or level scaling.


Documentation

Attributes

Problem
I've checked out the thread where somebody is asking for advice on what each attribute does and someone answered that the stats should be self explanatory. Well, they're not, at least not all of them. This might be a problem of missing implementations (work in progress stuff), but what are "character" and "libido" supposed to do? Isn't "character" just inverted obedience? If so, why is there one black sheep among the flock (one negative among positive attributes)? I have a stripper in one of my savegames that has 0 character and 100 libido and still refuses to work as a prostitute (which is kind of ridiculous).

Solution
I know the game is an alpha version, but some basic documentation wouldn't hurt. This includes things that are supposed to work and things that will be added in the future.


Conversion vs compatibility

Compatibility with old WM packs is nice, but a tool for converting them would be better. It bugs me that the missing elements are random generated for every new game.


Savegames

Modifications to characters that aren't in the saved game yet (yes, I did check the whole city) do not apply for some reason. The same goes for database changes (e.g. adding a new item). Is that a bug or do you actually save the whole database in a save game?


Error handling

The note that some file wasn't found is really not helpful. What would be helpful is a tool to verify characters or an error message that actually tells me what file the game was looking for. Also, crashing the whole game because a single image couldn't be loaded seems unnecessary.


Interface

Resolution

The maximum internal resolution is 1280x800 - 720p isn't too bad, but on a 1080p screen it still looks... questionable. Is there a way to increase the render resolution?


New day

Problem
The new day screen doesn't have the focus that I'd like it to have. To put it in simple terms: What I want to see in the first place is the image. Afterwards, a short text and a summary of stat changes would be nice. So that's the priority. Why does the image only get 1/3 of 3/4 of the screen? Why do the few numbers that show attribute changes get just as much? Why does the tooltip box (in which I've never seen more than one line) get five? Why does every building have a (relatively) huge thumbnail instead of a simple "Next -"/"Previous brothel" button?

Solution
A new layout! Did this within 3 minutes, it's enough to show the general idea. It should be better for both large screens (lots of space for the image) and small screens (because it uses a vertical layout instead of a grid). Note that "section" skips to the next/previous building, then the character overviews, then the personal overview.
In case you actually like it, consider using a different (similar to the old) layout for the overviews (doesn't make much sense to have a huge profile picture there).


Attribute overview

Problem
Currently, all attributes are expressed with two numbers - current and maximum. While that is technically acceptable, managing equipment for characters would be a lot easier if it would be visible how many points are the character's base and what comes from equipment (and, currently, traits).

Solution
There are two solid approaches - which one is better depends on how much space is available.

The first is a progress bar with multiple values.
<-------|----|---|--> (base, current, max, bar length = absolute max)
"Base" is the amount of points that the character has, "current" is the amount of points that is used for calculations, "max" is the current maximum and "absolute max" is the maximum possible at the current character level. The numeric values could simply be shown on the bar.

The other possibility would be color coding - less space requirement, but also less intuitive to read.
XX/YY
"XX" shows "current", the color (or background color) depends on the "base" to "current" ratio (light green to orange), "YY" shows "max" and is colored depending on the "max" to "absolute max" ratio (again, light green to orange is preferable).


Other problems

Whenever a stripper auto-rests, the stripping performance of the current day counts as minimum, causing all other characters in the brothel to earn much less money. I assume that's not intentional.

I checked the last few pages of this thread and noticed the discussion about different jobs for every profession. While I generally don't mind the idea, please try to consider if a certain job makes sense for the player before adding it. I'll try to give you a few (negative) examples (my apologies to MrKlaus, his post is the most productive in this matter, so I also took the examples from it):
Jobs that only add a different image type (e.g. dominatrix for the "bdsm" tag or receptionist for the "group" tag) - why not just make customers request that kind of stuff?
The same job in different locations (e.g. strippers, event dancers & cabaret dancers) - if there's no possibility for different outcomes for the player, it should stay generalized.
Overly complex or punishing mechanics (e.g. assassins and bodyguards) - while I think that it sounds very interesting, I also think that it's a little too complex (especially because killing the player in a game like this sounds like a really bad idea).
My point: As long as a job doesn't have an interesting mechanic (that doesn't punish the player too much) or adds the possibility for an extreme fetish image tag (side note: define "extreme"), it's propably unnecessary.

Finally, on the point of adding more attributes for dating and other stuff: Keep it reasonable and try not to overload the interface (character overview already is cramped).


It's unfortunate (for me) that you chose RenPy as your preferred framework. I have experience with C, C++, Java, Lua, PHP, HTML and CSS, but none with Python (and no interest in learning it at this time) so I can't really help you with code.

That's it for now, everything is up for discussion so feel free to bash me (but please stay reasonable).
Have fun!

[Xela]

Hey everyone!
So... this project has been around for a while and since I had a lot of free time in the past month I guess it's time to give some feedback. I'll put it in one post although I am aware that some of the topics have own threads. If you don't like that, feel free to tell me.

Disclaimer
Many people don't like criticism (especially programmers) - therefore I'd like to mention that everything written here is meant in a productive, non offensive way and is just my personal opinion.

Ok... now that one hell of a post And there are no actual programmers on the team, I am doing most of the coding and I am self-tough so constructive criticism is more than welcome.

Traits

Problem
Currently, most traits are just attribute modifications that don't have a meaning at all, especially since there are three other ways of gaining attribute points (experience, training and equipment).

That's not true, there are literally thousands lines of code, behavior, events and texts governed by traits. It is just not being relayed player in text form but attempts to create an appropriate environment and behavior of the characters. Also traits now have different mechanics as well and those "unique" properties you've suggested has been added as Effects (I do not remember if that is the case in an Alpha).

Most of the solutions proposed are already a part of the game (even the alpha release I believe).
==============================

Problem
Slaves have very few things that distinguish them from normal employees. APs are replaced by money to hire them, wages are replaced by the slave tax to pay them - in both cases it is essentially the same outcome for the player.

This has been mitigated to a good degree already, with fighters guild in the game, slaves cannot be ranked past 3 and a number of other adjustments to balance, situation did improve.

I was thinking about an anti-slavery religious movement and elven embassy that would work along the lines you proposed. It's something worth pursuing but when/how is another question.
==============================

Problem
Redundancy, duplication and the same thing multiple times. Seriously, I don't mean to be offensive, but the current tagging system is horrible. You essentially store the exact same data three times - in the name (currently not used as information source for whatever reason), the XMP metadata (a really bad way to obfuscate information) and the json files (that aren't even sorted for fast access).

Redundancy == duplication == the same thing multiple times.

XMP works awesomely in AA2 Also obfuscation of data is not the point here and there is a new tagger written in C# that works without it.

I have no idea what "sorting json file for fast access" means.

INFO     PyTFall 0.47 Alpha Loading: Tag Database
INFO     PyTFall 0.47 Alpha.tags loaded 24352 images from tags.json files
INFO     PyTFall 0.47 Alpha It took 2.41000008583 secs to execute!

Solutions:

We've tried storing complex data in filenames, looks ridiculous and bit of a pain for work with (tagger would also be required I think). I'd love to see a user changing a file name called jfmsiofh09whfw0efbn04w8hr0wrhbw0gfbw08trhj03hbrfw0irfjwe0-rehj0kfn0rde9hbn9wefubfsb.png without any additional tool  It's an option, just don't know if it's faster/more reasonable than json.

tag: set(images)

is how it's is stored in the game, json is required to be sorted in a different manner for reasons I don't want to go in right now. It can be circumvented, but I doubt it will significantly improve performance and all tagging software would have to be adjusted.

On the "bloating" front, CW and Dark and in charge of improving tagging logic.

Falling back (hierarchical order) can be handled with code, if it can be done with tagging concept, fine but it is not going to be easy.

The lesbian thing was inherited from WM, we've taken a bunch of concepts we prolly shouldn't have. But the current system is working, there is no denying that.

Generic locations are mostly used in inside/outside atm but also beach, forest, park. I don't believe it should be left out. Costumes are not used, yes, mood could be more general as well I suppose but believe it or not: We've actually removed a whole bunch of tags from the original concept!!!
===============================

Problem
Not only does the game allow it, I'd say it encourages it, especially in the arena. There are so many random things (rewards, enemy selection, critical hits) that it can get incredibly frustrating.

This was reported several times, I still don't understand why. If people want to do it, why not let them?
===============================

Arena

Problem
I know this is kind of a work in progress, but currently it bugs me very much that fighting in the arena is so much more efficient than anything else in the game. I consider it a good thing to make the game more than just a brothel sim, but in the end all activities should be equally rewarding.

Possibility, I am thinking about adding minigames and most importantly: integrating Arena events (ladder position, recent victories) with the rest of the game. But that kind of content creation is in the future (we need more NPCs, Locations, concept for girlsmeets and etc.) As for internal mechanics, we need to improve battle engine and interface (add relative strength to teams and etc.).

Preventing grinding or making it less profitable... I am not sure I like that. Also brothels are a lot more profitable now and the damn fighters guild is like an alchemy set where they turn trash into gold (but it's still in a very early stages).
===============================

Problem
I've checked out the thread where somebody is asking for advice on what each attribute does and someone answered that the stats should be self explanatory. Well, they're not, at least not all of them. This might be a problem of missing implementations (work in progress stuff), but what are "character" and "libido" supposed to do? Isn't "character" just inverted obedience? If so, why is there one black sheep among the flock (one negative among positive attributes)? I have a stripper in one of my savegames that has 0 character and 100 libido and still refuses to work as a prostitute (which is kind of ridiculous).

Solution
I know the game is an alpha version, but some basic documentation wouldn't hurt. This includes things that are supposed to work and things that will be added in the future.

It might hurt me

We've made mechanics too complex for a 2 + 2 = 4 explanations and they may change in the future, we may cook something up for the next release.
==============================

Conversion vs compatibility

Compatibility with old WM packs is nice, but a tool for converting them would be better. It bugs me that the missing elements are random generated for every new game.


Savegames

Modifications to characters that aren't in the saved game yet (yes, I did check the whole city) do not apply for some reason. The same goes for database changes (e.g. adding a new item). Is that a bug or do you actually save the whole database in a save game?


Error handling

The note that some file wasn't found is really not helpful. What would be helpful is a tool to verify characters or an error message that actually tells me what file the game was looking for. Also, crashing the whole game because a single image couldn't be loaded seems unnecessary.

The randomly generated elements are better now but you can just edit the files + throw in battle, beach and portrait pictures and you'll have a half-baked "native" character.

Whole database is saved, yes.

We may have gotten rid of the crash thing already.
==============================

Interface

Resolution

The maximum internal resolution is 1280x800 - 720p isn't too bad, but on a 1080p screen it still looks... questionable. Is there a way to increase the render resolution?


New day

Problem
The new day screen doesn't have the focus that I'd like it to have. To put it in simple terms: What I want to see in the first place is the image. Afterwards, a short text and a summary of stat changes would be nice. So that's the priority. Why does the image only get 1/3 of 3/4 of the screen? Why do the few numbers that show attribute changes get just as much? Why does the tooltip box (in which I've never seen more than one line) get five? Why does every building have a (relatively) huge thumbnail instead of a simple "Next -"/"Previous brothel" button?

There is very little to be done about the resolution without an obscene amount of effort, but it might get better after we redesign the screens.

We went with a summary screen approach, these are from a more recent version (actual game, not mock-ups):




=======================================

Problem
Currently, all attributes are expressed with two numbers - current and maximum. While that is technically acceptable, managing equipment for characters would be a lot easier if it would be visible how many points are the character's base and what comes from equipment (and, currently, traits).

And people on the other side of this argument are asking to obfuscate stats all together. It can be done without too much fuss I think but is bound to piss some people off.
=======================================

Other problems

Auto-rest thing is fixed.

I don't see how jobs bit is under "problems". I do agree with the narrative, however I don't believe that we're is in the majority here. I am convinced that most people for whatever reason, like having dozens of jobs working off the almost exactly the same mech/interface just with different texts/background.

As for PyTFall, next jobs will be fighting guild related and that's a completely new design.

I do not favor (this is very mildly put) adding more attributes to the game
=======================================

[livingforever]

Hey there!

That's not true, there are literally thousands lines of code, behavior, events and texts governed by traits. It is just not being relayed player in text form but attempts to create an appropriate environment and behavior of the characters. Also traits now have different mechanics as well and those "unique" properties you've suggested has been added as Effects (I do not remember if that is the case in an Alpha).

Most of the solutions proposed are already a part of the game (even the alpha release I believe).

Alright. Well, I haven't noticed any trait based mechanic other than for the "Virgin" trait in the alpha release. Maybe I just haven't been paying enough attention to it...

We've tried storing complex data in filenames, looks ridiculous and bit of a pain for work with (tagger would also be required I think). I'd love to see a user changing a file name called jfmsiofh09whfw0efbn04w8hr0wrhbw0gfbw08trhj03hbrfw0irfjwe0-rehj0kfn0rde9hbn9wefubfsb.png without any additional tool  It's an option, just don't know if it's faster/more reasonable than json.

tag: set(images)

is how it's is stored in the game, json is required to be sorted in a different manner for reasons I don't want to go in right now. It can be circumvented, but I doubt it will significantly improve performance and all tagging software would have to be adjusted.

Aha. So they are ordered by tag internally but json doesn't allow it. Interesting, didn't know that. Generally, I think adjusting the tagging software at this stage of development shouldn't be a reason not to make changes. I'm not sure how fast the conversion is (from the json format to the internal format), I guess it's not a big deal, but speeding things up wouldn't be bad either.

I agree that storing data in filenames looks somewhat ridiculous, but I definitely think that it is both faster and more reasonable.

• First of all, while I get the point of your example, it isn't realistic. Just because it's encoded doesn't mean it has to be unreadable. Renaming "-bj-in-fm-.jpg" to replace "bj" with "hj" (blowjob -> handjob) isn't so difficult.
• Second, it would avoid storage redundancy. The name of a file is always read by the OS, so it doesn't matter if there is information in it or not - it will always be accessed for every file.
• Third, it would be faster. Listing all filenames within a folder is a system level operation (compared to json parsing which requires a library). This is most likely but must not always be true for low-level languages like C++, but given that Python is a high-level language, reading and parsing a file with a library is definitely slower than just parsing the information from the filename (that, as mentioned above, has to be accessed anyway).

Falling back (hierarchical order) can be handled with code, if it can be done with tagging concept, fine but it is not going to be easy.

Actually, a combination of both would be the easiest approach.
Tagging:

• User adds tag
• Add all parent tags (recursive)

Parsing:

• Check for an image with the tag
• If none exists, check for next parent tag (recursive)

Not so complex, is it? Sure, you could also use a code-only solution with double-linking (parent -> children and child -> parent):

• Check for an image with the tag
• Find all other child tags of current parent (recursive to include their children as well) *
• Check for all found tags in random order (*recursive)

Personally, I think the first solution is more elegant because it doesn't require RNG to avoid using the same child tag and (propably more important) because it's more flexible (it allows the user to explicitly exclude a parent tag if it doesn't apply for some reason or if the image shouldn't be used as an alternative for anything).

The lesbian thing was inherited from WM, we've taken a bunch of concepts we prolly shouldn't have. But the current system is working, there is no denying that.

Yes, it's definitely working - but that's not a good reason to make the same mistakes again. The more you are afraid of making far reaching changes now (which I can totally understand by the way), the more you will get into trouble later on.

This was reported several times, I still don't understand why. If people want to do it, why not let them?

As I mentioned in my previous post, there is too much frustrating RNG at the moment. Most users reporting it are people that don't like save scumming but still do it sometimes because of that (side note: I'm claiming that not because I am one of them but because I have some experience in game design).

It might hurt me

We've made mechanics too complex for a 2 + 2 = 4 explanations and they may change in the future, we may cook something up for the next release.

Thanks for keeping it in mind  .

The randomly generated elements are better now but you can just edit the files + throw in battle, beach and portrait pictures and you'll have a half-baked "native" character.

Nope. That is exactely the problem: Simply editing the .girlsx files is not an option because they are missing information like occupation and location (among others). That's why a tool for converting them into your xml format would be nice.
I wrote such a tool for .rgirlsx files by the way (it reads the files from the current folder and converts them to the json format, missing information is prompted via GUI), but I was incredibly lazy (really damn lazy) so the output files are written line by line instead of by a json writer. I'd better not show the code to anyone  .
Seriously though, I could write a similar tool for girlsx to xml conversion (hey, maybe I'll even use a real XML parser) and upload them.

Actually, screw it, it's not like I have anything to do in the next month. Let's see if I get bored enough to write a character creation tool that can export chars and rchars, import girlsx and rgirlsx and modify tags (in the way that I suggested so you can't use the "missing editor" excuse)!

Whole database is saved, yes.

But... whyyyyyyy? I mean... I guess you have your reasons, but is that really necessary?

There is very little to be done about the resolution without an obscene amount of effort, but it might get better after we redesign the screens.

Oh. Well, can't do much about it if the framework doesn't allow it. And changing the framework at this point of development isn't a viable option I guess.

We went with a summary screen approach, these are from a more recent version (actual game, not mock-ups):

It's an improvement. Still not ideal in my opinion, but definitely better.
The problem still is the grid layout: You're using a lot of space for the text box even though there might not be a lot of text to show. But further reducing the width of the box would cause lots of linebreaks that you really don't want to have.

And people on the other side of this argument are asking to obfuscate stats all together. It can be done without too much fuss I think but is bound to piss some people off.

Ok, I give you that one. I guess it's just personal preference how much information you want to see.

And a final note about the new jobs: I'm not trying to stop you from adding new ones as long as they have a good purpose.
Have fun!

[Xela]

Hi

Hey there!Alright. Well, I haven't noticed any trait based mechanic other than for the "Virgin" trait in the alpha release. Maybe I just haven't been paying enough attention to it...

Job Events/Interactions/Girlsmeets are all very heavily based on traits.
=====================================

Aha. So they are ordered by tag internally but json doesn't allow it. Interesting, didn't know that. Generally, I think adjusting the tagging software at this stage of development shouldn't be a reason not to make changes. I'm not sure how fast the conversion is (from the json format to the internal format), I guess it's not a big deal, but speeding things up wouldn't be bad either.

It allows that, but it creates issues when binding the tags to actual character. Also, there is another issue, we do not have source code for python/qt based tagger and I am not versed enough in C# to make any significant changes to the new tagger in any short amount of time. Simply put, if we ever require a new tagger, I'll prolly have to code one from scratch.
=====================================

I agree that storing data in filenames looks somewhat ridiculous, but I definitely think that it is both faster and more reasonable.

   

• Second, it would avoid storage redundancy. The name of a file is always read by the OS, so it doesn't matter if there is information in it or not - it will always be accessed for every file.

It may be faster, hard to tell without timing. You'd have to analyze every single file name sting, from jsons, you just open/read the file and load data.
=====================================

Tagging:

• User adds tag
• Add all parent tags (recursive)

Parsing:

• Check for an image with the tag
• If none exists, check for next parent tag (recursive)

Not so complex, is it? Sure, you could also use a code-only solution with double-linking (parent -> children and child -> parent):

• Check for an image with the tag
• Find all other child tags of current parent (recursive to include their children as well) *
• Check for all found tags in random order (*recursive)

This process is a lot more complicated that it seems. You often require a combinations of many tags, at times some are more important than others, sometimes they all have the same weight and so on. Tagging system is far more complex and better tuned that one can imagine just by looking at tags and there are still improvements to be made. We don't utilize it enough yet either. It's a work in progress, but the way you look at it is oversimplification.
=======================================

As I mentioned in my previous post, there is too much frustrating RNG at the moment. Most users reporting it are people that don't like save scumming but still do it sometimes because of that (side note: I'm claiming that not because I am one of them but because I have some experience in game design).

The reason I do not worry about it too much atm is that we can add an option to lock random seed as an option in the future or enable saving only once every 10 days for example. Personally, I do not see a problem here and simple ways to improve the situation for the more coherent release.
=======================================

Nope. That is exactely the problem: Simply editing the .girlsx files is not an option because they are missing information like occupation and location (among others).

? What exactly is stopping you from adding that information? Those files are open text (they are actually renamed xml format allowing all xml syntax), game will pick up any fields it recognizes as native to itself so adding location, missing stats and occupation is valid. As I've said, adding battle_sprite and portrait images will make the WM girls (more or less) native to PyTFall.
=======================================

I wrote such a tool for .rgirlsx files by the way (it reads the files from the current folder and converts them to the json format, missing information is prompted via GUI), but I was incredibly lazy (really damn lazy) so the output files are written line by line instead of by a json writer. I'd better not show the code to anyone  .
Seriously though, I could write a similar tool for girlsx to xml conversion (hey, maybe I'll even use a real XML parser) and upload them.

Both of them are .xml. Conversion is not complicated but if you wanna make one, go ahead. Random girls from WM are not fun in PyTFall without converting (properly) image packs as well, and anyone who is willing to do that will write their own json files. (takes 5 mins, converting packs takes hour(s))
======================================

Actually, screw it, it's not like I have anything to do in the next month. Let's see if I get bored enough to write a character creation tool that can export chars and rchars, import girlsx and rgirlsx and modify tags (in the way that I suggested so you can't use the "missing editor" excuse)!

If you actually get around to writing one, see if you can add renaming images to tags in filename structure as well. I'd need a JSON with a simple dict of:

{"bj": [index, "blowjob"]} to convert the info in the game, we can see what's actually faster more convenient then.
======================================

But... whyyyyyyy? I mean... I guess you have your reasons, but is that really necessary?

Not necessary but:

--- launch game ---
INFO     PyTFall 0.47 Alpha game directory: D:\Coding\Dropbox\Dev\RenPy\pytfall\game
INFO     PyTFall 0.47 Alpha Loading: Crazy Tags
INFO     PyTFall 0.47 Alpha It took 0.733999967575 secs to execute!
INFO     PyTFall 0.47 Alpha Loading: Random Name files
INFO     PyTFall 0.47 Alpha It took 0.00500011444092 secs to execute!
INFO     PyTFall 0.47 Alpha Loading: Traits
INFO     PyTFall 0.47 Alpha It took 0.00399994850159 secs to execute!
INFO     PyTFall 0.47 Alpha Loading: Items
INFO     PyTFall 0.47 Alpha It took 0.730000019073 secs to execute!
INFO     PyTFall 0.47 Alpha Loading: Brothels
INFO     PyTFall 0.47 Alpha It took 0.00100016593933 secs to execute!
INFO     PyTFall 0.47 Alpha Loading: Tag Database
INFO     PyTFall 0.47 Alpha.tags loaded 24352 images from tags.json files
INFO     PyTFall 0.47 Alpha It took 2.09999990463 secs to execute!
INFO     PyTFall 0.47 Alpha Loading: Characters
INFO     PyTFall 0.47 Alpha It took 0.354000091553 secs to execute!
INFO     PyTFall 0.47 Alpha Loading: PyTFallWorld
INFO     PyTFall 0.47 Alpha Loading Random Characters:
INFO     PyTFall 0.47 Alpha It took 0.0179998874664 secs to execute!
INFO     PyTFall 0.47 Alpha Loading: Mobs
INFO     PyTFall 0.47 Alpha It took 0.0130000114441 secs to execute!
INFO     PyTFall 0.47 Alpha Loading: Exploration
INFO     PyTFall 0.47 Alpha It took 0.0720000267029 secs to execute!
INFO     PyTFall 0.47 Alpha Loading: Generating Random girls
INFO     PyTFall 0.47 Alpha It took 0.27999997139 secs to execute!
INFO     PyTFall 0.47 Alpha Loading: testing mode
INFO     PyTFall 0.47 Alpha It took 0.0199999809265 secs to execute!
INFO     PyTFall 0.47 Alpha Loading: GirlsMeets
INFO     PyTFall 0.47 Alpha It took 0.0 secs to execute!
INFO     PyTFall 0.47 Alpha Loading: Populating SlaveMarket
INFO     PyTFall 0.47 Alpha It took 0.00100016593933 secs to execute!
INFO     PyTFall 0.47 Alpha Loading: Arena!
INFO     PyTFall 0.47 Alpha It took 0.158999919891 secs to execute!

Because building databases takes time, loading them from a saved file (Python's binary serialization structure, written almost entirely in C, yes: C, not C# or C++ or Python!) is lighting fast and saves are loaded almost instantaneously. Writing code to add an option to reload databases when loading savefiles is easy and I've already done it, but because we change stuff so often, it proved to be annoying so we decided to leave it until there is a coherent game version.

PS: Items are loaded a lot faster actually, this is code I wrote yesterday, trying to use Ren'Py libs instead of Python once, proved to be a lot slower.
==================================

Oh. Well, can't do much about it if the framework doesn't allow it. And changing the framework at this point of development isn't a viable option I guess.

Framework doesn't give a sh!t, you can set up any reasonable resolution. It also does excellent job "stretching" the screen but in order to actually support different resolution, I'd have to calculate size of every graphic element based of screen width + height setting. It's a bit too much, especially since the game window can adjust really well. Also, using better/more coherent graphical resources may improve the matter.

Honestly, even native 1280x800 is pretty high for an indie sim game, most devs don't even bother with that.[/list]

[DarkTl]

Wow, so much text 

Problem
Currently, most traits are just attribute modifications that don't have a meaning at all, especially since there are three other ways of gaining attribute points (experience, training and equipment).

Aside from attribute modifications, every trait has (and will have) checks in the code where it makes sense. Moreover, for many traits attribute modification is the only way to show somehow that they are working, because some systems are not ready, so it's like a placeholder.

For those who don't know, save scumming means to create a save point before every important event (e.g. a fight in the arena or a new day) and reload if something bad happens.

I believe scumming protection should be an optional part. Maybe even a part of higher difficulties only.

The maximum internal resolution is 1280x800 - 720p isn't too bad, but on a 1080p screen it still looks... questionable. Is there a way to increase the render resolution?

Keep in mind that the most important our resource - girls pictures - cannot be redrawn to higher resolutions anyway.

Overly complex or punishing mechanics (e.g. assassins and bodyguards) - while I think that it sounds very interesting, I also think that it's a little too complex (especially because killing the player in a game like this sounds like a really bad idea).

Um, these jobs are decoration for non employed by player girls 
There is a difference between them (main stat, payment), and they won't actually kill anyone or something.

• An own tag for lesbian activities? That's a sexual orientation, not a sex type. Licking a woman as a woman can be considered a blowjob, fingering equals handjob and so on.

Correct from the viewpoint of logic, but counterintuitive. No one says "lesbian hot blowjob", they say "lesbian hot licking" 
Well, unless we talking about sucking a strapon or something. Thus, even more counterintuitive.

Great Figure

Another legacy trait btw. I'll think about it.

Today I'm testing our food poisoning effect irl, so I can't think straight enough to discuss other matters 

[CherryWood]

Another legacy trait btw. I'll think about it.

I know it doesn't really show in drawing styles of manga or anime, but some characters are stated to be more beautiful then others in the series.
It could be probably simulated just by starting stats in json, but these have very little impact on the gameplay now.

[livingforever]

Hey again!

It may be faster, hard to tell without timing. You'd have to analyze every single file name sting, from jsons, you just open/read the file and load data.

I disagree. Sure, the json approach requires less code because all the logic is hidden behind an API, but think about it:
OS file listing lists all filenames within a folder - the JSON file is a list of files with name and path.
Yes, you'd have to call String.contains to check for tags - but with JSON you also need to compare the tags (which is most likely a full string comparison). Additionally, you need to open and parse the file first.

Just because the library takes care of it doesn't mean it's gone performance wise.

This process is a lot more complicated that it seems. You often require a combinations of many tags, at times some are more important than others, sometimes they all have the same weight and so on. Tagging system is far more complex and better tuned that one can imagine just by looking at tags and there are still improvements to be made. We don't utilize it enough yet either. It's a work in progress, but the way you look at it is oversimplification.

I don't see why multiple tags and weights should be difficult to implement:

• Check for an image with a list of weighted tags *
• Mark all found tags from the list
• If none exists, replace all tags that aren't marked with their parent tags
• Shift the weight of the replaced tags to their parent tags (*recursive)

I should propably mention that I don't like the idea of looking for multiple tags or weighting them in general. The simple reason (based on my opinion): If you are looking for multiple tags then the image doesn't have a clear focus or there are too many unnecessary tags. If the image doesn't have a clear focus then it shouldn't be in the pack. If there are too many tags... read my first post.
I'm pretty sure that there are exceptions, but you get the general idea.

The reason I do not worry about it too much atm is that we can add an option to lock random seed as an option in the future or enable saving only once every 10 days for example. Personally, I do not see a problem here and simple ways to improve the situation for the more coherent release.

I believe scumming protection should be an optional part. Maybe even a part of higher difficulties only.

Let me try to clarify this: I don't expect you to completely prevent save scumming with the slot solution if you don't want to. But I still want to see the proposed changes to random elements implemented to reduce RNG frustration.

? What exactly is stopping you from adding that information?

Yeah... I never even tried that. Silly me.

Random girls from WM are not fun in PyTFall without converting (properly) image packs as well, and anyone who is willing to do that will write their own json files. (takes 5 mins, converting packs takes hour(s))

Indeed. Funny thing is that I stumpled upon the issue that there are way too many tags while doing that. Writing a tool for converting the data files still saved some time though.

If you actually get around to writing one, see if you can add renaming images to tags in filename structure as well. I'd need a JSON with a simple dict of:

{"bj": [index, "blowjob"]} to convert the info in the game, we can see what's actually faster more convenient then.

Uhm... the dictionary should only take me a minute to create, but what is the index for?
And by "filename structure" I assume you mean the tags.json files?

Sorry for the (potentially) stupid questions, my brain isn't working very fast today.

Writing code to add an option to reload databases when loading savefiles is easy and I've already done it, but because we change stuff so often, it proved to be annoying so we decided to leave it until there is a coherent game version.

Makes sense.

Framework doesn't give a sh!t, you can set up any reasonable resolution. It also does excellent job "stretching" the screen but in order to actually support different resolution, I'd have to calculate size of every graphic element based of screen width + height setting. It's a bit too much, especially since the game window can adjust really well. Also, using better/more coherent graphical resources may improve the matter.

That confuses me. Aren't you using a layout manager to scale the interface based on weights and alignments?

Keep in mind that the most important our resource - girls pictures - cannot be redrawn to higher resolutions anyway.

Confusing as well. There are very good scaling algorithms and libraries (that produce good results even when upscaling by factor two).

You could argue that the graphics card is upscaling (from the internal render to the screen resolution) much faster than you can do it with code - but at the cost of precision and customization. And since the internal resolution shouldn't change that often I think it would be worth it to make adjustments on your end.

Correct from the viewpoint of logic, but counterintuitive. No one says "lesbian hot blowjob", they say "lesbian hot licking" 
Well, unless we talking about sucking a strapon or something. Thus, even more counterintuitive.

I see your point. However, I think that less tagging effort is worth a lot more than slightly more intuitive tags.

Have fun!

[Xela]

I disagree. Sure, the json approach requires less code because all the logic is hidden behind an API, but think about it:
OS file listing lists all filenames within a folder - the JSON file is a list of files with name and path.
Yes, you'd have to call String.contains to check for tags - but with JSON you also need to compare the tags (which is most likely a full string comparison). Additionally, you need to open and parse the file first.

Just because the library takes care of it doesn't mean it's gone performance wise.

Well, if you code a tool that can write data to filenames and json, we'll know. Otherwise I am not guessing what's faster.

I don't see why multiple tags and weights should be difficult to implement:

• Check for an image with a list of weighted tags *
• Mark all found tags from the list
• If none exists, replace all tags that aren't marked with their parent tags
• Shift the weight of the replaced tags to their parent tags (*recursive)

I should propably mention that I don't like the idea of looking for multiple tags or weighting them in general. The simple reason (based on my opinion): If you are looking for multiple tags then the image doesn't have a clear focus or there are too many unnecessary tags. If the image doesn't have a clear focus then it shouldn't be in the pack. If there are too many tags... read my first post.
I'm pretty sure that there are exceptions, but you get the general idea.

It might work, depends on the fallback tree. Like I've said, Dark/CW are in charge of tagging concept, if you want to write one/participate, you're more than welcome (clearcut concepts is what the dev is missing the most atm). maybe we can even find some simple way to differentiate between old/new and keep the game working until all packs are converted.

Let me try to clarify this: I don't expect you to completely prevent save scumming with the slot solution if you don't want to. But I still want to see the proposed changes to random elements implemented to reduce RNG frustration.

Second, the random elements - let's start with the arena.

• The rewards should be further split up into tiers based on the item value (e.g. stimulant in tier 0, big mana potion in tier 1 and ultimate health potion in tier 2). The rewards could then be readjusted to reward one random item from each tier.
• Something similar should be done for the enemies. I don't want to get into details here because the chainfights don't seem to be very polished so I assume it's still a work in progress.
• Critical hits are a problem because most games that use critical hits have a high amount of hits per fight, reducing the randomness by applying the law of big numbers. In PyTFall, some fights are over after a single hit - that's not a good environment for random critical hits. If you want to keep the mechanic you should introduce items that balance it, e.g. a full body suit that prevents critical hits on the player.
• The training also is quite random. The amount of stat points that a character gets should be more consistent.
• Events like the prostitute violence or the above proposed slave raid are somewhat difficult to adjust. I think a pseudo random system would be the best approach here - which basically means that the chance for an event to happen increases until it happens and then gets reset.
• Finally, the shops could get a button that refreshes the inventory for a small fee.

- Rewards work fine, I will not complicate working systems until a final release.
- Same as above.
- At higher levels fights can take a really long while, one - two hits fights are less common I believe. Also there is no point of doing this before we rework battle engine.
- And I like randomness during training.
- Job attack Events depend on clients that get "Aggressive" trait randomly assigned, they are farther mitigated by security rating. I see no reason to change that.
- I actually hate stuff like this in games, it kinda ruins the mood and disrupts continuity. I expect mods will take care of request like this in the future.

In any case, most of this is fine-tuning, we'll take care of stuff like this when there is a game with more or less solid concepts in place + locking random seed solves most of these issues, if stuff isn't randomized after loading game anymore, save-scumming becomes a lot less attractive.

Uhm... the dictionary should only take me a minute to create, but what is the index for?
And by "filename structure" I assume you mean the tags.json files?

I mean if you're planning to code a new tagger, see if you can have it not only write to json but also to rename the files accordingly.

Forget about the "index", I though for a moment about how I'd go around doing it and though including indexed positioning in fn strings was a good idea, after a bit of rest: it is prolly an idiotic one.

That confuses me. Aren't you using a layout manager to scale the interface based on weights and alignments?

*Not exactly...

"The maximum internal resolution is 1280x800 - 720p isn't too bad, but on a 1080p screen it still looks... questionable. Is there a way to increase the render resolution?"

In order to render at higher resolutions, I wouldn't be able to use:

Code: [Select]

        frame:
            background Frame("content/gfx/frame/desk_1.png", 15, 15)
            xysize (600, 710)
            pos(20, 60)
code. I'd have to scale everything like:

It's possible but a pain and since window/fullscreen can be stretched to any resolution, I see no point in doing that.

[Xela]

Sorry but I don't understand what's wrong with tags at all. I mean, what you are talking about. Was this supposed to be about tagger, tags or tags calling in code? Something not working? (I'm using Rudi's tagger and I didn't have a problem yet) And WTF is "parent" tag? (tag is either there or not, what else?)

I personally would want to maybe change actual tags a bit (but only change to blowjob is truly required atm) and always welcome improvements to tags call methods, but I don't see any problem with the tagger. (but I didn't try the second one)

LoL That's the point I am trying to make. It is working and working really well.

livingforever believes that the system is too large, unintuitive and slow (loading process at the beginning of the game takes little over 3 seconds for 25 000 images), he thinks that we can do better by encoding tags in file names and improve the system by having less tags/hierarchy.

[Xela]

Isn't "character" just inverted obedience? If so, why is there one black sheep among the flock (one negative among positive attributes)? I have a stripper in one of my savegames that has 0 character and 100 libido and still refuses to work as a prostitute (which is kind of ridiculous).

This is not exactly true for character... the real black sheep is fatigue. I am going to go through all items, traits and code files tonight and change it to "energy" or something like that (adjusting values) tomorrow cause I am sick of inverting it all over the code.

[CherryWood]

Heh. thanks for explation of what's going on 

Ok, so my option is:
- I think that current tagger-json system is working fine for our purposes. Its likely not perfect but that could be said about just anything in game - and I just don't feel that the improvements there would be wort the time that could be spent elsewhere.
But maybe I just didn't understand the suggestion well enough.

- there is an overwhelming number of tags, but majority of them are secondary tags which are just optional to use - pack creators can just tag everything with only major tags like "profile" or "sex" and girls will work with generic texts with almost no effort (like girls imported from wm). That's why we didn't hold back there, it's just for the perfectionist freaks who care about it  But some tag revision is planned.


But to be honest, placing tags calls in code like job reports is kinda unfriendly... So if this suggested new system can improve that, then I'm sure willing to listen more.