Duskers

In Duskers, you operate a salvage vessel in a procedurally generated universe where derelict ships hold fuel, parts, records, and unseen dangers. You send drones into their rooms through a command-line interface, interpreting camera feeds, motion sensors, and sound while managing fragile equipment, dwindling supplies, and the evidence left behind by humanity’s disappearance.

Duskers places the player aboard a salvage vessel drifting through a universe of abandoned spacecraft. People are absent from the action: the operator stays aboard while remote drones enter the dark hulks, and the story reaches the player through records recovered from shipboard computers. These logs are fragments rather than a conventional cast-led plot, so uncovering the past is a parallel goal to keeping the vessel moving. Each ship can provide clues about what happened, but it is also a practical source of fuel, parts, drones, or upgrades. The premise ties its central questions to the survival routine: every visit is an attempt to recover enough material to continue, while whatever is learned from the wrecks gradually gives shape to the larger disappearance.

A derelict is explored as a connected set of rooms, with doors controlling which spaces a drone can reach. The operator first sees only what the ship’s old equipment can reveal. A drone camera presents a local view; the schematic gives a room layout; a remote microphone conveys sound; and a motion sensor can indicate activity beyond direct sight without identifying exactly what is moving. That limited information makes route planning a concrete task. The player can survey a vessel, note doors and possible dangers, and choose which rooms to open or bypass. Each command has to be entered at the console, making orders such as moving, opening, scanning, or gathering explicit. Exploration therefore combines spatial navigation with deciding how much uncertainty is acceptable before exposing a drone to another room.

The drones are both the player’s hands and the most vulnerable equipment in the operation. They can be selected individually, driven through rooms, and fitted with salvaged upgrades that change their capabilities. The manual describes tools that solve different problems: a motion sensor scans adjacent rooms while its drone remains stationary; a probe can explore accessible rooms; an interface upgrade connects to a powered terminal; and a lure attracts nearby organic threats. A stealth field can prevent detection while the drone moves, but damage or activating other equipment may switch it off. These interactions reward combinations rather than a universal safe method. A lure can draw a creature away from a route, a sensor can warn of movement, and a second drone can take a different role, but every tool depends on its condition and the layout at hand.

The command interface makes planning legible but also makes the operator responsible for translating intent into instructions. Commands can target rooms and devices, and the game provides status information based on ship logs and initial scans. A player can flag rooms on the schematic, switch between drones, and move from camera view to a broader map to maintain orientation. More advanced commands let a drone tow movable objects, pry open an unpowered door, or reconnect with the boarding vessel through an airlock. This is not a conventional direct-control action game in which a character reacts with a weapon. It is closer to remote operations: the player issues tasks, watches incomplete feeds, and changes the plan when the next image, sound, or sensor result alters the situation. A typed instruction is only useful if the drone can reach the target and its hardware still works.

Threats turn rooms and doors into tactical resources. Weapons are scarce, and entering a room does not guarantee that a hostile organism will be visible before it becomes a problem. The player can use a lure to pull threats toward a chosen location, use a sonic pulse to drive organic threats out of a room, or use stealth to move past detection. The tools have constraints: the sonic upgrade needs a stationary drone, while stealth may be disrupted by damage or by activating other upgrades. A door can delay contact or separate one region from another, but opening it without knowing what is nearby can expose a drone or create a route for danger. Different threats behave differently, and ships can contain failures as well as enemies, so survival depends on reading the room and tool feedback rather than relying on one weapon or fixed sequence.

Salvage feeds a fragile progression loop. Scrap gathered by a drone becomes a repair resource, while recovered equipment can be installed or exchanged among drones and the vessel. The manual’s repair and swap commands make the relationship tangible: a damaged tool may need fixing, an upgrade can be moved to the drone best suited to a task, and a drone can gather nearby scrap for later use. Fuel is required to travel onward, so completing an exploration without securing enough supplies can still leave the ship unable to continue. A lost drone takes its equipment with it, narrowing future options, while a breakdown can make a familiar tactic unreliable. Because the universe and derelict layouts are procedurally generated, the order and mix of resources, hazards, and available machinery vary. The player is repeatedly adapting a small inventory to unfamiliar conditions instead of building toward a single permanent loadout.

The vessel’s own upgrades extend what can be done on a salvage run. The operations manual describes systems such as a transporter for moving drones between the ship and a derelict or outpost, and other shipboard functions that manipulate found equipment or clear hazards. They connect the larger journey to the same remote, resource-conscious approach used inside a wreck: ship modules can create new options, but they require power, position, or salvage and may carry side effects. A drone can also be brought back to an airlock, allowing the operator to think about the return route as part of the mission rather than treating the farthest room as the only objective. Recovered objects may need to be towed or transferred before they can help the wider operation, so a successful excursion depends on both reaching a resource and getting it back into use. Damage changes those calculations: repairing a component spends materials that could have been reserved for another failure, while leaving it broken can remove a capability exactly when a later ship makes that capability valuable. Duskers is presented on Steam as a single-player game for Windows, macOS, and SteamOS/Linux, with Misfits Attic credited as both developer and publisher. The experience is built around its command console, schematic and drone feeds, rather than a separate multiplayer mode or a controllable human character. Its visual language of worn interfaces, sparse images, and transmitted sound keeps the player’s distance from the wrecks central to both navigation and survival.

The interface keeps the player at a deliberate remove from each danger. The schematic is not omniscient: it records the ship’s room connections and available information, but an unseen threat does not become harmless simply because a route is drawn. A motion indicator can signal activity, while the local camera may still be needed to learn what is actually in the drone’s immediate view. Listening for sounds and checking a sensor therefore supplement rather than replace cautious movement. The operator can pause to assess the information already received and then issue the next sequence, but the equipment may fail or new evidence may arrive only after a drone has moved. This gives the console a practical role beyond atmosphere: it is the means for tracking several machines, recalling their status, and coordinating tasks without a human body entering the wreck. The game’s tension follows from the limits of that remote knowledge, especially when a mission’s fuel and salvage value must be balanced against the risk of losing the tools needed for the next one.