Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

stm8022

28
Posts
A member registered Jul 31, 2021

Recent community posts

If you're continuing old game save with the current game version, that's probably the most likely reason for it. You'd need to check if your issues persist with a new playthrough, started with 0.2.4.

The game reality matching school rumors as well as the bus rides are parts of incoming 0.3 update.

https://itch.io/post/6499080

(1 edit)

How's the leveling up of the NPCs in your party supposed to work? Asking because with Evie at l.40 she's basically a deadweight in the latter game areas (Dred Valley etc) and there doesn't seem to be a good way to fix that. I took her to the Forsaken Keep, and fought l.47-48 mobs there. In time Evie gained a single level my own character (who was l.60 at that time) gained nearly 3, which makes zero sense -- if anything, it is my character who should be getting near-zero XP for curb-stomping what's effectively greys to her, while Evie should be getting XP bonus for defeating what from her PoV are "reds", thus giving her a chance to catch up level-wise.

"We have has sex before. Simon doesn't show any interest in me sexually. I had my first time with Simon."

Sammy needs to work on her observation skills, doesn't she. Either that or it's some serious case of hysterical denial :v

You're likely already aware, but these diary header icons are currently more confusing than helpful -- literally the same icons are used twice, basically relying on the player remembering what they're supposed to actually mean. For more intuitive version, there could be single person (or mirror) for Sammy and multiple persons for "people" tab, e.g. Though, guessing they're just placeholders for now.

The update sounds lovely overall, it's gonna be really hard to wait for it.

Yup, becoming Sammy eventually is completely understandable; i was just looking for some potential extra drama with that on the "originally a boy" path :v Looking forward to seeing more of Emilie and flatmate content.

Somewhat related question though, will there be any differences in writing in how both MC origins (whether they were originally boy or the girl) handle expectations of their current sexuality? I mean, they start to fantasize pretty quickly and never appear to be conflicted about the idea of other dudes putting their cocks in him/her or serving them sexually, i.e. ideas they likely weren't too keen on, or even considering, previously as a boy. Compared to being originally a girl.

(well, unless they're bisexual to begin with, i suppose)

A few more remarks after playing some more...

Shopping with Lisa introduces 3 extra outfits, but you can only buy 1, if can even afford that, and afterwards they're gone forever. Would be nice if they're added to the outfit list in the mall after that scene, for later purchase.

While i realize this is a lot to ask for, it'd be really great for the game CGs to have variant for blonde hair MC -- it's pretty jarring to see the default hair in the scenes if you're on the bakery route and the images don't match with what your character is supposed to look like. As long as the source pictures have the character on her own layer(s) it shouldn't even take all that much work -- even without it, it took literally 5 minutes to recolor one of existing images with Color and Linear Dodge in the photoshop: (sample) With layers it shouldn't take more than minute or two per picture. Heck, if your artist(s) are too busy, i'd be willing to do it for you, just to see it done :v

Potential issue: some of the track club scenes use "trackperf" variable to determine their outcome. The problem here is, the value of the variable is largely determined by choices during the very first team practice, which doesn't make much sense long-term, and dooms the player to sub-par performance no matter what they do unless they go back literally months in-game to correct that. It'd make much more sense if the trackperf variable was (instead) at least partially determined by club attendance, which currently has zero effect/benefit -- having the variable increase each time the player attends club meeting could lead to more logical outcomes, with systematic effort providing better results.

Event errors (probably fixed by now so putting this last): 

* Violet's 2nd bakery conflict events don't fire because they're scheduled to happen earlier than consultation event controlling the flag which triggers them. Removing daycount check and using "event.happened("bakery_consultation")" fixes it and makes things more flexible

* A number of Violet's dom/sub text messages don't trigger because they require "violetdateflag" which is only set when there's a date pending. The "violetdateflag" check is unnecessary, checking state of "violetrelate" is sufficient.

(10 edits)

Perhaps it's fixed in more recent build (playing 0.37.96) but there's pretty serious bug with the karaoke storyline -- after meeting Jun & crew ("confront them" option) the game advances through subsequent storyline steps each time the option to visit the karaoke place pops up, even if the player picks options which wouldn't allow for it, i.e. choosing "leave" on the initial "go in"/"leave", "leave" on the follow up "sing. $15"/"leave" or "go to room 7" on the "knock on door"/"go to room 7" set of choices.

This can lead to some absurd situations, like the MC suddenly acting as if she's already aware of Jun's profession when they never interacted further than initial meeting, references to scenes which the player never experienced (the bathroom incident) or suddenly getting notification they've reached the end of karaoke storyline when all they did was choose not to visit the place at all a few times to save money.

Perhaps after the "confront them" scene the game should make sure to only advance the karaoke plot counter when the player picks the "knock on door" option, and then on "go in" for subsequent semi-automated visits. Or simpler yet, do it only when the relevant scene was played, as part of that scene's code.

lol that makes sense. SugarCube v2 Documentation (motoslave.net) is pretty handy for the API docs, though i'd guess it's not something you'd need at this point. In any case good luck with your game, looking forward to the shapeshifter tribe story line completion, and then whatever is next in the pipeline.

(1 edit)

"There are more outcomes to that scene than those two, though you may not be able to access them if you don't have either the correct relationship stats with Padmiri, hypnosis, or aethereal chains."

I realize that, these are what i meant by "anything else" in my reply. My point was the harsh penalty applied with the option in question makes that particular option something no player is likely to pick willingly, when they have much better alternatives. Cancelling the debuffs after the scene is done would alleviate this issue, and bring it on par with other options available to the player in that scene.

"You can prevent this from happening by disabling the "Multiple full sex continued actions" option in the settings."

Ohh, thank you. I left the settings in default state to see what the game was like with them, and overlooked that's what the option would do. That solves the problem, then.

Unrelated, but wondering -- is there any particular reason your autosave is using Save.slots instead of Save.autosave for its location? Just feels a bit weird to see the autosave slot in the saves requester empty (and getting one manual save slot less)

The thing that confused me was, these vines are applied to your character and others by Padmiri and they apparently prevent you from making any actions during that scene, and this is fine and understandable. But then after the scene ends, you're told Padmiri is going to leave you like that... yet somehow you magically gain ability to move around and perform (some) actions again. How, it's never explained or addressed. So it creates impression descriptions and effects aren't on the same page, and something bugged out.

Also, having the ability to do any real talk disabled for that day (including the social phase) doesn't make you "play extremely carefully",  but it prevents you from playing the social part of the game on that day at all.

If it's all intentional, then these feel like extremely harsh penalties for just choosing scene option, and given you don't gain anything in return it effectively renders this option pointless -- the player might fall for it during their first playthrough, and even if they don't just reload right there and then, in subsequent games they're bound to pick instead "fuck it, am out of here" or anything else that doesn't just ruin entire day worth of training for zero gain. I mean, you give the player a choice between smashing themselves in the dick, and not smashing themselves in the dick. That ain't much of a choice at all /s

On separate note (a propos of dicks), i like the positioning/actions things this game uses; sparked a few observations, tho:

* kind of surprised me oral interactions are limited to one-sided dominant/submissive arrangements, and there's no 69 position for equal opportunity oral actions

* for herm characters mutual penetration tends to be very common  in the game (like, multiple times in nearly every encounter common) but in "reality" it's pretty hard to pull off as it'd require quite specific body arrangement, sort of a reverse cowgirl and 69 crossover. Simply so the body parts can line up instead of getting in each other's way. So it might make some sense to have such mutual penetration as specific (CA) that's only enabled in such separate pose (maybe the 69 one if it was added) and limit regular mounting positions to either penetration or getting penetrated, but not both at the same time? It'd feel less jarring this way.

Another small thing to maybe consider-- it'd be nice if, while browsing a store or your wardrobe, the allure indicator on the UI displayed the allure rating you'd obtain if you combined your currently worn outfit with the currently previewed item. Or just the allure value of previewed item. Currently it shows you what seems to be a calculation of "naked with only previewed item on" (in the store) or "only what's currently shown" (in the wardrobe, i.e. if you are selecting your underwear, it ignores any possible shirts/skirts etc you have set for that particular outfit) Which isn't very helpful and to some extent bugged -- after closing the store interface the indicator only updates on location change and such.

It'd give the player a better idea what sort of allure rating they can expect from their assembled outfit and/or when they're shopping for clothes, instead of only finding that out afterwards.

For HSL you only need conversion functions for HSL->RGB and back, which are really simple and ready-made pieces of code. E.g. here algorithm - HSL to RGB color conversion - Stack Overflow

Then you just show the HSL sliders to the player and translate to RGB for your purpose under the hood.

(4 edits)

Minor glitch -- opening and closing the Journal while the wardrobe screen is open results in the room action buttons showing up on top of wardrobe screen and becoming clickable. Following this with a click on the makeup button leads to a crash.

A small QoL suggestion -- on the wardrobe screen, please mark the primary/secondary colors set for currently selected/worn item type with border of different color. I.e. if for a white bra with pink accents highlight the white in first row and pink in the second row with different border, when bras are selected. (mainly because it can be hard to remember which color is actually used as 'primary' for some of the items)

For the v0.3 color picker, consider making it HSL sliders instead of RGB -- the former allows for much more intuitive/faster color selection and tweaking.

Also, if possible, consider giving the makeup screen a different selection of colors, specialized for this task instead of just copy of clothing colors? The ones currently available are maybe ok for the eyeshadow, but with 1-2 exceptions are nigh useless for lipstick and blush, and make the character look like a clueless clown. A few more subdued colors (pinks/nudes in particular) would do nicely here.

(6 edits)

A rather inconvenient error in v0.3.10 -- Padmiri's "punishment" scene applies a set of debuffs on her targets,  LVAr, LVAr, LVMo (on sidenote, the second LVAr should be probably something like LVLg since it affects legs)

The problem is these debuffs have duration of "-1 day" (until the next day actually) and persist  after the scene is finished. *And* the targets can potentially include player's character.

Not only this heavily penalizes affected characters' stats, and makes them use most of combat/sex actions, but also makes them unable to participate in conversations, as the only action available to them is "Apologize".

Ah, i see. Guess it'll mean a longer wait for me before i can resume; that's unfortunate, but fair enough if it's what people prefer. It's almost too bad both the setup and execution so far is so entertaining and neatly done, as it's going to make the wait all that harder :v

Out of curiosity, do you have any guesstimate/plans for implementing the early side-quests the game mentions? (helping local "police" with their internal issues) Their current lack is kinda making me hold back from getting farther in the game, since they're supposed to be tackled before the first mission and i'd rather experience things in story-compliant order...

Put the mouse pointer over the save you want to get rid of, and press Delete key on your keyboard. It's universal behavior for RenPy-powered games.

That's good to know :> While at it, a related observation, if you don't mind -- it currently takes ~5 beers for your character to get the "drunk face" and up to 10 for the "fully smashed" swirls. Aside from potential cost and time needed to reach this state (without cheats) this is quite at odds with your physical size and the character herself noting she's (now) a total lightweight when it comes to drinking; as such, it might make sense to increase the effect a beer has on the drunk state -- e.g. doubling it would result in getting drunk in 2-3 beers and smashed in ~5, which feels about right?

Not sure if a bug or intended, but "get a beer" at the pub costs you nothing, while "have a beer" at home costs you 20 coins. The cost should be probably comparable, otherwise there's very little point to the latter.

Adding to #1, it'd be nice if graduated idols were moved to some sort of "hall of fame" where you could view their profiles, or something along these lines. As a bonus, this could open up a possibility to (still) interact with them in some manner.

Also, maybe an option to set a concert as a "graduation ceremony" for an idol that's about to leave soon? It could make the fan base of that particular idol more likely to attend, or smth.

(1 edit)

On this note, the spa effectivity drop makes very little sense when you have more than 5 girls, and the subsequent session would involve ones who didn't just visit it. As does the limit of five girls itself. It'd make more sense if it worked similar to "socialize" option, i.e. with individual cooldown for a given girl, and being able to send any number of them there.

Seems to have been reported here: Unique Idol Drop Rates - Idol Manager community - itch.io

I took liberty to peek in the game code, and i'd guess this issue is caused by the huge impact of your current fame level on the number of new fans you acquire:

 private float GetFameNewFansBaseCoeff()
{
    return resources.GetFameLevel() switch
    {
        0 => 2f, 
        1 => 1.5f, 
        2 => 0.5f, 
        3 => 0.3f, 
        4 => 0.25f, 
        5 => 0.25f, 
        6 => 0.15f, 
        7 => 0.1f, 
        8 => 0.05f, 
        9 => 0.03f, 
        10 => 0.01f, 
        _ => 0.1f, 
    };
}

The catch is, fame levels are very easy/fast to acquire. In my game i have fame level 10 after a year or so, mainly from doing contract work. This means my new fan gains are reduced to 1% of what they'd be otherwise, even though i have just a bit above 100k fans total and obviously plenty of room to grow in this department.

As a fix i'd suggest increasing numbers needed to acquire fame (a bump as large as 10x wouldn't be out of place, considering you can hit the max in just a year) and/or improve the fame coefficient calculation to take into account the size of your existing fan base, and don't reduce it so drastically if the players fan base is still somewhat small.

 Hope this helps?

(1 edit)

Unfortunately no, #2 isn't yet a thing; the policies allow you to set arbitrary global cap at 20, 50 or 80 points, but there's no option to stop training given idol once she hits her specific potential in given skill. Which would be useful to have, as training beyond the potential takes 10x longer.

You don't want to ask members of the bully's clique, because if anything they'll cover for one another.

The people to ask are the friends of bullied girl; her best friends preferably, if she has any.

(1 edit)

Hello,

the main idol group in my game isn't generating more than 1-2k new fans per single release, with the current fan base of ~150k people. If anything, the number of new fans goes down, not up as the time goes and fan base grows larger. For a while i believed this could be some sort of weird balancing choice, but after hearing people are getting 30-50k fans per single with this sort of fan base, and seeing how my sister group with just few points generates 5-10k fans per single with its different mechanics, am starting to believe it's more likely to be some sort of a bug?

Here's a save file, with a new single for both main and sister group lined up for a release:

https://www.mediafire.com/file/ky82rcv9b79kl0b/auto_save.json/file

At the beginning of the game i have accidently closed the tutorial window before my first single was released. No idea if it has anything to do with this behavior.

If it's not a bug, but some sort of weird result of "working as intended" game mechanics, i'd appreciate some explanation what is causing it. Just how the game is determining fan gains etc. isn't really explained anywhere that i'd see.