Half-Life hits 30 FPS on a 2007 Nokia N95, with mouse and keyboard working

The original Half-Life is now running at about 30 FPS on a 2007 Nokia N95, and it is not just touch controls. Developer Dante D. Leoncini shared updates on X saying that, after trial and error, the game finally runs on their Nokia N95 at a “respectable 30 fps,” and that mouse and keyboard support is working. They add that there is still some slowdown, but they have already identified the cause and are working on a fix.

Just as important for anyone imagining this as a tech flex instead of a usable port: Leoncini says the mouse and keyboard work because the Nokia N95 has Bluetooth support. The N95 uses Bluetooth 2.0, which one can assume adds some latency, and the testing videos appear to show it. Even with that constraint, getting a first-person shooter’s input loop to function at all on a phone from the late 2000s is still an absurd sentence to read. But Leoncini does not stop at “it launches.” They also announced performance and graphical tweaks after those initial results, plus the ability to create dedicated servers and use the game’s weapons.

To understand why this matters beyond the novelty, it helps to remember what the platform is. The Nokia N95 launched in 2007 with a 332 MHz ARM11-based dual CPU. Memory also varied by model: the standard N95 had 64 MB of memory, while an 8 GB model came with 128 MB. If you are thinking “that sounds nowhere near enough,” you are right in the classic PC era sense. You are missing a dedicated graphics card. The point is that Half-Life was designed for a PC pipeline, so bringing it to a Symbian S60v2 phone requires rethinking how the engine renders, how input events are mapped, and how the game loop survives the hardware limits.

Leoncini’s project is specifically designed for Symbian S60v2, the smartphone software platform that supported Nokia phones in the 2000s. The mechanics are also unusually practical for something like this: users have to move the original game files to a specific folder, install the engine (which can be downloaded on Leoncini’s website), and run it. From there, they can access a control list that even supports playing purely via the phone’s own keyboard. That detail matters. It tells you this is not locked behind some custom accessory. The port is built around the constraints of what was actually in the device, not around an idealized hardware setup.

On the multiplayer side, Leoncini also points to what they are working toward next. They say they are working on a LAN or network play function, which could let you fill a room with Nokia N95 phones and play Half-Life with friends in the future. If the port reaches that milestone, the experience shifts from “single-player replay on a phone” into something closer to a retro network experiment. And because the source notes Bluetooth latency, the LAN angle is not just a fun idea. It is a direct way to reduce the performance and responsiveness compromises that Bluetooth can introduce, especially for twitch-heavy controls.

Meanwhile, Leoncini also frames an important reality: they have not yet tested if the entire game works. Their website says the “game runs reasonably well,” but they describe ongoing testing. They are also looking to improve performance, improve single-player AI, and polish graphical details. That list is the real product roadmap, not the headline number. For executives and operators, the second-order lesson is that ports like this usually succeed in layers. First comes basic compatibility at acceptable frame rate. Then comes correctness, content coverage, and system polish. And the final layer is often multiplayer synchronization and smooth input, which is where latency and edge cases tend to show up.

Why should decision-makers care if you are not building a phone game port? Because this is a clean case study in execution on constrained platforms. The hardware is old, the OS is niche, and the engine needs to survive limits that modern developers can barely imagine when “performance” means shader settings, not memory ceilings. Yet Leoncini is identifying slowdown causes, planning fixes, and enumerating the steps required for installation and controls. In boardrooms and product meetings, the temptation is to treat “platform” as destiny. This story argues for the opposite: technical outcomes follow the rigor of what you build and iterate, not the presumed status of the target device.

It also lands with cultural weight. Half-Life is one of the most important shooters of all time, and revisiting it is part of why these experiments travel. Leoncini’s work turns that cultural familiarity into a hardware archaeology project. If multiplayer LAN support arrives, it could even recreate a version of the classic PC era where people carried computers (or in this case, phones) into a room and played together. The stakes for peers are straightforward: if someone can make the N95 behave like a viable Half-Life target, the floor for “what counts as playable” on legacy devices moves again. And once that line shifts, competitors, platform holders, and indie builders all start asking a more uncomfortable question: what else is sitting in old codebases, waiting for someone to port it with enough discipline to make it real?