Marble I Like to Flick

A First-Person Physics Party Game
2026 · Personal Prototype · Godot

Interaction Design · Game Design · Prototyping

I wanted to make a physical game interaction with something already on my desk. In Marble I Like to Flick, you flick the side of a real mouse to strike a marble, while your friends privately bet on what happens next.

The idea began during my internship at Lilith Games and grew into a personal prototype.

Play on itch.io ↗

The Input

flick_input.gifPreview

The original mouse-flick demonstration, followed by a shot captured from the Godot build.

I have always been drawn to racing wheels, flight sticks, and the unusual controls of arcade machines. In Gugugaga Penguin, I explored gesture input with Leap Motion. These devices give the body something concrete to do inside a game.

They also ask the player to buy hardware or visit an arcade. I wanted to try the same kind of directness with a device people already owned.

The mouse was sitting in front of me. I was used to holding it, clicking it, and using it to aim. I started wondering what would happen if I let go.

Place the mouse down. Flick its side. Watch the marble move.

The Prompt

Before joining Lilith Games, I also received an internship offer from Sony Shanghai's Advanced Technology Center. That role involved making interactive experiences around advanced HCI, closer to installations one might encounter at an exhibition.

I chose Lilith because I wanted to work more directly on games. Still, I kept thinking about the interaction experiments I had passed up.

This project gave me a way to return to that interest. I could explore an unfamiliar physical action while keeping the work grounded in a game people could actually play together.

I set myself a small constraint: use the equipment already on the desk, but find a different way to touch it.

From Pen Fighting to Marbles

Spinning the mouse on its pad reminded me of dou bi, a pen-fighting game I played between classes in primary school. Each player placed a pen on a desk and flicked it into an opponent's pen, trying to knock it off the edge.

I tried to turn that into a game. Mouse movement gave me a direction and a speed estimate, but a single optical sensor could not independently resolve the mouse's translation and rotation. For a long, thin pen, that rotation was too important to ignore.

Then I remembered my father teaching me to play marbles, another childhood game built around a fingertip flick.

A sphere offered a simpler starting point. I could build the game around short movements across a table without reconstructing the mouse's physical rotation. Any spin in the game could come from the chosen point of impact on the marble.

The pen-fighting prototype stopped there. The physical flick stayed.

01 / PEN FIGHTING

Flick an object into another.
Rotation changes the collision.

02 / SENSOR LIMIT

One motion sensor.
No independent rotation measurement.

03 / MARBLES

Choose direction and impact point.
Use the physical flick for strength.

Gameplay

Aim → Impact point → Flick

Read the table
Look around before committing to a shot.

Choose a direction
Line up the shot and lock the aim.

Choose the impact point
Press Space to arm the input, then physically flick the mouse.

MOUSELook, aim, and choose the impact point

SPACEArm the physical flick

FLICKTurn a short burst of mouse movement into shot strength

TOUCHPADA short, sharp swipe as an alternative input

I separated aiming from the flick. Direction and impact point are chosen beforehand, so a mouse sliding sideways at the moment of contact does not drag the shot off target.

The input system looks for a short impulse and rejects obvious sustained pushes or repeated shaking. It reads movement, though; it cannot see the player's finger or prove how the mouse was touched.

World and Tone

the_club.pngPreview

The club and title screen shown on itch.io.

As I thought about my father playing marbles, I pictured him doing it in a suit. That image gave the game its setting: a Victorian-inspired gentlemen's club, where adults take a childhood pastime far too seriously.

I wanted the room, the formal clothing, and the English announcer to treat every flick as a matter of consequence. The players are still poking marbles around a table.

The same tone carries into the economy. A gentleman may lose a marble, then some chips, then the club's patience with his debt.

Please remain respectable. The ball is already making that difficult.

Giving the Spectators Something to Lose

I wanted a party game in which the conversation around the table mattered. Taking turns to flick was a beginning, but I also wanted the people waiting for their turn to have a stake in the shot.

Gamble With Your Friends was on my mind while I worked on the prototype. Betting suited the club, especially the bluffing and exaggerated confidence that come with it.

For this game, the thing to bet on was the table itself. Would the shooter hit a rail? Would two particular marbles collide? Would anyone lose a life?

Before each shot, the non-shooters receive three private wager cards. They choose one and stake chips. The same visible arrangement of marbles can give everyone a different reason to hope for a collision.

I wanted a friend's helpful advice to become slightly harder to trust.

The actual private wager interface, captured from the current Godot build during a solo turn.

RAIL

The shooter hits a rail.

COLLISION

Two specified marbles collide.

SURVIVAL

No marble loses a life.

Examples from the wager system. Returns depend on the card and the current game state.

One Table, Private Bets

Local multiplayer

private_phone_betting.pngPreview

The PC-and-phone walkthrough published on itch.io. The computer runs the table; each phone holds a private betting slip.

Local play made sense for a turn-based game inspired by billiards. Everyone could gather around one screen and pass the mouse between turns. But showing the betting panel on that screen would expose every secret.

I moved the private part to each player's phone. On the same Wi-Fi network, players scan a QR code or enter their seat code, choose a card, and lock their wager in a browser. They do not need to install an app.

The computer keeps the physics, turns, and settlement together. The phones handle each player's private choice. Once every eligible player has locked in, the game continues.

This leaves the shared screen free for the shot and the people in the room free to bluff. Solo play uses an in-game betting panel; the published online mode also keeps wagering in the game.

Keeping the Table Uncertain

My early notes asked how far the table itself could change: ice, pinball mechanisms, even golf or a team-based football table. The prototype settled on three variations of the same flicking game.

Each marble has three lives on each table. Lives reset between tables, while chips and debt carry through the match. A bad wager can follow a player into the next round.

CLASSICReadable collisions, rails, and pockets

ICELess friction; a gentle shot travels further

PINBALLBumpers add collisions and new wager conditions

The Process

Godot prototype captures

Put the decision on the marble
The yellow marker makes the selected impact point visible on the object being struck.

Make room for the flick
With direction and impact point selected, the player can concentrate on the physical gesture.

My notes kept returning to small, practical questions: could players push the mouse instead of flicking it? Could the touchpad work too? Why choose the impact point in a separate panel when it could sit directly on the marble?

These questions shaped the input classifier, the alternative swipe input, and the on-ball selection marker.

The multiplayer notes raised another set of problems: who controls the camera, how to separate each player's information, and when the next shot is allowed to begin. Solving those details took the idea beyond a one-shot interaction test.

These images were captured from the current Godot project. The Gameplay sequence and the PC-and-phone walkthrough above come from the itch.io presentation.

My Contribution

Personal project

Interaction Design
Developed the mouse-flick premise, tested the pen-fighting direction, and adapted the interaction to marbles.

Game and Social Systems
Designed the relationship between shooting and private wagers, the table variations, and the phone-based local betting flow.

World and Tone
Built the contrast between childhood play and a formal gentlemen's club, including its betting language and deliberately serious presentation.

Prototype Development
Developed and iterated the playable Godot prototype with AI assistance across code and parts of its graphics, audio, and text.

What I Would Change

I would test the flick with a wider range of mice, mouse pads, and touchpads. Weight, friction, and sensitivity change how the same gesture feels. A movement classifier can filter some poor inputs; it cannot make every device behave alike.

I would also watch new groups play through the phone setup and betting phase. The flow is implemented, but I still need to see whether it interrupts the conversation and whether players understand what they have bet on.

What I Carried Forward

I began with pen fighting and ran into a limitation I could not solve with the mouse's sensor. Keeping that exact form would have stopped the project.

Changing to marbles let me keep the part I cared about: touching an everyday object differently and seeing that physical action enter a game.

I now try to identify that part earlier. When a prototype has to change, I want to know which experience I am trying to preserve.