VROC

Virtual Racers' Online Connection

Racing Simulation Interface Guidelines

Alison Hine
2/17/99

Abstract

This document describes the features a racing simulation needs to incorporate in order for it to be integrated with an online racing service such as the Virtual Racers' Online Connection (VROC).

Contents

VROC Overview

VROC is a Web-based online racing service developed by racing enthusiasts. VROC was developed to allow users interested in racing Papyrus Grand Prix Legends via the Internet to host races at a single public location, and to conveniently join such races. VROC could be extended to support other racing simulations in a similar fashion.

VROC automates as much as possible both hosting and joining races. To view VROC in action, please go to the VROC web site:

http://gpl.gamestats.com/vroc/

VROC is implemented on the client side as a Java applet which runs in an HTML page. This applet contains a Host button, a Refresh button, and a list of available races.

When a user clicks the Host button, that user's IP address and other information (such as the user's name and type of connection to the Internet) is transmitted to the VROC Unix server. This information is stored in an SQL database on the UNIX server. The VROC applet then launches GPL and the user proceeds to the Multiplayer screen and hosts the race.

VROC's SQL database is scanned several times a minute by a cron job on the Unix server, and each GPL server listed in the database is queried for race status. The database is updated with information from the most recent query response.

When other users launch the Java applet by accessing a VROC race list page (known as a "Room"), the VROC Unix server supplies a list of all races currently being hosted in that "Room". The VROC applet displays this list and, depending on certain parameters, also provides a "button" which allows other users to join a given race.

The user may refresh this race list by clicking the Refresh button on the applet. This retrieves the latest race status information from the SQL database on the Unix server, and also pings each server (using the standard Windows ping program) to determine the latency from the local machine to each server.

When the user chooses to join a race, the VROC applet queries the specified server directly to determine if the race is still available for joining. If so, it writes the IP address of the server to an ini file in the local user's GPL folder and then launches GPL. The user then proceeds to the Multiplayer screen and joins the race.

Note: At this time, VROC is undergoing further development. The new version of VROC will incorporate extensive revisions, some of which will take advantage of new functionality contained in a GPL patch currently under development by Papyrus. However, the basic functionality and concepts described here will remain.

Feature Recommendations

Two features are necessary in order for VROC to support a racing simulation in the same fashion as GPL, and several other features are highly desirable.

Required Features

Remote Server Query

In order to allow VROC to extract current status information from the simulation when the simulation is executing as a server, the simulation must, when running in server mode (i.e. running as a host), respond to a query from VROC. This should take the form of (preferably) a UDP or (alternatively) TCP packet of information which is returned by the simulation when it receives a packet on a given port. This packet should contain all relevant information, such as:

Papyrus has made available a program which illustrates the query mechanism incorporated in Grand Prix Legends, and which VROC makes use of to supply information to the user via the VROC Race List. This program is available at:

http://nh.ultranet.com/~alison/gpl/files/gplping.zip

This program might serve as a model for other simulation developers who wish to develop similar functionality. The more closely a sim's query responses follow the GPL model, the more readily a version of VROC can be built to support such a sim.

An alternative to a server-initiated query would be if the simulation would periodically send a similar packet to a game list server (VROC in this instance) without being queried.

Client Launch with IP Address

VROC must launch the simulation's client and pass it the IP address or domain of the machine hosting the desired race session.

Preferably, the IP address or domain would be passed by VROC to the simulation through the command line when the simulation is launched, and the simulation would, in this case, attach to the server at the specified IP address or domain and proceed directly to its multiplayer screen.

For example:

myracingsim.exe ip=207.111.116.108

A much less desirable alternative would be for the simulation to read the IP address from a file, which VROC would write to the client's local hard disk before launching the simulation.

It is very desirable but not essential that the simulation automatically attach to the specified server and proceed directly to its multiplayer screen. As long as the IP address or domain is made available to the user on the multiplayer screen, the user could manually establish the attachment, but the fully implemented online racing simulation would automate this process when it receives an IP address or domain on the command line.

It is also very desirable that the host's IP address not be revealed to the client users, since this represents a security risk to the host.

Useful Features

Command Line Parameter Interface

It is very desirable to allow the calling program (i.e. VROC) to pass parameters such as track, race length, damage model, car class, car set, password, etc., to the racing simulation program at run time through the command line.

Server Launch to Multiplayer Screen

When the simulation is launched as a host, it is desirable that it proceed directly to the Multiplayer screen, thus relieving the player of the burden and potential confusion of navigating through other screens. This might be triggered by a command line parameter. For example:

myracingsim.exe -host

Remote Server Control

Many users have access to T1 or faster Internet connections at their place of work, and could run a game server on their office machine after hours. This provides a ready source of servers with high speed connections to the Internet, which is very desirable for the development of an online racing community.

In order to support remotely located servers, it is extremely desirable that the simulation allow a mode in which the server can be controlled from a remote location.

Unattended Operation

For the same reasons mentioned above, it is extremely desirable that the simulation provide a mode in which it can be left to operate unattended. This means that the server should be capable of looping endlessly through race sessions (including practice, qualifying, and race, as applicable) without intervention from an administrator or the host user. Ideally the server would follow a script containing track, race type and length, car type, and so forth.

This mode would be particularly useful for users with full-time Internet connections to their homes, such as cable modems and ADSL. Such users could leave their computers hosting an unending cycle of races for extended periods.

Result Reports

It is desirable for the simulation, particularly when hosting, to optionally deliver a report of the race results to a specified location. These results would ideally be in the form of a text file and would list the qualifying order and times (if applicable) and the finishing order, with DNF information if available. Qualifying lap times and race finishing times, or similar relevant information would also be desirable.

This report would ideally be sent to an IP address, domain, or email address which could be specified in the command line or in an ini file in the simulation's installation on the user's hard drive.

Gateway Support

The simulation should take into account the fact that some users will be operating from behind a gateway. In some cases, it is very desirable to support these users because they can provide excellent support for hosting multiplayer races.

Some users can run servers after hours on computers at their place of business, and these are often connected to the Internet via T1 lines, thus giving very high bandwidth and low latency, both very desireable for hosting multiplayer races. Such a scenario presents an ideal situation for a standalone or remotely controlled server which could be left running and be accessible to VROC users for many hours, particularly during peak gaming periods.

With the proliferation of ADSL and cable modems, many more technically-oriented users have installed gateways (typically running Linux) which allow several computers on their home LANs to be connected to the Internet via the high speed connection. Feedback from VROC users has shown that a number of these users are willing to run a racing sim server on a computer behind the gateway and host VROC races if the simulation supports operation behind a gateway.

Experience with VROC cable modem and ADSL hosts suggests that servers on these type of links will work quite well and present essentially the same advantages of a server on a T1 line.

Additional information about operation of a racing sim server behind a gateway can be found at:

http://nh.ultranet.com/~alison/gpl/faq-online.htm#hostboth

http://members.home.net/jms1/gplmultiplayer.html