Sparkfly original project / Development journal
Making a multiplayer .io action RPG feel physical
Sparkfly is an independent browser game project built around a simple question: can fast .io-style play still have the weight of an action RPG? This journal follows the systems that make the answer readable — combo timing, server-validated hits, useful equipment, and a world that reacts to movement.
By Firefly · Updated . New captures focus on movement, terrain, and weather.
Build snapshot
Movement and weather in the September build
Three local captures from September 14, 2026 show the work at close range: an interaction on a bridge, props against a cliff, and an encounter at a waterfall. Open any screenshot to inspect the full image.
Bridges and interactions
A jump prompt at the water’s edge
The bridge capture puts the interaction prompt next to the player, with the crate, planks, and riverbank all visible. The design challenge is to explain a nearby action without hiding the terrain the player needs to judge.
Terrain and props
Crates, cliffs, and rain
Two crates sit at the base of a cliff beside a stepped path. This scene is useful for checking whether props, elevation changes, and the player remain visually distinct when rain and darker lighting cover the same area.
Water and combat readability
Keeping the encounter visible
The waterfall capture brings the player, a goblin, its health bar, rain, and the five-slot combat bar into one view. It highlights a presentation test: environmental effects should leave room to read an enemy and the next available action.
The systems behind the screenshots
Make every number mean something
The interface is being built as a readable window into the game rules. A tooltip, a hit effect, and an item comparison should all explain the same underlying state.
01
Skills are data, not just buttons
The combat bar is designed around a five-position sequence. Each skill carries its own timing, range, stamina cost, cooldown, knockback, requirements, and training progress. That lets the same information power tooltips, equipment decisions, server validation, and the animation that the player sees.
02
Authority makes feedback trustworthy
The server owns accepted movement, skill use, hitboxes, range, damage, and resource costs. The browser can make controls feel immediate, but the result that matters is the confirmed result. Damage numbers, hit flashes, stun stars, and landing feedback are then anchored to that state instead of guessing locally.
03
Loot gives exploration a purpose
Inventory is more than a storage grid. A club can carry damage, strength requirements, durability, weight, quality, set information, critical chance, force, and value. Showing those details in context gives the player a reason to compare an item before deciding what to equip, sell, or carry into the next fight.
Under the hood
One state loop connects input to consequence
A player action starts as an intent from the browser. The server processes that intent inside the game instance, checks the current physics and rules, then sends back the relevant state for that player. The client uses that confirmed state for interpolation, rendering, UI, and responsive feedback.
That separation matters in multiplayer. It keeps movement, combat results, inventory changes, skill learning, quests, drops, NPC state, monster state, and map transitions in one authoritative path instead of letting each screen invent a slightly different game.
The current runtime shape
- 1Input: the browser sends a movement, skill, interaction, or inventory intent.
- 2Simulation: server-side Planck physics and game rules decide what is valid.
- 3State: the server serializes relevant entities and visibility information for the player.
- 4Feedback: the client turns the result into movement, animation, numbers, effects, and UI.
Engineering notes
Building the game as one connected system
A multiplayer action RPG becomes hard to reason about when every screen invents its own version of combat. Sparkfly keeps the important values shared: the skill tooltip should describe the same damage and cost that the server validates, and the player should see the same consequence that nearby players receive.
That principle also applies to the map. Greenwake is authored as connected region-relative maps, while the client caches static terrain work and the server remains responsible for collision, visibility, physics, and authoritative state. It keeps the world expressive without moving game rules into presentation code.
The result is a project that can be improved in small passes: first make the state correct, then make the consequence visible, then tune the presentation until the player understands what happened.
The world outside the menus
Greenwake is the testbed
Greenwake is the opening region: a safer frontier settlement surrounded by old roads, fields, cliffs, and forests that become more dangerous away from town. The connected maps currently include Greenwake Village, Mosswood Edge, Northwood, Southreach Fields, and Westroad Plains.
Map work is being built for more than a flat backdrop. Cellars, caves, towers, and future multi-floor dungeons can reuse a region-grid position while portals connect different elevations. Only the current map needs to be active at once, which keeps larger dungeon plans practical for a browser client and a multiplayer server.
The authored geometry matters too. Cliff edges, waterfall openings, harvestable trees, and terrain details should preserve the designer's intent instead of being replaced by a generic automatic guess. That makes movement and exploration feel like parts of the same world as combat.
Where it goes next
The next development passes
The current build has visible foundations, but it is not being presented as a finished commercial release. The next work is about turning those foundations into a deeper loop that stays readable when more players, enemies, equipment, and map events are on screen.
Combat depth and balance
Finish the five-step timing language, perfect timing, damage tuning, hitbox validation, and skill experience rules.
A more reactive world
Connect NPC memory, quests, monster behavior, drops, and map events so exploration changes what happens next.
More meaningful equipment
Expand item variety, set interactions, durability decisions, and progression without turning the inventory into noise.
More of Greenwake
Continue the region with authored terrain, vertical spaces, safer routes, dangerous edges, and reasons to return.
This journal will continue to record concrete changes from the playable project. The screenshots above are evidence of the current direction; future updates will add new captures as the systems become more complete.