Trixel Rocket 2 - Devlog 04 - What am I working on... I need to reimagine the camera system!

#TrixelRocket2 Devlog 04 - In this quick update, I started working on a new enemy generation system but then want to redo the camera system and how that works before. What are your thoughts? 🚀 Download Trixel Rocket for free on App Store at: https://apple.co/31s4gzt ► Download Unity at h

This Trixel Rocket 2 update is a good look at how one design decision drags another behind it: work on a new enemy generation system exposed a problem with the camera, and now both are being rethought together. Here is where the game stands and what is changing.

Enemy generation forces a rethink

Work started on an enemy generation system, and that immediately raised bigger questions about the game's structure. The current setup is placeholder-grade: a few enemies fly in just to give the player something to shoot at, plus one enemy that rotates around the planet continually firing torpedoes at you. Some of that will probably survive into the final game, but the way enemies come in and how they are generated is being reimagined rather than extended.

The camera problem it exposed

The rethink surfaced a limitation in the current camera. The player continually rotates around the planet, and the existing view gives a little visibility left and right with a slight downward camera shift - fine for shooting at distant incoming enemies, but you cannot see what is behind you or in the area where you are standing. If the new system generates enemies close to the player, the current camera literally cannot show them, which makes the design a non-starter without a camera change.

The planned fix

The direction being explored: pull the camera back and angle it slightly downward, so the player sees further down and gets a wider field of view around their own position. The open question is where within the rotation of the player input that camera adjustment should happen - that is the piece being worked out in the current sessions.

The takeaway

Systems in games are not modular in the way we would like: an enemy spawner is also a camera problem, which is also a player-feedback problem. Catching that dependency at the design stage - before building the full generation system against a camera that cannot support it - is exactly the kind of course correction that looks slow in a devlog and saves weeks in practice.

That camera experiment is literally the evening's work at recording time, which is what makes these updates useful to follow: the game is being designed in public, decision by decision. If you are building your own game, notice the order of operations here - question the system, find what it breaks, fix the foundation first.