More than a decade is a long time to leave a ball lost.
Back in 2013, Norwegian developer Knut Ryager’s original Lost Ball won Game of the Year at the Norwegian Game Awards. Now he is returning to it with something considerably more ambitious than simply polishing up an old project and putting it on Steam.
The new Lost Ball is a physics-based puzzle-platformer built around accumulation. Every level gives you another ability, and those abilities increasingly collide with a world full of ropes, magnets, gravity fields, fluids, destruction, optics, circuitry, portals, projectiles and plenty more besides. Ten completely new levels sit alongside remakes of the original ten, meaning players can see both where Lost Ball came from and what more than a decade of additional experience can do with the idea.
Perhaps just as interesting is what happens after the campaign. Players get the complete editor and scripting tools Knut himself uses to build the game, with Steam Workshop support opening the door to entirely new puzzles, mechanics and potentially things the developer never intended anyone to create.
Lost Ball also arrives at an interesting point in Knut’s own development process. Its custom physics engine began as entirely hand-written work, while generative AI tools have since been introduced to assist with code, procedural graphics and sound, localisation, and some music.
So, we caught up with Knut to talk about returning to an award-winning project after more than a decade, building interconnected physics systems without everything exploding, handing his development tools over to the players, and what changed when AI entered the workflow.
Lost Ball trailer
Before we send the ball rolling again, could you introduce yourself and tell us a little about your background? How did you first get into game development, and what were you doing when the original Lost Ball came together?
I first started programming back in high school, where I made a program to solve the problems in physics class. So after that, I got a bit extracurricular and started working on my physics engine. I hadn’t seen many 2D platformers with accurate physics; that’s what intrigued me about making a ball-rolling simulation with accurate curves and friction conversion.
The development was pretty slow for a few years, though, since I didn’t study any computer science until university. In the beginning, I was building my slopes with sine/cosine functions; it was mostly in the last year, when I first heard about NURBS curves from a friend I was actually able to begin making the game’s actual levels.
The original Lost Ball won Game of the Year at the Norwegian Game Awards back in 2013. More than a decade later, what made you return to this particular project rather than leave it as something from an earlier chapter of your life?
I always wanted to make Lost Ball into a proper game, but this was a time-consuming prospect. The original game was in Flash, which pretty much died around the time I finished Lost Ball. Two of the games I beat in the Norwegian Game Awards did become commercial games, while my game just had a free web version, so the victory didn’t exactly feel complete.
To release Lost Ball commercially, I would have to rebuild it in a modern engine. I gave it a shot porting it 7 years ago, but it seemed like it would take probably half a year, which I didn’t consider very well-spent time, since that’s only the very beginning of what it would take to make it into a proper game. It would also need massive architectural performance overhauls to even be playable on most PCs.
But with the recent years’ technology advances, I realised I could do the port much faster, so the initial port was finally made in a few weeks. And once I had the game ported, all of a sudden I went full speed into development of the new Lost Ball.How strange has it been revisiting levels and ideas you created so long ago? When rebuilding those original ten stages, were there moments where present-day Knut found himself questioning what 2013 Knut was thinking?
At first I didn’t have any ideas for the new levels I was going to add, so I was actually a bit envious of my earlier self at first, thinking maybe I had lost my creativity since then. However, after being in idea generation mode for some months, I realised I was actually getting much better ideas this time. So now when I look at those original 10 levels, I can only really shake my head. One thing I am questioning is why did I have 2 cave levels, and so many puzzles where you blow up rocks?
The new Lost Ball game revolves around gaining another ability with every level, with mechanics eventually interacting across gravity, fluids, optics, ropes, magnets, destruction, circuitry and more. How do you introduce that many systems without overwhelming the player?
Those abilities solve puzzles, so there are increasingly difficult puzzles introducing each ability, before combining the need for multiple abilities. For example, when you acquire the magnet, there is a lever that must be pulled, and another that must be pushed with inverse magnet force to activate an AND logic gate circuit, which opens the room’s exit gate.
So you’re typically forced to learn the abilities and related mechanisms as you acquire them. I also added demo levels for the coming Steam Next Fest in October, and these give the player more room to focus on each ability. So I’m restraining myself a bit here in making hard puzzles for now. The plan is for both the players and me to make the most crazy hard levels later with the level editor.
Those systems also create enormous potential for unintended solutions. When somebody bypasses your carefully constructed puzzle by combining two mechanics in a way you never considered, do you see that as something to fix or exactly the kind of behaviour a physics game should encourage?
I put up some fences for workarounds I notice. For the original Lost Ball game, I actually realised how to bypass some puzzles when I tried them over 10 years later, and I am not going to give that kind of pondering time to close any loopholes.
But alternate solutions are great, I think, if they also require some ingenuity. There are cases where you can just build a lot of speed and zoom across puzzles; these typically require some playing skills and are enjoyed by speedrunners, so it’s not that much of a problem either, I think.
You built the custom physics engine yourself rather than relying entirely on an existing engine’s simulation. What did writing your own technology let you do that would have been harder otherwise, and how painful has maintaining it become as Lost Ball has grown more complicated?
The hardest part of building the engine was debugging problems, since for performance reasons, physics engines must “cheat”, which invites more bugs/edge cases, which spirals into more messy handling of “special cases”. But being able to tune what the engine focuses on, and integrate with any gameplay system, is the big advantage of building your own engine. The best example here is Lost Ball’s support for arbitrary smooth curves and concave polygons, which is not supported in, e.g. the Box2D physics engine. I use these a lot for jumps/half pipes/tunnel shapes.
The destructible terrain with the fire/melting/drying system must integrate well with polygon bounding box systems. Games like Noita have used “falling sand” simulations with the particle grid extending to all solid ground, while I am using geometric operations on polygons to adjust terrain, and sparse grids for fluids. This can give an edge in my scenarios where I don’t really have much fluid normally, while still being able to convert all my polygons to fluid. But remains to be seen how players will use fluids in their levels. And there are a lot of parallel calculations here; it may be hard to force an existing engine to work with them.
Now, there could be ways to hack your way to get your custom features into existing engines, but you might not know if it’s feasible until it’s a bit late. So the main advantage of building your own engine is that you end up forging your own path instead of following what the engine conveniently lays out for you. But the engine did take up the majority of the development time of the original Lost Ball, and it got quite painful to work with the math/physics. It’s one of the main reasons I ended up taking such a long break from the game.
With so many interconnected systems, I imagine changing one small thing can have consequences somewhere completely unexpected. What has been the most spectacular example of the physics breaking during development?
For the fire system, I have settings for temperature as well as melting points/burn speeds for different materials, and an overall level theme burn modifier. I didn’t really think too hard about this at first, so I just threw it in there. But this ended up with all kinds of polygons catching fire, including dirt/snow, and just burning down my entire level to the ground.
Another issue I have encountered a lot is with fluid, which will flow along polygons, but then it suddenly stops at some invisible wall in the air. So I had to ponder a lot whether some system in Lost Ball had actually left these “ghost walls” there, or what could possibly have caused it.
Lost Ball includes the complete level editor used to build the campaign, rather than a simplified tool created specifically for players. Why was giving people essentially the same toolbox you have so important?
I am trying to get a selling point going here, with the in-game level browser being able to play all the custom levels people will hopefully contribute to the game. So we’ll see about that! I also plan to share some harder levels myself later, which means I can release content without making software updates to the game. I basically have a 2D polygon modelling editor where you can visually sculpt polygons with operations like vertex/edge selection, drag/rotate/resize/extrude, and define curves between vertices.
This kind of polygon sculpting is mostly used in 3D, while 2D level editors typically use a tile engine, so I think there is a lot to appreciate here for people who prefer complexity beyond the typical 2D level editor while still keeping it simple.
Players can also use scripting to create custom game modes and distribute their work through Steam Workshop. At that point, you are almost handing them a small game-development kit rather than merely a level editor. How far do you think people will realistically be able to push it?
Yes, I haven’t gotten too much time to use this yet, but I was able to create a level called “Flappy Drone”; you can maybe guess which game it resembles. I’m planning to make a few more custom games to showcase the potential.
Is there also something slightly terrifying about giving thousands of players access to your tools? Are you expecting the community to produce levels that make your own campaign look embarrassingly straightforward?
It’s possible; players can even copy my campaign levels as starting points. So my levels might end up looking weak if people do that. But hopefully that will mean that my game is a success and will benefit the players.
I also want to dig into your AI disclosure, because it is unusually specific. You say the custom engine was originally written from scratch by you before AI began being used to accelerate development in 2026. What changed at that point, and what made you decide these tools had become useful enough to introduce into the Lost Ball project?
Coding tools became a lot stronger with Claude Opus 4.5, which I tried back in January. It was the first agentic coding tool I tried, so I certainly didn’t expect it to already work so well. So what changed was just me testing agent coding.
AI-generated code can save time, but in a game built around tightly interconnected physics, it could also introduce problems that are difficult to spot. How do you review and validate generated code before trusting it inside something as fundamental as Lost Ball’s simulation?
Manual testing is actually the most efficient way to judge code for the game, because of how fast you can spot errors compared to reading code. A good example is the simulated fluid stopped by invisible walls – immediately obvious as seen in the game, but just a tiny rounding error in the code.
I created about 100 test levels to observe various aspects of Lost Ball. In a few minutes, you could easily spot a dozen bugs that you likely would have never thought about reading the code. So before reading any AI code, you’ll want the AI to work as much as possible on it; this often means 5-10 manual testing rounds with corrections to get a feature working as your “initial” code.
And you will typically see a lot of regressions, bugs that appear and reappear later. I have about 20000 unit tests, which may sound like a lot, but realistically you would need hundreds of thousands of them to catch most regressions. AI will typically break ~10-20 of those tests per hour. And you’ll also want the AI to profile and optimise the code to show that it works efficiently. So it’s only really sensible to read the code after it’s already working, to avoid wasting time reviewing bad code. And so when you finally read it, you don’t typically have too much to complain about.
But even when the code is working, for AI code, one of the main concerns is the large amount of it that AI can generate even when less code could do the same job, and how well isolated the code is, because if your code is a big mess, AI will adapt to your patterns and create an even bigger mess. I split Lost Ball into 50 assemblies to improve this, so the physics here is about 50000 lines of the 1.65 million total code lines, so you can have a lot of detailed tests for your base physics, while a lot of stuff like enemy code is not as critical.
You can, however, pull off some pretty big refactors with the help of AI that were hopeless before at such scale. For example, the original Lost Ball written in ActionScript 3 used Object-Oriented architecture for the physics engine, and it was refactored to an Entity Component System with over 10x better performance in about 50 AI hours. So although the AI code is more bloated, you can also reach a much greater scale of testing and refactoring.
You have also disclosed AI use for localisation and procedural generation of graphics and sound, while music made using Suno is explicitly labelled. There is considerable disagreement within indie development about generative AI at the moment. How do you decide where you are comfortable using it, and are there parts of Lost Ball’s creative process you deliberately keep entirely human-made?
There’s a pretty stark divide there between programmers and artists, as programmers mostly embrace such tools. I might be a bit extra pro-AI, since my Master’s degree is in AI.
What we can agree on, though, is that the last thing anyone wants to see is some beginner suddenly showing up and outdoing you with their fancy AI. So I’d much rather gear up massively with AI myself, and not let that happen.
For the music, I reached out to the original composer for Lost Ball to join; he was a bit busy, though, but maybe he’ll show up later. So I’ve been going for a lot of Suno and sound effects from online libraries. The game’s credits/sound player is pretty detailed for this, so you can check the source of all sounds in the game, including all the people who shared their sounds online.
For graphics, I went with vector graphics like the original Lost Ball Flash game, which means they are typically drawn by code. AI can do this reasonably well, and it can use measurements correctly for the game. This is neat when editing (“discussing”) the art later in terms of the drawing math rather than, e.g. pixels.But that doesn’t mean everything is quick and easy like some people claim after making a “1-prompt” game. It took around 15000-20000 AI prompts so far, and they typically take 10-30 minutes to run. The longest one I ran so far took over 70 hours. To gain more speed, I have 4 computers working simultaneously.
The part I keep deliberately human-made is the levels, which I make in the level editor. That’s where I am cutting up polygons, and I can also apply some texture compositions like edge coating/blend/gradients/tints. So it’s an editor where you have a lot of power to build what you want and feel like the master architect, even though a lot of AI went into building all the powerful tools.Going back to the game itself, there is an interesting contrast between the authored campaign and potentially unlimited community creations. Once Lost Ball is released, do you see your 20 levels as the main experience, or almost as a demonstration of what can be built with the systems you are handing over?
Lost Ball’s campaign is meant a bit as a demo; I focus more on adding many features rather than exploring them fully, so there will be many ideas left to construct. I do hope to see some crazy levels out there!
Finally, Lost Ball has already had one life and one Game of the Year award. When this new version releases in 2026, what would make returning to it after all these years feel worthwhile: finding a much larger audience, seeing the Workshop take off, watching players break your puzzles in ridiculous ways, or something else entirely?
Definitely having more audience is what I am hoping for the most, as the original Lost Ball didn’t reach as far as even the competitors I beat at the Game Awards. In any case, I’ll have plenty of time to construct my ultimate complex puzzle once the game is done, and I might even build another game with my engine.
A big thank you to Knut Ryager for taking the time to speak with us about Lost Ball.
Returning to something you made more than a decade ago must be a peculiar experience, particularly when that project already carries an award with its name on it. There would probably have been a much easier version of this story where Knut simply cleaned up the original, made it work nicely on modern PCs and called the job finished.
Instead, Lost Ball has seemingly become an opportunity to see just how much further the original idea can be pushed.
More abilities mean more interactions. More interactions mean more solutions. And giving players the same editor and scripting tools used to make the campaign means there is every possibility that, shortly after release, somebody on Steam Workshop will construct something Knut never remotely planned for.
For a game fundamentally built around experimenting with physics until something works, that feels rather appropriate.
Lost Ball is coming to Steam in 2026.
Whether the ball remains lost for very long once the community gets hold of it is another question entirely.
Want to find more Q&As with indie devs? Head over to our Interviews section.
