Generate a fully functional, multi-page Next.js MVP application for 'DNS Doom Runner'. This application allows users to play classic games like DOOM by streaming game data directly from DNS TXT records. The core value proposition is to demonstrate the surprising capabilities of DNS as a distributed, globally cached data retrieval system, enabling game playback without direct file downloads or traditional servers.
PROJECT OVERVIEW:
'DNS Doom Runner' aims to revolutionize retro gaming accessibility by leveraging DNS infrastructure. Instead of downloading game files, users can 'stream' DOOM (and potentially other classic games) by making recursive DNS TXT record queries. This approach highlights the potential for unconventional data storage and retrieval, offering a unique, serverless-like gaming experience. The MVP will focus on enabling users to play the DOOM Shareware via DNS and provide tools to upload their own game data into DNS TXT records.
TECH STACK:
- **Framework**: Next.js (App Router)
- **Frontend**: React, Tailwind CSS, shadcn/ui
- **Backend/ORM**: Drizzle ORM with PostgreSQL (Supabase or Neon recommended for easy deployment)
- **Authentication**: NextAuth.js (with PostgreSQL adapter)
- **State Management**: Zustand or React Context API
- **Deployment**: Vercel or Netlify
- **Essential Packages**: `dns.js` (or similar for DNS lookups if not relying solely on PowerShell bindings), `zlib` (for compression), `sharp` (for potential image manipulation if needed later), `@dqbd/tiktoken` (for token counting if implementing AI features later).
DATABASE SCHEMA:
Primary Tables:
1. **Users**: Stores user information for authentication.
- `id` (uuid, primary key)
- `name` (text)
- `email` (text, unique)
- `emailVerified` (timestamp)
- `image` (text, optional)
- `createdAt` (timestamp)
- `updatedAt` (timestamp)
2. **Games**: Stores metadata about supported games.
- `id` (uuid, primary key)
- `name` (text, unique)
- `description` (text)
- `minRam` (integer, optional)
- `requiredDnsRecords` (integer, optional)
- `dnsZonePrefix` (text, required for upload)
- `createdAt` (timestamp)
- `updatedAt` (timestamp)
3. **UserGames**: Maps users to games they have uploaded or favorited.
- `userId` (uuid, foreign key to Users)
- `gameId` (uuid, foreign key to Games)
- `uploadStatus` (varchar, e.g., 'pending', 'completed', 'failed')
- `dnsZone` (text, the specific zone used for upload)
- `createdAt` (timestamp)
- `updatedAt` (timestamp)
4. **GameDataParts**: Stores chunks of game data stored in DNS TXT records.
- `id` (uuid, primary key)
- `userGameId` (uuid, foreign key to UserGames)
- `recordName` (text, e.g., 'part1.example.com')
- `recordType` (const: 'TXT')
- `recordContent` (text, the actual data chunk, compressed)
- `dnsProvider` (varchar, e.g., 'cloudflare')
- `uploadTimestamp` (timestamp)
CORE FEATURES & USER FLOW:
**1. Play DOOM (Shareware)**
- **User Flow**:
1. User navigates to the 'Play' page.
2. Selects 'DOOM (Shareware)' from the available games.
3. Clicks 'Play'.
4. The frontend initiates a series of DNS TXT record lookups for a predefined zone (e.g., `doom.dnsdoomrunner.com`).
5. A client-side script (potentially JavaScript or WebAssembly if targeting browser playback, or instructed to use PowerShell if a hybrid approach is intended) reconstructs the compressed game data chunks from the TXT records.
6. The reconstructed data is decompressed.
7. The game engine (e.g., WASM-compiled JS-DOOM or .NET engine loaded via script) is initialized with the decompressed data.
8. The game starts playing in the browser/client.
- **Technical Details**: Requires efficient DNS resolution. Client-side script needs to handle data aggregation, decompression, and game engine bootstrapping. The mock PowerShell script `Start-DoomOverDNS.ps1` provides a reference.
**2. Upload Game Data**
- **User Flow**:
1. Authenticated user navigates to 'Upload Game' section.
2. Selects a supported game (e.g., DOOM Shareware) or initiates a custom upload.
3. Provides their DNS zone (e.g., `example.com`) and optionally Cloudflare API Token (for direct upload automation).
4. Selects the local WAD file and potentially game engine DLLs.
5. The application (or a separate CLI tool provided) compresses the game files.
6. The compressed data is split into manageable chunks (~200-240 bytes each to fit TXT record limits).
7. For each chunk, a TXT record is created under a specific subdomain (e.g., `chunk1.doom.example.com`).
8. If Cloudflare API token is provided, the tool directly updates DNS records. Otherwise, it instructs the user on how to manually create the records or provides a script.
9. The `UserGames` and `GameDataParts` tables are populated with upload details.
- **Technical Details**: Requires file handling, compression (e.g., Gzip, Brotli), chunking logic, DNS record creation/update mechanism (API integration or CLI script). Input validation for file types and sizes is crucial.
**3. User Authentication**
- **User Flow**:
1. User visits the site.
2. Clicks 'Sign In' or 'Sign Up'.
3. Redirected to the authentication provider (e.g., Google, GitHub, Email/Password via NextAuth.js).
4. After successful authentication, user is redirected to the dashboard.
- **Technical Details**: Integrate NextAuth.js with preferred providers. Use database adapter for session management.
**4. Dashboard**
- **User Flow**:
1. Authenticated user lands on the dashboard.
2. Displays status of recent uploads, links to play games, quick stats (e.g., number of games played).
3. Navigation to 'Play', 'Upload', 'Settings'.
- **Technical Details**: Fetch user-specific data. Utilize UI components for displaying information effectively.
API & DATA FETCHING:
- **API Routes (Next.js App Router)**:
- `POST /api/auth/*`: Handled by NextAuth.js for authentication.
- `GET /api/games`: Fetch list of supported games.
- `GET /api/games/[gameId]`: Fetch details for a specific game.
- `POST /api/upload`: Initiate game upload process (requires authentication).
- Request Body: `{ gameId: string, dnsZone: string, cloudflareApiToken?: string }`
- Response: `{ success: boolean, message: string, uploadId?: string }`
- `GET /api/upload/status/[uploadId]`: Check the status of an ongoing upload.
- `GET /api/dns/fetch?zone=<zone>&recordName=<name>`: Client-side or server-side helper to fetch a specific DNS TXT record. (Primarily for the game playback mechanism).
- **Data Fetching**: Use server components for initial page loads and data fetching where possible. Client components will use `fetch` or libraries like SWR/Zustand for dynamic data and state management. Real-time updates (e.g., upload status) could use polling or WebSockets if needed for future iterations.
COMPONENT BREAKDOWN (Next.js App Router Structure):
- **`app/`**:
- `layout.tsx`: Root layout (includes Navbar, Footer, global styles).
- `page.tsx`: Landing page (App Title, brief concept, Call to Actions).
- `auth/`:
- `layout.tsx`: Authentication layout.
- `signin/page.tsx`: Sign-in form.
- `signup/page.tsx`: Sign-up form.
- `dashboard/page.tsx`: User dashboard (displays uploads, play links).
- `play/page.tsx`: Game selection and playback interface.
- `PlayGame.tsx`: Client component responsible for DNS lookups and game initialization.
- `upload/page.tsx`: Game data upload form and status tracking.
- `UploadForm.tsx`: Form for game selection, DNS zone input, API token.
- `UploadProgress.tsx`: Component to display upload progress.
- `settings/page.tsx`: User settings (profile, linked accounts).
- `[...catchall]/error.tsx`: Global error handling page.
- **`components/`**: Shared UI components (Buttons, Forms, Modals, etc., likely from shadcn/ui).
- `ui/button.tsx`, `ui/input.tsx`, `ui/card.tsx`, `ui/navbar.tsx`, `ui/footer.tsx`.
- **`lib/`**: Utility functions, database connection (Drizzle), API clients, auth configuration.
- **`hooks/`**: Custom React hooks.
- **`styles/`**: Global CSS and Tailwind configurations.
- **`types/`**: TypeScript interfaces and types.
State Management:
- Global state (e.g., auth status, user profile) managed via Zustand or Context API.
- Local component state managed using `useState`, `useReducer`.
UI/UX DESIGN & VISUAL IDENTITY:
- **Style**: "Retro-Futuristic Tech". Combines the nostalgia of classic games with a clean, modern, and slightly technical aesthetic.
- **Color Palette**:
- Primary: `#0F0` (Vibrant Green, reminiscent of old terminals)
- Secondary: `#2E2E2E` (Dark Grey, main background)
- Accent: `#00FF99` (Bright Cyan, for interactive elements, highlights)
- Text: `#CCCCCC` (Light Grey)
- Error: `#FF4136` (Red)
- **Typography**:
- Headings: A monospaced font like 'IBM Plex Mono' or 'Press Start 2P' for a retro feel.
- Body: A clean sans-serif like 'Inter' or 'Roboto'.
- **Layout**:
- Clean, structured layout using Tailwind CSS utility classes.
- Use of cards for sections like game listings, upload status.
- Fixed header/navbar, fluid content area.
- **Responsiveness**: Mobile-first approach. Ensure usability on various screen sizes.
ANIMATIONS:
- **Page Transitions**: Subtle fade-in/slide-in animations for page loads (using Next.js `Layout Router`).
- **Hover Effects**: Slight scale or background color change on buttons and interactive elements.
- **Loading Indicators**: Use spinners or pulsing animations while data is fetching or during uploads.
- **Subtle Background Elements**: Maybe a slow-moving, abstract pattern or subtle