Actual local development capture
01 / Bottle King
The challenge
Turn a simple physical action into a satisfying game loop, with readable landing outcomes and reliable match-state transitions.
Reading the problem / Bottle King
A throw produces a physical result and a turn result.
Bottle physics, avatar expression and turn-based play need a coherent account of what happened and what comes next.
Physics, avatars and tournament progression are in development; the portfolio should distinguish playable work from planned online behavior.
How can a tactile throw remain clear inside a turn-based multiplayer flow?
Evidence: the project account and the attributed artifacts on this page. Process drawings and interaction studies are reconstructed explanations; numerical research or business results are included only where separately supported.
02 / Bottle King
The approach
Unity simulates bottle physics while HTTPS commands and polling coordinate turn-based rooms through a Durable Object. Clients report landing outcomes; server-side coordination handles entries, timeouts and settlement.
03 / Bottle King
My contribution
- Throw input, bottle-flight tuning, upright-landing rules and feedback.
- Avatar presentation, hand grip, character reactions and first- and third-person views.
- Practice and tournament flows, matchmaking, reconnect and in-game coin progression.
- Unity clients connected to a Cloudflare backend with transactional room coordination and idempotent settlement.
The process / Bottle King
A direction.
A way to build it.
A tactile throw must resolve both the physical landing and the next allowed turn.
A schematic of sequence and overlap, not a dated project schedule.
Establish turn ownership
Make the active player and valid action clear before a throw begins.
Connect physics and match state
Distinguish flight, landing evaluation and progression to another turn.
Explore throw and response
Iterate on the in-development Unity interaction alongside avatar and feedback presentation.
Review the transition
Inspect whether the player understands the landing verdict before the match advances.
How can a tactile throw remain clear inside a turn-based multiplayer flow?
The bottle’s flight is only part of the interaction. Players also need to know who may throw, whether the landing counted and what happens to the turn afterward. Connecting those states makes a tactile mechanic understandable within a larger match flow.
Journey map / Bottle King
See the whole task in context.
Choose a step to connect the person’s intent with the interface and the design decision.
Current intent
Prepare a throw
Physics, avatars and tournament progression are in development; the portfolio should distinguish playable work from planned online behavior.
- Interface context
- Turn preparation
- Review question
- How does the interface make turn ownership unambiguous?
Representative task sequence and recovery path, not a measured emotional curve or historical research map.
Behind the experience
A playable moment needs a connected system.
For Bottle King, this map connects “Prepare a throw” to “Advance the turn”. Read across to follow the task, then select a layer to inspect the interface, design and delivery references behind it.
| Layer | Prepare a throw | Flip the bottle | Inspect the landing | Advance the turn |
|---|---|---|---|---|
| The task | Prepare a throw | Flip the bottle | Inspect the landing | Advance the turn |
| Visible interface | Turn preparation | Turn preparation | Throw interaction | Landing & turn result |
| Design checkpoint | Physics, avatars and tournament progression are in development; the portfolio should distinguish playable work from planned online behavior. | Establish the player who can act now. | Let the bottle interaction remain the focus of the throw. | Resolve the landing before moving ownership to another turn. |
| Implementation reference | Make the active player and valid action clear before a throw begins. | Distinguish flight, landing evaluation and progression to another turn. | Iterate on the in-development Unity interaction alongside avatar and feedback presentation. | Inspect whether the player understands the landing verdict before the match advances. |
| Recovery | Unsuccessful landing → communicate the result → allow the next valid turn | |||
A reconstructed delivery map: the implementation row summarizes design-process dependencies, rather than claiming to document the original backend architecture.
Resolve physics and turn state together.
Reconstructed comparison of design approaches. These are review studies, not a claim that both directions were historically tested or shipped.
What this direction changes
Resolve physics and turn state together
Connects landing feedback to the next available action.
Put turn ownership around the physics interaction.
The preparation view establishes the active player, the throw view protects the action, and the landing view resolves the result. These studies examine that structure without suggesting that every planned online or tournament feature has shipped.
01 / Turn preparation
Turn preparation
←Flip the bottle→
Flip the bottle
Establish the player who can act now.
02 / Throw interaction
Throw interaction
←Inspect the landing→
Inspect the landing
Let the bottle interaction remain the focus of the throw.
03 / Landing & turn result
Landing & turn result
←Advance the turn→
Advance the turn
Resolve the landing before moving ownership to another turn.
Try the interaction
Bottle King / Control & feedback study
Bottle King01 / 03
View 01
Turn preparation
Establish the player who can act now.
◈
Illustrative input-to-feedback relationship, not a simulation of the game’s physics.
Starting context
Prepare a throw
Make the active player and landing verdict unmistakable.
Separate throw prompts, landing feedback, player identity and turn ownership. The same hierarchy should hold across different backgrounds.
Illustrative type-role specimenBottle King
Prepare a throw.
Advance the turn.
HeadingThrow interaction
24 / 30 px · regularBodyHow can a tactile throw remain clear inside a turn-based multiplayer flow?
16 / 26 px · regularLabelAdvance the turn
12 / 18 px · regularStateUnsuccessful landing → communicate the result → allow the next valid turn
12 / 18 px · regularPortfolio-font hierarchy illustration; the source does not establish the exact client font or token scale.
Keep physical feedback and match progression aligned.
How does the interface make turn ownership unambiguous?
Turn ownership needs a clear cue before an input is accepted. An expressive avatar can reinforce identity, but should not be the only indication of whose action is valid.
What feedback explains a valid landing without distracting from the physics interaction?
Landing feedback should resolve the physical event before the interface advances the match. Otherwise a player may see a progression change without understanding why it happened.
Describe the landing and the next allowed action.
The in-development build brings physics, avatars and turn-based tournament ideas together. Specifications need to distinguish the implemented throw loop from planned network behavior and describe how each landing state changes the available action.
A proposed agent task should identify whether it changes local physics feedback or match-state logic. Review the landing verdict and turn transition together; a visually convincing throw is not sufficient evidence that the match state is correct.
Bottle King remains in development; current playable behavior and intended multiplayer progression are different parts of the project scope.
Accessibility & standards
Access belongs in the design.
For Bottle King, carry accessibility requirements from the core user journey into component states, prototypes and engineering acceptance criteria.
WCAG 2.2 AA · EN 301 549 · APCA · WAI-ARIA · Platform guidance
Keep controls and feedback understandable
Review control discovery, remapping or alternative inputs, HUD scale and redundant visual/audio cues. Explain failure and recovery without relying on color alone.
Protect readability and motion comfort
Assess menus and HUD against relevant WCAG 2.2 AA criteria; use APCA as an additional text-readability tool. Plan reduced camera motion and non-flashing feedback.
Evaluate the playable experience separately
Use native platform accessibility guidance and player testing for gameplay. A readable menu does not establish accessibility of every mechanic, input method or device.
Review scope & standards references
These are design references and review priorities, not a claim that this historical project passed a WCAG audit. Record criterion-level evidence, assistive-technology and device results, unresolved issues and retest outcomes before making a conformance statement.
APCA supplements the WCAG 2.2 contrast checks; it does not replace them. WCAG 3 remains a draft. EN 301 549 v4.1.1 is the latest published edition checked on 6 November 2026; its publication and its formal EU legal citation are separate matters. Confirm the applicable procurement or legal baseline with the client.
Outcomes & scope
What the work delivers.
- In development. This is turn-based coordination with client-reported physics, rather than a continuously synchronized or server-authoritative physics world. Regional load testing and stronger anti-cheat remain future work.
Results are described within the documented project scope. Illustrative studies are identified separately from original project artifacts.
Review & next iteration
What needs to hold up in use.
Use these questions to review Bottle King against the behavior the design is intended to support.
- 01
Can a player tell whether the bottle result advances the turn?
- 02
Can another attempt begin without uncertainty about the current state?
Project-specific acceptance questions for a future review, not reported usability-test results.
Reflection / Bottle King
What I’d carry forward.
A throw has to communicate both physical behavior and the state of the turn. Keeping those two results legible provides a useful test for the next gameplay iteration.