Blastline has been released
Hello, this is Yuu!
Just as I announced in my previous post, Blastline, the game I had entered in Defold Game Jam 2026, went live on itch.io and Wavedash on Monday, October 5.
Blastline
Dash through the night city as a vampire girl, blasting the smartphone zombies swarming your fuse.
This one turned out to be a game I have a real attachment to, so even though it’s just a release announcement, I’d like to write a slightly longer piece and go over how the two weeks of development went.
What Kind of Game It Is
The main character is a vampire girl. The stage is a night city teeming with “smartphone zombies” who never once look up from their screens.
When she runs, a glowing fuse trails out from under her feet. The zombies are drawn to that light, swarming onto the line and sticking to it. When the moment feels right, you light the fuse, a wave of light races along it, and the blast radius swells with every zombie caught in it. The zombies caught in the blast dissolve into light, and their life energy becomes hers.
She herself is extremely frail, though. Get jostled around in the crowd and she’s crushed in no time, and she must not get caught in the light she set off herself either. Her health drains little by little, so you can’t afford to take your time. The more you gather, the bigger your payoff — but the narrower your escape route gets. That choice between greed and knowing when to pull out is the heart of the game.
The stages are divided into eight nights, and the goal in each night is a three-star rating. It depends on how you approach it, but a single night can be over in as little as ten seconds and at most a few minutes, so I think it’s easy to pick up.
The Idea Born from the Theme
Having finally felt some real traction with js13kGames after a long while, I decided to ride that momentum into the next jam. That was Defold Game Jam 2026. As I wrote in my previous post, this was my first time using Defold.
So for the few hours before the theme was announced, I was working through Defold tutorials and jotting down the basic pitfalls in my notes. In other words, before deciding what I wanted to make, I first looked into what this engine could actually make.
The announced theme was “Chain Reaction.” When you hear “chain reaction,” puzzles are the first thing that come to mind, and a puzzle game was in fact what I originally planned. But in a jam, the amount of time players can give any one entry is tiny. If I wanted them to understand what the game was about within the first ten seconds, a game where you move a character from a top-down view would get the idea across better than a puzzle that requires reading the rules of a board. So I decided to prioritize clarity and rethought the rules almost from scratch.
Turning the problem over while looking at all kinds of games for reference, what I landed on was this: “you’re weak yourself, so you lure the enemies in and wipe them out.” In games where huge numbers of enemies come at you, getting surrounded is normally a sign that things are going badly. In this game, though, enemies gathering around you is both a gain and a hazard. I wanted to build it so that your only means of fighting back is also your only threat.
The day after the theme was announced (9/21), I spent one day writing a prototype with no art and no setting at all — just circles and lines, enough to check how it felt. It was a throwaway prototype, built on the assumption that the real version would be rebuilt in Defold.
When I played it, though, it honestly wasn’t much fun. There was no cost to drawing a line, so it came down to running around and pressing the button whenever. No decision was being made. So I made moving around slowly drain your health, with sprinting draining it even faster. But hold off on detonating and the longer you wait, the bigger the crowd grows and the more your escape routes close off. Adding costs like these, and agonizing over how harsh the punishment should be for getting caught in your own blast, I kept tuning until I finally reached the point where you feel that hesitation: “I want to stretch this a little further, but this is about to get dangerous.”
The Six Days Before the Core Started Working
Building the Stage and Struggling with Assets (9/23–9/25)
From 9/23, it was finally time to build the real thing in Defold. The first thing I did was get the character on screen in the center. From there I made her walk, put zombies in, built a system to spawn them, and so on — assembling it one piece at a time.
What gave me the most trouble here was the character art. I wanted walking animations for all eight directions this time, but I couldn’t get the motion to look the way I wanted no matter what I tried, and it ate a lot of time. I had planned to swap out the walking sprites at the very end, but in the end I’m still using the temporary ones I made first. That’s why the walking animation is a little stiff. Even so, if I had kept fussing over it, the finish line would have kept moving further away, so I think cutting it off was the right call.
Building the night city map also gave me a hard time. I really wanted to make a bunch of props and recreate more of a night cityscape lined with buildings, but I judged that I wouldn’t make the deadline if I kept at it, so the map is pared down to the bare minimum.
The Wall of Visuals (9/26–9/27)
Just when I thought the city was done, going with a tilted top-down view caused a new problem: the character looked like she was buried in the ground. Half a day to solve that. From there came a run of visual adjustments — tuning how the camera framed things, conveying the darkness of night, getting the fuse’s glow right. The fuse in particular I redrew over and over in a short span, trying to fix how the overlapping parts of the line came out unnaturally bright.
The Morning the Core Came Alive (9/28)
In this game, several hundred zombies appear on screen at once. Whether it would still run smoothly with that many had worried me since before I started building. So from the late night of 9/27 into the early hours of 9/28, I pulled an all-nighter running tests, lining up endless zombies and measuring the performance cost. It was fine on the PC I develop on, but on my test device it dropped to 30fps. That’s the reason I didn’t target mobile this time. That said, I had no room to chase it down at that point, so I deliberately left it until the final day — something I would normally tackle first.
And then, in the morning right after finishing those tests, the core of this game — “light the fuse and a wave of light races along it” — finally worked. This was after the jam’s halfway mark. Up to that point, the first week had been, frankly, a stretch spent chasing stage-building and visual problems.
That same day I dropped in the blast radius preview, the check for whether you’d caught yourself in it, the health system, and more all at once, and it finally started to feel like a game.
Two Days Shaping the Game
9/29 was the day I built the way into the game: the title screen, the settings screen, and so on. And that night, I gave the game the name “Blastline.” It’s a coined word combining blast and line, and it refers to the fuse itself. I usually name a game right before it’s finished, but this time I settled on it at the halfway point. Since changing to a different title partway through means remaking the logo and the images, it’s really safer to decide as late as possible. But I liked the name quite a lot personally, so my worry about wanting to change it later turned out to be unfounded.
9/30 was UI day. I hadn’t nailed down the on-screen display in detail during the prototype stage, so I put together the parts players actually see — the collection gauge, health, the item slots, win/loss conditions — while adjusting their layout. The lamps that increase as your chain grows were a particular holdout: not just how to present them, but the spec itself wasn’t locked down until the final day, and the collection gauge animation never made it in. There was more I wanted to do, but here too I’m glad I drew the line somewhere.
The Last Three Days
This is where it got hardest. The remaining time was always on my mind, but at that point I still couldn’t see whether it would actually come together. I felt like I was being chased by something the whole time, and even looking back now, these three days feel far heavier than the eight days before them.
I started building the stage select and results screens, but while looking at how other browser games flow from screen to screen, the number of screens I needed to make kept growing and the end stopped being in sight. In fact, the two days of 10/1 and 10/2 went almost entirely to screens.
The first time I wrote out the remaining work was at midnight, as the date turned over to 10/3. Two and a half days left before the deadline. I should have done it much sooner.
Writing it out did settle my resolve, though. This became the single busiest day of the two weeks, and I put in the per-stage settings, the star ratings, saving, the chain multiplier, and more all together. Preparing the BGM and the explosion assets was around this time too.
One other thing I decided during this stretch was that the tutorial was absolutely going in. With the mahjong and hanafuda games I’d made up to now, it never even occurred to me to include a tutorial. But in this game, the system of luring enemies in and blowing them up is just too hard to convey with words alone. That’s exactly why I felt this was the one place I couldn’t cut corners.
At the same time, I had wanted to put in a little hidden element, but there was clearly no way the time was there at that point, so I gave up on it for the time being.
The Final Day and the Dawn
Six and a Half Hours on the Tutorial (10/4)
The final day started in the dead of night, finishing up the effects and sounds for absorbing a zombie.
From midday, it was finally time for the tutorial. I built it so the main character teaches you the controls through dialogue, advancing in stages: movement and health, gathering zombies and the collection gauge, lighting the fuse and getting clear, chain practice, and then the handoff into the main game. I even worked in moments where a zombie barges in mid-explanation and she panics. I didn’t want it to just explain things in dialogue and be done — I wanted you to learn by actually moving your hands. In the end, the tutorial alone took about six and a half hours.
Cutting Items, and What the Freed-Up Time Went To (the night of 10/4)
As evening came, I made the call to cut items from the spec. I had four kinds of items in mind back at the prototype stage, and the item slots had been on screen since four days earlier, but there was no time to finish them to a usable state, so I reluctantly shelved the whole thing.
My original plan was to spend one day each on effects and the tutorial. As it happened, both came together faster than expected, and cutting items freed up a bit more time on top of that. Even so, by this point it was already 10 p.m. Still, having built a flow where you play while talking with the main character in the tutorial, I wanted to leave one more trick at the end. So I used that freed-up time to slip in the easter egg I had once given up on. How to find it, I’ll leave for you to enjoy.
Right after that, I also knocked out the work to make the itch.io and Wavedash versions each run correctly — that took only a few minutes.
Three and a Half Hours of Level Tuning (the early hours of 10/5)
The one big job left was level tuning. I’d been putting off the most tedious thing until last, so from here it was a race against the clock.
What I mainly tuned was the size of the map, the number of zombies, the distance from which zombies are drawn to the fuse’s light, and the proportion of zombies that come after you. The further you get through the stages, the shorter the reach of the light and the more zombies that attack. Early on you can stand still and they’ll gather on their own, but later you have to stretch your line out and go collect them yourself. That, in turn, makes keeping a long fuse harder and harder.
The performance problem I’d postponed on 9/28 got settled here too. When I cut the number of simultaneous zombies down considerably, even my test device started hitting 60fps. It wasn’t a bug — it was a level tuning issue. That said, I never had the room to give mobile any thought in the first place, so it stays where I dropped it at the start: out of scope.
In the end I was able to keep at it until dawn. The last stage was the one place I came up a little short of three stars myself, but after confirming that three stars were achievable on every other stage, I could finally submit.
Incidentally, the entry count, which was 41 eight hours before the deadline, ended up at 78 including my own. Nearly double in the last few hours. Knowing everyone else was pushing right up to the wire too was a little reassuring.
Final Thoughts
Running for two weeks straight on Defold for the first time and shipping a game that has everything from a tutorial to a bonus trick in it — I’m genuinely happy about that. Of course there are things to reflect on too, like the Wavedash version not getting fullscreen or mute toggles.
The jam results are announced on 10/11. I’m planning to go over the results, the feedback I received, and my takeaways all together in next week’s post.
If this caught your interest, please do give it a play! And if you feel like it, I’d love to hear what you thought on X or elsewhere!