I showed Rift Runner at this week’s class test and collected comments on Nodenoggin. People liked the movement and the look of the game, but a few could not tell what the rhythm system was doing while they played.
That was useful to hear, because rhythm is now the main thing I use to explain the game.
Peer feedback from the Week 5 playtest on Nodenoggin.
Guest lecture notes: 19 October 2026
Ricky’s talk discussed how his teams make games through collaboration and experiments. Blackboard places Ricky Winchester Talk.pptx in Week 5, Making Unique Games. The recording includes examples from Hohokum and Wilmot’s Warehouse.
Design ideas can come from different people on the team. Art and technical experiments can develop together, with each changing the direction of the other. Someone still needs to make decisions and keep the project manageable.
The advice on scope was to choose limits that help shape the game. A small team can build around one useful tool or interaction. Leaving some things unexplained can also give the player room to imagine them.
Ricky encouraged showing unfinished work early. Feedback needs to be read in context: some comments describe unfinished parts, while others reveal a problem with the idea itself. Playing classmates’ games can also help develop critical judgement.
For a pitch, he suggested describing a particular moment that makes the game interesting. A long introduction to the setting can delay the part that makes someone want to play.
The talk also covered calm communication, giving people time to think and keeping documentation useful for the team. Near-term work can be specific while later plans stay more flexible.
Ricky explained why his team avoids generative AI, including concerns about losing practical skills, control over small design decisions and its environmental and ethical effects. This was his account of the team’s approach.
My response to the 19 October talk
The advice about testing unfinished work fits the comments on my HUD. Alice and Maggie could see that rhythm was part of the game, but the reward was still difficult to read. That is a problem I need to address through the game’s feedback.
For the pitch, I can show one timed dash building a reward and what the player can do with it. That gives the viewer a specific example before I explain the rest of the run.
I also need to keep the scope manageable. Clear instructions and readable rewards are more useful at this point than adding another system. The playtest comments give me a reason to prioritise those changes.
The discussion about practical skills is something I need to consider in my own process. I should be able to explain the timing and HUD decisions, and keep records of the changes I make.
In Week 3, several classmates asked what made this more than another fast FPS. At that point the rhythm idea was still mostly a plan. The v0.11 build shown here has a 140 BPM beat that affects shooting and dashing.
A well-timed manual shot earns extra damage, and an accurate dash travels further. Missing the beat does not stop either action. Beat assist is optional. My pitch uses BPM: Bullets Per Minute as a comparison and explains the difference I am aiming for.
The Week 3 comments also asked for a clearer goal and a world worth moving through. The prototype now has seven connected regions on one map, starting in Relay Canyon and leading through more industrial spaces towards the core.
The HUD shows the current area and objective. In the pitch I describe the intended audience as players who like quick FPS movement and are curious about rhythm, without wanting every missed beat to halt the fight. I still need to develop the story.
At this stage, the upgrades mostly improved stats.
A developer capture of the HUD at this stage in Relay Canyon.
What classmates noticed this week
Several people liked shooting and dashing with the beat, and one said the dashes felt responsive. Another liked that enemies fire back, which made combat feel more interactive. The art and sound also made a good impression.
In Week 3 people had liked the movement but struggled to see a clear hook; this time some noticed the rhythm idea straight away.
The difficult part is making the rhythm reward obvious during a fight. One classmate thought the indicator near the bottom was a radio. Another said it looked like an overlay that matched the music without showing what it changed.
There is a Perfect shot bonus and feedback banner in the build, but these comments suggest that the connection between timing and damage still gets lost in play. Someone also asked for a stronger reward when hitting the beat.
I want to test that before increasing the bonus, since a larger number alone might not make the rule easier to understand.
The v0.11 build shows a Perfect shot reward, although classmates still struggled to read its effect during play.
The HUD needs another pass. A player missed the Dash 3/3 counter because it was small. Others found information scattered around the screen and suggested clearer labels, a better placed metronome and ammunition nearer the crosshair.
There were requests for more variety in music, gun sounds and weapon models as well. One person suggested unlimited dashes.
What I planned after the first test
I want the next test to show whether players understand what an accurate shot or dash gives them without my explanation. I will make the beat indicator and reward feedback easier to notice, then see if players can read them while moving and aiming.
I also need to revisit the dash limit and the spread of HUD information. The suggestion about more varied sound and weapon shapes is worth keeping, but I would rather check readability and the core rhythm rule first.
The build at this stage had a working loop of fighting, choosing an upgrade and moving on. The harder question from Week 3 remains: can an upgrade change a player’s next decision instead of only raising a stat. This is the next part I need to prototype and put in front of players.
The Week 5 comments gave me a clearer idea of what was getting lost during combat. Dashing no longer has a three-charge limit. Accurate dashes now build S, SS and SSS ratings at four, eight and twelve successful beats.
Reaching SSS gives a short speed boost and unlimited ammunition. I have made the beat guide smaller and put the reward next to it, while moving the Perfect and kill messages away from the crosshair.
An optional aim magnet helps when the reticle is close to a visible enemy. The enemies also have red weakpoints that pulse with the music, giving me another way to make timing and targets easier to read.
The v0.15 build places the SSS reward above a smaller beat guide and moves feedback away from the crosshair.
The HUD was another repeated point in the feedback. The v0.15 update uses larger type, keeps health and ammunition in the lower corners, and puts the enemy count at the top right. The weapon list now appears briefly after switching instead of staying on screen.
I can change the HUD size, screen margin and crosshair size in the settings. Tab opens the current build sheet and pauses the fight, so I can read my choices without getting shot.
The new HUD settings let me change the size and spacing of combat information.
The older question about upgrades has moved on as well. The build now offers six choices from a pool of 26 upgrades, grouped into Runner, Precision, Barrage and Blast. There are two rerolls.
Some cards alter what I do in combat: Dash Capacitor charges the next attack after a Perfect dash, while Marked Target rewards repeated weakpoint hits. The image below shows an actual gold-tier choice screen.
I also corrected enemy spawn overlaps and the entrance triggers that could interrupt progress through the second area.
An in-game gold-tier choice between Chain Recovery, Sync Spark and Warm-Up Loop.
I have updated the pitch to match v0.15. It now shows the current rhythm system, upgrades and HUD, along with the Week 5 comments that prompted these changes. The 14 October PDF above remains as a record of the earlier version.
I wanted to see whether players could follow the rhythm rewards, manage the first encounter and find the way to the next level.
Mason
Suggested trying closer enemy placement, or reducing how many things the player has to focus on at once.
Asked for a short tutorial and clearer instructions.
Mason playing the first level of Rift Runner.
Alice
The bonus effects were hard to understand, with too many things competing for attention on screen.
Hit effects need clearer feedback.
Enemies in the first level attack too often; she suggested lowering their attack frequency.
A short story or introduction would help establish the setting.
Alice trying the first level of Rift Runner.
Shirley
She enjoyed the game, but found the first level too difficult.
Suggested giving the player more ammunition.
After clearing the area, she could not tell which way to go next.
Shirley testing the first level of Rift Runner.
Maggie
The screen that appears after clearing a level is abrupt and looks like a death screen. She suggested a distinct completion and reward screen.
Well-timed shots and dashes need more positive feedback, such as a brief screen-edge effect or an encouraging prompt above the action.
She noticed a floor bug on the way to level two.
She suggested more aim assistance in Focus mode and asked about a Chinese language option.
Maggie testing Rift Runner and the route towards the second level.
What I took from the test
The beat system has rewards, but Alice and Maggie still found those rewards difficult to read during combat.
Shirley and Alice both found the opening difficult. Ammunition, enemy pressure and the timing of instructions all need another look.
I did not expect the level-clear screen to look like failure. Success and the route forward need to be much clearer.
Changes proposed after this test
Review first-level enemy attacks and ammunition capacity. Try Mason’s enemy-placement idea without making the scene busier.
Add a short control tutorial and a brief introduction before the first fight.
Improve beat and hit feedback, then give the level-clear moment its own reward screen and clearer direction to level two.
Fix the floor on the way to level two. Explore optional Focus-mode aim assistance and a Chinese language option.
Later development
The tutorial, opening-difficulty adjustment, supply rooms, clearer routes, bridge-floor repair and Chinese interface developed after these comments are recorded in Week 6.
The Pitch page holds the latest full deck and gameplay video. The v0.11 and v0.15 material above remains part of the development history.
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.
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.
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
The two experiments made on 7 October were Prism Relay, about painting a connected power route, and Beat Foundry, about shooting and dodging to a 120 BPM loop.
In Week 2 I developed my first-person shooter idea from Week 1 into a clearer design intention. The photograph below is the main record of this work. My writing is on the printed worksheet; the sticky notes are comments written by other people.
They are feedback on the idea, not features I have already built.
Week 2 worksheet and peer review. The handwriting on the printed page is my original concept; the sticky notes are other people’s comments. Select the image to view the full-size original.
My original design intention
I want players to explore, fight enemies and improve their build as they move through combat areas and choose upgrades. I want the experience to feel fast, powerful and exciting. Weapon upgrades and decisions about rewards are part of that experience.
On the worksheet, I listed an FPS shooting game in a futuristic world. The elements I want to design include weapons, visual effects, movement, aiming and upgrades. I also wrote that the game should be easy to understand, energetic and focused on movement.
These notes describe the intended experience and possible mechanics; they are not a finished prototype.
Feedback from other people
The sticky notes include positive comments that the idea is clear, as well as questions about what makes it different from other FPS games. Several people ask what the futuristic world looks like and what its story is.
One comment suggests making exploration more prominent in a prototype because players already know the basic conventions of first-person shooters.
Other notes ask whether the game is a roguelite and what happens when the player loses. Suggestions include giving the game a more distinctive setting or background story, experimenting with unique gameplay, and considering limits or cooldowns for abilities.
I am treating these as questions and suggestions from peers, not as decisions already made.
What I will develop next
The most useful question from this review is how to make the concept recognisably my own. I need to define the world more clearly and decide which action, beyond familiar shooting, creates the main experience.
I also need to explain the loop after failure if I keep the roguelite structure.
For the next small test, I plan to outline one area that rewards exploration, one combat encounter and one upgrade choice. I will use feedback from that test to decide whether exploration, movement and upgrades work together as intended.
I have not yet recorded a playable test of this Week 2 concept.
Later development
The later FPS gives the player a route through a machine world towards its core. The remaining story work and the changes to teaching, movement and rewards are recorded in Week 6.
