The Problem

Ticket buyers need confidence that a seat offers the view they expect, but most online ticketing sites show only static seat maps or low‑resolution images. Without an interactive preview, shoppers risk purchasing seats with obstructed sightlines, leading to refunds, poor user experience, and lost revenue for venues.

What This Does

StadiView is a browser‑based demo that renders a fully procedural 3‑D football stadium using Three.js and GSAP. The index.html page loads the Vite‑bundled bundle, which starts in src/main.js. Seats are generated on‑the‑fly and displayed with GPU‑instancing; clicking a seat triggers a camera flight into a first‑person view, overlaying simulated pricing and availability data.

Key assets are stored under src/assets/ (icons, logo, Vite badge) and styling lives in src/style.css. The only runtime JavaScript files are src/main.js (application bootstrap) and src/counter.js (utility for a simple on‑screen counter used in the demo UI).

How It Is Wired

Execution begins with index.html, which loads the Vite dev server bundle that resolves src/main.js.

  1. src/main.js – entry point. It imports the setupCounter function from src/counter.js and calls it once to initialise a demo counter UI. It also contains the Three.js scene setup, seat generation, and interaction handlers (orbit controls, click‑to‑fly, escape to return). All visual and animation logic stays inside this file.
  1. src/counter.js – defines two functions: setupCounter – creates a DOM element for the counter and registers a click handler that invokes setCounter. setCounter – updates the counter’s numeric display.

The internal call graph shows a single edge: setupCounter → setCounter. No other internal modules are imported, and there are no circular dependencies. Consequently, the only code path that other modules depend on is the counter UI; the bulk of the application (scene creation, seat instancing, camera animation) is self‑contained in src/main.js and does not expose reusable APIs.

Because the repository contains only two JavaScript modules, the wiring surface is minimal: change to seat generation or camera logic requires editing src/main.js; adjusting the counter UI requires editing src/counter.js. No external services, file I/O, or network calls are performed.

How To Use It

# Clone the repository
git clone https://github.com/moses-y/football-stadium
cd football-stadium

# Install dependencies (npm is inferred from package.json)
npm install

# Start the development server (Vite script defined in package.json)
npm run dev

Open the URL printed by Vite (typically http://localhost:5173). The demo runs entirely in the browser; no environment variables or additional configuration files are required.

Real‑World Use

A ticketing platform could embed this demo as a preview widget. When a user selects a seat in the production UI, the platform would replace the static seat map with the Three.js scene, feeding real seat‑specific data (price, availability, view‑obstructions) via a JSON API into the same rendering pipeline used by src/main.js. The camera‑flight logic already supports a first‑person view, so integration would mainly involve swapping the simulated data layer for live data.

// Example integration point
import { initStadium } from './src/main.js';
fetch('/api/seat/12345')
  .then(r => r.json())
  .then(data => initStadium(data));

Code Health & Issues

  • Medium – Enable Dependabot or Renovate – package.json is present but no update bot is configured; a .github/dependabot.yml should be added to keep dependencies patched.
  • Medium – No test suite – repository lacks any test files; code paths are unverified by automated tests.
  • Medium – No CI/CD pipeline – .github contains only a funding file; adding a GitHub Actions workflow would enforce linting/build checks.
  • Low – License present – LICENSE.md and COMMERCIAL-LICENSE.md exist, satisfying legal requirements.

No Dockerfile, secrets, or additional configuration files are detected.

The Bottom Line

StadiView delivers a compact, visually impressive 3‑D stadium demo with a clear, low‑complexity codebase (two JS modules). It is suitable as a proof‑of‑concept or UI component for ticketing sites that need an immersive seat preview. However, the lack of tests, CI, and automated dependency updates means production adoption should be preceded by adding those engineering safeguards.