u/wakaba-dev

The timer is restarting; it's the await general_timer.timeout calls that are piling up. Each call to has_eaten() pauses at that line, so when the same timer finally times out, the waiting calls all continue and emit is_starving.

Keep has_eaten() to just general_timer.start(). Connect the timer's timeout signal once in _ready(), then move the print, hunger-state change and is_starving.emit() into that timeout handler. Set one_shot if this should happen once per feeding cycle. That keeps one countdown and one timeout handler, rather than adding another waiting function each time food is eaten.

your jump direction is getting multiplied by a negative speed. mouse_pos - global_position points toward the mouse, but current_jump_velocity ranges from -250 to -1200, so multiplying them sends it the other way. Use direction * -current_jump_velocity if you're keeping those negative charge values.

The charge behavior has another issue: jump_towards_mouse() runs while jump is held, while release only writes velocity.y. Your left/right block also changes velocity.x every physics tick. Those are three places controlling the same launch velocity, so fixing the negative multiplier alone won't fix the charging behavior. I'd separate the charge/release logic from the normal horizontal movement.

A year is plenty of time if the game is small enough, and "a 2D horror RPG" can be cut down to something tiny without losing what makes it good.

The practical move is to build the smallest complete version first: one short map, one enemy or scare mechanic, one puzzle, start to credits in 20-30 minutes. That forces you to touch every part of the pipeline (art, dialog, saving, audio) on a game you can actually finish, and finishing a small thing teaches you fast what the real version will cost. Once that works you can expand it or start the bigger one with much better judgment.

Also worth agreeing with your friend early on what "done" means, so scope creep doesn't quietly double the project halfway through.

The example scene question is the underrated one. A pack that ships with a small Godot project or demo scene saves real time, because you can see the import settings, filter mode and scaling the artist had in mind instead of reverse engineering them from a bare PNG.

The recurring friction points are mostly consistency: pivot points that shift from frame to frame or pack to pack, spritesheets sliced at a cell size that doesn't match your grid, and resolutions drifting between packs so a character from one sits wrong next to tiles from another. Also licensing - a clear license file inside the zip saves everyone a headache later, and plenty of packs skip it.

Backups and version control solve different problems, and it's worth having both. A backup saves you when the drive dies or the folder gets wiped. Version control saves you from yourself: when a change turns out to be a dead end, you go back to the version from before it instead of unpicking everything by hand. Git plus a hosted repo covers a lot of that, but not everything: untracked or gitignored files and anything you haven't pushed yet simply aren't in it, so an independent copy off the machine, like a weekly zip on another drive or a cloud folder, covers what the repo misses. One habit worth building early: actually restore once. Pull the project into a fresh folder and open it, because a backup you've never tested is more of a hope than a plan. My guess is the fear fades once recovery stops being theoretical, but that's just a guess.

10 downloads a few hours in doesn't mean much either way, so don't read into it yet. Judge an itch page over weeks and by conversion, views to downloads, not raw downloads. On where to post, you're right that gamedev subs mostly reach other devs. For small free games, short clips where the hook lands in the first seconds (TikTok, Shorts, that format) tend to be the best shot, since devlogs and long videos usually only pay off once some audience exists. Genre communities with weekly feedback or screenshot threads can also work well. For posting style, leading with the funniest or weirdest gameplay moment usually lands better than 'I made a game'. And I'd worry less about page rating for now, polish starts mattering more once there's traffic to convert.

45-75 is a solid range, honestly the bigger lever now is character, not timing. If every strike is the same full flash-then-boom, players still learn the shape of it within a session. Mixing in far-off rumbles with no visible flash, or a close crack with almost no delay, keeps the brain from settling. On the violins: a consistent danger-music swell turns into a UI element fast, once players trust it they lean on it instead of staying scared. The cricket silence is the stronger tell because it's subtraction, not addition. Maybe let the music lie to the player sometimes? But yeah the silence-first instinct is the right one.

Atmosphere dies faster from rhythm than from missing effects. If the lightning and thunder run on any kind of detectable interval, players' brains file it as wallpaper within minutes and it stops registering at all. Randomize the gaps hard, and vary the flash-to-thunder delay so the storm feels closer some minutes and farther away others. Second thing worth noticing: your whole list is global systems, stuff that runs everywhere whether the player is there or not. Psychological horror usually lands through things that react to the player specifically. The ambience that thins out when they stop moving, a sound that stays just off camera, that kind of thing. Rain, fog and tree density set the stage fine, but the fear will come from what the world does around the player, not from how much of it exists overall.

The feature list is a trap. Glow, SSR, SSAO, tonemapping all sound like the fix, but scenes that look good usually get there with boring discipline instead: one strong key light, deliberate shadows, and a clear idea of what the player should be looking at. When a scene looks flat, try simplifying the lighting before adding effects, and pull up a reference shot from a game with a similar mood and study its contrast and color balance before touching sliders. The Blender color management gap others mentioned is real too, but pipeline fixes come after you know what look you are even aiming at.

The honest answer for co-op specifically: it is not a shared campaign game. The main story is basically solo, and multiplayer comes in two layers. Online mode (unlocks around level 10) drops you in a shared world where you see other players running around and can team up for quests and social hubs, and proper co-op lets you join a friend's world to help with their campaign challenges and dungeons, or have them help with yours. So as a hangout-and-do-stuff-together game it delivers, but if your group expects to play through the story side by side, that part is not really there. Since it is free, the only real cost is the 180GB of disk space, so have one person in the group install it first and report back before everyone commits.

From playing co-op with my regular group: the word tactical sets an expectation most co-op games never cash in on. I expect planning to matter, assigning roles, covering angles, calling targets before anyone moves. What usually happens is everyone sprints in and it turns into chaos within ten seconds, which is fun in its own way but it is not tactical. The games that actually deliver on the promise tend to force coordination through design instead of hoping voice chat discipline shows up: splitting information between players so nobody has the full picture, or making loud mistakes genuinely costly. If your survey is about expectations, that is the gap I would flag. The marketing says coordination, the default player behavior says mayhem, and the design has to pick a side.

Headcount isn't what sells crowded, activity does. Ninety people sharing the same idle loop reads as a set no matter the number, so give a handful of them specific jobs: two arguing over the bill at the grill, someone haggling at a stall, a group sheltering from the rain under an awning. The rain is a free win since crowds react to weather, so people huddling, hurrying, or holding something over their heads instantly makes it feel real. Then sell it with traces rather than more props: grill smoke drifting, puddles catching the lantern light, litter near the busy stalls. At 854x480 upscaled nobody reads fine detail anyway, they read motion and light, so put the effort into flickering lanterns and animated behavior over static decoration.

The thing that makes flashlight horror work is contrast, not darkness. If everything is dark, the flashlight stops being a tool and becomes the whole screen, and players go numb to it. Keep pockets of warm safe light so the dark zones read as threat instead of default. At retro fidelity players mostly read silhouettes and motion, so spend your budget on enemy shapes and animation timing rather than texture detail. And the scares live in anticipation more than visuals: a distant sound cue or a half-glimpsed shape does more than any lighting setup. Demytreus is right about sound too, footsteps behind the player are cheap and brutal.

Glad it helped! Nice side effect of per-tower word lengths: it doubles as a difficulty dial for the mode, so you can tune the pressure without touching the base game. Good luck with the demo this week.

Swapping placement decisions for execution skill is a legit challenge-mode move, but your own note is the crux: if the ceiling is raw words-per-minute, the mode stops being tower defense and becomes a typing test. The interesting version keeps the tactical layer alive under the typing, so short keywords on weak towers and longer ones on strong towers would make word choice itself the decision. Mistyping costing the shot also feels very different from slow typing costing time, and players read those two failure modes completely differently. As an optional mode it works exactly because it tests a different skill than the base game, so expect some players to love it and some to bounce off it completely, which is honestly fine for a challenge mode.

For real. Multiplayer makes it even more obvious, since the thing you're actually validating is whether it's fun with other people, and no amount of clean netcode answers that. A rough build with a couple friends on a call tells you way more than a tidy codebase ever will.

ibb & obb was made exactly for this, two players sharing one keyboard, and it's all coordination puzzles so it hits the creative thinking box. PICO PARK is another good one, tiny download, and up to 8 players can cram onto one keyboard if they squeeze, which helps a lot with 13 kids and 3 computers. Keep Talking and Nobody Explodes is the sleeper pick for your setup: one kid plays on the PC, everyone else huddles around a printed bomb manual telling them what to do, so a single computer keeps a whole group busy and it's pure communication and logic. All of these work fully offline. Overcooked also supports two on one keyboard if you want chaos instead of thinking lol

For this genre specifically, 2D isn't a compromise, it's kind of the expected look. Balatro, Slay the Spire, Into the Breach, all flat 2D and all did numbers nobody with polished 3D would complain about. Board and tactics players read the screen like a tabletop, so clarity of the pieces matters way more than dimensional depth, and a faithful 2D version of physical art has a charm that 3D ports usually lose. The digital versions of Root and Wingspan kept the original illustrations and people love them for exactly that. Your situation sounds close to that: you already have real art made for the game, so leaning into it is a feature not a limitation. The temporary lava table is more of a risk than the flat style ever will be lol

The stuff that changes the most is usually the stuff that never shows up in a clip. Under the hood my co-op project went through three netcode transport migrations and a rolled-back player rework. Trying to build on top of something you already know is wrong costs more in the end. Your point about prototyping before polishing is the same lesson from the other side, the ugly early version is what tells you whether the idea deserves the pretty visuals at all.

the "optional boost with a real downside" slot is such a good design slot. mandatory mechanics get solved, players find the optimal way to use them and the decision disappears. optional ones with a cost stay a decision forever, because every use is a small gamble on what's about to walk in. skipping it becomes skill expression too, confident players go blind less because they learned the timing. and it gives you a difficulty dial for free, the more tempting you make the 2.5x the more the game punishes greed

blur as the price of the 2.5x is a nice touch, makes the gamble visible instead of just mechanical. way better than just locking the buttons, players will feel the cost before anything even gets them

thanks, that helps. two honest pieces. the docs still don't cover what one-way collision should do from the side, even in 4.7, so I can't tell you what's supposed to happen there - the minimal repro (player scene plus one platform plus one tween, nothing else) is what settles it, and if it reproduces there it's worth searching the godot github issues. the other half is interesting though: the AnimatableBody2D docs say a moved AnimatableBody2D has its velocity estimated and should push bodies in its path, and yours isn't pushing. that mismatch is exactly what the repro would isolate - if a lone tweened AnimatableBody2D doesn't push the player, the tween path is the suspect, and if it does, something else in the scene is involved

and there's your first unfair spot, found in record time. damage with no visible cause doesn't read as difficulty, it reads as the game cheating. the rim works because it shows you what you did wrong, the plain border does the opposite. also, someone who's not good at the genre is honestly the best kind of playtester for exactly this, skilled players compensate for missing feedback and never notice it's gone

ha that was fast. spouse playtest is the oldest trick in the book for a reason. curious what the first unfair spot turns out to be

oh the soap is nasty, that's exactly the gamble. you literally pay for speed with blindness, and people will take it every time because 2.5x feels free until something is already in the room. the curtain is the sneakier one though, "feels safe" giving you faster progress trains players to hide behind it right up until they shouldn't