Two players.
One honest approach.
We got into co-op game development because we think shared play is genuinely special. Everything we do flows from that belief — from how we scope work to how we hand it off.
Back to homeOur foundation
The foundation of Twinstick is a simple observation: most co-op features in arcade games feel like a second player was bolted on after the fact. The game wasn't designed for two — it was adapted. That gap is where we work.
We started with the question: what would an arcade game look like if two players were the starting point, not a feature? That question still shapes everything.
Intentional scope
We agree on exactly what gets built before anything starts.
Playable results
Every engagement ends with something you can run and play.
Co-op as foundation, not feature
Two-player interaction is designed in from the first line of logic, not added at the end.
What we believe is possible
Cooperative arcade games occupy a particular space — they're fast, immediate, and physical in a way that other genres aren't. When two players share that space well, the experience can be genuinely memorable. We believe that kind of experience is worth building with care.
Play first
The game has to feel good before anything else. Fun isn't a side effect — it's the entire point.
Together by design
Co-op mechanics that feel like they belong — not afterthoughts, not compromises.
Honest process
Clear scope, realistic timelines, and work that lands as described. No vague promises.
Core beliefs
Multiplayer deserves its own design language
A co-op game is a fundamentally different thing from a solo game with a second controller plugged in. We treat it that way.
Scope clarity prevents most problems
Most project friction comes from unclear expectations. Spending time on scope upfront is respectful — of your time and ours.
Documentation is part of the work
Handing off a codebase without context leaves you stranded. We write things down so you can continue with or without us.
Fun is a technical problem
When a co-op loop doesn't feel good, there's usually a specific design or implementation reason. Finding it is part of our craft.
Small is often more coherent than large
A focused, playable loop that works well is more valuable than an ambitious system that breaks in three places. We keep scope tight enough that quality stays manageable.
Principles in practice
Beliefs only matter if they show up in the actual work. Here's how ours translate into how an engagement actually runs.
We start every project with a written scope document. We deliver playable builds, not just code. We flag blockers early rather than working around them quietly.
Written scope before work starts
Both parties sign off on what's being built before a line of code is written.
Builds you can actually run
Deliverables are executable. You can test with real players before deciding on next steps.
Early flags, not late surprises
If something's harder than expected, we say so early — not at delivery when it's too late to adjust.
Clean handoff documentation
Code and design notes are written with the assumption that someone else will read them later.
Your pace
We match the rhythm of your project, not the other way around.
Your goals
We start by understanding what you actually need from the engagement.
Your team continues
We hand off work that your developers can own, extend, and understand without us in the room.
The human-centered approach
We work with individual creators and small teams, and that context shapes everything. You're not a ticket in a queue — you're someone with a specific game in mind, specific constraints, and specific goals.
We ask questions before assuming. We adjust when your situation changes. We write documentation that reads like it was written for a person, not a compiler.
Innovation through intention
We don't adopt new approaches because they're fashionable. We adopt them when they make the work better for the people playing the game.
Tried foundations
Core loop design and two-player architecture on proven game engines — stable ground to build from.
Tested patterns
We use co-op patterns that have been validated through play, not just theory.
Steady improvement
We refine our approach with each project — quietly, without disruption to ongoing work.
Integrity & transparency
We don't have a long list of past clients to point to for credibility. What we have is a commitment to doing the work as described, being honest when something is harder than anticipated, and not overstating what a service includes.
Pricing is flat and public. Scope is agreed in writing. If we think a different approach would serve your game better, we'll say so — even if it means recommending less work.
Published prices — no discovery calls needed to find out what things cost.
Written scope — you know exactly what's included before any work starts.
Early communication — blockers and changes flagged before they become problems.
Community & collaboration
We're working in the indie and small-studio co-op space because we like the people who build there. Creators who care about making games that feel good to play together — that's a community we want to be part of, not just adjacent to.
You're a collaborator, not a ticket
We work with you, not around you. Your input during an engagement is useful and welcome — we ask questions because the answers improve the outcome.
We want you to grow past us
The goal isn't repeat engagements out of dependency. It's leaving you with work and knowledge that your team can build on independently.
Long-term thinking
A prototype that's clean and documented is worth more to you six months later than one that worked perfectly when we handed it off but nobody can extend. We write code and notes with the future in mind.
We also keep scope tight not to minimize work, but because coherent systems age better than sprawling ones. Focused builds give you something solid to iterate from.
Readable, extendable code
Written with future contributors in mind — commented, organized, and free of workarounds that made sense in the moment but break later.
Scoped for sustainability
Smaller, well-executed builds are a more stable base than large ambitious ones that haven't been tested end-to-end.
What this means for you
All of the above translates into a working relationship that's calm, clear, and productive. Here's what you can expect from the start.
You know what you're getting
Scope is in writing, pricing is public, and deliverables are specific. No ambiguity about what the engagement includes.
You can test it yourself
Every delivery is a runnable build. You can sit two people down with it and see how it feels — not just read a report.
You can continue without us
Documentation and code quality mean your team can take what we built and keep going — independently, at their own pace.
If this resonates, let's talk
You don't need a polished brief to get in touch. A rough description of what you're building and where you're stuck is enough to start a useful conversation.
Get in touch