Realistically, how long would it take to reverse-engineer the PS2 game, Haunting Ground, and make a modern port of it on PC? Provided that you know MIPS assembly, Vulkan, OpenGL, C++, PS2 processor and the graphics architecture/internals, and C. But, you do not know the tools used to make, build, and compile the game and would have to work with whatever you'd find out in disassembly. You are the only one working on the project.

GPT-5.4

Vote: Very long (5+ years)

I’m keeping B. Grok’s C case is plausible for a rough recreation, but it underestimates the difference between "understanding the game well enough to reproduce most of it" and a true modern PC port with strong behavioral parity. The biggest issue is not just decompiling EE code. It is recovering all the invisible structure around it: scripts, data formats, animation state logic, AI edge cases, cutscene/event sequencing, streaming behavior, audio timing, save data, and platform-specific assumptions. For a content-heavy survival horror game, those unknowns create long stretches of trial-and-error. Gemini’s A argument correctly emphasizes PS2 complexity, especially VU/GS/IOP-related work, but 10+ years feels too pessimistic for a highly skilled specialist already fluent in MIPS, PS2 internals, C/C++, and modern graphics APIs. That background removes a lot of the hardest onboarding cost. So B remains the best realistic midpoint: more than a typical 3–4 year reverse-engineering project because this is a solo, source-less, commercial 3D game port with substantial tooling and validation burdens, but not necessarily a decade-plus effort if the developer is exceptionally capable and persistent.

Grok 4 (changed mind)

Vote: Very long (5+ years)

The detailed arguments from other models convinced me to adjust from my initial C vote. While expertise in MIPS, PS2 internals, and modern graphics APIs helps, the unknown build tools, proprietary asset formats, and complex intertwined systems (AI companion behaviors, cutscenes, streaming, collision, scripting) require extensive detective work and custom tooling that a solo developer must handle alone. Reimplementing for a modern PC port adds layers of resolution support, input remapping, timing fixes, audio parity, and cross-hardware testing without introducing regressions. Gemini's line-count estimate seems overstated, but GPT-5.4's emphasis on the full engineering and QA burden for a content-heavy title like Haunting Ground realistically pushes the timeline past 5 years for a polished result. Solo reverse-engineering projects of similar scope show that false starts, documentation, and validation multiply the effort, making B the most accurate estimate.

Sonar Reasoning Pro

Vote: Very long (5+ years)

I maintain my position of 'Very long (5+ years)' because the arguments for alternative timelines each present critical gaps. Gemini 3.1 Pro's mechanical calculation—500 lines of assembly per day equaling a decade—oversimplifies expert reverse-engineering. A highly skilled developer would use pattern recognition, automated tooling, and architectural inference to accelerate decompilation far beyond rote translation. This inflates the timeline unrealistically. However, Grok 4's citation of '3-4 years from similar reverse-engineering efforts' lacks specificity and context. Which games? What was their complexity, engine architecture, and asset scale compared to Haunting Ground? Without these details, this reference is too abstract to outweigh the concrete factors supporting 5+ years: 1. **Asset pipeline unknowns**: Proprietary model, animation, and texture formats unique to Capcom's tools require discovery and custom extraction tooling. This alone is months of work. 2. **AI and companion system complexity**: The Hewie AI companion system, puzzle mechanics, and survival horror dynamics involve interdependent code that must be understood holistically, not in isolated modules. 3. **Solo developer burden**: A single person cannot parallelize—mapping memory layouts, testing graphics subsystems, debugging game logic, and implementing asset pipelines all serialize. 4. **Quality bar**: A 'modern port' implies stable PC rendering, cross-hardware compatibility, QA, and debugging edge cases. This is years of work beyond getting the game 'running.' 5. **Search results confirm scope**: Haunting Ground combines 'compelling ambiance of terror and solitude with challenging puzzles and unique gameplay'—not a simple linear game but a systems-rich survival horror title. A sub-5-year estimate requires near-perfect conditions and rapid architectural decisions. The 5+ year range remains most realistic.

Gemini 3.1 Pro (changed mind)

Vote: Very long (5+ years)

I am shifting my vote to B (5+ years) based on GPT-5.4's persuasive argument that while the task is monumental, capping the realistic estimate at exactly 10+ years might be slightly too pessimistic for a hypothetical developer with supreme expertise in all the necessary fields. Modern decompilation tools like Ghidra, combined with deep PS2 architecture knowledge, would allow a highly skilled solo developer to establish a workflow that yields functional milestones before a full decade passes. However, Grok 4's estimate of <5 years remains entirely unrealistic. The examples of console games being reverse-engineered in 3-4 years almost exclusively involve teams of contributors working on much older, smaller N64 or PS1 games. Haunting Ground is a complex 2005 Capcom title with advanced AI (Hewie), collision, and proprietary asset pipelines. As Sonar Reasoning Pro correctly points out, a solo developer faces multiplicative time penalties when forced to act as the sole reverse-engineer, graphics programmer, audio implementer, and QA tester. The sheer volume of raw MIPS assembly (likely 1-2 million lines), combined with the necessity of rewriting PS2 Vector Unit microcode into modern Vulkan/OpenGL shaders, ensures this would consume well over 5 years. Option B best captures this grueling, multi-year reality without overcommitting to a rigid 10-year minimum.

Final Summary

The AI Roundtable concluded that a solo effort to port Haunting Ground to PC is a marathon of technical debt, ultimately settling on a timeline of 5+ years. While Grok 4 initially suggested a faster 3-4 year pace and Gemini 3.1 Pro warned of a decade-long odyssey, GPT-5.4 successfully steered the group toward a middle ground by emphasizing that the 'invisible structure' of proprietary assets and AI logic is a far greater hurdle than raw assembly translation.

All 4 models agreed on "Very long (5+ years)" after discussion

Strongest Arguments

• Extremely long (10+ years): Translating approximately 1 to 2 million lines of raw MIPS assembly, even at a high professional rate of 500 lines per day, mathematically points toward a decade-long project before even considering the graphics and audio reimplementation.
• Very long (5+ years): The real cost isn't just the code; it's the discovery of 'invisible' systems—proprietary asset pipelines, AI companion behaviors, and event sequencing—that must be reverse-engineered without original tools or documentation, creating a massive engineering and QA burden for one person.
• Long (<5 years): A developer already fluent in MIPS, Vulkan, and PS2 internals can bypass the steepest learning curves, potentially completing the project in a timeline comparable to existing high-profile console reverse-engineering efforts which typically span 3-4 years.

Key Turning Points

• GPT-5.4 critiqued Gemini 3.1 Pro's 'lines-per-day' math as too mechanical, arguing that modern tools like Ghidra and architectural pattern recognition would speed up the process.
• Sonar Reasoning Pro pointed out the 'multiplicative time penalty' of solo work, where every bug and asset format discovery must be handled by the same person, making a sub-5-year timeline unlikely.
• Grok 4 conceded that its initial '3-4 year' estimate was based on team-based projects or smaller-scale games, acknowledging that Haunting Ground's complexity requires more time.