Gaming

Dave the Diver: a developer-side look at the design and tech

Dave the Diver as a GameDev case study

Dave the Diver sits in a small group of indie releases that earn close reading from working developers, because the design is unusually legible. A side-scrolling underwater exploration loop and a sushi restaurant management loop alternate inside a single day-night cycle, and around those two halves sits a wider ecosystem of farming, creature capture, weapon upgrades, and a slow narrative about a sea people called the Sea People. The interesting questions for a developer are not about whether the game is fun, which sales and reception have already settled, but about how MINTROCKET held a hybrid together for dozens of hours without either loop collapsing into filler.

This page is written for game developers, technical designers, and producers who want to study the structure and craft behind Dave the Diver rather than read a player walkthrough. It looks at the hybrid design, the way the two loops are stitched into one session, the technical signals visible in the shipped build, the production context around the studio, and the takeaways a small team can borrow or deliberately avoid. The focus keyword is used where it actually describes the subject, not as decoration.

What follows is a working developer reading of the game, not a review. Numbers, verbs, and system names are taken from what the released build shows, with the usual caveat that a shipping title hides more than it reveals, and that any technical reading is provisional until a studio confirms or denies it.

Two loops, one session: the core structure

The single most discussed design idea in Dave the Diver is the alternation between the dive and the restaurant. Each in-game day is split: a daytime dive where Dave explores the Blue Hole in real time, and an evening shift at Bancho Sushi where the player serves dishes and earns the money that funds the next day. The loops share an economy, an inventory, and a narrative clock, and they use very different verbs, which is what makes the alternation feel meaningful instead of decorative.

From a design perspective, this is a “two verbs, one session” pattern that predates the game, but Dave the Diver executes it with a few specific choices worth naming.

One shared inventory: fish, ingredients, and weapons flow between loops without a hard gate, so the player’s choices underwater shape the menu at the restaurant.
A hard time budget per day: oxygen, light, and the closing bell create real opportunity cost, which keeps the dive loop from sprawling into a sandbox.
A visible economic readout: cash on hand, restaurant income, and upgrade costs are always legible, so the management loop stays readable for players who dislike spreadsheets.
Gentle failure: a depleted oxygen meter returns Dave to the surface with most of his catch, which keeps the alternation from becoming punishing and protects the day-to-day rhythm.

The point of the structure is that each loop owns a tone. The dive is exploration, risk, and resource acquisition. The restaurant is service, pacing, and reinvestment. Neither loop tries to do the other loop’s job. That separation is a key reason the alternation does not read as busywork, and why each half of the session asks for a different kind of attention.

For a developer, the most useful frame is to think of the day as a single play unit. The two loops are not stitched together by a transition screen so much as by the things that physically carry over: the fish in the cooler, the cash in the register, the suit sitting on the rack. Once that mental model is set, most of the other design decisions in the game fall out of it, including the pacing of updates and the way story content is dropped into the day.

What the hybrid asks of the player

Most genre hybrids start to fail when one loop becomes a tax on the other. In Dave the Diver, the design is careful enough that the dive produces the raw material that gives the restaurant loop its meaning, and the restaurant loop gives the dive a reason to keep happening. A player who only cares about the underwater half can mostly skip the management, while a player who only cares about running the restaurant still has to go down to refill the pantry.

That balance rests on a few small decisions that are easy to miss but hard to replicate.

Menu recipes are partially deterministic: the restaurant can serve a set of “always available” dishes, so the kitchen never fully starves on a bad dive day.
High-value catches carry diminishing returns on raw price, which pushes the player toward cooking and pairing instead of vending everything.
Weapon and suit upgrades are gated by both currency and rare materials, so the dive and the restaurant have to advance together to reach the next tier.
Vendor restocks and certain event triggers are tied to the day clock, which means the player’s time at the restaurant is not pure downtime: it is when the next opportunity becomes available.

From a developer point of view, the takeaway is that a hybrid loop only works when both halves impose constraints on each other. If either half can be safely ignored, the design collapses into two separate games stapled together. The constraint is also what keeps the game’s pacing honest: there is no shortcut that lets the player skip the dive, and no shortcut that lets the player skip the service shift, which is the difference between a hybrid and a collection of modes.

Why the Blue Hole feels alive: world and encounter design

The dive loop is not a single map. The Blue Hole is a layered space with multiple depth bands, each with its own fauna, hazards, and visual identity. New content unlocks as Dave’s gear improves, and certain creatures only spawn at specific depths or under specific conditions. The result is a steady “there is always something to find” feeling without the scale of an open world.

Several mechanisms support that feeling without breaking the side-scrolling scale.

Vertical depth bands replace a single long map, so the player can return to a familiar zone and see new behaviour as conditions change.
Time of day and weather shift the encounter table, so a morning and an evening run through the same stretch feel different.
Catch logs and marine encyclopedias fill in a forgiving curve, which encourages the player to revisit zones they thought they had cleared.
Mini-boss encounters and story events gate progression without requiring a hard fail, so the loop stays inviting.

For a technical designer, the relevant question is how much of that variety is authored versus simulated. A world that feels alive for thirty hours is not necessarily a procedural world; in many cases it is a hand-authored set of encounter tables that is rich enough to disguise the seams. The Blue Hole leans toward the second model, which is a useful counterpoint to the assumption that depth always requires procedural systems.

A practical signal of the authored approach is how predictable the experience is across runs. A purely procedural dive would produce more variance between sessions, including runs where the player comes back with almost nothing. The Blue Hole does not feel that random, and the encounter pacing stays inside a narrow band even when the player experiments. For a small team, that predictability is a feature: it is easier to write quest scripting, to plan content drops, and to write update notes when the team knows roughly what the player will see on a given day.

Combat, capture, and the moment-to-moment verbs

The verb set in the dive is intentionally narrow. For additional context, Dave can swim, aim a harpoon or another weapon, fire, dodge, and interact. There is no deep combo system, no stamina bar in the action-RPG sense, and no skill tree on the combat side. Combat and capture share a single aim-and-fire input, which keeps the moment-to-moment play from splitting into two control schemes.

That small verb set is what allows the rest of the game to exist. A wider combat system would compete with the management loop for the player’s attention. A capture-only system would have made the dive feel passive. The compromise, with combat and capture on the same input and weapon and ammo choice doing the differentiation, is one of the cleanest choices in the project.

Weapon progression is also kept legible. New weapons are visibly different in spread, range, and damage profile, but they do not introduce new control surfaces. That keeps the on-ramp gentle and the long-term mastery curve real without ever turning the game into a fighting game.

There is also a quiet reason that the verb set stays narrow: it keeps the game’s tutorial surface small. A player who learns to swim, aim, fire, and dodge has learned most of what the underwater half will ever ask. New content teaches by changing the world, not by piling on new inputs. For a developer, that is a strong template if the rest of the project can carry the variety on its own.

Tech and engine signals from the released build

MINTROCKET has not published a detailed postmortem of the rendering or simulation stack behind Dave the Diver, so any technical reading has to be drawn from what is observable in the shipped versions on PC, Nintendo Switch, and other platforms. Even with that limitation, several signals are clear.

On the rendering side, the game uses a 2.5D approach that combines side-scrolling 3D geometry with billboarded and animated 2D sprites, which is why the underwater scenes read as painterly without becoming flat. The lighting model is generous: surface shafts, caustic patterns, and a darker palette in deeper zones carry a lot of the mood work. The game also ships across a wide range of hardware targets, including lower-spec handhelds, which points to an asset and shader budget that is conservative on purpose.

Layer	Observable behaviour	Likely implication for a developer
Rendering	2.5D mix of 3D backgrounds and 2D characters	Permits a consistent art style across hardware tiers without a single hand-painted pipeline
Lighting	Volumetric surface light, depth-based palette shifts	Cheap way to signal depth and time of day without per-frame dynamic global illumination
Encounter system	Depth- and time-gated spawns, no procedural infinite map	Authored encounter tables scale better than procedural ones for content teams of this size
Combat verbs	Single aim-and-fire input drives both combat and capture	Reduces cognitive surface area and protects the alternation rhythm
Save and loop	Short, repeatable day-night cycles with a clear daily handoff	Natural unit of save, telemetry, and balance work, which helps a small team ship and patch
Audio mix	Music and ambience shift per loop and depth band	Adaptive music can ride on the day clock without a complex per-state system
UI legibility	Cash, oxygen, time, and catch log always visible	Persistent UI doubles as economy documentation for the player

On the simulation side, the day-night cycle is the dominant system. Oxygen, restaurant hours, creature spawns, story beats, and even some vendor restocks are anchored to it. Anchoring so much to a single clock is a strong production decision, because it gives the team one shared frame of reference for testing, balance, and content drops. If something feels off in the economy, the team can bisect the day to find the responsible system without a complex debugging toolchain.

On multiplayer, it is worth being precise: Dave the Diver is a single-player game, which simplifies a lot of the technical design. There is no networking authority model to maintain, no rollback layer, and no cloud save synchronisation beyond what the storefront provides. That choice is itself a development decision with real consequences, and it is one of the reasons a small team could ship a content-rich single-player release on a modest budget. It also keeps the QA surface predictable, because the only state to verify is local state.

For developers, the practical lesson is that engine and tech choices in this game look like a chain of conservative decisions that add up. None of them is novel on its own, but the combination is what allowed a small team to ship on PC, then on Switch, then on additional platforms, without a re-architecture between ports.

Production context: small team, hybrid scope

Dave the Diver is developed by MINTROCKET, a studio within the NEXON family. The team has been described in interviews and store materials as a relatively small core group, supplemented by specialists, with a long iteration period before release. The game launched first on PC in 2023 and has since appeared on additional platforms, including Nintendo Switch, where the title has been specifically noted for how well it adapts to handheld play.

For developers, the production context matters because the game’s scope is wider than its team size suggests, and the design is built around what a small team can maintain.

Most content is gated by depth and time rather than by branching narrative, which keeps writing and quest scripting contained.
New weapons and suits are added as discrete items, not as full skill trees, which reduces the QA surface area per update.
The management loop is numeric and rule-based, not an agent simulation, which makes balance changes easier to ship without breaking save data.
Post-launch updates have been able to add content without restructuring the core loops, which is a sign that the underlying data model is forgiving.

A useful contrast is to compare this with hybrid games that tried to simulate both halves at full fidelity and ended up with a team twice the size and a roadmap twice as long. The takeaway is that scope discipline, not engine power, is the largest factor in shipping a hybrid of this complexity on a small-team budget.

There is also a less visible production signal in the title: the studio chose to ship a single, coherent product rather than a service with battle passes, seasons, and a live calendar. That decision changes what the team had to build. There is no matchmaking service, no ranked mode, no seasonal reward track, and no event scheduler. The team can spend its writing, art, and engineering hours on content that lives inside the existing loops, which is a much smaller surface area to maintain than a service layer would be.

What the port to Nintendo Switch actually proves

Dave the Diver on Nintendo Switch is a useful test case for handheld and lower-spec targets. The Switch version runs the same content as the PC release, which is not trivial given the visual density of the underwater scenes. From a development perspective, the port is evidence of a few things.

Asset budgets were set with a lower-spec target in mind, even on PC, so the same content can be re-targeted without a heavy downgrade pass.
The 2.5D rendering approach scales more cleanly than a full 3D character pipeline would, because most of the cost is in background geometry and lighting rather than skinned character shaders.
The game design itself is friendly to handheld play: short sessions, clear save points, and a save-anywhere model are all native to the design, not bolted on at porting time.
Performance work could focus on a small set of expensive scenes rather than on a full asset rebuild, which is what most cross-platform ports struggle with.

For a team thinking about Switch or handheld PC targets, the lesson is that the constraint has to be visible in the very first design decisions, not tacked on during the port. Dave the Diver looks like a game that was always going to ship on a handheld, even though the original platform was PC.

It is also worth being honest about the limits of the Switch reading. The For additional context, portable version does trade off some of the dense particle work in the deeper zones, and certain lighting effects are simplified on the smaller screen. Those cuts are not failures, they are the price of a cross-platform release on a small-team budget, and the fact that they were small enough to ship without a redesign is the actual story.

Economy and balance: the silent workload

Most of the design discussion around Dave the Diver focuses on the alternation between loops, but the economy underneath is doing a lot of quiet work. Catch values, recipe payouts, upgrade costs, vendor restocks, and oxygen budgets all have to be tuned against each other or the rhythm breaks. A dive that pays too well makes the restaurant loop irrelevant; a dive that pays too little makes the loop feel like grinding.

Balance lever	What it controls	Risk if mis-set
Catch base price	Direct income from the dive	Skips the cooking and pairing layer, collapses restaurant relevance
Recipe multiplier	Reward for cooking and pairing well	If too high, the dive becomes pure ingredient farming
Upgrade tier cost	Length of the progression curve	Too cheap compresses content; too expensive turns the game into a grind
Oxygen capacity	Time available per dive	Too short starves the restaurant, too long removes the time-budget pressure that defines the loop
Weapon damage	Combat pacing and risk	Too high trivialises creature variety; too low pushes players to avoid encounters
Vendor restock	Availability of new gear per day	Too fast skips the loop, too slow stalls the progression curve

The interesting choice is that the economy is mostly visible to the player. Prices, multipliers, and upgrade costs are shown, which lets the player reason about the system rather than guess at it. That legibility is a form of respect for the player’s time, and it is also a smart QA decision, because players who understand the numbers can give clearer bug reports when something feels off.

For developers, the balance table is a reminder that the economy is the most expensive silent system in the project. Every tweak to a multiplier is a small change in code, but it can shift the entire pacing of the game. MINTROCKET has kept the levers narrow, which is what makes that workload manageable. A hybrid with more verbs, more upgrade paths, and more vendors would need either more designers or a heavier data-driven balance tool.

Live operations: updates, DLC, and the meaning of free content

Since launch, MINTROCKET has released a sequence of free updates and at least one paid expansion for Dave the Diver, including content drops that add dive areas, new sea creatures, new restaurant mechanics, and a separate paid experience. For developers, the structure of the live operations is the actual story, not the individual patches.

A few patterns are worth naming because they are the kind of decisions a small team can copy.

Free updates add content that lives inside the existing loops, which means the team is not maintaining a parallel codebase or a separate mode.
The paid expansion is treated as a clearly separated experience, which protects the main game’s balance and save data from being perturbed by expansion design changes.
Update notes are written in the same voice as the rest of the game, which keeps the design language consistent across the development team and the player base.
Post-launch support is paced around the same day-night cycle the game uses, which is a small but effective piece of brand consistency.
Content cadence is aligned with the existing save model, so returning players do not have to migrate saves or restart to enjoy new content.

For a studio planning a live game, the lesson is that the live operations model is a design decision as much as a business decision. The expansion-versus-free-update split has to be made before the content is built, not after, because the two paths imply different QA, balance, and save-data commitments. A useful sanity check for any small team is to ask whether the new content can be added without touching the existing economy constants, and if not, whether the team has the bandwidth to rebalance the whole game for that change.

What developers can borrow, and what to be careful with

It is tempting to read Dave the Diver as a template, but most successful designs are careful answers to a specific set of constraints, not templates. Still, there are borrowable patterns and there are traps, and it is worth being honest about both.

Borrowable: the day-night cycle as a shared frame of reference for testing and content drops.
Borrowable: the single aim-and-fire verb that covers combat and capture, which keeps the on-ramp gentle.
Borrowable: the legibility of the economy, which doubles as player education and as a QA tool.
Borrowable: the conservative rendering and lighting choices that make cross-platform work easier.
Borrowable: the rule-based management loop, which keeps the simulation side testable without a full agent framework.
Be careful: the alternation only works because both loops are short. A two-hour dive and a two-hour restaurant shift would collapse the rhythm.
Be careful: the lack of multiplayer is not an oversight; it is a design decision that removes a class of bugs and a class of features. Adding multiplayer later is not a small change.
Be careful: the authored encounter tables rely on a content team that can keep up. A team that cannot maintain the encounter content will see the world feel static.
Be careful: the visible economy is a design choice that does not transfer well to games where mystery is part of the appeal.

If there is one general lesson, it is that hybrid games work when each loop is willing to be small. Trying to make either half of the alternation into a full sub-game is how hybrid designs lose their rhythm.

It is also worth naming the things Dave the Diver does not try to be. It is not a roguelike, it is not a survival game, and it is not a management sim in the heavy sense. The moment a team starts adding crafting trees, base building, or large narrative branching, the alternation pattern stops working, because the design is built on the assumption that each loop is bounded. That bound is a feature, not a missing feature.

How to evaluate Dave the Diver as a developer, not as a player

There is a healthy habit of separating the player experience from the developer signal. As a player, Dave the Diver can be enjoyed on its own terms without thinking about any of this. As a developer, the same release is also a study in scope discipline, anchor systems, and the cost of every extra verb.

For a quick self-check when you play or watch a session, the most useful questions to ask are the same ones MINTROCKET had to answer.

What is the shared frame of reference that holds both loops together?
Which loop is allowed to be smaller, and why is that the right half to limit?
What is the single most expensive system, and is it load-bearing for the design?
Where does the design show its numbers to the player, and where does it hide them?
If the game shipped on a lower-spec handheld tomorrow, which feature would break first?
Where does new content go when it has to live inside the existing loops, and where does it need a separate mode?

These are not questions with universal answers, but they are useful prompts when you are designing a hybrid of your own. The interesting part of Dave the Diver is not that it found a formula; it is that it found an answer to a specific set of constraints, and that answer is mostly legible in the released game.

A useful follow-up exercise is to try to design a hybrid that breaks one of those constraints on purpose, and to see what fails first. A version with a longer dive loop, a version with a hidden economy, or a version with branching narrative will each surface a different limit of the pattern, and that limit is usually more useful as a design lesson than another success story.

Where to look next if you are studying the game

For a deeper look at the design history and reception of the title, the Dave the Diver Wikipedia entry is a useful starting point, with the usual caveats about Wikipedia’s coverage of recent releases. For a write-up that focuses on how the game feels on a specific platform rather than how it is designed, the Verge’s review of the Nintendo Switch version gives a good platform-side read that complements the developer framing here. That review is a useful reference for what a platform-focused writer notices, because the things that show up there are usually the same things that show up in a porting checklist.

For developers who want to keep the comparison in-house, it is also worth pairing this read with our look at Subnautica Aurora codes and the broader discussion of subscription platforms in our Game Pass for PC guide. Those pieces are not about the same game, but they cover adjacent production questions: managed services for small teams, and the live operations economics that any post-launch hybrid has to live inside.

Frequently asked questions

What makes Dave the Diver interesting from a GameDev perspective?

The game combines a side-scrolling underwater exploration loop with a sushi restaurant management loop in a single day-night cycle, and the alternation is held together by a shared economy and inventory rather than by a thin menu between two unrelated modes. For developers, it is a useful case study in scope discipline, because both loops are deliberately small and clearly bounded.

What engine and tech does Dave the Diver use?

MINTROCKET has not published a full postmortem of the rendering or simulation stack, so the engine is best described by what is observable in the shipped versions: a 2.5D pipeline that mixes 3D backgrounds with 2D characters, depth- and time-gated encounter tables, and a day-night clock that anchors most of the gameplay and economy. The game has shipped on PC and on lower-spec handhelds, which is a useful signal about the underlying asset and shader budgets.

Is Dave the Diver a multiplayer or single-player game?

Dave the Diver is a single-player game. That choice is itself a design decision, because it removes the cost of a network authority model, rollback, and cloud save synchronisation, and it lets a relatively small team ship and support a content-rich release without the live-service plumbing that multiplayer titles need.

How does the day-night cycle drive the design?

The day-night clock is the game’s anchor system. Oxygen capacity, restaurant hours, creature spawns, story beats, and even some vendor restocks are tied to it. Anchoring so much to a single clock gives the development team a shared frame of reference for testing, balance, and content drops, and it gives the player a clear rhythm for each session.

Why does the economy in Dave the Diver feel fair to players?

Catch prices, recipe multipliers, and upgrade costs are mostly visible in the UI, which lets the player reason about the system rather than guess. The economy is also tuned so that the restaurant never fully starves on a bad dive day, and so that high-value catches have diminishing returns on raw price, which pushes the player toward cooking and pairing instead of vending everything for cash.

What can small studios learn from Dave the Diver’s production model?

Most of the content is gated by depth and time rather than by branching narrative, weapons and suits are added as discrete items rather than as full skill trees, and the management loop is rule-based rather than a full agent simulation. Each of those choices shrinks the QA surface area per update, which is what lets a small team ship a wide content roadmap without a runaway maintenance cost.

How did the Nintendo Switch port affect the design of Dave the Diver?

There is no public evidence that the design was changed for Switch after the fact, but the fact that the Switch version runs the same content as the PC release is evidence that the original asset and shader budgets were set with a lower-spec target in mind. The 2.5D rendering approach also scales more cleanly than a full 3D character pipeline, and the save-anywhere, short-session design fits handheld play naturally.

Does Dave the Diver have paid DLC or only free updates?

The game has received a series of free content updates, and the team has also released at least one paid expansion that is treated as a separate experience. The free updates add content inside the existing loops, while the paid expansion is structured to protect the main game’s balance and save data, which is a useful pattern for any studio planning a live game.

What is the biggest design risk in building a hybrid like Dave the Diver?

The biggest risk is that one loop starts to feel like a tax on the other, which usually happens when the two halves do not impose constraints on each other. The hybrid only works when both halves change the player’s options in the other half, and when both halves are willing to be small. Doubling the scope of either loop tends to break the alternation rhythm that defines the design.

How can I study Dave the Diver as a developer without playing it for a hundred hours?

A useful short exercise is to play or watch a single full day-night cycle with the UI visible, and to write down which numbers are shown, which are hidden, and which systems change when the clock changes. That single session will surface most of the design decisions that the rest of the game is built on, and it gives you a vocabulary to compare the game with other hybrids you are studying.