Week 3: FPS Prototype and Peer Feedback

Written by

in

  • In Week 3 I showed the current version of my FPS prototype and collected comments on Nodenoggin. Their comments helped me see what was clear in the demo and what still needed work.
Nodenoggin board with classmates’ feedback on the Week 3 FPS prototype.
Classmates’ comments on the Week 3 prototype.

Guest lecture notes: 5 October 2026

  • Venezia G.’s Game Loops and Pillars presentation covered the game overview, design pillars and repeatable actions. I checked these notes against the PDF in Blackboard’s Week 3 folder.
  • An overview should explain what the player does in a few sentences. The suggested structure was a hook, the actions and player fantasy, then the experience being promised. It should be possible to explain the main idea in about 30 seconds.
  • Pillars should help decide which features belong in the game. Each needs a short explanation, because a title alone can mean different things to different people. A feature should support a pillar without working against another one.
  • One useful check was to reverse a pillar. If the opposite could also describe a sensible game, the original is probably a real design choice. A claim such as “best in class” does not help me choose between features.
  • The session separated the core loop from the metagame. Hades II was used to explain how arena fights and rewards connect to longer-term upgrades. Astro Bot showed how actions can be mapped from seconds to longer periods of play.
  • A loop diagram should show the actions in order and what the player gains or spends. Resources can include health, equipment or story progress. The notes also stressed revisiting the overview and pillars after prototyping.

What I took from the 5 October lecture

  • For my FPS, “fight, upgrade, proceed” needs more detail. I need to show what the player gains from a fight and how an upgrade affects the next encounter.
  • This gives me a way to review the movement, readable combat and rhythm aims. For rhythm, I need to explain the reward for timing an action, then show it in the prototype. Calling the game an FPS roguelite does not explain that choice.
  • The same questions apply to the two smaller experiments: paint and connection progress in Prism Relay, and timing bonuses in Beat Foundry. I can use their rules to compare what the player is actually deciding.

What classmates said

  • Several classmates liked the movement. They described it as smooth or fluid, and some also liked the visual effects, sound and general look of the prototype. One person thought the idea of linking rhythm to shooting was interesting.
  • The movement and sound were the parts people noticed first.
  • The question that came up most often was what makes it different from other fast FPS roguelites. One classmate compared it with Ultrakill; another suggested looking at BPM: Bullets Per Minute. A few felt there was no clear hook yet, despite liking the demo.
  • The suggestions include changing the players’ expectations regarding FPS, such as the handling of firearms, shooting, or the portrayal of enemies.
  • Players also asked what effects the upgrades and levels would have. If the upgrades merely increase a single number, it might not change the way players play.
  • One comment suggested changing the pace between fights with a quieter or reward-focused level, rather than making every area another battle. Another asked for a clearer reason to keep moving through the world.
  • Although some liked the art and sound, others wanted me to spend more time defining the gameplay, the design pillars and the kind of player this game is for.

How I will use the feedback

  • First, I need a short explanation of what the player does repeatedly and why this particular game is worth playing.
  • I will compare my idea with the games named by classmates and write down where my own rules or player experience differ.
  • I need rhythm to affect the player’s choices. The beat should give them a reason to time a shot or dash.
  • For a small next test, I want to try an upgrade that changes a decision in combat rather than only raising a stat.
  • I can observe whether players use the movement option, whether upgrading affects the next battle, and where the actions start to repeat. Short breaks between encounters might help test the rhythm.

Points from my one-to-one feedback

  • In the one-to-one discussion I was also asked to think more about worldbuilding and to make two more prototypes. For each idea, I need to ask what is unique or interesting about it, who would play it and why they would choose it.
  • Someone recommended that I refer to “Splatoon” and “Slime Rancher”.

Later development

Comments

One response to “Week 3: FPS Prototype and Peer Feedback”

Leave a Reply

Your email address will not be published. Required fields are marked *