Problem
I wanted to build a small game that was more than a static interface: it needed timing, state changes and controls that felt understandable.
JavaScript game
Blade Rhythm
A timing-based browser game where the player attacks, heals and reacts to enemy movement. The project was mainly about connecting game logic, keyboard input and interface feedback.
Target group
People who enjoy short timing games, including portfolio visitors who want to try the interaction instead of only reading about the code.
My role
Game concept, frontend, JavaScript logic, interface states and responsive adjustments.
Tools
HTML, CSS, vanilla JavaScript, DOM updates, keyboard input and simple automated tests.
Interaction evidence
The game loop in four steps
Enemy movement
A timer updates the enemy position and creates the timing window for the player.
Player input
The attack button or Space key checks whether the enemy is inside a valid hit zone.
State update
Health, combo, difficulty and status values change according to the timing result.
Visible feedback
The interface reports the result and the next enemy cycle begins with the current state.
Testing evidence: Automated checks cover restart timers, keyboard controls, enemy attacks and reachable timing zones. External playtesting is still a next step.
Process
From simple idea to playable loop
1. Core loop
I started with the basic loop: an enemy moves, the player reacts, and the game updates health, status and difficulty.
2. Player feedback
I added visible timing zones, button labels and status values so the player can understand what is happening while playing.
3. Difficulty and reset
The game increases pressure over time, while restart logic keeps the loop from duplicating timers or keeping old state alive.
Implementation
Code and testing choices
JavaScript choice
I used vanilla JavaScript because the project is small enough to understand without a framework. That also makes the game easier to present and explain.
Interaction choice
The game can be controlled with buttons and keyboard shortcuts. This made the interaction faster and helped the game feel less like a normal webpage.
Testing and iteration
I added automated checks for important behavior such as restart, keyboard controls and enemy attacks. I also tested the layout responsively so the arena does not break on smaller screens.
Result
What the project shows
The final result is a playable browser game with visible state changes, keyboard controls and a difficulty loop. In my portfolio, it shows that I can build interactive JavaScript and test important behavior instead of only styling static pages.
Usability testing plan
Can first-time players understand the game loop?
Status: Planned — external testing has not yet been completed.
Objective and participants
Test whether 3–5 people who play casual browser games, with mixed keyboard familiarity, can understand the goal, controls and difficulty changes without instruction from a moderator.
Tasks
- Explain the goal of the game.
- Attack successfully inside the timing zone.
- Use healing at an appropriate moment.
- Restart the game.
- Explain how the difficulty changes.
Observe and measure
Record task completion, critical errors, moderator assistance, hesitation or wrong turns, and participant comments. Observe whether the timing zone, health state and keyboard controls are noticed.
Pending evidence
Findings: Pending external sessions. Resulting design changes: Pending analysis of the completed test notes.
Reflection
What I learned
This project helped me understand how quickly small JavaScript projects need structure. Game state, timers and UI updates have to work together, otherwise the experience becomes confusing.
Next step: I would improve the visual feedback, add clearer onboarding and make the difficulty curve easier to understand for first-time players.