Creative spikes: how to explore ideas without derailing your game
A practical guide to testing new ideas in production without losing your project
There’s a moment in every single production I’ve ever been part of where someone brings up an idea that wasn’t in the plan. A new mechanic. A different approach to a level. A visual treatment nobody had considered. And the idea is good. Not “worth filing away for the sequel” good. Actually really good, right now, for this game. This should be of no surprise to any game developer. The creative process doesn’t end when production begins. Far from it. Development begets creativity.
What studios do with this varies dramatically.
Some teams shut it down reflexively - “we’re in production, we can’t be doing this” - and devs carry a low-grade resentment about the decision for the next three months. Some teams chase it without thinking too hard about the cost, and then find themselves in a different kind of trouble six weeks later. And some teams have figured out how to take the idea seriously, test it deliberately, and make a real decision about it without burning the project down.
The tool for that last approach is a creative spike.
What a spike actually is
The term comes from agile software development, where a spike is a short, time-boxed investigation you run when an unknown is too large to estimate around. You’re not building anything permanent. You’re buying information.
In game development, a creative spike is the same thing applied to a creative or technical question: a small, focused effort - typically one to two weeks, rarely more - with a defined question at the center, explicit criteria for what a useful answer looks like, and a clear agreement about what happens when time is up.
That last part is where most studios get it wrong. A spike without a defined endpoint and a clear decision framework isn’t a spike. It’s just scope creep with better branding.
Preproduction is different
Quick clarification. Preproduction is about preparation and a large part of that is to answer questions. Running experiments, testing mechanics, pressure-testing the vision - all of that is expected and appropriate before you’ve committed to a production plan. The cost of exploration is baked into the phase. You don’t need a framework for deciding whether to spike something when the whole phase is, in a sense, one large spike.
What follows is primarily about production - the period after you’ve committed to a plan, locked a scope (as much as one can “lock scope” in game development), and made promises to yourself or others about what you’re building. That’s when new ideas become genuinely complicated and when having a real process for handling them matters.
The two questions you actually have to answer
When a promising idea surfaces in production, there are two questions worth separating cleanly, because they’re easy to collapse into each other and that tends to produce bad decisions.
The first is: is this worth exploring at all?
The second is: can we afford to explore it right now?
Both questions need real answers. Studios that skip the first one waste time exploring ideas that don’t belong in the game. Studios that skip the second one explore ideas they can’t actually afford and then wonder why they’re behind.
Is this worth exploring?
The first question is partly about risk management and partly about creative instinct - and in practice, those two things aren’t always easy to separate. A new idea might be worth a spike because the existing solution has a nagging weakness nobody’s been willing to name. It might be worth one because a team member noticed something in playtesting that nobody has a good answer for. Or it might just be that someone had a genuinely better idea than what’s in the plan, and the honest thing is to admit that.
The clearest filter is this: does the idea clearly advance your vision, your pillars and the experience you’re trying to create? Not “does it sound cool” and not “would players probably like it.” Does it make this game more itself?
A few real categories of ideas that tend to warrant a spike:
A technical unknown: say the game director has a theory that a certain shader would dramatically change how a biome reads emotionally, but nobody knows if the engine can handle this particularly expensive shader at scale without tanking performance. You’re not going to resolve that by talking about it.
A design question: a new traversal mechanic has come up that seems like it might work better than what’s currently in the build, but it touches a lot of existing systems and the implications aren’t obvious. Playing with it in isolation for a week tells you things that three design documents won’t.
An art direction shift: say an artist has been sketching a cell-shaded treatment for a dream sequence. The doodles look genuinely interesting. But “looks good as a sketch” and “works in-engine” are not the same statement, and you need to know which one you’re dealing with.
A level design hypothesis: the team suspects that a different structural approach to a mid-game hub would solve a pacing problem they’ve been papering over with smaller fixes. That’s worth a short investigation before committing to a rebuild.
A narrative or tonal question: a writer proposes a different register for a key character that wasn’t in the original design doc. It’s plausible. It might be better. Running a few scenes in that voice and testing them in context costs a week and tells you something real.
The category matters less than the underlying logic: you’re running a spike when a question is real, when the answer would change what you do next, and when you can’t get that answer any other way.
Can we afford it?
This is where intuition tends to mislead people. The idea feels urgent. The team is excited. The instinct is to find a way to make it work. Which is sometimes right - but the question deserves a real answer, not a rationalization.
A useful set of questions to work through, roughly in order:
Does it fit in the schedule? Look at the project plan with the spike inserted. Not the optimistic version of the plan - the one that reflects where you actually are. If making room for a one-week spike requires shifting work that was already on the critical path, you’re not really choosing whether to run the spike. You’re choosing what to sacrifice for it.
If we spend a week on this, what specifically is not getting done instead? Name the thing. “We’ll push some tasks” is not an answer. “The combat team won’t start on the boss encounter this sprint” is an answer. That level of specificity changes the conversation.
Can an external team run this spike? This is underused as an option and worth considering seriously, particularly for art and technical work. If a technical artist has floated a new shader approach, it’s not an absolute necessity for your internal team to be the one to test it. Bring in a freelance tech artist (or a graphics engineer if you can find one) to prototype it on a separate branch. If a 2D animation style has come up that nobody on the team can actually execute - think of something like Persona 5’s all-out combat overlays, where an animated 2D layer punctuates the 3D action - you can hire an external 2D animator to produce a proof-of-concept and composite it against real footage from the build. It won’t be the same as having the work fully integrated. But it’s often enough to make a real decision. And it doesn’t cost you team velocity.
What are the contextual implications for the team? Context-switching is expensive and most people underestimate it. Pulling two engineers off a system they’re deep in to run a one-week spike doesn’t cost one week. It costs one week plus however long it takes them to get back to where they were. That cost is real and it compounds. On the flip side: if the team has been excited about this idea and not running the spike means watching it get shelved indefinitely, that has its own cost. Morale is a resource. People who feel like their ideas get a fair hearing work differently than people who feel like the plan is untouchable.
All of that goes into the calculation. None of it is a formula. You’re making a judgment call - but you should be making it with real information, not enthusiasm.
How to actually run one
Assuming you’ve decided the spike is worth it and you can afford it: structure matters, and the structure is not complicated.
Start with a hypothesis and two or three questions.
The hypothesis is the thing you believe might be true. “We think cell-shading the dream sequence will create a more emotionally distinct experience than the current approach.” The questions are what you’re specifically trying to answer. “Can we execute this at acceptable performance cost? Does it actually read as more distinct in context, or just different? How much additional work would full integration require?”
If you can’t write a clear hypothesis, the spike isn’t ready to run. The hypothesis is what keeps a week of exploration from becoming a week of wandering.
Set pass and kill criteria before you start.
Before the spike begins, agree on what a pass looks like and what a kill looks like. Not vaguely - specifically. “Pass: the prototype performs within acceptable frame budget on target hardware and reads as meaningfully distinct in a blind playtest. Kill: either condition fails.” Those criteria don’t need to be elaborate. They need to exist and they need to be agreed on before anyone starts working, not after you’ve already seen results you’re attached to.
A pass can lead to one more round of exploration, but only with a new hypothesis and new questions. “It worked, let’s keep going” is not a plan. If the first spike answered its questions and raised a new one that’s worth answering, treat it as a new spike - with its own scope, its own criteria, its own endpoint. The second round is not a continuation. It’s a new commitment.
A kill is an agreement, made by the team, that this direction is closed. Not “on hold.” Not “we’ll revisit.” Closed.
Time-box it and hold the box.
One to two weeks is the right range for most spikes at the indie scale. Frankly, two weeks starts to feel more like a mini-production phase than an investigation, and tha might be a sign you’re either exploring something too large to spike or you haven’t scoped the question tightly enough. If a week keeps getting extended because “we’re almost there,” the spike has become something else. Name that honestly and make a real decision about it.
Assign clear ownership.
Someone runs the spike. Not the whole team - a small group, usually one to four people (this is contextual, of course), with someone accountable for the outcome. That person is responsible for bringing the result to the team at the end of the time-box: here’s what we found, here’s what it means, here’s the recommendation.
After a kill
I wrote about this before. Killing an idea the team was genuinely excited about is one of the harder leadership moments in production, and it doesn’t get easier just because the process was clean.
People brought something they cared about. They spent a week on it. The result didn’t clear the bar - but that doesn’t mean the idea was bad or the person who proposed it was wrong to raise it. Those two things need to be separated clearly.
What that looks like in practice: acknowledge the work, acknowledge what was learned, and be specific about why the decision came out the way it did. “We found out X, which means Y won’t work for us at this scale” is a more useful sentence than “it didn’t pass.” The team needs to leave that conversation understanding not just what was decided but why - and trusting that the process was honest.
The bigger cultural point is this: if people experience a kill as a reprimand - if the message they take away is “don’t bring up ideas that don’t make it” - you’ll stop getting ideas. The spike process only works over time if the team believes their ideas get a real hearing. A well-handled kill is part of how you build that belief. A poorly handled one erodes it fast.
When not to use them
A few situations where a spike is probably not the right tool:
When the question is really a scope question. If the idea is genuinely good but would require significant rework of existing systems or authoring significantly more content than originally anticipated, the relevant question isn’t “does this work” - it’s “are we willing to pay the real cost of including it.” That’s a production and prioritization conversation, not a spike.
When you already know the answer. Sometimes a spike gets proposed because it feels more diplomatic than saying “we’re not doing this.” If the honest answer is that the idea doesn’t fit the vision or the schedule, say that. Running a spike you expect to kill is expensive theatre.
When the team doesn’t have capacity to run it honestly. A spike conducted by people who are already overloaded, under time pressure, and half-present will produce unreliable results. If you can’t run it properly, either find external capacity or wait until you can.
The ideas that surface mid-production aren’t a problem to be managed: they’re just game development working the way it’s supposed to, creatively and iteratively. The question is whether you have a real process for finding out which ones you should pursue, and what they’ll actually cost to include.
A spike, done well, is how you hold both things at once: genuine creative openness and genuine production discipline. You’re not choosing between protecting the plan and being receptive to better ideas. You’re creating the conditions where both can be true.
If this was useful, you might also like:
