Devlog
Devlog
This is a small team building a large-shaped game in a browser. What follows is a selection of the decisions and mistakes that shaped it, kept honest, because a devlog that only records successes is an advertisement.
The constraint that decided everything
The target was sixty frames per second on a mid-range phone, in a browser, with no download. That single line settled more design arguments than any creative discussion did.
It is why the world is rings rather than sprawling zones, why the creature population is a fixed pool that gets reused rather than an ever-growing list, and why distant creatures fall into cheaper simulation instead of being deleted and re-created. Objects that would be created more than once per frame are not created at all. They are borrowed from a pool and returned.
The game also ships without a bundler. The browser is handed source modules directly. That is unusual in 2026, and it is a deliberate trade: the build stays simple and the deploy stays trivial, at the cost of having to care how many files a cold start touches.
Four abilities, one job each
Combat was redesigned around a rule rather than a wish list. Four abilities, four roles, no overlap: melee, ranged, control, area. If two buttons did a similar thing, one of them was wrong.
The version before this had more abilities and less identity. Players pressed whatever was off cooldown, which meant the fight had no shape. You were not making decisions, you were emptying a bar. Cutting back forced each ability to justify itself.
The ranged cast is the clearest case. It has no cooldown at all. What limits it is that it takes a second, costs energy, and breaks if you move, take off, or take a hit. That makes it a reward for having already controlled the fight, and it makes the slow zone and the knockback matter, because they are how you buy the stillness the cast needs.
The flight ceiling that trapped people on islands
Your altitude limit grows as you level. Originally it was an absolute height in the world, which is the obvious way to write it, and wrong.
The floating islands sit well above that limit. A player standing on one who took off was immediately yanked below the surface they had been standing on, because the ceiling did not care that they had climbed up there legitimately. The fix measures the ceiling from whatever surface you launched from, so any place you can stand is a place you can fly from.
The interesting part is what it did to the design. With the absolute cap, altitude gated access to the high islands. Without it, the gate had to become the difficulty of what lives up there, which is a better gate anyway, because skill can beat it.
Vigor, and making flight a system
Flight began as a toggle. You could fly, or you could not. It was fine, and it was boring.
Now it is charges you spend and recover, and the recovery is the design. On the ground charges refill steadily; in the air they barely refill at all, unless you are diving fast enough, at which point they pour back. Flying well means giving up height for speed and getting it back, in a rhythm. The recovery curve is deliberately quadratic in level, so the mid-game still manages its tank while only the cap becomes carefree. A linear curve was either fiddly forever or trivial immediately, with no setting that was interesting at both ends. The whole system now has its own page.
Later the bird itself was taught to fly properly, nosing to match your aim and rolling into turns in proportion to how fast your heading changes. Before that, a diving bird was a level model sliding downwards. Neither change was noticeable on its own. Together they are the difference between piloting something and dragging it.
The recolour that could not be a tint
Letting players recolour the bird looked like a small job. Multiply a colour into the material, done.
It was measured, and it did not work. A tint cannot repaint a texture: dark plumage stayed dark, detail muddied, and the shading that makes feathers read as feathers washed out. The finding is kept in the design notes rather than deleted, because it is the reason the real system exists.
What shipped instead identifies which parts of the model belong to which recolour zone and recomputes the shading, so brightness and depth survive a colour change. It cost far more than a tint, and it is why a recoloured bird still looks like a bird. One deliberate exception stands: models whose painted art would be spoiled by recolouring, such as the Phoenix, keep their fixed look rather than being supported badly.
The phones that broke it
Mobile browsers are where a WebGL game finds out what it actually is.
A foldable booted to a white screen, not a crash but a white screen, because the burst of graphics work at startup exceeded what the device would grant in one go. A phone put to sleep and woken came back with a rendering context that claimed to be fine while being entirely unusable, so the recovery code never fired. An older iPhone choked on the boot sequence for a third reason entirely.
Each took real investigation, and each fix is structural rather than a device check: a startup paced to what the graphics driver will actually grant, and a watchdog that verifies the context genuinely works instead of trusting it to say so. There is no list of phone models in the code. A quality scaler measures the machine in front of it and adjusts, which is also how it handles the phone that has not been released yet.
A queue for a small world
Worlds are capped at about ten players during development, and the honest version of "the world is full" is a queue, so we built the Classic one: your position on screen, first in first served, automatic entry when a spot frees.
The pleasant surprise was how much engineering the queue did not need. A player's presence in the world evaporates the moment their connection does, so a crashed client frees its spot with no cleanup job, no heartbeat and no stuck slots. The queue simply advances. The cap itself is a live-tunable setting, so when the worlds grow, nobody has to reinstall anything to queue less.
Naming, and moving house
The game was called Paulie's Adventure for most of its life. In 2026 it became Paulie Paulie and moved to this domain.
The trigger was mundane. The game had been living as a subdirectory and a subdomain of the consultancy site that built it, and that arrangement structurally could not support what the project needed next. Once the move was necessary the naming question came with it, and the doubled name won because it is what the bird's family actually calls him. The bird himself, and the lost afternoon that started all of this, are on the home page.
Moving a live game between origins is more delicate than it sounds. Sign-in, the human-verification check and the backend services are all bound to the address the game is served from, and each fails closed, so nothing breaks visibly at build time and everything breaks at once for real players. Cutting over meant enumerating every one of those bindings in advance. Some were found anyway.
The avatar that is also a website
The bird at the top of this site's home page is not a picture, and not a copy. It is the game's bird: the same component, loaded from the game's own servers, running the same model, animations and voice clips.
That means the site cannot drift from the game, because a change to the model appears here automatically. It also means the site degrades honestly. If the game's servers are unreachable the hero falls back to a still image rather than an empty box, which incidentally makes this website a rather good uptime monitor.
It launched
Paulie Paulie went live in the browser on 24 August 2026, at play.pauliepaulie.com. The shop and Google sign-in switched on the day before. Nothing was announced until both had been used for real. One live purchase, then one live refund, with the item granted and then taken back in the database, not just on a receipt.
That order was deliberate. A shop that has never refunded anything is a shop that has never been tested. The whole loop took 192 seconds and both halves were read back from the live database rather than trusted from the payment page.
There are no ads in the game. That's still the plan, but the plan waits on an approval that isn't ours to grant, so the launch didn't wait for it.
Measuring the phones instead of guessing
The game now carries a debug screen you can open on any phone, no cable and no laptop. It prints the frame rate, the physics cost and the quality tier, and one tap exports the whole log. Every performance change since launch has been argued from those exports.
They were humbling. The quality scaler, the part that lowers detail to hold sixty frames a second, was hurting the phones it was meant to help.
It read a battery-saver cap as a failing device and walked one phone to minimum quality for the rest of the session. It read a single long frame as a total collapse. It read a burst of new creatures as the phone overheating, and pinned it there for a minute.
Each one was a measurement lying, not the hardware failing. Each is fixed by checking the measurement, not by adding a list of phone models. One handset went from spending 59 percent of a session at minimum quality to 27 percent, on the same route.
Flying was fine. Arriving wasn't.
The clearest export came from a new foldable. Walking, it climbed to the top quality tier. Flying the same world, it sat at the bottom one. Between the drops it was flying at 63 to 85 frames a second, so flight itself wasn't the cost.
The cost was what flight triggers. Fly fast and the world ahead has to be filled before you get there, so up to 200 creatures spawn in a couple of seconds.
Every one of those was rebuilding its animation setup from scratch. The scaler read the resulting stutter as the phone giving up and dropped a tier. That did nothing, because resolution wasn't the problem.
The tempting fix was to cap flight speed. We didn't. Flight is the point of the game, and the numbers didn't blame it.
Three things changed instead. A creature keeps its animation setup when it leaves the world and comes back, so 200 spawns went from 46 milliseconds to 10. The spawner gets a time budget per frame that shrinks as quality drops. And a spawn burst now delays a quality drop instead of causing one.
The next export from that phone reached the top tier while flying and never touched the bottom one.
The hour the game froze
That fix shipped with a bug. The new spawn loop was written to keep going until it had placed at least one creature. When every placement in a frame failed, it kept going forever. The game froze mid-flight with the music still playing.
The tests that approved it had only ever checked the case where spawning succeeds. The fix took an hour, and the loop now gives up after a fixed number of attempts whether or not they worked. The test that would have caught it, one where every attempt fails, now runs before anything like it can ship again. A test that only checks the happy path isn't a test of the exit.
What is next
Built and landing next: at the lower quality tiers, only the nearest creatures are drawn. Everything still exists, moves and can attack you.
Bosses, anything fighting you and anything close by are always drawn. The rest simply wait until you're nearer. Drawing two hundred animated creatures at once is what a phone can't do, and lowering the resolution never helped with that.
After that, the order hasn't changed. Android and iOS follow, sharing the same codebase rather than being separate builds. The platform-specific parts sit behind a thin layer instead of being forked through the game logic. A desktop release follows those.
There is no roadmap page promising dates. The bird is real and the world runs at sixty frames a second on a phone. The rest gets built in the order it makes sense to build it.