It has been a while. Quite a while, in fact. The last time I wrote properly about my Paradroid remake, it was running in GameMaker, the doors had finally learned not to close on passing droids, and I was still discovering just how many apparently simple things Andrew Braybrook had hidden inside the original game.
The project never entirely went away. The artwork, deck layouts, droid data and a considerable amount of slightly questionable code remained safely stored away. Recently, I decided it was time to return to the Dreadnought—this time rebuilding the game natively for Apple platforms while treating the old GameMaker project as an archaeological record that absolutely must not be “helpfully” rewritten.
[Add image: the earlier GameMaker version beside the current native build]
Starting again without throwing everything away
“Rebuilding” sounds cleaner than it really is. This is not a case of opening the old project, pressing a conversion button and waiting for a shiny new version to appear. The GameMaker project contains years of accumulated knowledge: deck maps, tiles, droid statistics, animations and dozens of small decisions made while studying the original. Some of it is elegant. Some of it only makes sense after staring at it for a while. All of it is useful.
The new version is being written natively in Swift, using SpriteKit for the game world. The aim is not to redesign Paradroid into something unrecognisable. I want it to feel like Paradroid, but to take advantage of modern Apple hardware, smooth movement, proper controller support and a presentation that can scale cleanly across macOS and iOS.
The old project therefore stays read-only while I work. It is a reference library and a record of what I previously discovered, not a sacrificial source tree. That distinction has already saved me more than once.
Reconstructing the Dreadnought
The deck layouts came across surprisingly well, although “surprisingly well” should not be confused with “without problems”. Converting the tile data is the easy part. Understanding what every tile means is where the real work begins.
Paradroid’s decks are not simply floors and walls. Certain tiles describe routes that the droids are expected to follow. Straight sections, crossings and curved junctions all have meaning. Early versions technically followed these paths, but the droids moved as if they were tracing a spreadsheet. They reached a tile, turned sharply and carried on. It worked, but it did not look remotely alive.
The current system moves from tile centre to tile centre, uses proper curved movement at corners and has a fallback for traffic jams and blocked routes. Droids can reverse when necessary instead of sitting forever in a metallic queue. This still needs refinement, but it now feels like movement through a ship rather than counters being shuffled around a board.
[Add image or short video: path tiles, debug overlay and a droid taking a curved junction]
Doors: a small feature that never is
Doors deserve their own mention because they are a perfect example of this project. A door should open when a droid approaches, remain open while something is passing through and close afterwards. Simple.
Except the droid may be moving quickly, approaching from either side, fighting, being pushed, or following another droid. The door must not close through a sprite, trap an AI unit, or rapidly change its mind every frame. The working version now gives AI and player-controlled droids the same reliable passage and includes enough space around the doorway to avoid most embarrassing accidents.
I have learned to be suspicious of any task described as “just make the door open”.
Teaching the droids to notice you
The enemy droids now have separate ideas of visibility, detection and response. Those things sound similar, but keeping them separate makes the behaviour much easier to understand and tune.
A droid can have a sensor range without necessarily having a clear shot. Walls block line of sight. Once alerted, an armed droid can pursue and attack using the same underlying weapon hardware as a player-controlled version. The damage values are deliberately separate, however. The first implementation allowed enemy weapons to use full player damage and the result was a series of one-shot deaths. Accurate, perhaps, but not especially entertaining.
Enemy-fired weapons currently cause 25 percent of their normal damage. Projectile speed, animation and cooldown remain the same, so the weapon still feels correct while the balance can be adjusted independently. These numbers are provisional; the important part is that the system now has a sensible place to tune them.
[Add image: sensor circles and line-of-sight rays during testing]
Get help!
Not every droid should stand and fight. The 302 and 329 Messenger droids now have a provisional GetHelp behaviour. When they detect the player they try to reach the nearest armed droid. If no help is available, they continue to escape rather than suddenly becoming brave.
The choice is partly thematic and partly practical. Messengers are a natural fit for reporting trouble, and the two models give me a fast and a slow example to test. The 302 has a real chance of reaching assistance; the 329 remains catchable. If further research reveals the original behaviour, the assignments can change without rewriting the system.
This is the sort of detail I love about Paradroid. A small difference in behaviour immediately gives a droid a purpose beyond its number and weapon.
The transfer game
The transfer sequence is one of Paradroid’s defining ideas, and also one of the easiest things to get almost right.
My first pass had the broad shape of the game but not its character. The original is not a generic grid of symbols. It is a continuous illustrated circuit, with rails, splitters, joiners, generators, changers and pulses travelling towards the centre. Fortunately, the original artwork and tile definitions from my earlier project were still available. Using those directly produced a much stronger foundation than approximating the pieces again.
The centre timer also matters. During side selection it fills upward, giving the player time to choose, then reverses and drains during the contest. That change sounds cosmetic until it is missing; without it, the whole sequence feels oddly flat. The current transfer game has the selection phase, the two droid banks, animated pulses and the central struggle, but circuit generation and some of the more unusual component behaviour still need further study.
[Add images: empty transfer grid, centre timer half-full, and a completed circuit]
Tactical Flight
Losing a host droid should not always mean an immediate, unavoidable end. When a captured host is destroyed, the player now falls back into a damaged 001 Influence Device and enters a four-second state I have called Tactical Flight.
For those four seconds the 001 is protected, shown in blue and the HUD displays a countdown. Alerted enemies disengage and return towards their routes, giving the player a brief chance to run for a lift or attempt a desperate transfer into a low-level droid. Opening a lift, terminal or transfer screen pauses the countdown so interface time does not consume the escape window.
When the timer expires, the 001 remains alive but vulnerable and in poor condition. It creates a proper last-chance moment without turning failure into an automatic cut-scene.
[Add video: host destroyed, blue 001 and the Tactical Flight countdown]
Terminals, lifts and the ship around the game
The information terminals now share a more coherent visual language with the lifts. Droid records, game statistics and the ship plan appear as parts of the same Dreadnought computer system rather than unrelated menus.
The ship plan distinguishes the active deck, uncleared decks and cleared decks. Terminal and lift interaction areas are directional and deliberately small, so a screen opens when the player is actually beside the correct face of the unit rather than somewhere vaguely nearby. This occupied far more time than the sentence suggests. At one point every horizontal terminal worked perfectly while the vertical ones were half a tile out. Then they were half a tile out in the other direction.
Controller prompts adapt to Xbox, PlayStation and generic controllers, while keyboard instructions remain available on macOS. Music and sound preferences persist between sessions, and the interface pauses the correct pieces of game state rather than allowing combat or cooldowns to continue invisibly behind a menu.
Working with AI without handing over the game
It would be easy to describe this as “AI made the game”, but that is not what the process has been.
I provide the knowledge of the original, the references, the behaviour I remember and a fairly constant stream of testing corrections. The AI helps inspect several generations of project code, turn those observations into systems, and document why the decisions were made. The useful part is not accepting the first answer. It is being able to say, “that turn is half a tile too early”, “the timer moves in the other direction”, or simply, “it works, but it looks wrong”, then trace the cause quickly.
That collaboration has also made good comments more important. The code now records not only what a system does, but why choices such as GetHelp assignments, sensor distances and enemy damage scaling are provisional. I want to be able to return after another long gap and understand the reasoning instead of repeating the archaeology from the beginning.
Where it stands now
The native game can load and render the Dreadnought decks, move the player and path-following droids, operate doors and lifts, enter terminals, fight, transfer control and track cleared decks. The presentation is beginning to feel like one connected system rather than a collection of experiments.
There is still plenty to do. The transfer circuits need closer comparison with the original. Tactical AI needs more testing. Weapon balance will certainly change. Terminals and HUD elements will continue to be polished, and every new deck will probably uncover another assumption that seemed perfectly reasonable until a droid drove into it.
But the Dreadnought is alive again, this time as a native Apple game, and that feels like a very good place to continue from.