The Nintendo DS is getting an unusually ambitious horror experiment. A homebrew project titled Resident Evil 2: Deadly Science is working to adapt the first disc of Resident Evil 2 for the dual-screen handheld, aiming to preserve a great deal of the original game’s structure rather than simply recreating a few scenes or making a themed demake.
At its current stage, the project is very much unfinished. Its developers describe it as rough, and the list of outstanding problems matters just as much as the working features. But the early technical scope is notable: the first two cutscenes reportedly function, the fundamental survival-horror loop is in place, music and sound effects are present, and all 125 rooms on disc 1 can be accessed.
That does not mean it is a finished portable version of the PlayStation game. It means a group of developers has established a substantial foundation on hardware with radically different constraints, then exposed the work as a homebrew build for people equipped to compile and run it.
What is currently working in Resident Evil 2: Deadly Science
The project’s most encouraging milestone is that its core interactions reportedly work together. Players can pick up objects, combine items, fight zombies, and reach a game-over state when health is depleted. Those systems may sound basic in isolation, but they are the connective tissue of the original game: exploration depends on inventory management, progress depends on using the right items and keys, and combat has to coexist with limited resources and enemy behavior.
The conversion also retains the original zombie AI. In simple terms, AI here refers to the game logic controlling how enemies behave. Keeping that behavior intact is meaningful because the sensation of playing a survival-horror game is not only defined by its rooms and enemies; it also relies on how those enemies react, pursue, obstruct routes, and pressure the player inside fixed-camera spaces.
According to the project details, all 125 rooms from the first disc are present, including elements that are essential to how Resident Evil 2 is constructed:
- Pre-rendered backgrounds
- Depth masks
- Camera changes
- Collision handling
- Floors, stairs, and slopes
- Doors and their 3D opening animations
- Locks, keys, gates, and items placed in rooms
Pre-rendered backgrounds are the static or mostly static scene images used by many PlayStation-era survival-horror games. Rather than rendering every wall and corridor in real time, the game places character models and objects into a prepared image. A depth mask is part of the trick that determines when a character should appear in front of, or behind, parts of that image. Without it, a character can look as though they are walking through furniture or stepping in front of walls that ought to conceal them.
That context helps explain why converting the rooms is more involved than putting background art on a DS screen. The project needs to make camera transitions, movement boundaries, floor geometry, interactive objects, door sequences, and visual layering all cooperate. The reported inclusion of those systems suggests an effort to carry over the original game’s room-by-room design rather than build a looser reinterpretation.
Related coverage includes Resident Evil 2 Is Being Rebuilt for Nintendo DS in Ambitious Homebrew Project.
Why the Nintendo DS angle is particularly interesting
The DS is a natural conversation piece for a project like this because its two screens create the possibility of a different interface layout from the original PlayStation release. The project is specifically built with dual-screen support, though the available details do not establish exactly which information is assigned to each display or whether that arrangement will change as development continues.
There is already a separately referenced DS release with a very similar name: Resident Evil: Deadly Science, described as an enhanced version of the original PlayStation game that arrived across territories in 2006 during the series’ 10th-anniversary celebrations. This new homebrew effort concerns Resident Evil 2, and the naming overlap is easy to notice, especially given the “DS” initials.
The broader point is that this is not an official new DS launch. It is a community-made technical project and should be judged accordingly: by what it can demonstrate, how reliably it runs, and whether the developers can close the gaps still visible in the build.
The biggest limitations are not hidden
The team has not presented the current build as complete. Only the first two cutscenes are said to be operational; the other cutscenes are not yet working. There are also visual issues where players can see through walls, while music reportedly sounds wrong in some locations.
Those are material problems for a game so dependent on atmosphere. Cutscenes carry story presentation, fixed views need reliable visual occlusion to sell each location, and music is a major component of tension. A functional item system and enemy encounters make a build playable, but solving the presentation problems will be important if this is to feel like a coherent version of the game instead of an impressive proof of concept.
Storage is another obstacle. The ROM is already said to be roughly 300 MB, while the project hopes to stay below 512 MB. That is a meaningful ceiling because the build process converts source game data into DS-ready assets, and the project’s own setup notes indicate that converted data can take up roughly 420 MB before the final ROM is considered. Managing that footprint without cutting necessary data or compromising quality is likely to remain a practical development challenge.
How the project is being made
The developers are using REA, short for Reverse Engineer Anything, along with Claude Code, while human developers review the code and verify that the project works. That combination will draw attention because code-generation tools can accelerate tasks, but they do not remove the need for technical judgment. The available project description explicitly characterizes the work as involving a human team rather than an unattended automated output.
In practical terms, reverse engineering means examining how existing software and data behave so compatible tools, conversions, or implementations can be created. For this project, that work appears to include extracting and converting data from the first disc, then rebuilding the material into an NDS ROM. The conversion also has to account for unusual data types, including raw-sector files used for XA voices and movie audio.
None of that guarantees a final release or a smooth path to completion. It does, however, clarify why the present state contains both considerable progress and conspicuous breakage. Rebuilding the structure of an older console game for a distinct handheld architecture is a series of interdependent tasks, not a single visual port.
What prospective players should know
This is currently a project for technically confident users, not a plug-and-play download. Its documentation describes a build process requiring development tools, asset conversion, and a compatible disc-image input from disc 1. Windows users are directed through Ubuntu via Windows Subsystem for Linux, while macOS and Linux users need a comparable collection of development dependencies. The resulting ROM can be used with melonDS, and saving requires SD-card support through a flashcart, DSi setup, or an emulator’s virtual SD configuration.
That distinction is important: compiling a homebrew project, configuring storage, and maintaining a build after updates are different from simply launching a retail cartridge. Users should also ensure they understand and follow applicable rights and ownership requirements before handling game data or related files.
For now, the value of Resident Evil 2: Deadly Science is in the evidence of what has already been brought together: disc 1’s rooms, the original zombie behavior, key movement and interaction systems, audio, and the beginnings of cinematic playback. The next measure of success will be whether the team can fix the missing scenes, visual leaks, inconsistent audio, and size pressures without losing that foundation.
It is also another reminder that old hardware still inspires unusually focused technical work. For a separate look at how rumors and technical clues can send game communities into overdrive, see the recent HLX discussion around Valve.
