Force5 Development
Back to builds

Lonesome Void (codename)

Lonesome Void starts as a 2D top-down browser game to prove the core loop of ship exploration, resource collection, attachment upgrades, and realistic roadblocks before the larger 3D version. It is also the practical version I can build now while I work up to the wider scope, asset load, and solo-dev demands of the full game.

3/8/2026

  • Browser-native 2D top-down pass on a larger 3D space exploration plan, following the kind of scope progression games naturally took over decades.
  • Fully controller-compatible in the browser, with local save data plus export/import backups.
  • The main puzzle is learning the ship and its constraints through direct input and feedback, then solving environmental roadblocks with tools instead of scripted puzzle tricks.
In development
gamebrowserphaserspaceexplorationcontroller

Timeline

  • March 2023 (approx.): early Unity mechanic prototypes started the direction, even before the full game concept was settled
  • 2023 through 2025: the larger 3D version stayed in notes, naming, and world-building rather than active production
  • Early 2026: it became clear the full 3D game was too large for a first solo game
  • March 2026: active prototyping shifted into a 2D top-down browser version to establish the loop, controls, lore, and ship systems in something playable now

Problem as experienced

This is not solving the same kind of day-to-day workflow problem as the other builds on the site. The real problem here was scope.

The full 3D version was clear enough as a direction, but it was not a realistic first solo game. If I kept treating that version as the starting point, I was going to spend years building toward a target that required more technical depth, more art production, and likely more people than I have right now.

The better problem to solve was: what is the smallest playable form of this game that still keeps the right core loop and the right feeling of unfamiliar systems, blocked progress, and ship-based problem solving?

Why existing patterns did not fit

I am not trying to make a classic puzzle game where the player learns the designer’s intended answer pattern.

The direction here is closer to realistic unknowns inside an unfamiliar environment:

  • learn what the ship does by pressing buttons and seeing feedback
  • understand which attachment or ship capability changes the situation
  • mark a blocked area, leave, and come back later with the right tool

The resource gates are meant to feel like practical roadblocks, not authored “solve the clever sequence” moments. The comparison is less “find the ceremonial key” and more “figure out how to break the door down with what is available.”

Core loop

  • Explore from the ship through the surrounding grid
  • Find resources needed to rebuild the Auron drive and return home
  • Collect attachment upgrades that open access to blocked resources
  • Use notes, beacons, and map memory to return to unresolved locations later

Iteration path

The original plan was a much larger 3D space exploration game. That remains the larger direction, but not the correct starting point for where my own skill set is right now.

The 2D top-down version is meant to do what game series have done naturally over the last forty years: establish the world and loop in a simpler form first, then expand the scope later. That is the practical path here.

In practice, the current prototype is landing a lot closer to the original NES Legend of Zelda than to a modern 3D exploration game. That is useful, not a failure. It shows which parts of the world, progression, and ship logic still read clearly when the presentation is stripped down.

This also gives me a place to lock down names, lore, progression rules, and player expectations before the production cost of the full 3D version enters the picture.

Current implementation

The current build is browser-native:

  • Phaser 3 runs the main 2D gameplay layer with automatic WebGL or Canvas rendering
  • Plain HTML, CSS, and TypeScript handle the HUD, menus, and systems panels
  • A custom Canvas 2D map sits alongside the gameplay layer
  • Saves stay local through IndexedDB, with JSON export and import for backup or control
  • Controller support comes directly from the Gamepad API
  • The app is packaged as a static browser build with installable PWA support

There is no backend, remote database, or hosted multiplayer stack behind the current version.

What is in motion

The main work right now is the menu layer, which will probably end up reading more like a cockpit than a traditional game pause menu.

Current focus:

  • fast cockpit interaction for map, attachments, notes, and ship status
  • keeping menu entry and exit nearly instantaneous
  • using notes, pins, and beacons as a practical memory aid for unresolved problems
  • making the map work more like MGRS so normal orienteering and land-nav concepts apply
  • giving the cockpit enough information density to feel like a ship system, not just an overlay

Constraints

  • browser performance matters, especially when moving between gameplay and the cockpit
  • menu transitions cannot become slow, decorative, or animation-heavy
  • the limitation should stay on player knowledge and decision-making, not UI friction
  • the 2D version has to stay practical and not quietly expand back into the full 3D scope
  • art direction is still unresolved; current SVG art is there to get something on screen, not to define the final visual language

Current state

Right now this is still an early playable slice.

What exists:

  • a basic playable character
  • basic controller compatibility
  • debug collectibles used to test attachment and resource ideas
  • early map work that can already be navigated outside the full gameplay loop

What does not exist yet:

  • meaningful world interactions across the full loop
  • mature attachment behavior in the field
  • final art direction
  • a hosted pre-alpha build

Open questions

  • how much information the cockpit should expose versus leave for player discovery
  • how far the 2D version should go before the larger 3D follow-on becomes practical
  • how to keep environmental roadblocks readable without sliding into tutorialized puzzle language
  • what final visual style can carry the world without turning production into the bottleneck