The reason the "Go Back" menus feel awkward is because at various points, you start in your room, not the living room. So being eplicit about where it's going would avoid that dissonance.
My other commentary on default menu positions has to do with digital design ergonomics. Basically, the more clicks or mouse movement a user has to make to get to a particular page, the slower and clunkier the UI feels and can actually cause increased repetitive strain injury if the user pushes thru it. So identifying most common menu navigation paths and making those paths have the fewest clicks and/or mouse movement, the overall better the ergonomics will be. In the case of your game, as it currently stands, the most common path would likely be going from the garage to the player's room, or vice versa.
BUG: This game NEEDS to not take priority over other windows. When in fullscreen, I cannot ALT+TAB away or minimize it without going to the main menu first. Given this is a NSFW game, that is an obvious problem.
The menuing feels backwards in many ways. The "Go Back" menu taking you to the hallway and then the living room should instead be more explicit. And the default, top menu item should be the most common action you anticipate from the player. Personally, I believe that most common action should be moving the player closer to their room when in the house, or perhaps toward the garage. Either way, if I want to get to "an end" of a space, the menu should ideally keep the path toward that end in the same position so the player can spam click to get there.
Similar thoughts on both counts. With current implementation, eating is just a chore that threatens to lose your unsaved progress if you don't pay attention. In general, it's better to incentivize behavior by giving the player an upside to performing an action. Pure punishment for not doing an action only serves as padding and frustration if there aren't additional factors like action economy and balancing multiple decisions with both upside and downside to consider. At the very least, not eating shouldn't result in gameover, but instead something like loss of growth or poor job performance or something else recoverable.
BUG: Whenever Petra would comment on my size, she'd keep looping her dialogue until it was time to sleep. Not only does this waste the day, but I can't give Petra the Growth Infusion.
Cute. Interesting concept. Unfortunately, I hate playing games that reverse controls for contrived reasons. I should be able to press down (S key) to go down. And the opposite for up with the W key. I get that we're increasing her weight, but we're trying to go down.
Bug: Once a succubus was detected and a fight was about to start, the next turn button became disabled and game could no longer progress. Even starting a new game kept the next turn button disabled.
I also recommend adding the CSS style "user-select: none;" to the root of your DOM to prevent accidental text selection within the game. I lost a run due to that.
Also might want to consider "pointer-events: none;" for elements that shouldn't register input but are over the game area.
As mentioned in other comments, the start of the game needs some work. Either a count down or the game should start paused or slowed and then resume at full speed once the first jump input is triggered.
More importantly than all that tho, you need change the input events you're using to register a jump. You are currently using either "click" or "mouseUp" events, and you should be using "mouseDown" and "keyDown" events. Those "down" events will trigger the frame the input is registered, where as the "up" events trigger the frame the input is released. That's why everyone is having a hard time with the jumps. Currently the jumps only trigger when you release the left mouse button, not when you first press it like expected.
Hissing Growth changes from boosting Boobs and Thighs to Boobs and Belly. Arbok doesn't scale with Belly, so that's a downgrade in most cases. Also the effect of using the level 3 version actually boosts Boobs and Thighs 20%. So effectively no change from level 1.
After playing a bit more, I've realized part of the problem is that it's subtle when a client has the relevant physical feature. Some futa have endowments that just look like puffy mons at first glance. Or you have to scrutinize the latex to determine "Is that a bulge or not?" The boob sizes are also fairly subtle, and with only 2 or 3 clients on screen at a time, it's not trivial to quickly compare and be certain that they're actually "big".
Increased font sizes on the customer requests would also be nice.
So... am I missing something? I've got to satisfy 3 customers with my initial 5 clients, but the customers are asking for futas and big boobs and I have no way of ensuring the clients have those features. And with only 5 clients I can't just wait until I get the appropriate "stock".
Game appears to get stuck trying do too many player actions and the "Reset Blue Actions" button isn't working. I'd figure at the very least the action log on the right should indicate my player is attempting something, but it's only saying I'm getting shot at.
Also, right clicking to hit next turn should have a hold to confirm, or double or triple click to confirm. It just skipping without confirmation feels bad when you're not intending it.
Already, by the 2nd level, I'd say things are too hard. You get penalized for falling, but you get zero points if the timer runs out anyway. The fact that you have go back to the checkpoint should already be enough of a penalty with a timer in place. Additionally, it's not trivial to parse what are safe spots to jump to and what are pits. Especially the gray brick section in the latter half of the 2nd level. The timer feels quite tight even with no falls.
Window scaling is quite bad. Not only does it start very small on Windows, if I change my resolution to try to make it bigger, the UI gets culled from the viewport. And then if I exit and go back to my starting resolution, it opens the app even smaller than before and continues to cull the UI from the viewport.
Unsure if intentional, but my car's performance lowered after reducing its weight.
UX could be better by removing Yes/No prompts when attempting a race. Tutorial is needed of course, but once that's been done, the player doesn't need to be asked again. And asking if the player wants to race after they've already click the race option is redundant.
Game has potential, I look forward to future updates.
My experience was it that you had to chat with them and provide their expected answer 5+ times. If you're already in an alliance when the prompt for them to join should triggered, it will skip the prompt.
For adding commas, if you're using javascript, you can simply use:
number.toLocaleString()
and it will return the number formatted for whatever the user's language prefers, eg. comma separation for US locale, period separation for many European locales, etc. You can pass a string to the function to specify the locale if you want to be opinionated, such as 'en-US' for US locales.
If you want to do scientific notation you could do:
number.toExponential()
If you want to use your own abbreviations, you could do something like:
const num = 1234567890;
const commaNum = number.toLocaleString('en-US'); // Returns 1,234,567,890 regardless of user's locale
const splitNum = commaNum.split(','); // Splits the string into an array of strings using the commas as the split points
const displayNum = splitNum[0]; // Set the display num to the most significant digits; 1 in this case
if (splitNum.length === 1) {
return displayNum // No commas means no abbreviation necessary
}
else
if (splitNum.length === 2) {
return displayNum + "K"; // 1 comma means we're dealling with thousands
}
else
if (splitNum.length === 3) {
return displayNum + "M"; // 2 commas means we're dealling with millions
}
else
if (splitNum.length === 4) {
return displayNum + "B"; // 3 commas means we're dealling with billions; which we are in this specific case
}
else
if (splitNum.length === 5) {
// Continue the pattern until numbers get so large that scientific notation is the only thing that's reasonable any more...
}
The above code will only return 1-3 whole number digits followed by an abbreviation letter.
Fun game. Cute graphics. Frustrating upgrade system.
The upgrades can't really be engaged with until you have a few battles under your belt, so the mention of them at the beginning doesn't align with game flow. Mildly stymieing.
Upgrades increasing in power cost never feels good to the player. Upgrades should be all positive. If you're going to increase the resource cost to use an upgrade, then at the very least, leave the option to use the lower grade versions so that the more expensive version becomes optional instead of feeling like a trap. Repair lvl 3 feels particularly egregious in this regard.
The stat increases with upgrade levels is nice, but not being able to see what a level up will grant stats-wise is annoying.
Infect ability doesn't really feel worth it action economy-wise.
Having to land all the QTEs for the multi-hit attacks or take the full damage feels wrong. Partial success shouldn't be all or nothing. In that same vein, the basic Pulse would probably feel better to upgrade into a multi-hit variant instead of more damage. Infect could become more or less potent depending on successes. Same for healing. Multiple successes doesn't have to translate into a 1:1 multiplier on potency. Something like 1 success = 100%, 2 successes = 150%, 3 successes = 200%, or 50%, 75%, 100% would be fine.
Fun game. Wish there was more detail and levels of body part growth.
I highly recommend adding page zoom support as this is unplayable at 4k resolution and without zoom support, the user is forced to lower their montior's resolution which is very annoying.
