screens

Yesterday I finished laying the groundwork for the core systems in my new game project!

I have a state machine that manages basic application flow, spawns the environment, the player, and the camera into the scene, then resets if it detects that the player fell off the world.  The state machine is also the provider of Update/FixedUpdate/LateUpdate hooks for any entity in the game that needs an update loop (see my other post about keeping the Unity API at arm’s length from your game systems).

The environment is procedurally generated, if you couldn’t tell 😉

There is a resource manager for instantiating prefabs from the Resources folder.

There is an input manager for handling input from Unity and mapping it to user-defined key bindings, including 8-way joystick (aka. D-pad) controls.

The camera is a simple isometric follow cam, just pass it a transform and it will follow the transform around at a specific angle and offset.  You can also zoom in and out with the mouse wheel.

The player is just the guts from my old Grenade Guy demo ported into this new framework, so it’s a CharacterController with velocity, acceleration, gravity and ground-snapping.  It bumps and slides around the environment nicely, but I’m still suspicious of CharacterController generally as I’ve had major problems with scalability (e.g. many characters on screen simultaneously), although that was years ago.  It also drives basic headlook for a character mesh; currently it just tries to look at the spot in the world where the cursor is hovering.

(There’s a minimal worldspace UI framework too, which nicely fits itself to a camera’s far plane and works independent of screen resolution or camera settings, but it’s not being used for anything yet.)

Combine all of these elements and you can run around a simple little world with a few obstacles.  Not bad for what my work log claims to be ~40 hours of work, which includes writing these blog posts.  Progress!