Gamibase Studio · Director in active development

Project Director

Project Director is being built for one game project at a time: talk at any altitude, shape an approved living game model, move the next playable slice, and judge the result where it matters—in the game.

Gamibase Studio
Search Bloxiti / sessions, assets, commands...?K
UE5.8

Reelhaven

UE5.8 · Sample project
Approval requiredContent lanesFlatPause
# Flat view# Now

You · 14:02'The reel feels sluggish when a big fish hits — like pulling through mud. What would night fishing take?'

Directormatched to your 1:24 playtest note; night fishing logged as an open question beside co-op scope.

7 moments today — open the day

Director · Now

The reel tune is ready to feel — your call decides it.

Tune proposal

Waiting for your review

Reel torque ramp

Shorten the spin-up so the reel bites immediately under load.

ReelTorqueRampMs 320 ms 210 ms

1:24 — “the reel feels sluggish” ▣ screenshot pinned

A/B re-play · 20 squeued behind: bigger splash when the fish escapes

? Open question · Dusk water · from your 2:12 note

Dusk water reads flat. Which way should it lean?

Stylized ripple bandsDenser sim foamPainterly, sparse specular
Add a note to this sitting...
Output

09:18:02 Cook started on this machine

09:18:41 Play: Maze

09:19:08 Wrote Binaries/Win64/Bloxiti.exe

09:19:44 Waiting on playtest review

gamibase-studio-serviceLocal project connectedReview requiredApproval requiredReady
Interactive implementation preview using sample project data. Capabilities shown are being live-proven for early access.
The Director loop

From an idea to something you can play.

One project-bound conversation carries intent into ordered work, playable evidence, and the next decision.

01

Talk at any altitude

Begin with the vision, a feature, an exact change, or a question.

02

Approve the living game model

Intent, open questions, acceptance, and revisions remain explicit.

03

Build the next playable slice

Work is organized around the smallest milestone that can be played and judged.

04

Prove, play, and tune

Every “done” returns with playable evidence; feedback becomes a grounded proposal rather than a detached ticket.

Intent and reality

What you meant and what the project proves stay separate.

The approved game model owns design intent. Verified outcomes and proof packs show what actually exists. When they disagree, Director surfaces drift rather than silently rewriting either. Project continuity—visible freshness and exact project isolation—supports that trust instead of replacing the loop.

The boundary

Approved intent

The living game model keeps design intent, open questions, and acceptance criteria explicit.

Observed reality

Verified outcomes and project state show what the build actually contains.

Playable proof

Proof packs attach evidence to the claim so “done” can be judged in the game.

Your creative call

When intent and reality disagree, Director surfaces the drift. You decide what to keep.

One project only

Records stay scoped to the opened project, with source and freshness labelled. Configured provider or storage behavior is disclosed rather than implied.

The taste loop

Play it. Say what feels wrong. Compare the change.

During native play, feedback stays attached to the exact moment, project state, and live values. After play, Director can return a grounded proposal for A/B review. You decide what feels right.

01

Play natively

Mark the moment in the running game so the note stays attached to state and values—not a detached ticket.

02

Review one grounded proposal

Return to a concrete change proposal you can compare, including A/B review when the slice supports it.

03

Accept with proof and reversal

Keep the version that feels right with playable evidence, and a path to reverse the change if needed.

Currently in development

Get on the list before Studio opens.

Studio isn’t public yet. Our team uses it today and opens access gradually.

Join Studio early access

Leave a work email for a future opening.