The No Means Nothing scene 10_RadeksPlace ships 5 primary Beer GameObjects alongside 24 numbered BeerCan props and a BeerDrinkingController that declares a Drunk Effect block with a Range(0,1) intensity field. Each Drink() call pulses the PPEffectsManager.Drunk channel; cumulative intensity is what pushes the run toward the 13_Wasted branch. This counter walks the same accumulation curve so you can see how close your run is to the Wasted scripted sequence before you commit.
The shipped scene file carries 5 primary Beer GameObjects, 24 numbered BeerCan props, 8 BeerCanEmpty variants that visually replace a full can once it has been consumed, and 6 Beer_ scenario points hosted on the TutorialManager class. The Boombox.BeersEmpty child links the drinking state to the cassette side quest, and the McDrinkBeer marker is the actual per-drink action point.
The BeerDrinkingController._drunkEffectValue field is annotated [Range(0,1)] in source, confirming the drunk intensity is a normalized 0-to-1 weight rather than an arbitrary float. Each Drink() call pushes this weight up by the per-drink step.
The Beer class exposes a static OnBeerDrink Action event. Because it is static, it fires once per drink regardless of which Beer instance was consumed - this is the global signal that the drunk state has incremented.
The PPEffectType enum ships a dedicated Drunk = 2 entry alongside RedWhite and NoiseTransition. The PPEffectsManager._drunk field holds the PPEffect reference, and AddTemporaryEffect pulses it with the BeerDrinkingController's _drunkEffectDuration and _drunkEffectFadeDuration values.
The controller swaps the can's MeshFilter to a random entry from _emptyMeshes after drinking, and swaps _colliderFull for _colliderEmpty. The 8 BeerCanEmpty variants in the scene are the visual evidence of cumulative drinking - each BeerCan consumed leaves an empty stand-in on the table.
The TutorialManager exposes Beer_OpenDoor_Drank and Beer_OpenDoor_NotDrank as separate methods - the exit door branches on whether the player has drunk. The two branches are not symmetrical: drinking routes through the Drank door, refusal routes through the NotDrank door.
There is no 13_Wasted.unity scene in the shipped _Scenes/_MAIN directory and no Ending_Wasted Config.asset alongside the four canonical Ending Configs. The 13_Wasted.asset ships as a standalone MonoBehaviour config - the Wasted outcome is a scripted state branch reached by hitting the drunk threshold, not a dialogue-driven ending.
The Boombox.BeersEmpty child in the scene links the drinking state to the cassette side quest. Clearing every beer feeds back into the boombox state machine, which is why a maximally-drunk run also clears the BeersEmpty condition.
Tap Log a drink each time Radek hands the player a beer in the 10_RadeksPlace scene. The counter infers the current drunk-effect weight from the per-drink step the community reports and lights up the matching tier. The Wasted band is red - hit it and one more drink is the commonly cited trigger for the Wasted scripted sequence. All thresholds here are C-level community consensus; treat your own runs as the real test.
The shipped TutorialManager class exposes ten Beer_ and DrinkBeer methods. Each one is a named entry point in the drinking sequence - from the first trigger at Beer_Start through the social-pressure beat at Beer_BeerTention_Start, the per-drink callback at Day3_AfterWork_OnDrinkBeer, and the door branch at Beer_OpenDoor_Drank versus Beer_OpenDoor_NotDrank.
Beer_StartInferredEntry point - opens the Beer sequence when the player crosses the start trigger.
Hosted on TutorialManager
Beer_OpenBeerBoxInferredFires when the player opens the BeerBox prop, revealing the available cans.
Hosted on TutorialManager
Beer_BeerTention_StartInferredOpens the social-pressure beat - Radek pushes the player to share a beer.
Hosted on TutorialManager
Beer_BeerDrinkYourselfInferredPlayer-initiated drink - the player takes a beer on their own initiative.
Hosted on TutorialManager
Beer_BeerTention_DrinkTaskCompleteInferredFires when the drink task is complete - closes the social-pressure beat.
Hosted on TutorialManager
Beer_ResolveOpenInferredResolves the open-beer state and hands control back to the corridor flow.
Hosted on TutorialManager
Beer_OpenDoor_DrankInferredExit-door branch when the player has drunk - the door-out state after drinking.
Hosted on TutorialManager
Beer_OpenDoor_NotDrankInferredExit-door branch when the player has not drunk - the door-out state after refusing.
Hosted on TutorialManager
Day3_AfterWork_DrinkBeer_StartInferredDay 3 after-work flow entry - opens the post-shift drinking scene.
Hosted on TutorialManager
Day3_AfterWork_OnDrinkBeerInferredDay 3 after-work per-drink callback - fires each time the player takes a beer during the Day 3 flow.
Hosted on TutorialManager
The BeerDrinkingController MonoBehaviour groups its serialized fields under five headers. The Drunk Effect block carries the Range(0,1) intensity weight that this counter mirrors; the SFX block carries the seven shipped sfx_beer audio clips; the Empty block explains the visual swap that leaves BeerCanEmpty props on the table.
_ringTransformPull-tab ring on the can - animated when the player opens the beer.Inferred_capTransformCap mesh that pops off during the open animation.Inferred_openRotVector3Target rotation applied to the cap during the open tween.Inferred_openDurationfloatDuration of the open animation in seconds.Inferred_drinkStartPosVector3Starting position of the can in the drink animation.Inferred_drinkStartRotVector3Starting rotation of the can in the drink animation.Inferred_drinkUpPosVector3Target position as the can lifts toward the player's mouth.Inferred_drinkUpRotVector3Target rotation as the can lifts.Inferred_startDrinkDelayfloatDelay between the open animation and the start of the drink animation.Inferred_toHeadDurationfloatDuration of the can-to-mouth tween.Inferred_gulpDurationfloatDuration of the gulp itself - the visible drinking beat.Inferred_easeDrinkEaseDOTween ease curve applied to the drink animation.Inferred_meshRefMeshFilterMeshFilter on the beer can - swapped to an empty-mesh variant after drinking.Inferred_emptyMeshesMesh[]Array of empty-can meshes - one is picked at random so each drained can looks a little different.Inferred_colliderFullColliderCollider used while the can is still full.Inferred_colliderEmptyColliderCollider swapped in once the can is empty - changes how the can interacts with the world after drinking.Inferred_openAudioClipsfx_beer_open - plays when the can is opened.Verified_openVolumefloat [Range(0,1)]Volume of the open sfx.Verified_gulpAudioClipsfx_beer_slurp - plays during the gulp beat of the drink animation.Verified_gulpVolumefloat [Range(0,1)]Volume of the gulp sfx.Verified_destroyAudioClipsfx_beer_destroy - plays when a can is destroyed (thrown or crushed).Verified_destroyVolumefloat [Range(0,1)]Volume of the destroy sfx.Verified_drunkEffectDurationfloatHow long the drunk post-processing effect holds its target weight after a drink.Verified_drunkEffectFadeDurationfloatHow long the drunk effect takes to fade back to baseline after the hold window.Verified_drunkEffectValuefloat [Range(0,1)]Normalized 0-to-1 intensity of the drunk effect - the Range(0,1) attribute in source confirms this is a clamped 0-1 weight, not an arbitrary float. This is the per-drink step that pushes the screen toward the Wasted branch.VerifiedThe shipped English dialogue table carries dozens of beer-pushing lines from Radek and the matching capitulation and refusal choices from the player. The most-cited capitulation line - "Fine. One beer. Then I'm done" - bumps Anger, Submissiveness, and RadekRelationship while costing Willpower. That is the first drink pulse this counter logs.
The exact threshold is not text-verifiable in the available sources. The BeerDrinkingController._drunkEffectValue field is annotated [Range(0,1)] in source, confirming the drunk intensity is a normalized 0-to-1 weight, and the 13_Wasted asset ships as a standalone MonoBehaviour config - but the per-drink step and the trigger threshold are not in the dump. Community consensus puts the Wasted risk band at roughly 7 or more drinks in a single RadeksPlace sitting. Treat that as a community-reported estimate, not an authoritative constant, and treat your own runs as the real test.
No. The four canonical endings - RanAway, GotCaught, Willpower, Anger - each ship a dedicated scene file and an Ending Config asset carrying a DialogueNode. Wasted does not. The 13_Wasted.asset ships as a standalone MonoBehaviour config, there is no 13_Wasted.unity scene in the shipped _Scenes/_MAIN directory, and there is no Ending_Wasted Config.asset. The outcome is a scripted state branch reached by hitting the drunk threshold inside the 10_RadeksPlace scene, not a separate scene load.
It is the normalized 0-to-1 intensity weight that the BeerDrinkingController pushes onto the PPEffectsManager.Drunk channel when Drink() is called. The Range(0,1) attribute in source confirms the value is clamped between 0 and 1. The PPEffectsManager.AddTemporaryEffect call holds the weight for _drunkEffectDuration seconds, then fades it back over _drunkEffectFadeDuration seconds. Cumulative intensity across multiple drinks is what pushes the state toward the Wasted branch.
Yes. Community consensus puts the Wasted risk band at roughly 7 or more drinks in a single sitting, so one or two beers will land you in the Tipsy tier and let you exit through Beer_OpenDoor_Drank without approaching the threshold. The capitulation line "Fine. One beer. Then I'm done" is the commonly cited safe single-drink entry point - it bumps RadekRelationship and costs Willpower without saturating the drunk channel.
Every drink you log, your running session count, and your max-drinks-in-a-session record are saved under the beer_counter localStorage key in this browser only - no server, no account, no telemetry. The counter is a planning tool for your own runs, not a leaderboard. Clearing your browser data clears the lot.
The Boombox.BeersEmpty child in the 10_RadeksPlace scene links the drinking state to the boombox state machine. Clearing every beer on the table feeds back into the BeersEmpty condition, which is why a maximally-drunk run also clears that side of the boombox state. If you are routing for the cassette achievement, the drinking sequence is one of the levers you can pull on Day 3.