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

Date: December 15, 2025

Article: Dev-01

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.