Project: DOOM 1993 — Browser Game with Security Audit (made by IMD Swarm)

Build a fully functional website where users can play the original DOOM 1993 engine directly in their browsers using WebAssembly. Use existing open-source code rather than recreating the game from scratch.

1. Source Code Research

Analyze these GitHub repositories:

• https://github.com/id-Software/DOOM
• https://github.com/theMagicalKarp/wasmdoom
• https://github.com/cloudflare/doom-wasm
• https://github.com/freedoom/freedoom

Select the safest and most reliable implementation. Verify repository authenticity, licenses, dependencies, maintenance history, and known vulnerabilities.

2. Mandatory Source Code Security Audit

Before using any third-party code, thoroughly audit it for malware, backdoors, spyware, cryptocurrency miners, malicious scripts, hidden network requests, data exfiltration, suspicious dependencies, and security vulnerabilities.

Check for XSS, remote code execution, memory corruption, buffer overflows, unsafe file processing, and WebAssembly vulnerabilities. Review JavaScript, C/C++, WASM integration, dependencies, and build scripts. Avoid unverified precompiled binaries and execute no untrusted scripts before inspection.

Use available security tools such as CodeQL, Semgrep, OSV-Scanner, and dependency scanners. Document actual findings and fix confirmed serious vulnerabilities.

3. Website Development

Create a modern, responsive website with authentic DOOM gameplay, a dark retro interface, red accents, pixel-style fonts, and a large game viewport.

Implement movement, shooting, enemies, weapons, audio, fullscreen mode, keyboard/mouse controls, and game restart. Add mobile controls if feasible.

Use Freedoom Phase 1 as the default freely redistributable game assets. Allow users to load their own legally obtained DOOM.WAD or DOOM2.WAD locally in the browser. Never upload WAD files to external servers or redistribute proprietary assets without permission.

4. Final Code Security Audit

After development, conduct a second, independent security audit of all generated code, including HTML, CSS, JavaScript, WebAssembly, dependencies, build configurations, and deployment files.

Verify that the website contains no malicious functionality, unauthorized tracking, data leaks, dangerous permissions, insecure file handling, or unexpected network connections.

Validate uploaded WAD files, enforce file size limits, protect against malformed inputs, and implement appropriate browser security policies. Fix Critical and High vulnerabilities before deployment. Prefer a separate security agent that did not write the code.

5. Testing and Deployment

Test the actual game in Chrome and Firefox, including loading, movement, shooting, enemies, sound, fullscreen, level transitions, and valid/invalid WAD files. Check browser compatibility, performance, and unexpected network requests.

Prepare a production-ready static website suitable for GitHub Pages, Cloudflare Pages, or IPFS. Do not deploy before completing the final security review.

6. Deliverables

Provide the complete working website, source code, build instructions, and three reports: SECURITY_AUDIT.md, TEST_REPORT.md, and LICENSE_REPORT.md. Include audited repository commit hashes, vulnerabilities found, fixes applied, tests actually performed, and remaining risks.

Critical requirements: Use a real DOOM engine, not simulated gameplay. Never claim tests or audits were completed without executing them. Do not invent security results. Prioritize security, functionality, and legal compliance over appearance. The final product must be playable, tested, and ready for safe deployment, with any remaining security limitations clearly documented.

7. Modding and Custom Asset Support

Design the game with a modular asset system to support future customization without modifying core engine code. Allow replacing enemy sprites, animations, weapons, textures, sounds, and maps through custom resource packs (PWAD).

Prepare an extensible mod manager with options to upload, enable, disable, and switch between compatible asset packs. Support custom enemy appearances while preserving original game behavior. Validate and securely process all uploaded assets locally in the browser.

Keep the architecture flexible for future modding features, including a visual asset editor and custom enemy configurations. Document supported formats, compatibility limitations, and how to create new asset packs.