The Engine Became Pluggable

One Camera, Four Personalities

IsometricController   RTS pan/drag, left-click drag, edge scrolling
FPSController        W/S move, A/D turn, Q/E strafe, right-click look
SideScrollController WASD pan
FollowController     attaches to a TransformNode with an offset

All behind an ICameraController interface, resolved through a CameraSystem singleton, swappable at runtime from the console or from code — and selectable per map via a camera_controller worldspawn key.

The Command Set

camera controller <isometric|fps|sidescroll|follow>
camera controllers
camera info
camera fov <radians>
camera pos <x> <y> <z>
camera target <x> <y> <z>
camera reset

Nine commands to fly a camera around by hand in a build that mostly did not load anything yet. This is what debug tooling looks like when somebody expects to be debugging for a living.

The Bugs Are the Interesting Part

• ▸A camera angle override blocked non-isometric controllers from working at all.
• ▸FPSController did not start looking forward.
• ▸SideScrollController had the wrong axes and directions.
• ▸Switching back to isometric from FPS did not restore the original camera.

That last bug is the reason CameraSystem now stores the original camera for restoration, and the reason MapRenderResult grew a cameraController property.

RTSCameraController.ts was deleted and replaced by IsometricController. A GameInputHandler was split out so game click logic and camera controls stopped sharing a file. FPS right-click look deliberately does not use pointer lock.

Known Issues: none stated.

Why This Is The Release That Predicted Everything

The engine did not know yet that it was about to load idTech3 maps. It knew it wanted to be configurable. Every later decision — five gametypes, four view effects, per-map movement profiles, a shell swappable between the site and the game — is this interface again.