The pause issue was caused by how Unity triggers it's events. The ESC menu previously loaded some dependecies by script, which would only fire once the menu got activated. At the same time, it tried to set up the Options submenu, which already required one of these dependencies, causing a race condition which would then (more often than not) cause an exception and thus abort the function before the game was paused. The fix was to set up the dependencies in the Inspector, rather than by script.

The Breached and Cracked stack cap were fixed for consistency reasons. Depending on how Effects are caused, their actual value can differ, usually 2% - 4%. A stat is changed by this value times the stack. For example, Breached erroneously capped at a stack of 1, causing a maximum Energetic Defense reduction of 4%, given the value of the Effect is also 4%. Now, it's capped at 20, which allows a maximum reduction of 80% which is quite substantial.

Making ESC reliably pause sounds small but it's the kind of fix players notice immediately, so nice to see it in 0.5.3. Was the pause issue related to the parallel map generation you described in the ledge-spawn devlog, or something separate in the menu handling? Also curious whether the Breached and Cracked stack cap mattered much for balance once they could actually reach max stacks.

Hiding among 100 NPC deer with up to nine player deer sounds like the crowd itself becomes the main mechanic, so I can see how a performance pass snowballed into reworking the deer too. Did the NPC deer behaviour have to change so player deer can genuinely blend in, or does the Hunter mostly spot players by how they react, like bolting when a TrailCam catches them? Also curious how the 40-second Wendigo night phase changed the pacing of a typical match.

Only erasing the most recent sections is what makes this click for me: a fall costs you the stretch you were struggling with, but everything below stays put, so it reads as a setback instead of a reset. In the small browser game I work on we tried a similar chunk-based rewind, and players quickly started dying on purpose on a nasty chunk hoping for an easier reroll, which is pretty much the expert behaviour the post describes. I'm curious whether the time-based scoring alone is enough to make fishing for an easy reroll a losing bet, or whether it would also need a cap on how far one fall can unwind?

Funders wanting a polished vertical slice, or a year of full-time work from the whole team, while Young Suns was still in production is the brutal bit. A 30 person studio can't build two games at once, and Dabbous says they've never had a hit to pay for it

a deathless...roguelike?

The fullscreen case is a sneaky one, since the browser can hide a panel without ever running your close handler. I like the random-click tester idea a lot; mashing buttons while toggling fullscreen and switching tabs catches stuff no normal playtest does. In my own browser game the tab losing focus was the other sneaky path, so I ended up deriving pause from what is actually visible instead of a flag I set and clear by hand. Did you also check visibilitychange, or does the fight keep running when someone switches tabs?

For the item farming problem you could seed the item roll by section index instead of by generation count. Falling would still reroll the terrain, but section 12 always hands out the same thing, so dropping down ten times just gets you the same pickup ten times and the first one is the only one that counts

Set of reason keys, and the fight only ticks when the set is empty. Each panel adds its own name on open and deletes it in every close path, so if something slips through you end up with one named leftover like "bank" in your error report instead of a bare true

Counters went bad for me in the mental model the moment open could fire twice and close once

Well, in this case by exploitation, I meant basically this quote:

Given the opportunity, players will optimize the fun out of a game.

https://www.designer-notes.com/game-developer-column-17-water-finds-a-crack/

So, if you had randomized items along the way, players might jump down repeatedly to pick up an item many times, and then the rest of the game is not challenging anymore, a.k.a. boring.

Of course, you could do things like only handing out rewards when the player reaches certain heights for the first time.
I just thought about what this spool generation might look like with a more Rogue-like roguelike, and it would certainly be tricky to make it work...

Every day the term "roguelike" strays further from the light (rogue)

In this game at least, there doesn't seem ot be any items or XP.

But I thought of this as an interesting mechanic as well when they mentioned expert period and deliberately falling to regenerate the following area. It leads to a weighing of lost time due to falling/falling back vs the chance of better alternatives.

Even for a novice period, falling, whether deliberately or accidentally, and getting a better outcome doesn't seem like a bad thing to me. They describe how that makes progression easier by chance rather than through explicit deliberate game design with easing and fallbacks.

Other games and game mechanics make use of risk vs potential reward too. I'm thinking of roguelites right now where you can pick something up or not or activate something at a cost. A gain may not be guaranteed. Or it offering a reroll of items on offer.

I don't see this much different. The form is different through level generation/spooling and a different cost, but the tension or strategy mechanism is not fundamentally different in my eyes.

I guess it comes down to what you see as "exploitation". When you see it as deliberate game design it's not really exploitation. If it's deliberately part of the influenced scoring then it's not an exploit either. Even if it's multiplayer, it can be part of game depth and game strategy.

The New Democratic Party of Canada (where this coop is in). The suggested to buy out Bioware with public money.

I wonder if they generate items/XP as part of the level generation, and if the spool generation means that those get regenerated as well when you fall. That would make it exploitable by just falling over and over (and the exploiting isn't very fun in itself).

Although, I guess, if you set it as the goal to escape as quickly as possible, then that might already naturally give players a reason to not intentionally do it, and also help struggling players out. Probably depends a lot on the details...

What is NDP?

Jump buffering is the one I'd tell every new dev to add first. It costs almost nothing and players never notice it, they just stop feeling like the game ate their button press. Same idea works outside platformers. In a tick-based game, queueing the last click for the next tick fixes a lot of "I clicked it, why didn't it work" complaints.

Played only for a bit, and as you said its your first game I comment too much in the technical aspect and lets pretend it doesn't have any bugs or jankiness for now. I don't like the game too much, maybe it was the GMTK prompt though? I don't know what was the prompt given, but what I dislike, is that it's kind of like those old arcade Dragon's Lair games. The way you win this one is: you boot it up, go through every interact-able item until you exhaust all options, run out of time, die, repeat, but now you remember the places that you already checked, and you go check other ones instead of the ones you already checked, yes the number changes every run but you know where to find it now. All the other options are just time wasters for the first few runs you do. I haven't finished the game but I'm guessing that's the gist of it, it's a memory game. (Not bad at all tho for your first game jam, the graphics look cohesive and well put together)

Well I'd like that the switch around to be more clear, its hard to tell how fast is too fast to move, maybe the red danger thing could be replaced with a sliding bar or some kind of progression, like: (1) ok (2) getting a bit tilted to the side (3) getting too close to dmg! (4) getting damaged and losing a heart. (this can be done with a slider or color you don't need text, just a better indication, also you should try and calculate if its possible for the player to catch the falling objects, from any place on the screen, it might be impossible to react (not sure just a feeling) in some situations. Id maybe make objects of different weights too, so they don't fall all at the same rate (you can color code the fruits so the player can tell easily), and give a small delay of a few milliseconds between when the object appears and then falls down so the player can prepare for multiple objects and plan out which ones to go for first.

Also i know its a demo, but there's no penalty for not catching the fruits, when i went down to 1 heart i stopped trying to catch them and let go of the mouse. Got to 233 score before getting tired of it and decided to close it. https://postimg.cc/9Dyv0w24

We need more co-ops and syndicates. Suits get money blown up their ass all the times while the workers get crumbs. Money distribution is always crap in companies that aren't worker run.

It's a pity they had to fire some people, but I'd they can survive and maybe make a good game, that'd be preferable. The NDP should focus on funding these kinds of companies instead of trying to buy bioware back from the Saudis with taxpayer money.

I was just talking about platformers today saying how crash bandicoot and somewhat old PS1 controller gave me an aversion to platformers after trying to make a jump for 30 times.

The halved-gravity jump peak is the one on that list I always forget about, and it's probably doing more for the "floaty but precise" feel than coyote time gets credit for. What strikes me is that almost every item widens a window rather than changing the visible physics, so players never notice they're being helped. Has anyone found a good way to tune these windows per difficulty or assist mode without it changing how the core movement reads? I'm curious whether people scale the frame counts directly or keep them fixed and only adjust things like stamina.

WTF is this AI slop

Linking the patch notes in the first post back is a good way to restart

Good idea, I will do that soon

On the rebuilding: A rebuilt Mech will always be stripped of items and weapon. Items are randomized drops and higher-rarity weapons are randomly dropped from enemies, that had them equipped. I will add the possibility to craft either in a future update.

A classic that crossed my path again. It has not been shared in this community yet, so I am posting it.

Great resource about platformer control forgiveness with visual references.

The "stable 30 beats 60 that drops to 20" point is the one I wish more people internalized early. Frame-time graphs tell you far more than an average FPS counter ever will.

Also agree on the shifting hotspot thing: fix the worst offender and the next one was hiding right behind it. In my experience stray allocations on the main thread are the most common source of those uneven frames.

Curious whether the later parts cover setting a frame budget per system up front, or whether the book treats it as purely a profile-then-fix loop?