Week 4: FPS Design Direction

This week I put together a direction board for my FPS idea and a hand-drawn hide-and-seek loop for the classroom exercise. The board develops the FPS concept after the Week 3 feedback.

Lecture notes: 12 October 2026

The session covered pitching, game design documents and gameplay loops. This matches the core-loop and player-experience topic listed for Week 4 in Blackboard.
A pitch and a GDD use some of the same information, but have different readers. The pitch explains the idea and why someone would want to play or support it. The GDD gives a team enough detail to build it.
He distinguished an early prototype from a vertical slice. A prototype explores whether an idea works. A vertical slice is a short section intended to show the experience and finish of the proposed game.
The Tetris example showed how a simple loop contains many smaller decisions. Block shapes, movement speed, collisions and failure rules all need answers, even if the pitch only shows the broad steps.
We were asked to consider different timescales: what the player does moment to moment, what those actions achieve over a level, and why they come back later. A diagram also needs to make the win and failure states clear.
The discussion connected level layout and tutorials to the loop. A tutorial can introduce the actions one at a time. Maps and blockouts help explain how the player moves between those actions.
The planning advice was to break broad features into smaller tasks and leave room to reduce scope. The pitch should explain what can be cut while keeping the main experience. The session also raised accessible presentation, including avoiding colour as the only way to communicate information.

My hide-and-seek sketch shows a countdown, searching and two possible outcomes. It still needs rules for the time limit and how a player is found. Those details would matter if someone else tried to make or play it.
For Rift Runner, I can separate the immediate movement and shooting from the longer loop of clearing a room, collecting supplies and choosing an upgrade. That should make both the diagram and pitch easier to follow.
I would keep the first explanation focused on the player’s goal. The detailed input and timing rules belong in the supporting design notes. A short playable section is also a better way to explain the movement than a long list of features.

Class record: my 12 October recording notes, checked against the Week 4 module topic in Blackboard.

I wrote the player’s immediate goal as: keep moving, try different weapons and reach the exit. The short loop is fight, upgrade, proceed.
This gave me a clearer way to explain what happens between encounters.
“Survive in a world of machines, and enjoy the rhythm fight” is my pitch slogan.
The board sets out three design aims. Movement should feel fluid, with running, jumping and sliding helping the player avoid attacks. Combat should be clear, with recognisable enemies and strong hit feedback.
For Rift Runner, rhythm was still planned at this stage. I wanted to reward shots and dashes on the beat while keeping the controls responsive.
I also sketched rules for the world. Canyon and industrial areas could form one continuous level, with side paths and raised platforms offering different routes. Combat gates would open when nearby enemies have been defeated.
Robots, drones and turrets would need different shapes and clear visual or audio cues so players can understand their roles. Weapons would suit different ranges; health pickups, upgrades and signs would support the player’s route through the level.
For tone I chose energetic and rhythmic over slow or gloomy. The style board points towards a 3D cartoon look, animation and warm lighting rather than realism or pixel art. The images on the board are visual references for colour, lighting, characters and interface.

The class exercise was to draw a gameplay loop in a small group, then let the other groups guess the game from the diagram. The image below lays out a simple game loop. The catcher closes their eyes while the other players hide. After a countdown, the catcher searches for them. If the catcher finds everyone, they win; if they do not find every hider, the hiders win.

The Week 3 feedback asked what makes the FPS distinct. The direction board makes my intended experience clearer, but it does not answer that question on its own.
I want to test whether rhythm changes the way a player moves and shoots, and whether an upgrade changes their next decision rather than only raising a number.
For the hide-and-seek idea, a short paper rules test with other players would show where the loop is unclear. These are next steps, not tests I have already carried out.

The reference board draws on Roboquest for the cartoon FPS environments and Hi-Fi RUSH for music-linked action and interface feedback. Roboquest and Hi-Fi RUSH are credited as references; the board images belong to those games.
The useful design question was how the references could support the rules. Raised paths should offer different movement choices, while a rhythm cue should show the timing of a useful action. The later build and pitch show how I developed those intentions.