Oh, there are a few time-of-day locked events, and I don’t mean just dream-based ones.
Perhaps more food for the early game would be useful.
You might find that you don’t die of hunger as much if you’re more infected. More infection means you need to have a good way to get rid of juice, but you don’t get as hungry.
Temporarily changing attributes like fatigue rate is possible but not trivial. A lot of the game balance is fairly carefully tuned, but even outside of that it’s a little challenging implementation wise to have things decay. Or maybe challenging is the wrong word. More like, labor intensive.
That’s a neat idea. It would be a pretty simple change to just have everything take four hours. I’m not sure what it would do to balance, and I’d probably leave in the legacy system of clock ticks, but it might help make things easier.
The biggest risk to changing mechanics is just that it’s not adding content. I’ve been lazy/busy and haven’t written the last two encounters.
As for save scumming, I was leaning pretty hard into the roguelike ‘lose often’ style. If the early game isn’t enjoyable then maybe I’ll have to try and add some one-time things at the start to move people along faster or do some kind of new game+.
Drinking is the only interaction, I’m sorry to say. I had some plans to add more interaction with a contaminated sample container and a juicer, but those got moved to Momo’s encounter, the juicer, and another that I’m working on. I had stubbed out one extra action for people playing as male characters, but that’s incomplete and I don’t know if I’ll get to it.
The web build is experimental and I’m not even convinced I want to keep supporting it. At the very least, it’s working on my browser and I can’t debug remote machines. If you can share your browser info I might be able to try and reproduce the issue. If you go to chrome://version and give the top few fields (Google Chrome, Revision, OS, and JavaScript) I can try to reproduce your setup to see if I can make it break.
Google Chrome 126.0.6478.127 (Official Build) (64-bit) (cohort: Stable)
Revision a435861f0ca363a64f7485619ee5939833823fce-refs/branch-heads/6478@{#1592}
OS Windows 10 Version 22H2 (Build 19045.4529)
JavaScript V8 12.6.228.21
If there’s more information you can provide, like any error messages or warnings, that would be great. It’s also worth trying in an incognito window to make sure it’s not a browser plugin that’s interfering.
Thank you for the kind words!
For the suggestions:
I might try adding sound effects later. I’m not sure how many people play games like these muted or how annoying the sounds will get, but it’s not off the table.
A few people have asked for non-bursting. I’m of two minds about how to accommodate. Since it doesn’t make a whole lot of sense for a character to be perfectly normal looking in one scene and then “oops, you’re a berry now, game over” I’d need to think of something else for immobile. Berrified is a neat idea, though.
Definitely more filled problems coming. I don’t always add them into events because it can make balancing gameplay harder, but there will be more in the future without a doubt.
Oops. :x Fixed and reuploaded.
There isn’t a timer on the buttons. I just disable them as soon as they’re fading and reenable them when they’re unfaded. I don’t particularly like it either, but it might be at the limits of what I can do without a bigger rewrite of the event system. If I spend another 40-80 hours on it, I might be able to fix it, but I feel like I should go back to adding content if it is “solved enough”.
“You know a thing when you use some soft and there’s a dialog box that blocks you from using the rest of the program? The same thing is needed here.”
Yes, but I need to figure out how to do that.
It should be happening already (except inventory, but that’s a different bug). Only one UI item can be active at a time, but when the active element changes there’s a time when the old ones aren’t active any more but still have their callbacks. It’s like if you’re using a phone and just about to push a button but something else pops up and moves the button away, but reversed.
One thing I’m trying is to disable all the other buttons on just the hud after being pressed, which won’t solve all of the issues but might alleviate the problem a little.
Shortcuts are a good idea for an accessibility function. I’ll see if I can make that happen.
“I think that it’d be more interesting if you could still do things as normal regardless of how long you’ve been awake, but got progressively greater penalties to every action according to how long it has been since you last slept.”
That’s pretty close to exactly the way it is now. You can go two or three days without sleep before dying of sleep deprivation and your skills start to get pretty severely penalized after about 24-36 hours of not sleeping.
The short answer is ‘no’. There are three renderers in Godot. You can think of them as ‘fast’, ‘normal’, and ‘high quality’. Fast is the most compatible, and in theory can even be run in a web browser, though I’ve not been able to get that to work. I’m using ‘normal’, which doesn’t support a lot of the higher quality rendering options yet. I used the HQ one for my last game and people complained about visual problems on embedded hardware.
I am planning to brighten up the night scenes a bit by adding some moonlight.
I like that solution. Good idea. The task has a pretty heavy mental fatigue right now (0.4, if my memory serves), so you’d be able to make two per day if you had the batteries. That still seems like a lot, but maybe it isn’t given the need to find batteries. I’m still worried a bit about people finding a first order optimal strategy and just optimizing the fun out of the run.
One other consideration is whether it’s worth adding the special case. I like systems based stuff where behaviors emerge naturally, and adding special checks for whether the person has made a certain number seems to interfere with that. Or I’ll forget and make some change to the intelligence checks and end up with a strange bug.
Perhaps then it’s worth looking back to your earlier point about guaranteed success on any roll. Just thinking out loud: There’s always a 10% chance of success. I don’t really want to change that. If it’s changed so (net bonus after penalties > greater than the check) -> guaranteed success, then once a person’s int bonus exceeds 2 they auto succeed on everything (until they get tired). That seems a little imbalanced. Could also do the D&D thing where it has to be ten-over, which doesn’t have an exact mapping here. I’m going to have to think about it more. If I can’t find anything better then maybe the special case is fine.
Hmm. If there are automatic successes then the lab would be pretty easy to abuse. Just max out your int and then spam making myogen and elastinup until you’re invincible. Perhaps something like Gambler’s Dice which prevent long spans of bad luck. There’s already a floor on luck (can’t be less than a 10% chance of success no matter your debuffs), so perhaps lowering the ceiling could help, too.
Got it. I think you’re right about talking more about what the stats do. It was pretty clear in my mind what they did, it’s better to be explicit sometimes. Until I actually make the changes, here’s what they do:
There are only three hidden traits, charm, intelligence, and strength.
All of these bonuses start as 1x.
I don’t think I can necessarily say “chance of succeeding str increased by…” because the bonuses from things myogen and thinkies (1) have diminishing returns as you take more and (2) because the way that success/failure is calculated isn’t linear as a function of those.
Fill vs max fill and infection, well, I do want people to be on the edges of their seats for those.