Phantom Silksong: what developers can actually take from a quiet sequel
When the phrase “phantom silksong” circulates in developer chats, it usually means a very specific conversation: how a small studio can ship a sequel that does not feel like a content patch, why the combat team chose silk-and-needle over the original’s nail, and what the long silence between announcements taught the wider community about release-window communication. Hollow Knight: Silksong is a real, confirmed product from Team Cherry, and as of the scheduling date for this article it has not yet received a definitive, public launch date that we are willing to report as fact. The rest of this piece treats the game as a case study: it analyses what is already documented in official updates, what the published trailers and the Steam page actually demonstrate, and what indie developers and technical leads can responsibly borrow from the design decisions on display.
The goal is not to summarise a hype cycle. The goal is to read a publicly visible game-development artefact the way a producer or technical director would. That means separating confirmed mechanics from community guesses, looking at animation, traversal, enemy encounter design, and the engine assumptions those decisions imply, and asking, at each step, what a four-to-six-person team learned in order to make a sequel feel distinct without rebuilding their toolchain from zero.
The position of Silksong in Team Cherry’s production history
Team Cherry shipped Hollow Knight in 2017, then supported it with multiple free content packs, and publicly announced Silksong in early 2019. The studio structure remained small throughout: a handful of core developers based in Adelaide, Australia, collaborating with contracted composers, voice actors, and a shifting circle of freelance artists and playtesters. The fact that the game is a sequel, not a brand-new IP, defines almost every production decision that followed. The original toolchain, art pipelines, animation rig, and the team’s mental model of the world already existed; the project had to be evaluated as a marginal cost on top of a known engine rather than a greenfield undertaking.
For a developer reading the public history, the useful lessons are not about marketing mystique. They are about how a small team can use an existing engine and a known IP to expand scope without multiplying risk. Treating the sequel as a “build new levels in the same engine” job kept the failure modes inside a familiar design surface. That decision is also why animation, traversal, and combat carry visible similarities to the first game: the rig, the input mapping, and the camera philosophy were already in place.
A second observation is structural. Team Cherry’s updates have largely been event-driven rather than calendar-driven. Trailers and a public demo appeared at specific showcases; development news between them has been limited. For studios trying to learn from that pattern, the takeaway is not “go silent.” It is that a small team with a fixed content pipeline can defend a long communication gap only when their audience has a deep trust in the original release. Newer studios cannot rely on the same patience without first earning it.
What we can responsibly say about Silksong’s design from public material
The clearest design line carried over from the original is the 2D Metroidvania structure: a single interconnected map, traversal-gated regions, and an exploration loop driven by upgrades rather than by quest markers. Hornet, the protagonist of Silksong, replaces the Knight, and the move-set, enemy pacing, and the way new abilities open shortcuts are all variations on that template. The official Hollow Knight: Silksong page on Steam and the trailers released at events like the Xbox & Bethesda Games Showcase have shown enough of the world to confirm that Team Cherry is iterating on the same system rather than designing a new one from scratch.
The change that matters most to developers is the protagonist’s toolkit. Hornet is faster, has a longer effective range, and a recovery model that rewards mid-air aggression more than the Knight’s grounded poise-and-poke combat. The animation team appears to have reworked the rig to support a more vertical, momentum-driven moveset: dash-launching off pogo points, vertical silk-thread ascents, and combos that chain off aerial hits. From a production standpoint, this is not a trivial reskin. It implies new animation states, new collision profiles, new enemy timings, and new boss design heuristics, because every existing enemy has to be re-evaluated against a faster, more aerial character.
| Design area | Original Hollow Knight | Silksong (publicly visible) | What it implies for development |
|---|---|---|---|
| Protagonist archetype | Slow, grounded, melee range | Fast, aerial, longer range | Rig, animation, and collision rework |
| Traversal palette | Wall jump, dash, pogo | Silk threads, dash-launch, vertical climb | New movement ability gating |
| World structure | One large connected map | Pharloom, a new kingdom with its own regions | New art sets within an existing engine |
| Combat rhythm | Poise and patience | Momentum and aerial chains | Enemy timings and boss phases retuned |
| Quest layer | Loose, environmental | Visible quest log and named NPCs | Light quest tracker added to the UI |
This table is not a side-by-side review. It is a reading of public material. The original combat loop rewarded poise and reaction time; the silhouette of the new combat loop rewards vertical momentum and mid-air commitment. For developers, that is a useful case study in how a sequel can preserve genre identity while changing feel.
Animation, rig, and the cost of a faster protagonist
Animation is the most expensive single cost in a 2D action project, and Silksong visibly raises the bar. The trailers show longer animation arcs, more frames per second of motion, and a higher density of in-between poses than the original game. The reason is the new movement: the more aerial the protagonist, the more angles the camera has to track, the more poses the rig has to interpolate, and the more states the state machine has to handle without ever producing a frame that breaks the player’s mental model of the character.
Concretely, a fast aerial character creates four production problems a slower grounded character does not have. First, collision has to be re-tuned so that a dash and an attack can overlap without producing false hits against background geometry. Second, the state machine has to expand to cover airborne attacks, aerial recoveries, and the transitions into and out of vertical climb. Third, the animation bank has to grow, because the same number of ground attacks is no longer sufficient when the player can attack from many more launch positions. Fourth, enemy timings have to be revised, because an enemy designed to punish a slow grounded character will feel cheap against a fast aerial one.
For a small team, the only realistic answer to that pressure is asset reuse plus careful variation: the same skeleton, the same rig, the same animation layering, with new art layered on top. If the team had decided to build a second rig from scratch, the project would have multiplied its animation cost without producing a proportional improvement in player experience. The decision to keep the rig and rewrite behaviour on top of it is the kind of choice producers should be able to defend with a graph of art cost against iteration time.
- Reuse the rig, rewrite behaviour: a faster character can be made from a known rig by adjusting state machine transitions, not by replacing the skeleton.
- Layer animations: hold poses, blend trees, and additive layers can multiply the apparent move-set without producing a separate animation file for every variant.
- Redesign enemy timings before retuning collision: the cheapest way to keep combat fair is to slow enemies, not to add new hitboxes.
- Profile frame time on the busiest scenes: more aerial combat means more on-screen effects, so particle, lighting, and parallax budgets need real numbers, not guesses.
Traversals and the geometry of a new kingdom
The new world, Pharloom, is built around verticality in a way the original Hallownest was not. Public trailers show spire-like structures, silk-thread ascents, and a higher density of background-to-foreground layering. For a 2D engine, verticality of that kind is expensive because parallax art, camera dead zones, and collision layers all have to handle more extreme angle ranges than a flat horizontal map would. The team has to choose, at design time, how much of that verticality is art and how much of it is level geometry, and that choice feeds directly into build size and iteration time.
One useful pattern from public material is the use of “anchor” traversal nodes: silk-thread points that function as both visual landmarks and gameplay waypoints. They give the player a reference frame in a vertical space, and they give the level designer a constrained set of places where traversal logic is allowed to be complex. Constraining complexity to a small set of nodes is a common way to keep level scripting maintainable. The same pattern shows up in other 2D action games as grapple points, lanterns, or marked climbing surfaces; the choice of silk as the visual language is specific to the IP.
Another visible choice is the density of background art. Pharloom appears busier than Hallownest, with more layered scenery, more ambient animation in the background, and more particle systems. For developers, that raises a familiar question: how much of the frame budget is spent on things the player does not directly interact with? The honest answer is that background art is part of the player’s emotional read of the world, but only if it does not compete with foreground action. A silhouette test on every level is a cheap way to keep that contract.
Combat encounter design under a new moveset
The For additional context, Hollow Knight article is a useful starting point for the production history of the original game and the context into which Silksong was announced. For a design-level reading, the differences and new features summary maintained by IGN is one of the cleanest side-by-side references for what the sequel changes relative to the first game. Both of those resources are useful without being definitive, and they should be read as community-curated summaries rather than as primary sources.
Combat encounter design is the place where the public design decisions are most visible. The original game taught the player a vocabulary of pogo-bouncing, shade-dashes, and patient one-on-one duels. The sequel shifts the vocabulary toward aerial chains, quick needle extensions, and recoveries that let the player stay in the air longer. The implication for enemy design is that the safest reference point is no longer the player’s grounded reach, but the player’s possible landing point. An enemy that telegraphs a long horizontal sweep will feel very different against a character who can launch vertically out of the sweep than against a grounded one.
The team appears to have responded by introducing enemies that operate at multiple altitudes: flyers that force the player upward, grounded sentries that punish an over-eager descent, and mid-height zones that sit between the two. The bosses shown in public material are built around that verticality, with phase transitions tied to altitude rather than only to health. That is a useful pattern for any developer designing a boss against a mobile protagonist: phase the boss by reachable space, not only by remaining hit points, and the encounter will scale with player skill rather than punishing it.
From a production standpoint, this also means the encounter design team has to share a vocabulary with the level design team. If the level designer places a high platform that the player can reach but the encounter designer has not tuned the enemies for, the player will either cheese the encounter or get frustrated. Coordination between the two teams is the cheapest way to prevent that, and it usually means a shared design document with concrete numbers: vertical reach, dash distance, silk-thread length, attack hitbox size.
| Encounter type | Original design approach | Silksong approach (publicly visible) | Production takeaway |
|---|---|---|---|
| Standard enemy | One altitude, telegraphed single attack | Multi-altitude, with aerial option | Plan enemies around player reach, not just player position |
| Miniboss | Single arena, multi-phase by HP | Multi-tier arena, phases by altitude | Phase by reachable space |
| Boss | Long combo, patient punish windows | Vertical transitions, ranged needle states | Keep at least one attack per phase that the player’s new move can answer |
| Swarm encounter | Limited aerial mobs | More aerial density | Profile frame time on worst-case swarm |
Quest layer, UI, and the cost of a small change
One of the most discussed additions in public material is a visible quest log. The original game asked the player to track their own objectives in their head or in external notes. The sequel has shown a tracker surface. From a developer standpoint, the apparent smallness of that change hides a real production cost: writing system that has to be localisable, that has to remember objective state across saves, that has to handle quest lines that branch, and that has to be readable on every supported resolution without competing with the rest of the HUD.
The honest production lesson is that even a small UI addition in a content-heavy game touches several systems at once. A quest log needs a data model, a serialisation path, a UI layout, a localisation pipeline, and a QA matrix. The fact that a small team committed to that work tells developers something about user research from the first game: players wanted a softer hand on objective tracking, and the team decided the cost was worth paying. Whether the result is well-tuned will be visible only at full release.
The change also has design consequences. A quest log encourages designers to write more discrete objectives, which in turn encourages players to optimise rather than to wander. The original game’s design tolerated wandering because there was no explicit way to track progress; the sequel’s design tolerates optimisation because there is. Both are legitimate design positions, but they are not the same. A developer adding a quest log to a similar game should be aware that the change is not purely a UI change: it is a change to the player’s relationship with the map.
Engine, scope, and what the visible design implies about the toolchain
Team Cherry has not publicly documented the engine used for Silksong, but the visual and behavioural continuity with Hollow Knight strongly suggests a continuation of the same Unity-based toolchain. That continuity is itself a design decision. The same engine means the same editor, the same profiler, the same animation tools, the same shader pipeline, and the same asset import workflow. Switching engines mid-sequel is a classic producer’s mistake, and the visible fact that the team did not do that is the most important engine-related lesson in the project.
For a small studio, the cost of continuity is often invisible. A new engine would have meant a new editor, new version control habits, new build pipelines, and a new set of platform certification requirements. The savings from not switching are not in licence fees; they are in cognitive load. The team did not have to learn a new toolchain, and that is a direct saving on iteration time. For a developer evaluating their own sequel, the question is not “which engine is best in the abstract” but “which engine do we already know well enough to keep moving in.”
There is also a performance lesson in the visible scope. Pharloom is larger, busier, and more vertically complex than Hallownest. The team is shipping that on the same engine family and on platforms that did not change. The only way that is possible is through careful budgeting of frame time and memory on the busiest scenes, and a willingness to cut art that pushes either budget. Producers reading the project should ask, scene by scene, what the worst frame looks like, what the worst allocation spike looks like, and what the team’s exit criterion is when a scene fails the budget. The answer is not always public, but the discipline has to exist.
Sound, music, and the original game’s most-cited strength
The Hollow Knight soundtrack by Christopher Larkin is one of the most consistently praised elements of the original release, and the public trailers for Silksong indicate a continuation of that partnership. For developers, music and ambience are not decoration; they are part of the player’s emotional map. A new region needs a musical identity that the player can recognise without reading a label, and that identity has to be cohesive across exploration, combat, and boss phases.
Production-wise, the soundtrack is a place where outsourcing is well understood. The composer works to a brief, receives level geometry and art reference, and returns stems that the audio team integrates. That division of labour is healthy because it lets the in-house team keep moving on systems while the music is iterated in parallel. The risk is that integration happens late, and the audio mix has to be rebalanced against new sound effects. Teams can defend against that by allocating a small audio slot in every vertical slice review.
From a research and planning point of view, a Metroidvania soundtrack has to do two jobs at once. It has to give the player a sense of place during exploration, and it has to amplify tension during combat without obscuring enemy audio cues. A useful test is to play the region in silence; if the level is unplayable without music, the audio mix is doing too much work and the level design is doing too little.
Risk, scope, and the long gap between announcement and release
The visible gap between the original Silksong announcement and the eventual release is not a marketing problem, it is a production problem. A small team building a content-heavy sequel in a shared engine accumulates risk in a small number of places: new protagonist animation, new traversal mechanics, new region art, new boss design, and platform certification. Every one of those areas can be retried, and the team’s ability to absorb a failed attempt is what a long development window buys. The opposite risk is a forced ship: a release that is functionally complete but not yet emotionally finished, and that is a worse outcome for a sequel whose value depends on its moment-to-moment feel.
For developers, the practical lesson is to separate “scope risk” from “polish risk.” Scope risk is the chance that a feature cannot be built at all within the available time and tools; polish risk is the chance that a feature is built but feels wrong in the player’s hand. The two have different mitigations. Scope risk is reduced by cutting the feature or by resourcing it properly; polish risk is reduced by playtesting, iteration, and a willingness to rework the feature. Silksong, on the public evidence, has spent more time on polish risk than on scope risk, and that is a defensible choice for a sequel.
There is also a community-facing component. A long gap generates pressure, and that pressure has to be managed. The team has chosen to communicate through event appearances and the Steam page rather than through a development blog. That choice has costs in community trust, and the team’s willingness to absorb those costs is itself a sign of how the studio is structured. A team that depended on community goodwill for early access funding would not be able to make the same choice.
What a producer or technical lead can borrow from the project
The most important lesson is that a sequel is a product of the same toolchain and the same studio, not a fresh start. Treating it as a fresh start is the most expensive mistake a small team can make. The Silksong project is, on the public evidence, an exercise in marginal cost: keep the engine, keep the rig, keep the design vocabulary, and rewrite only the parts of the system that have to be rewritten for the new protagonist to feel new.
Three concrete practices follow from that. First, design a one-page engine decision document at the start of the project. The document lists the engine, the editor version, the platform targets, the build pipeline, and the exit criterion for each. Second, write a one-page animation decision document that names the rig, the state machine library, the animation bank size, and the iteration cycle. Third, write a one-page encounter design document that names the protagonist’s reach, dash distance, and aerial options in concrete numbers. These documents do not need to be long, but they need to exist and to be shared across the team.
- Keep the engine. Switch only when the cost of staying in the engine exceeds the cost of switching, and never switch mid-sequel unless there is no other way to ship the new feature.
- Reuse the rig, rewrite behaviour. Animation is the most expensive line item in a 2D action project, and the rig is the most reusable part of it.
- Phase bosses by reachable space. A mobile protagonist changes what counts as a fair encounter, and the safest rule is to phase by altitude and reach rather than only by hit points.
- Treat the UI as a system change, not a cosmetic change. Even a small UI addition touches data, localisation, save state, and QA matrix.
- Plan audio in parallel with systems. A soundtrack that arrives late forces a rebalance, and a small audio slot in every vertical slice prevents that.
- Separate scope risk from polish risk. The two have different mitigations, and conflating them is how small teams over-scope and under-polish at the same time.
Common misconceptions developers should avoid when reading the project
Three misconceptions appear regularly in community discussion. The first is that the long development window is a sign of a troubled project. A long window is a sign of a content-heavy project with a small team and a commitment to polish. A troubled project would have shipped at lower quality or shifted to a smaller scope; this one has not visibly done either. The second is that the new protagonist is a simple reskin. The new move-set requires new animation states, new collision profiles, and retuned enemy timings, and a team that treated it as a reskin would have shipped a worse game. The third is that the original engine is automatically a constraint. The visible scope of the sequel demonstrates that the engine is not the bottleneck; the design vocabulary and the team’s familiarity with the toolchain are.
A fourth, subtler misconception is that the sequel’s design has to be a strict improvement on the original. The original game has a specific emotional tone, and that tone is part of its value. The sequel is a different game with a different protagonist, and a faithful adaptation would lose the thing that made the original memorable. The right comparison is not “is Silksong better than Hollow Knight” but “does Silksong give the player a coherent experience that uses the new toolkit.”
How a small team should scope a similar sequel
The shortest useful answer is: decide what is being preserved and what is being replaced, and write both lists down. The preservation list is the engine, the rig, the camera, the design vocabulary, the audio pipeline, the build pipeline, the platform targets, and the team’s mental model of the player. The replacement list is the parts of the system that the new protagonist requires: new animation states, new traversal nodes, new enemy timings, new boss phases, and new content. The preservation list should be long, and the replacement list should be as short as the team can defend.
From that decision, the rest of the project follows. The art team can reuse most of its pipeline; the animation team can keep the rig and add a new layer; the level design team can keep the editor and add new regions; the audio team can keep the workflow and add a new score; the QA team can keep the test plan and add new cases. The only place the team is doing fundamentally new work is the new protagonist’s behaviour, and that is the smallest place to put a large amount of new risk.
A useful internal target is to keep new code under thirty percent of the codebase. That is not a hard rule, but it is a useful number to defend. If new code is climbing past fifty percent, the project is no longer a sequel; it is a parallel project, and the team should be honest about that. If new code is climbing past eighty percent, the team has effectively cancelled the sequel and started a new game, and the project plan should be rewritten to match.
Validation, QA, and the difference between development testing and certification
QA for a Metroidvania has a few predictable failure modes: a softlock in a region, a quest that cannot be completed, a save file that cannot be resumed, an enemy that spawns out of bounds, an audio cue that does not fire, and a localisation string that overflows a UI panel. The cheapest way to surface all of those is a combination of automated checks for deterministic failures and human play for subjective failures. Automated checks are good at catching softlocks, broken triggers, and missing audio; human play is good at catching balance issues, narrative breaks, and moments of confusion.
For a small team, the practical answer is a structured internal playtest with a small group of trusted external testers, a checklist of known failure modes, and a regression test on every build. The list is not glamorous, but it is the difference between a project that catches its own bugs and a project that ships them. The team’s QA budget should be visible on the production plan, not absorbed into general development time.
Certification is a separate concern, and for a small team it is the part of QA that is least under their control. Console certification requires a build that meets a specific technical contract, and a team that has shipped once already has a much better sense of what the contract requires. The visible fact that the team has shipped the original on multiple platforms is a useful predictor that the sequel will be able to clear certification without surprises, but it is not a guarantee, and the team has to budget time for resubmission if a regression is caught late.
What a developer should read first if they want to learn more
For primary sources, the official Team Cherry site, the Steam page, and the trailers released at public showcases are the only places where the development team has spoken directly. The Steam page in particular is the team’s own description of the game, and it is the most reliable public document on the project’s scope. Everything else, including this article, is editorial interpretation layered on top of those primary sources.
Frequently asked questions
What is phantom silksong, in plain terms?
Phantom silksong, as a search phrase used by players, is shorthand for Hollow Knight: Silksong, the sequel to Hollow Knight developed by Team Cherry. The game is a 2D action Metroidvania starring Hornet in a new kingdom called Pharloom. It is a real, announced project with a public Steam page, public trailers, and a confirmed developer.
Is phantom silksong released yet?
As of the date this article was written, the game has not received a definitive public release date that we are willing to report as fact. The Steam page exists, public trailers have been shown, and a public demo has appeared at events, but the team has not shipped the full game. Players looking for a release date should watch the official Team Cherry channels and the Steam page directly.
What platforms is phantom silksong planned for?
The publicly visible material has confirmed PC, and Team Cherry has historically supported consoles on prior releases. Specific platform lists and certification windows have shifted over time, and the safest answer for developers and players is to consult the official Steam page and the team’s announcements at the time of any planned purchase.
How is the combat in silksong different from Hollow Knight?
The new protagonist has a faster, more aerial moveset with longer effective reach and a recovery model that rewards mid-air aggression. The original Knight was slower and more grounded, with a combat loop built around poise and patient one-on-one duels. The new combat loop rewards momentum and aerial commitment, which in turn forces new enemy timings and new boss phases.
How long has the project been in development?
The project was announced publicly in early 2019, after the original game and its content packs had shipped. The actual development window is longer than the announcement window because pre-production on a sequel typically begins before a public announcement. The team’s communication has been event-driven rather than calendar-driven, which has produced a long visible gap between announcements.
Will silksong use the same engine as the first game?
Team Cherry has not publicly documented the engine in detail, but the visual and behavioural continuity with Hollow Knight strongly suggests a continuation of the same Unity-based toolchain. The decision to stay in the same engine is a meaningful production decision in its own right, and it is one of the most important signals developers can take from the project.
Why does the sequel feel different in pacing and feel?
The new protagonist is faster, more aerial, and built around a longer effective range. Pacing changes follow from the new toolkit: a faster protagonist enables faster traversal, faster combat resolution, and a higher density of on-screen action. The team’s art and audio decisions support that pacing with busier backgrounds, more vertical regions, and a score that sits more consistently in the player’s audio field.
What should developers actually take from the project?
The clearest lesson is to treat a sequel as a marginal cost on top of an existing engine rather than as a fresh start. Reuse the rig, the editor, the build pipeline, and the design vocabulary, and rewrite only the parts of the system that the new protagonist actually requires. That decision limits scope and concentrates risk in a small, manageable surface.
Is the quest log a real change in design philosophy?
Yes. The original game relied on the player to track objectives in their own head, while the sequel has shown a visible quest log. The change is not only a UI change; it is a change in the player’s relationship with the map. A developer adding a quest log to a similar game should be aware that the change touches data, localisation, save state, and QA matrix, and that it shifts the design toward optimisation rather than wandering.
Where should a new developer start reading about the project?
Start with the official Team Cherry site and the Steam page, because those are the team’s own primary sources. Use the Wikipedia entry on the original Hollow Knight for production history and context, and use community-maintained side-by-side references like the IGN differences and new features page to read the design changes at a glance. Treat everything else, including this article, as editorial interpretation layered on top of those primary sources.
Leave a Reply