Others The Ultimate Stripper Club [v1.0.4] [everglow]

[dooka58]

Maybe everyone else likes it playing the same every time. Maybe everyone else goes and manually changes all their people before they start a new game. Personally I'd rather get variation, and I'd rather have it built into the game. Therefore I suggested it as an idea for future inclusion. You or anyone else is free to say you dislike this idea. The developer is free to implement it or not.

Perhaps I misunderstood you, but I thought we were talking about randomizing popularity and/or price. My bad, if I was mistaken... ideally, price would scale with earnings drivers like we suggested, but personally I'm satisfied with my popularity cap of 50. I didn't have to edit anything but once, and the dev didn't have to do anything.

I don't quite understand why you want this feature "built-in" when girlpacks are user generated and customizable, which I think is a strength rather than a weakness. I wouldn't like forcing hiring limitations on everyone when the early game is already a pain. In my opinion, the whole point of a game like this is to set it up how you want instead of it being balanced giving the exact same experience for everyone.

Anyway, I absolutely agree with what you said about the negotiations being too opaque and the effects of the stats being too hidden though. You're right that the game doesn't give enough clues about what actions and stats do. For example, upgrading the club seems extremely potent, so it makes even less sense to pay more for hires in the beginning.

To this point, the randomizer I am working on for TUSC relates proficiencies and persuasion-related stats to the scale of popularity and therefore expense. More popular girls are less likely to reject you in training and more proficient in performances which directly impacts earn along side their popularity.

Thanks for the update. If popularity does impact other earnings-related stats, which I thought were randomized, then that's pretty much the solution to the pricing issue. I'm not sure if I want this built into the base game though, but I would run it against my packs when you're ready to share.

 

[redle]

I don't quite understand why you want this feature "built-in" when girlpacks are user generated and customizable, which I think is a strength rather than a weakness.

Just my own personal opinion, but as far as I'm concerned the use/benefit of girl packs is 100% the imagery (photos and videos). Whether some random third-party creator decided this person "has skills" and this other person is "unpopular or unskilled," and has thus hard-coded those values as completely intertwined with the imagery is really not of interest to me. And it is not so much that I could not open all the files and change them myself so it was not a 3rd party's decision... I don't really want static data (I would agree the imagery coming in the form of girl packs is a strength; I would disagree and say that stats being part of the girl packs is a weakness). If they were unpopular for me personally I would not have downloaded that set in the first place (or would be inclined to delete it). So for me, if they are left in the game I would be interested in seeing them. I would prefer that the packs contained no stats at all. Any stats needed to play the game were randomly assigned during the game. I don't want these 5, 10, however many specific girls to always be the ones that end up in the vip, this other group is always my bouncers, etc... I don't want the stats to pigeon-hole people (whether it be preventing them as an early hire or making them specially aimed at a specific job). The only real potential downside to completely random (and I'll clarify here since this seemed to be a sticking point for you before)...

By random I do not mean take every stat, salary, value of any kind and roll each one completely in isolation. If there are logical links such as a stat that increases earnings and a cost (i.e. salary) or any other relationship, one does not write code to roll these values separately. One is rolled randomly then the "matching" value is generated from the first value (with potentially some wiggle room).

...potential downside is if a given pack has missing categories of imagery. I'd still probably prefer completely random for myself, but a very solid argument could be made that available content for the pack should hedge the possible results for any specific character. I'm more in games for the game aspect then the porn. I like adult games, but I prefer my games to first and foremost play well.

But at this point I've tried explaining myself 3 or 4 or so different times. I imagine the point is beyond belabored here. I'd prefer variation over repetition... that about sums it up.

 

[Disgruntler]

But at this point I've tried explaining myself 3 or 4 or so different times. I imagine the point is beyond belabored here. I'd prefer variation over repetition... that about sums it up.

To really sum everything up, succinctly--you want Scramble Mode.

I'm not sure if I want this built into the base game though, but I would run it against my packs when you're ready to share.

When it is 'ready for prime time' I'll have it for you. Don't expect much in the way of presentation.

 

[Disgruntler]

Hiring a second and third barely changed gross profit at all, meaning they were at best barely paying for themselves and not increasing profits at all.

This comes down to having a place for them to work. So if you have 6 girls working, but only the stage and a single slot at the bar, you'll always have 4 girls doing nothing to increase spend or protect your opening time.

 

[redle]

This comes down to having a place for them to work. So if you have 6 girls working, but only the stage and a single slot at the bar, you'll always have 4 girls doing nothing to increase spend or protect your opening time.

Maybe I misinterpreted some of the upgrades. I thought the stage upgrade claimed it added additional work slots. Granted thinking about the actual workday the stage only ever shows one person at a time. Might need to go back and see if its me who can't read or if the description is misleading. Even then the stage seems to often have enough empty-time with just 1 that having 2 should have doubled my profits instead of resulting in no change if it was actually about the work they put in.

As for the bar, it is a potential money maker, but I decided to avoid and delay its use quite a bit. It adds micromanagement, does not add to the visuals, doesn't have enough supply purchase widgets, and makes the no-money softlock way too easy and frequent a problem.

======== update
I went back and looked: Stage 1 says it provides 8 stage slots. Maybe that means something different to someone else, but to me that means 8 people can work simultaneously on the stage alone. That would also match how other upgrades and job slots seem to work.

 

[kashmoneybang]

Maybe I misinterpreted some of the upgrades. I thought the stage upgrade claimed it added additional work slots. Granted thinking about the actual workday the stage only ever shows one person at a time. Might need to go back and see if its me who can't read or if the description is misleading. Even then the stage seems to often have enough empty-time with just 1 that having 2 should have doubled my profits instead of resulting in no change if it was actually about the work they put in.

As for the bar, it is a potential money maker, but I decided to avoid and delay its use quite a bit. It adds micromanagement, does not add to the visuals, doesn't have enough supply purchase widgets, and makes the no-money softlock way too easy and frequent a problem.

the bar is the single biggest moneymaker in the game. if you want to maximize profit, going into bar 3 as early as possible is the best route.

 

[redle]

the bar is the single biggest moneymaker in the game. if you want to maximize profit, going into bar 3 as early as possible is the best route.

I should have also added that the bar masks true profit.

I don't disagree the bar can turn a profit. The game doesn't have any time-dependent mechanic though. Either the player is making money or losing money. How fast it is made doesn't have any real effect (other than how many times the player must click open-club to reach the same dollar amount).

The fact that bar upgrades reduce cost and increase prices without having any downside to them is never going to work for play balance. But for now, take advantage while its there.

 

[everglow]

I went back and looked: Stage 1 says it provides 8 stage slots. Maybe that means something different to someone else, but to me that means 8 people can work simultaneously on the stage alone. That would also match how other upgrades and job slots seem to work.

Negative, you have only one stage – is the "stage" and not "stages". 8 slots means you can run 8 shows during night. They might be performed by a single girl, you can have 1 show for each of 8 girls or any mix of the two. The duration of the single show is also dependant on the stage upgrade.

 

[everglow]

For everyone asking the correlation between `popularity` and `salary` at the moment, this is the actual code:

salary = min(max(round(obj.popularity / 10 * 250), 200), 2500)

Regarding girl `popularity` itself: in the current version of the game won't really affect anything else except for a tiny weight in VIP/SPA requests. But, given one of the feature I postponed on 1.0 was to make club `popularity` and `reputation` dynamic and not related to upgrades, girls' `popularity` will definitely play a bigger role there, so today changing it to all < 50 impact only how much you spend to hire, tomorrow might impact reputation and popularity of your club.

Regarding completely avoiding static numbers in girlpacks and make everything completely random: it's something definitely not on my page. I have a strong opinion on this, it just make no sense to me to prevent pack creators to customise some values or even players to do the same. If everything would be random why downloading girlpacks in the first place? Could be just a 3-4 static videos for every girl, the entire game would be < 500MB and definitely boring.

Regarding loans is a good idea, I'm reading you guys, just not commenting everything since you write a lot
In next version(s) there will be surely some facilitators to prevent bankruptcy, I just need to recollect all your discussion and find the most balanced one.

For everything else: I'll come back reading everything more carefully, right now is just a ton of text/ideas/discussion to process

Cheers

 

[dooka58]

But at this point I've tried explaining myself 3 or 4 or so different times. I imagine the point is beyond belabored here. I'd prefer variation over repetition... that about sums it up.

Look, I understand your point, but you still don't understand mine. You needn't rehash explanation of why randomized stats are preferable to you. I totally get that part, and I even agree with you to a certain extent, but you're not listening to my perspective. My point is the girlpack stats, which I agree are arbitrary and unnecessary (especially since the ones I'm using were designed for VC), are already fully customizable. We can just get rid of them if we don't like them, so that's the part I think you're mischaracterizing.

You keep saying girlpacks are "hard-coded" when the data is actually just plain text (json and yaml format aren't hard to parse), and the girlpack editor tool makes it very easy to change stats in a table. I could understand if it were compiled machine code, but it's definitely not. This custom data approach is what gives us more choices: If you're like me, and you want the popularity to all be low (because currently they all seem to start from zero training), then we can edit them to fit that. Later, if the dev makes popularity scale more with earnings, then we can adjust accordingly. But if you want random stats instead, you can run a script to scramble the data. We can already set the data to do what you want, without the game also forcing everyone else down the random path every time. I mean, I probably could have manually scrambled your data a dozen times while we've been discussing this, even without a randomizer script. That's what's killing me.

Furthermore, some of the stats are already randomized; that's what's actually 'hard-coded' and unchangeable--no matter what I do, I can't seem to affect those stats. I don't mind dice rolls, but it ought to be within logical rules for the gameplay to flow and make sense. I already can't make sense of the existing randomness, which hampers strategy and progression in gameplay, and I can imagine if the distribution of random stats is not handled carefully, it could easily make the game too rough, and regardless, it'll reduce customization if it's a built-in feature rather than a custom option. The way it is now, we can configure the randomness distribution and impact factor however we like (for the stats which aren't already randomized).

In my opinion, adding and removing packs, plus customizing them is what gives us replayability, not restarting the game many times looking for the same people with different stats/prices. To be honest, I don't plan on restarting this game if I can help it. Therefore, that sort of replay value is the last thing on my mind and doesn't seem fun to me. Moreover, I'm thinking of new players who will be confronted with more objectively "bad" choices and could easily get in a 'game over' scenario, as if the early game wasn't already obtuse enough.

 

[redle]

Negative, you have only one stage – is the "stage" and not "stages". 8 slots means you can run 8 shows during night. They might be performed by a single girl, you can have 1 show for each of 8 girls or any mix of the two. The duration of the single show is also dependant on the stage upgrade.

I've been to places where more than one performance was going on a single stage. "s" or no "s" is not really a definitive proof to a reader (besides typos always are possible). Either way, I understand how it works now (would be better if the label said, "8 nightly shows" or something rather than "8 slots" which leave a lot of room for interpretation). Not sure I exactly agree with the design, but that's not really up to me Thanks for letting me know how it works.

Regarding completely avoiding static numbers in girlpacks and make everything completely random: it's something definitely not on my page. I have a strong opinion on this, it just make no sense to me to prevent pack creators to customise some values or even players to do the same. If everything would be random why downloading girlpacks in the first place? Could be just a 3-4 static videos for every girl, the entire game would be < 500MB and definitely boring.

If you don't like random stats, certainly your right and do not implement it. It's just a suggestion that I would like. There is no right or wrong.

I will say, I do not at all understand how removing custom stats (i.e. overriding them with random values) would somehow make image and video sets smaller though. The game has a predefined set of video categories. Every girl regardless of any starting stats eventually upgrades to access their full video collection and use all of their categories. Currently some girls always have specific categories unlocked as soon as they are hired rather than needing to unlock them, but the exact same videos are present whether stats change or not. The difference randomness adds is that instead of ThisOneGirl always starting with sex and needing to unlock blowjob, maybe next time she will start with blowjob and need to unlock sex, or neither start unlocked and the player needs to unlock both.

Regarding loans is a good idea, I'm reading you guys, just not commenting everything since you write a lot
In next version(s) there will be surely some facilitators to prevent bankruptcy, I just need to recollect all your discussion and find the most balanced one.

Not sure how others feel. Preventing bankruptcy or not is not really my concern. Game-over moments existing aren't inherently a bad thing. As I see it there are 2 basic problems.
1. The game does not tell the player when they hit game-over
2. Game-over happens too easily by mechanics that should not cause game-over (pressing "purchase upgrade" or pressing "buy supplies" should never result in game-over, but in the current game those are the 2 actions most likely to cause game over)

 

[Disgruntler]

For everyone asking the correlation between `popularity` and `salary` at the moment, this is the actual code:

salary = min(max(round(obj.popularity / 10 * 250), 200), 2500)

salary = 200 if (obj.popularity < 10) else (obj.popularity * 25)

might be a bit 'cleaner', seeing as the min 2500 is redundant if popularity is capped at 100. I dunno, I'm a math guy coming from Java and C# so the idea of temporarily sneaking into floats is weird. But Python's gonna Python, I'm actually not sure what would be the fastest or how CPython will optimize this.

Regarding girl `popularity` itself: in the current version of the game won't really affect anything else except for a tiny weight in VIP/SPA requests. But, given one of the feature I postponed on 1.0 was to make club `popularity` and `reputation` dynamic and not related to upgrades, girls' `popularity` will definitely play a bigger role there, so today changing it to all < 50 impact only how much you spend to hire, tomorrow might impact reputation and popularity of your club.

oooooooooh.

Regarding completely avoiding static numbers in girlpacks and make everything completely random: it's something definitely not on my page. I have a strong opinion on this, it just make no sense to me to prevent pack creators to customise some values or even players to do the same. If everything would be random why downloading girlpacks in the first place? Could be just a 3-4 static videos for every girl, the entire game would be < 500MB and definitely boring.

I can definately see this as an argument. My personal opinion on the matter is

1) If you don't want to do it, don't do it, obviously

2) Scramble Mode has turned into one of Venus's Club's best successes, and has more or less turned into the default way to play for a lot of players. But you are also correct that player/creator control and customization is massively important to the success of both games.

I'm for randomization as an option, and not mandatory, but others may not agree. Regardless of what you do, I'm going to use and run my own randomizer for my own enjoyment but no one should feel forced to do so if they don't want. I think player tools to control such matters is a great win, but I also am not convinced you need to be the one to make that happen.

You've got enough on your plate as it is.

 

[redle]

You keep saying girlpacks are "hard-coded" when the data is actually just plain text (json and yaml format aren't hard to parse), and the girlpack editor tool makes it very easy to change stats in a table.

I think there is a misunderstanding of what hard-coded means. In software development and computer coding it means that a value does not change during the lifetime of running the app. It has a predetermined value when the app starts and it never changes. It has nothing to do with how said predetermined value is stored; whether it can be changed through text editors; or who has access to the storage of the value.

Look, I understand your point, but you still don't understand mine.

I understand that you do not want random data. That's perfectly fine. I've never tried to tell you that you are wrong for wanting it that way. Each of your posts either asked a question or said something like

I don't quite understand why you want this feature "built-in"...

And so I tried to answer your questions (which means explaining my point of view). Your point of view is perfectly valid. We just don't share the same opinion on random stats.

 

[redle]

salary = 200 if (obj.popularity < 10) else (obj.popularity * 25)

might be a bit 'cleaner', seeing as the min 2500 is redundant if popularity is capped at 100. I dunno, I'm a math guy coming from Java and C# so the idea of temporarily sneaking into floats is weird. But Python's gonna Python, I'm actually not sure what would be the fastest or how CPython will optimize this.



oooooooooh.



I can definately see this as an argument. My personal opinion on the matter is

1) If you don't want to do it, don't do it, obviously

2) Scramble Mode has turned into one of Venus's Club's best successes, and has more or less turned into the default way to play for a lot of players. But you are also correct that player/creator control and customization is massively important to the success of both games.

I'm for randomization as an option, and not mandatory, but others may not agree. Regardless of what you do, I'm going to use and run my own randomizer for my own enjoyment but no one should feel forced to do so if they don't want. I think player tools to control such matters is a great win, but I also am not convinced you need to be the one to make that happen.

You've got enough on your plate as it is.

Yeah, in one of the posts I added the comment that things like randomized stats can easily be a settings option that a player can toggle (didn't originally feel it needed saying... everything is optional, just depends what a developer wants to include or not).

As for the the math... the "round" is likely redundant as well. Without changing 10 in the denominator to 10.0 that is most likely int-math and dropping the fraction already so there is no round-up ever.

 

[Disgruntler]

As for the the math... the "round" is likely redundant as well. Without changing 10 in the denominator to 10.0 that is most likely int-math and dropping the fraction already so there is no round-up ever.

No, Python will convert that to a float because it's using the / operator and not // and the result is a decimal value. But then it's multiplied by 250 which removes the decimal place, but once it's a float it stays a float. The round would be necessary to assert an integer value after the float conversion caused by the / operator.

We know that it's forcing a float there as well, because if you had--say... 15 as a value, 15 / 10 as an int would output 1, and not 1.5, which multiplied by 250 would give 250, and not the 375 the game actually has as a result.

The / operator always outputs a float in Python.

 

[redle]

No, Python will convert that to a float because it's using the / operator and not // and the result is a decimal value. But then it's multiplied by 250 which removes the decimal place, but once it's a float it stays a float. The round would be necessary to assert an integer value after the float conversion caused by the / operator.

We know that it's forcing a float there as well, because if you had--say... 15 as a value, 15 / 10 as an int would output 1, and not 1.5, which multiplied by 250 would give 250, and not the 375 the game actually has as a result.

The / operator always outputs a float in Python.
View attachment 2695840

That's version dependent I believe. "/" converting to float I believe became a thing only in Python 3

I'll also add that
9/10.0 * 250 = 225 which is both greater than 200 and less than 2500
So either your if statement replacement needs editing or other problems are at work.

Although I'm really not sure how much of the code base is python or java script. I've not used Electron at all I thought it was all javascript.

I looked it up to verify:

Division
Integer division (rounding down):

# Python 2 only:
assert 2 / 3 == 0

# Python 2 and 3:
assert 2 // 3 == 0


“True division” (float division):

# Python 3 only:
assert 3 / 2 == 1.5

 

[dooka58]

I think there is a misunderstanding of what hard-coded means. In software development and computer coding it means that a value does not change during the lifetime of running the app. It has a predetermined value when the app starts and it never changes. It has nothing to do with how said predetermined value is stored; whether it can be changed through text editors; or who has access to the storage of the value.

"Hard coding (also hard-coding or hardcoding) is the software development practice of embedding data directly into the

You must be registered to see the links

of a

You must be registered to see the links

or other executable object, as opposed to obtaining the data from external sources or generating it at

You must be registered to see the links

. Hard-coded data typically can only be modified by editing the source code and

You must be registered to see the links

the executable, although it can be changed in

You must be registered to see the links

or on disk using a

You must be registered to see the links

or

You must be registered to see the links

.

You must be registered to see the links

, on the other hand, encode arbitrary information through

You must be registered to see the links

,

You must be registered to see the links

,

You must be registered to see the links

, HTTP server responses, configuration files, preprocessor macros, external constants, databases, command-line arguments, and are determined at runtime." (

You must be registered to see the links

)

I trained in Information Systems, but I chose a different career path. You can argue that Wikipedia is a bad source or whatever, but in the context of what we're discussing, I think it's okay. The data within the girlpacks are clearly "softcoded" external configuration files. It has everything to do with how values are stored and who can access them. However, I think this terminology issue is totally besides the point.

I understand that you do not want random data. That's perfectly fine. I've never tried to tell you that you are wrong for wanting it that way.
And so I tried to answer your questions (which means explaining my point of view). Your point of view is perfectly valid. We just don't share the same opinion on random stats.

See, I don't actually think we disagree about random stats all that much. Like I said, I wouldn't mind random stats if the choices were well-informed and a bit more balanced. (I know it'll never be completely balanced)

What we really we disagree about is whether this should be built-in or customizable. The current approach allows everyone to choose fixed or random (and also allows for customized random distributions), whereas if we went with a built-in implementation, then we wouldn't have a choice and would get whatever formula the dev came up with every time.

We have two options: A or B. I'm saying "we can already choose A or B" while you keep saying "I understand you want B when I want A" when in reality, I want the choice to do both or either. Your proposal excludes my options while my approach still allows your choice, albeit you have to take an extra step. That's the part I don't think you appreciate from my perspective.

 

[redle]

dookie85 I can see your point on hard-coding. For me there's still a bit of perspective variance there especially now that so many languages are interpreted at runtime and it is often just as easy to edit values typed into code as typed into a data file. But mainly I see flatfiles as static rather than dynamic resources, especially when they are moved into the apps sphere of data storage, I consider them part of the app at that point. And, perhaps in error, I've heard things like, "That's hardcoded in settings file. Tell them they can edit it there," far too often in my coding work. But yes, I get where you are coming from.

I only brought up the terminology issue because you seemed to be saying that I think it is hard to get to the data and that's my reason for... something. I know the data is there. I can edit it if I want. I can find third-party tools that will manipulate it if I want. I can write my own similar version of the game but one that ignores the stat values in the files if I want. Great, I know I can do these things (some obviously require more work than others). You are right, hard-coded/soft-coded, that is 100% irrelevant. It was a phrase I used to indicate that the game does not vary them.

As for making random stats part of the game, I suppose that is a perspective choice as well. I dislike needing 5 and 10 different tools that I need to maintain, remember, and make use of in order play a single game. I want my game to be self-contained. That isn't to say that I won't muck about in the data or even mod the source code. If a feature is worth having, it is worth having as part of the software itself. In my mind there needs to be a rather extreme reason for tools and features to be intentionally excluded from the software and maintained separately. I would much rather write a mod that is incorporated into a game directly than write and use external tools to do the same thing.

Don't get me wrong, I like that people do create tools. I like that people are creating new ideas and potentially modding the game with or without actually modding the game. I may well use external tools from time to time. But for me, in my opinion, when a game is complete it should incorporate all the useful play features itself. Not to mention, unless I am mistaken, a tool to randomize the stats did not exist in any capacity when I requested it (I'm not sure if this is true or not. I was certainly not aware of any such tool. "Scramble" sounds like a tool that is actively being produced now, but it may or may not have had prior versions and been in existence for some time). Regardless, it was presented as a suggested idea. It remains a suggested idea (granted everglow's recent comment heavily implies it will never be a game feature). I would prefer all features I use to be part of the "official" game. That means so long as the game is supported the feature is supported rather than it potentially getting outdated. That means I don't need to track, update, and use multiple programs to play a single game. If the game has a new release that in any way involves stats I don't need to figure out how the game changed and then try to adjust stats to match or wait until some third-party does the work and updates or creates some external tool. I can just play the new release.

As for having your cake and eating it too, I mentioned it before, but the game having the ability to make the stats random does not mean the game can not also leave the stats alone. Both can co-exist within the game. That's the beauty of software. Users can be given choices. Random versus from-file can exist as a setting the same as it could exist only one way or the other.

If our whole discussion has been because of a misunderstanding of whether or not this feature need be mandatory or optional, they you are correct that I totally misunderstood.

 

[Disgruntler]

That's version dependent I believe. "/" converting to float I believe became a thing only in Python 3

I cannot speak on this, I'll take your word for it.

I'll also add that
9/10.0 * 250 = 225 which is both greater than 200 and less than 2500
So either your if statement replacement needs editing or other problems are at work.

In python the ... if ... else ... operator works like I noted.

200 if (x<10) else (x*25) first checks the if clause. When x=9 it sees true, so gives the value before the if operator. If it sees false it does the value after the else operator.

The equivalent in C/C++/C#/Java of Pythons x if y else z is

y ? x : z;

"Scramble" sounds like a tool that is actively being produced now

It's more accurate to say that this is a user tool I built for myself and is not in a state I could possibly release outside my own personal use, but I may create an adapted version that is more usable for not-mes once I get it to a state I like. For myself if I want to make adjustments to it I can just change the Java itself but for others, that simply will not do.

Given that... SOMEHOW... Java's JSON parsing capabilities are rediculously nonexistant compared to C# and I'd want to make a front end for others, if I go forward I'd want to adapt what I've been doing to Unity and add in some user-adjustability interface features.

That said, not adding that kind of functionality into the base game is something I can sympathize with. VC has a tool created for it for managing Girlpacks and it's just too good and too complete for me to want to make a version in VC itself. At the time it was just a better use of my time to debug and make more gameplay features, and I think everglow has a similar mentality.

Sometimes some good ideas aren't gonna get implemented, because manpower is better used elsewhere. Everglow knows what he wants to make, so let him cook.

 

[redle]

I cannot speak on this, I'll take your word for it.



In python the ... if ... else ... operator works like I noted.

200 if (x<10) else (x*25) first checks the if clause. When x=9 it sees true, so gives the value before the if operator. If it sees false it does the value after the else operator.

The equivalent in C/C++/C#/Java of Pythons x if y else z is

y ? x : z;

I understood the ternary operator... my point was
obj.popularity = 9
>>> salary = min(max(round(obj.popularity / 10 * 250), 200), 2500)

My point was everglow's code will yield 225, your code will yield 200
Granted it's just a matter of updating yours to x<9