nfs_web_authoring_analysis.md

Need for Speed Web Racing: Technical Analysis

Based on Recovered Artifacts (December 2025)

1. Game Architecture

• Platform: Web Browser (Internet Explorer / Netscape Navigator)
• Technology:
  • Frontend: HTML/JSP (JavaServer Pages) for UI and Lobby.
  • Logic: JavaScript (NFS.js, javascripts.js) for browser detection and navigation logic.
  • Engine: ActiveX Control (IE) or Netscape Plugin.
    • Technical Note: Users did not download a standalone .exe. The game was native code (C++) packaged inside a web component (.ocx or .dll) that executed within the browser window. This allowed seamless integration with the HTML Lobby.
  • Launcher (Servlet): A Java program running on EA's servers.
    • Its function was to receive user requests (e.g., "I want to race in event X"), verify session/subscription, and return the parameters needed for the browser plugin to launch the game executable.
    • Identified Path: /LaunchGame.
  • Graphics Engine:
    • Likely based on NFS 3: Hot Pursuit or NFS 4: High Stakes (circa 1999-2000).
    • Supported Software Mode and Hardware Mode (Direct3D).
    • Required DirectX 5.0 minimum (according to howtoplay.jsp).
    • Allowed adjustment of visual effects like "Driving Assists" and graphic quality.

2. Game Mechanics (from howtoplay.jsp)

• Game Modes:
  • Free Demo: Restricted to Chevrolet Corvette on Rusty Springs track.
  • Single Player: Time Trial, One Opponent, Seven Opponents, Hot Pursuit.
  • Multiplayer: Head-to-head online racing (up to 4 players).
• Monetization: Required subscription to "EA.com Platinum Service" for full access.
• Download System:
  • Modular resource loading.
  • Cars and tracks were downloaded individually as needed.
  • "Advanced Options" like Night Mode, Traffic, and Weather also required separate downloads.

3. Key Files & Status

File	Status	Function
demo/home.jsp	✅ Recovered	Main page for the demo.
howtoplay.jsp	✅ Recovered	Instructions and gameplay details.
interstitial.jsp	✅ Recovered	Loading screen with ad logic.
inc/NFS.js	❌ LOST	Core JavaScript library for game logic.
/LaunchGame	❌ LOST	Server-side servlet that launched the executable.
Game Binaries	❌ LOST	Actual game files .cab, .dcr, or .exe.

4. Deep Analysis of Lobby & Execution

Based on multi/home.jsp and demo/home.jsp:

Lobby Flow (Waiting Room)

The "Lobby" was not part of the 3D game, but an HTML/JSP web interface.

1. Room Selection: Player chose "Beginner", "Intermediate", or "Advanced".
2. Download Phase (Pre-Game):
   • Crucial: Downloads happened BEFORE entering the race.
   • Upon selecting a room/car/track, the site calculated missing files.
   • User had to click "DOWNLOAD" on the web. Once complete, the button changed to "RACE" (or "ENTER GAME").
3. Game Room:
   • Player List, Game List, and Chat.
   • The Host configured laps and AI.
   • Everyone had to press "READY" on the Host to start.

What did NFS.js contain?

Important: Neither NFS.js nor javascripts.js contained the game engine.

• Technology: In 2000, JavaScript was too slow for 3D graphics.
• Real Function: These files were the "glue" or "remote control".
  • Bridged the web page and the Plugin.
  • nfsPopUp(): Opened windows.
  • Bridge: Sent commands like "Start race with Car X" to the Plugin.
  • The actual engine (physics, graphics) was in the separately downloaded .ocx (ActiveX) file.

Multiplayer Architecture & Lobbies

The system used a hybrid model typical of the era (2000):

1. Centralized Lobby (EA Server):
   • Discovery: The "Game List" and Chat resided on EA's web servers.
   • Protocol: HTTP/Java. You saw an HTML table with rooms and created games.
   • Matchmaking: Manual. You chose which room to enter ("Beginner", etc.) and which game to join.
2. Match (Listen Server / P2P Hybrid):
   • Host: The player who created the game ("Create Game") acted as the SERVER for the race. Their PC calculated physics and rival positions.
   • Clients: The other 3 players connected to the Host's IP (negotiated by the Lobby).
   • Advantage: EA saved costs on expensive dedicated servers.
   • Disadvantage: If the Host disconnected or had lag, the game was ruined for everyone.

Network Protocol & Connectivity (56k & IPs)

• The 56k Modem Era:
  • In 2000, dial-up modems connected your PC directly to the ISP's network.
  • Real Public IP: Your computer obtained a public IP address (e.g., 80.20.10.5) accessible worldwide. NAT did not exist (Network Address Translation used by modern routers).
  • Consequence: You didn't need to open ports. Any player could connect to your IP ("Hole Punching" was unnecessary).
  • This simple architecture allowed complex games to work without expensive central servers.

Resource Management (Cars & Tracks)

Lobby script analysis confirms:

1. "Pre-Game" Loading (No Streaming):
   • Resources did NOT load while playing (56k bandwidth was insufficient).
   • Before entering a room, the system validated missing .viv / .qfs files.
   • You had to download and install them before the "PLAY" button became active.
2. Configuration Files:
   • There was no fixed config file on your PC.
   • Race configuration was sent dynamically from the server at launch time (inside the file generated by /LaunchGame).

Synchronization & Physics (Netcode: Why Desync?)

Racing games of that era (and today) DO NOT use strict determinism because "Input Delay" would be unacceptable for driving at 200 km/h.

The Real Model: Client Prediction + Server Authority

1. Your PC (Client):
   • Does not wait for the server. Moves your car immediately when you press key (Zero Input Delay).
   • Sends your position and inputs to Host ("I am at X=100, Y=20").
2. The Host (Authority):
   • Receives your position.
   • Calculates validity. Wall Example: If the Host sees a parked car you didn't see due to lag, the Host calculates a crash.
3. The Conflict (Desync/Rubberbanding):
   • Host sends correction: "No, you aren't at X=110, you crashed at X=100".
   • Your game receives this packet late and teleports your car back to match Host reality. This is "Rubberbanding".

TCP or UDP?

• UDP is used (DirectPlay used both).
• TCP is bad here: If a "position" packet is lost, TCP pauses everything to resend it. In racing, you don't want the position from 1 second ago, you want now. It's better to lose a packet (UDP) and get the next one than to pause the game.

Detailed Execution Mechanism

Analysis of interstitial.jsp reveals launch was triggered by simple navigation: location.href = "/LaunchGame?SERVICE_ID=2141".

How did this work?

1. Request: Browser requested URL /LaunchGame.
2. Servlet Response (The "Message"): Server returned a file with a custom MIME Type (e.g., application/x-nfs-init), not HTML.
3. Handoff:
   • Browser detected file type.
   • Checked registry for the handling plugin (NFS Plugin).
   • Execution: Browser started the plugin and passed the content of that file.
4. Message Content: That file contained session data in plaintext or encrypted binary:
   • AuthToken=... (Validation).
   • GatewayIP=... (Multiplayer Server IP).
   • AssetList=... (Cars/Tracks to load).