Category: Articles: Dev Blog

Development blogs to record the progress of the Shattered Bounds game(s)

  • Dev Blog 2 – Steps 8-17: Setting up Networking

    Date: December 22, 2025

    Article: Dev-02

    TLDR

    • Completed Milestone 1 (M1) with a working networked setup (host + clients + GM console).
    • Finished the first version of the Player HUD, wired into the live game state.
    • Stabilized performance in test scenes while pushing toward high, consistent framerates.
    • Currently realigning the scenes in Unity so each one has a clear role: Host, Player Client, and GM Console.
    • Milestone 2 (spatial mapping) is still postponed until I can get the required headset and spatial cameras

    Milestones from Steps 8-17

    These steps have been all about turning the early prototype into a proper, network-aware foundation that players can eventually stand on.

    Here’s what’s been completed:

    • Telemetry integrated for this phase
      The logging backbone set up in M0 is now connected into the new networked flow. The host can track key runtime stats during a test session, which will later help with balancing, AI “director” behavior, and overall performance tuning.
    • Performance and stability tests at high frame rates
      I’ve run repeated tests to keep the prototype scene stable at high FPS targets on my dev machine. The exact numbers will evolve with hardware, but the focus is clear: keep things smooth enough that attacks, enemy movement, and hit detection feel responsive.
    • Networking system set up for a local host
      A basic host/clients model is now in place. One machine runs as the authoritative host, and player clients connect into it. This is the backbone for fair, synchronized multiplayer in Shattered Bounds: Battlegrounds.
    • Functioning GM console connected to the host
      The Game Master (GM) console can now talk to the host, monitor what’s happening, and trigger key controls like Emergency Stop. This is critical for safety when real people are in the arena.
    • First-pass Player HUD completed
      The initial Player HUD is now up and running. It hooks into the networked game state so players can see essential information (like their status and session context) while they play. This will evolve, but the basic “player-facing layer” is finally there.
    • Successful tests with Host + GM + two test players
      I’ve run end-to-end tests with:
      • One host,
      • One GM console,
      • Two player clients.
        These are still internal tests, but it’s the first time the full loop—host, GM oversight, and multiple players—has been exercised together.

    Where Things Stand Right Now

    With Milestone 1 finished, SB: Battlegrounds now has:

    • An authoritative host managing the game state,
    • A GM console plugged into that host for safety and control,
    • Player clients that can join, play, and be monitored,
    • A first version of the Player HUD that makes the experience legible from the player’s point of view.

    The current focus is on realigning scenes into their proper roles. During early experimentation, it was easy to let everything live in one “does-it-all” scene. Now I’m:

    • Separating the Host scene (game state, enemy control, telemetry).
    • Cleaning up the Player Client scene (what an individual player actually loads and sees).
    • Isolating the GM Console scene (tools and overlays for overseeing a session).

    This cleanup is not glamorous work, but it’s important. Clear boundaries now mean less pain later when I start layering in more systems, more players, and eventually more arenas.

    Meanwhile, Milestone 2 (spatial mapping) is still on hold. To meaningfully move forward on mapping real spaces and testing in mixed reality, I need to secure:

    • A mixed reality headset,
    • Two spatial cameras.

    Until those are in place, I’m focusing on everything I can build and polish on the current hardware: networking, HUD/UI, GM tools, and the underlying logic.

    Current Challenges (Technical and Personal)

    Two big constraints continue to shape the pace of development:

    • Budget
      There’s still a funding gap for:
      • The first mixed reality headset,
      • Spatial cameras,
      • Weapon controller prototyping.
        Those are all essential for the next major jump (spatial mapping + real-world playtests), but they’re not in reach yet.
    • Time
      Family comes first, which means development happens in the gaps—nights, weekends, and the odd quiet pocket of time. Free time fluctuates, and so does progress speed, but the project keeps moving forward step by step.

    Even so, Steps 8–17 have been a meaningful turning point:
    SB: Battlegrounds has moved from “single-machine sandbox” to a small, networked environment with real roles—host, GM, and players—and a HUD that actually shows something worth looking at.

    Next up: finish the scene realignment, refine the Player HUD as testing continues, and keep preparing the codebase so that when hardware arrives, the shift into spatial mapping and controller integration is as smooth as possible.

  • Dev Blog 1 – Weeks 1–7: Laying the Foundation

    Date: December 15, 2025

    Article: Dev-01

    Since writing this post, the project now called Shattered Bounds: Battlegrounds was previously referred to as “Proto-Park.” Anywhere you see “Proto-Park,” it’s talking about the same experience.

    TLDR

    • This first dev blog rewinds through Weeks 1–7 of building the Proto-Park, marking the shift from years of planning and mobile app work into active Unity development for Shattered Bounds.
    • Foundation systems are now in place: telemetry logging, a first enemy template (the floating cube), zone boundaries and alerts, a basic sound system, an early GM console with E-stop and debug overlays, and an initial KPI/financial model.
    • Right now everything is running on a laptop only, with base telemetry, XR weapon tests, and safety/control systems taking shape; Week 7 exposed the physics engine as the main performance hog, reshaping how optimization is approached.
    • The biggest challenges are performance tuning on limited hardware, learning Unity best practices while building, and managing ADHD + part-time hours that pull attention between worldbuilding, design, tech, and business.
    • This dev blog exists to create external accountability, share honest progress and setbacks, and slowly gather a community of people who want to watch – and eventually help – Shattered Bounds come to life.
    • What’s Next: Dev Blog 2 – Review development progress until now

    Since this is the first entry in the dev blog, I want to rewind a bit and cover the first seven weeks of work already done on the road to creating the Proto-Park.

    I started learning to code about five years ago, building mobile apps in Visual Studio. Over the last year and a half, that skillset has been slowly redirected toward a bigger idea: Shattered Bounds. In October 2025, I officially moved from “planning and dreaming” into the programming phase for the Proto-Park.

    This blog is where I’ll track that journey.

    Milestones from Weeks 1–7

    The first seven weeks have been about building the foundations that everything else will rest on. Here’s what’s in place so far:

    • Telemetry system
      A logging backbone that can monitor game stats. It’s already tracking the basics, and is being designed to handle future data like player experience metrics, throughput, and AI behavior signals.
    • First enemy template
      A simple floating cube that can be spawned, attacked, and defeated. It’s not pretty, but it proves that player strikes register correctly and that the basic combat loop works.
    • Zone monitoring and boundaries
      A system to define the play area, detect when players move toward the edges, and trigger alerts when they get too close. This is an early but important step toward the safety model.
    • Sound system
      A simple audio layer for alerts and music, so the game can communicate more than just through visuals.
    • GM control board skeleton
      The beginnings of a Game Master console, including:
      • An Emergency Stop mechanic,
      • Debug overlays to help visualize what’s happening under the hood.
    • KPI and financial model
      A first-pass business model to understand:
      • How Proto-Park might operate as a real business,
      • What occupancy and pricing might need to look like,
      • And what “viable” actually means in numbers.

    None of these are final. But together, they form the scaffolding I can now start hanging real gameplay and operations on.

    Where Things Stand Right Now

    This phase is about the base layer:

    • Telemetry wired in and recording.
    • First enemy template functioning.
    • Early XR weapon tests.
    • Safety and control systems beginning to take shape.

    Progress hasn’t been fast, partly because I’m learning Unity and game development as I go. Debugging days can feel long and slow—but they’re where most of the real understanding comes from.

    A good example: in Week 7, I spent about five days wrestling with system performance only to finally identify the main power hog: the physics engine. That’s not shocking for a game, but seeing it in real data, on my setup, changed how I think about optimization and future feature decisions.

    Right now, all testing is happening on a laptop only, with no headset yet. A mixed reality headset is planned for spring/summer, which will be a big step forward in seeing how everything actually behaves in the target environment.

    Current Challenges (Technical and Personal)

    On the technical side:

    • Performance tuning with limited hardware.
    • Learning best practices in Unity while also trying to push the project forward.
    • Making sure early systems (like telemetry and E-stop) are robust enough to last, so I don’t have to rip them out later.

    On the personal side, I’m also dealing with ADHD, which definitely shapes how this process feels.

    • I have a strong urge to skip ahead—jumping straight into worldbuilding, player experience design, product ideas, or financial planning—before the current layer is truly solid.
    • When I do that, I usually end up having to backtrack, because everything in this project really does stack on the previous step.
    • My attention is constantly pulled between:
      • World building,
      • Game mechanics,
      • Player experience,
      • Product and hardware ideas,
      • Business and financial planning.

    On top of all that, this is a part-time project, built in my free time.

    One of the reasons I’m writing this dev blog is to create a bit of external accountability. By making the journey public – even in this early, rough stage – I’m hoping to:

    • Keep myself moving forward,
    • Share honest progress (and setbacks),
    • And build a small community of people who are interested in seeing Shattered Bounds slowly come to life.

    If you’re reading this, you’re already part of that.