Noteleks — Week One
This week I finally started building Noteleks — a browser game I have had in mind for a while. Most of the work was not adding features. It was tearing down the ones that were holding everything back.
My sister and I have been making music together. We set up practice days this week — actual scheduled time, not just "we should do this sometime." We are building a setlist. It is early, but having a structure around it changes how it feels. Something is starting to take shape there.
On the development side, this week belonged entirely to Noteleks.
What Noteleks Is
Noteleks is a browser-based game I have been planning to build for a while. The stack is Laravel 12 on the backend and Phaser.js for the game engine — everything runs in the browser, with Laravel handling routing, templating, and eventually game state persistence. The name is "skeleton" spelled backwards. That tells you most of what you need to know about the aesthetic.
The basic idea: you control a skeleton character navigating rooms, fighting enemies, surviving rounds. Think dungeon crawler, browser-native, built from scratch.
I pushed the initial commit today. But most of the week was not adding new things — it was cleaning up the mess that had accumulated during early prototyping.
The Refactoring
The Player class was the problem. It had grown to over a thousand lines: debug overlays baked into movement logic, a Spine animation system that added manifest dependencies the project did not actually need, watchdog timers, fallback systems layered on top of other fallback systems. It worked, barely, but adding anything new meant digging through all of that first.
I cut it down to around three hundred lines. Removed the Spine system entirely and replaced it with WebP frame-based animations — idle, run, jump, attack, jump attack. Each animation has its own FPS setting. The whole thing is simpler and easier to reason about.
The bigger change was extraction. Instead of one class doing everything, I pulled each concern into its own manager:
- AnimationManager — handles animation state transitions
- InputHandler — centralized keyboard input (WASD, arrows, space)
- PhysicsManager — collision detection and knockback forces
- EntityFactory — template-based entity creation so spawning enemies is not copy-paste
- EnemyManager — enemy lifecycle, round-based spawning
The architecture is component-based now — a proper ECS pattern with a GameObject base class, reusable Component behaviors, and a SystemManager coordinating everything. It is the kind of foundation you want before the game gets complicated, not after.
Where the Game Stands
After the cleanup, here is what is actually working:
- Player movement and jumping — direct keyboard controls, no input lag
- WebP frame animations synced to movement state
- Melee attack with a proper hitbox and a 500ms cooldown
- Enemy spawning — zombie, skeleton, ghost, and boss types
- Knockback physics when enemies are hit
- Round-based wave system that escalates difficulty
- Score tracking and HUD display
- Debug mode with visible collision boundaries
The weapon system has a framework in place — spear, dagger, fireball, arrow, magic bolt are all stubbed — but none of them fire projectiles yet. That is the next real feature push.
What Is Next
Room generation. Right now the game runs on a flat stage. The next step is procedural room layouts — floor tiles, walls, and platforms that are different every session. That is what turns this from a tech demo into something that has replayability.
More next week.
— Joshua, Graveyard Jokes Studios