How to Avoid the Second Game Curse with DigiTales

If you build a successful game, does it mean your next one will be successful too?

Every indie studio dreams of making their second game bigger and better than the first. More features. Bigger team. Higher production values. DigiTales did exactly that with Between Horizons.

Their first game, Lacuna, launched at the height of COVID in 2021. Noir detective aesthetic, clear marketability, solid success. Their second game, Between Horizons, launched in 2024 into a flooded market with a sci-fi theme that didn’t scream “detective game” and a scope that ballooned beyond what their niche could support.

I sat down with Julian Colbus, founder of DigiTales, to understand what went wrong, and more importantly, what he’d do differently. 

He shared in depth production lessons and dove deep into dissecting his approach to building games one after the other. 

You can watch the full conversation in this video here or read a summary of the lessons below.

The Preproduction Trap: Why Time Compression Can Kill

Lacuna had five years of preproduction before DigiTales existed. Between Horizons had to be pitched while still shipping Lacuna.

While managing monthly milestones for Lacuna, they squeezed in concepting Between Horizons. Every design decision was rushed. Every scope choice was made under pressure.

The lesson: You have to pitch your next game while shipping your current one—or you fall into a financial hole. But this compression makes you skip critical thinking time.

How to avoid it:

1. Start concepting months before your current game ships. Not full-time, but dedicated hours weekly.
2. Timebox your concepting phase. Set a deadline: “We need a pitchable prototype by X date.” Without this, concepting bleeds into crisis mode.
3. Lock one person to future game concepting. Don’t pull them into current production fires. Protect their time ruthlessly.
4. Build financial runway into Game 1’s budget. Plan for 3-6 months of preproduction on Game 2 before publisher money arrives. If you can’t afford this, your Game 1 budget was already too tight.

Red flag: If you’re pitching Game 2 the same month Game 1 ships, you’ve already failed preproduction.

The “Better” Fallacy: When Improvements Break Your Business Model

Between Horizons added features that made sense for the genre. Better traversal systems, more varied mechanics and larger scope. All justified by design logic.

But they required 40% more budget and 50% more team size. The niche couldn’t support it.

**What happened: **“We fixed things that weren’t broken. The additions increased scope, budget, and manpower in ways we didn’t need.”

The game was better on paper. But “better” broke the unit economics.

The lesson: Not all improvements improve your business. Some just make your game more expensive to produce than your market can support.

How to avoid it:

1. Run the budget math BEFORE designing improvements. Don’t design first and budget later. Start with: “Our market can support X revenue. Publishers need 2x our dev budget to break even. Therefore our budget is X/2.”
2. For every proposed feature, ask: “Does this require more people or more time?” If yes, ask: “Will this feature grow our addressable market enough to justify the cost?” If no, cut it.
3. Differentiate between core improvements and scope expansion. Core improvements: better tutorial, clearer UI, tighter game loop. These don’t balloon budget. Scope expansion: new systems, new mechanics, new content types. These do.
4. Use this formula: Time to break even = (Dev Budget × 2) ÷ Expected Monthly Revenue. If it’s over 12 months, your scope is too big for your market.

Red flag: If your pitch deck says “bigger team,” “more features,” or “higher production values” without quantifying market expansion, you’re in danger.

The Marketability Blindspot: Quality Can’t Save Bad Positioning

Between Horizons is a detective game. But the original title, key art, and positioning didn’t communicate that. Sci-fi visuals. Abstract title. No genre signals.

They only realized this after launch when data showed: players came because they followed DigiTales, not because the game looked like detective gameplay.

They added “A Sci-Fi Detective Adventure” subtitle over a year after release. Changed the key art. Too late.

The lesson: You can’t fix bad marketability with good gameplay. Players need to know what your game is before they click.

How to avoid it:

1. Run the 5-second test in preproduction. Show your key art + title to 20 strangers. Ask: “What kind of game is this?” If fewer than 15/20 get it right, your positioning is broken.
2. Genre signals must be instant. Noir detective = trench coat, fedora, rain, neon. Sci-fi detective = ??? This is the problem. If your genre mashup doesn’t have established visual language, default to the stronger signal.
3. Your title should contain your genre or core verb. Examples that work: “Detective,” “Mystery,” “Investigation,” “Case Files.” Examples that don’t: abstract nouns, made-up words, poetic phrases.
4. Test wishlists EARLY. Put up a Steam page with minimal assets months before launch. If you’re not hitting 100+ wishlists/day organically after announcement, your positioning is weak.
5. Compare your positioning to successful comp titles. Not “inspired by” but direct competitors. Do a side-by-side screenshot test. If yours doesn’t scream the same genre within 3 seconds, fix it.

Lacuna worked because:

• Title suggested mystery (lacuna = gap/missing piece)
• Key art: detective with cigarette, trench coat, noir lighting
• Genre instantly recognizable

Between Horizons failed because:

• Title = abstract sci-fi
• Key art = space station, no detective signals
• Genre = unclear until you read description

**Red flag: **If your team describes your game as “It’s like X meets Y” and neither X nor Y are visible in your key art, you have a positioning problem.

The Scope Compression Method: How to Actually Set Achievable Scope

Everyone says “scope small” but nobody defines what that means in practice.

The lesson: “Make the smallest game that you actually wanted to make. Because if I had to make Pong in three days, I would lose interest after the first.”

How to set scope that works:

Step 1: Define Your Design Pillars (Max 3)

These are non-negotiable. For DigiTales: “No getting stuck” meant players always progress even with wrong answers.

Write these down. Be specific about what they mean technically. If you can’t code it in your head, it’s too abstract.

Step 2: Mark Features as Must-Have vs Optional FROM DAY ONE

Don’t wait until you’re behind schedule. Tag features during concepting:

• Must-have: Core loop, critical to design pillars
• Nice-to-have: Enhances experience but not required
• Experimental: Cool idea, first to cut

Step 3: Build Your Budget Reality Check

**Formula: **(Team size × Months × Cost per person) = Total budget

Then: Expected revenue of “does okay” games in your genre × 0.5 = Max budget

If these don’t match, either:

• Cut scope (fewer features, shorter game)
• Extend timeline (same scope, more time)
• Don’t make this game

Step 4: Delete Features Throughout Production

At least once a month, review:

• Are we on track?
• If no, what’s the last major feature on the milestone list?
• Cut it.

Don’t try to save everything. You won’t.

Real example from DigiTales: Between Horizons planned better traversal mechanics. Varied animations. Balancing sections. Would’ve been cool.

Halfway through production: not feasible. Cut it entirely.

Julian’s take: “You shouldn’t be emotionally attached. It only hurts until you actually cut it off, and then you’re super relieved you don’t have to do this thing anymore.”

Red flag: If you haven’t killed at least 3 features by mid-production, you haven’t scoped realistically.

The Estimation Reality: How to Plan When You’re Always Wrong

You will estimate wrong. Always.

The lesson: Stop trying to estimate perfectly. Build systems that work when you’re wrong.

How to estimate realistically:

Rule 1: Double Your Best Estimate

Whatever you think it takes = 2x that.

A bug could be severe but easy to fix. Or look minor and take a week. You won’t know until you’re done.

Rule 2: Track Time Early

Use time tracking tools for your first few features. See how long things actually take. Extrapolate from real data, not gut feeling.

Rule 3: Build Buffer Into Your Pitch

If you think the game takes 6 months, pitch 12 months. If you think it costs $100K, pitch $200K.

Publishers won’t extend budgets easily without renegotiating terms. Better to finish under budget than beg for extensions.

Rule 4: Monthly Reality Checks

At the end of every milestone, Julian asks: “If we continue at this pace, will we finish on time?”

If no, which features die? Decide now, not at the deadline.

Rule 5: Be Honest With Publishers Early

Don’t wait until you miss the deadline to say you’re behind. If you’re 2 months out and realize you need 4 months, tell them NOW.

Red flag: If your schedule has zero buffer and every feature is “critical,” you’re setting up for catastrophic delays.

The Asset Pipeline Mistake: Don’t Build Before You Test

The Problem: Between Horizons created assets for game design that wasn’t locked. When design changed, assets were wasted or needed rework.

The lesson: “Have a pipeline where the writing and game design are actually set in stone and final before other people start making assets.”

How to build the right pipeline:

Phase 1: Design First (No Assets)

• Designers and writers prototype with placeholder art
• Gray boxes, stick figures, text only
• Focus: Is this fun? Does it work? Right difficulty?

Phase 2: Test With Real People

• Playtest with strangers (not your team, not your friends who want to be nice)
• Iterate on design until it works
• Lock the design

Phase 3: Now Make Assets

• Only after design is proven and locked
• Artists create for finalized systems
• Minimal waste, minimal rework

DigiTales’ mistake: Built assets while hoping the cases would work. They did, but it was a costly gamble.

DigiTales’ fix (current game): “We only create assets we actually need. For our new game, we created one or two sprites we might not need. That’s it.”

Red flag: If your artists are building assets for systems that are still “in testing,” you’re burning money.

The Feature Prioritization Framework: What to Cut and When

The Problem: Every feature feels important. How do you actually decide what dies?

The lesson: Use a 2×2 matrix. Every feature gets scored on:

1. Does it make the game fun enough? (Gameplay priority)
2. Can you show it in a trailer? (Marketing priority)

The Matrix:

High Gameplay + High Marketing = Keep Core mechanics that are visible and sellable. Example: Detective deduction system with visual UI

High Gameplay + Low Marketing = Keep (But deprioritize polish) Required for fun but invisible in screenshots. Example: Behind-the-scenes logic systems Action: Implement functionally, don’t over-polish

Low Gameplay + High Marketing = Consider Looks good but doesn’t affect core loop much. Example: Fancy traversal animations Action: Only if budget allows

Low Gameplay + Low Marketing = Cut First Neither fun nor sellable. Example: Complex inventory system in a narrative game Action: Delete immediately

When to cut:

• End of every milestone: “What’s the last major feature on the list?”
• When you’re behind schedule: “What’s least essential?”
• When testing reveals issues: “What can we simplify?”

Julian’s framing: “We can keep this feature and crunch, go over budget, and risk bankruptcy. Or we cut it and make a smaller game that’s still great.”

When you frame it like that, teams understand.

Red flag: If you can’t rank your features by priority right now, you don’t have a real plan.

The “Is the Fog Funny?” Principle: What Actually Matters

**The Problem: **Every department thinks their domain is what makes the game good.

• Artists want perfect visuals
• Designers want perfect systems
• Programmers want perfect code

**The lesson: **Monty Python anecdote: During a reshoot, someone insisted the fog didn’t look right. An actor snapped: “But is the fog funny?”

They weren’t making a fog movie. They were making a comedy. It had to be funny.

Applied to games: “With games, it has to be fun. It has to work. However you achieve that is the main goal. If the art isn’t perfect, if the sound design isn’t perfect—it’s all secondary.”

What players care about:

1. Is it fun?
2. Does it work?
3. Can I progress?

What players don’t care about:

• Clean code architecture
• Perfect documentation
• That one pixel that’s slightly off
• The fog

Real examples:

• Fallout trains are NPC hats walking under tracks. Nobody knew. Nobody cared.
• Roblox games look terrible and lag constantly. Kids love them anyway.
• Lethal Company is janky and unpolished. Huge hit because the core is fun.

How to apply this:

1. As a producer, your job is to say “good enough” when departments want to over-polish. Artists will want to redo sprites. Programmers will want to refactor systems. Say no.
2. Test often with real players. If they don’t complain about something, it’s good enough. Don’t fix what isn’t broken.
3. Everything not player-facing can be duct tape and prayer. If players don’t see it, it doesn’t matter. Hack it together and move on.
4. Game design trumps everything else. The ugliest games with good design have massive fanbases. Visual polish without good gameplay = pretty failure.

Red flag: If your team is spending time perfecting things that aren’t player-facing, you’ve lost sight of what matters.

The Real Curse Isn’t Bad Luck

The second game curse isn’t about luck. It’s about scaling wrong.

You had constraints on Game 1: time, money, team size. Those constraints forced focus. They made you cut aggressively. They made you prioritize ruthlessly.

Game 2? You have more resources. That sounds good. But more resources = more ways to lose focus.

You add features because you can. You expand scope because you have the team. You chase “better” without asking if better serves your business.

DigiTales learned this the expensive way:

• Between Horizons was higher quality than Lacuna
• It had better mechanics, bigger scope, more production value
• It still struggled because none of that fixed the business model

The lesson every second-time developer needs: More isn’t better. Focused is better. Marketable is better. Achievable is better.

As Julian put it: “We could’ve made changes that made sense but wouldn’t have required us to increase team size and money. We could’ve focused on the core of detective gameplay. That would’ve been the smart move.”

Your second game doesn’t need to be bigger. It needs to be smarter.

---

Woww you read all the way through! 😻👏

If you want more tactical production breakdowns like this, check out our YouTube channel and join our Discord where game devs share real lessons, not highlight reels.

And if you need project management that actually helps you cut scope and ship on time, check out Codecks, built by game devs who’ve been in the trenches.