1. Overview

1.1 Goals

Projekt 2501 (called P2501 in this doc) is an online multiplayer action game. Its main goal is to be a replacement for a game like BZFlag but be extendable in the future.

1.1.1 BZFlag

While we say that we want it to be a replacement for BZFlag, we don’t mean that it is a DIRECT replacement. It will not duplicate BZFlag function by function. The game should be like BZFlag in spirit, if not specific game rules. Things such as health, damage, different weapons, and the like WILL be made available, and the primary “powerup” system will not be the picking of flags. But the game WILL be a fun online multiplier shooter focusing on vehicle combat and ease of use.

If the project is done correctly, a rule set mod could be made that would make the game play very similarly to BZFlag (one shot = 100% damage, maps with flat geometry, single weapon pickups, etc ).

The initial intent is to keep the code open but separate from BZFlag as well. If the project comes to fruition and the rest of the BZFlag project wishes to reuse technology from P2501 then that will be great, but if that does not happen then it is perfectly acceptable for the games to co-exist.

1.1.2 Frank Siegert’s Project 2501

http://www.wizards.de/~frank/project2501/index.html

This project is not related to the older and now apparently defunct game Project 2501. This project does have similar goals but uses a K in the name instead of a C to show differentiation. The project authors also both enjoyed the Ghost in the Shell manga/anime series J

1.2 Language

P2501 is written in C# using the .net/mono frameworks. The main goal of the project is to show that a fully functional game can be made in managed code. This will allow a single distributable binary to be made for all supported platforms. This fact will allow the game to have an automatic update system.

The use of C# and managed code will limit the releasable platforms. The default platforms will be Windows, OSX, and Linux. Other platforms that may have mono support may be possible but will not be the main focus of the game. Given that both OSX and Linux do not currently “double click” mono executables, some platform specific scripts will need to be made to provide an easy to use launcher for those systems. A small .app file for OSX and a small bash script that trigger mono will made available, and should require minimal maintenance.

That being said, some other languages will be involved in the project. Global services will use PHP to implement the authentication, listing, and statistics system. Lua will be available for scripting on the server side, as well as possibly on the client if time allows. XML will be used to store data for the client (settings and UI positions). These other languages will be used in OS independent ways to keep with the main goal.

1.3 Servers and public services

The server system in P2501 will be more restrictive then it is in BZFlag. Users will be required to submit a registration email address and password to play. Users that have not verified the email address will be limited to a small number of servers that are run by the project itself. Players will be able to register up to 5 call-signs that are use for play.

Servers must provide an authentication key to the list server in order to be sorted into the proper section for the client. Sections will be broken up into 3 main groups, Preferred, Community and Leagues.

Preferred servers will be servers run by the project, or run by community members that meet specific criteria in quality and management. This is an invite only system. The preferred section is the only section that will have servers that allow unverified users to play. The main goal of this is to provide a place for new players to instantly play and learn the game, but at the same time to separate greifers from the main community. Severs for unregistered users will have in game “tool tips” and help prompts to assist the player in learning the game.

Community servers can be run by anyone that requests an authentication key from the list system. They will only show for players who have verified email addresses, but are not run by the project itself. Community server owners must provide a valid email address and have a registered game account to get an authentication key.

League servers are similar to community servers but have been tagged as belonging to a registered league. These servers will only be show to members of the league, and will have instances that can be ‘locked down’ to specific teams to allow for match play.

The main goal of the tired system is to provide a positive benefit to players that verify account information. To further this goal, statistics, friends, and league play will only be available to verified users.

1.4 Game Servers

Game servers will host one or more game states at a time. Each game state will be considered an ‘instance’, and not affect any other instance. Instances do not have to run the same map or rule set, nor use the same resources. Instances can be created or deleted “on the fly” as the server runs. Server owners can set various conditions or permissions on specific instances as needed. Players can change instances as needed with out reconnecting.

An instance represents a complete game state, including score. By default changing instance will reset a player’s score and state, in the same way a new player is treated. Server plug-ins can be made to change this behavior if desired. This gamestate is managed by the GameState assembly that is shared with the game client using synced communication.

Game servers will push statistics up to a global collection system.

1.4.1 Updates

All servers that register publicly will be automatically entered into an online mailing list that will notify owners of new versions of the server. Servers that are not running the current version will not be listed.

1.5 Game Client

The game client will be a C# application using windows forms and OpenTK. The application will consists of 2 main interfaces, the launcher form and the main game display.

The launcher form will contain the interface for player registration/authentication, character management, server listing, and a simple news browser. Menu items will also be available to configure graphics preferences for the main game view such as screen resolution and items to enable the player to configure various input settings

The news browser will be a simple HTML control that connects to a special blog page on the project’s website.

The game view will default to a full screen window at the main display’s desktop resolution, but will have options to be changed to a lower resolution, or be placed into a dynamically sizeable window.

1.5.1 Update system

The game will have an automated update system that is able to update clients as soon as they launch the client. This system will perform a series of updates as needed in order to keep the clients on the current version. Development builds will have an option of disabling the update system for program data.

The main entry point into the game will be a small OS specific launcher. On start this launcher will check the user’s home directory/profile to locate a launcher of a higher version. If one exists it will launch it and exit. Once the launcher starts it will check for updates to the patcher. If there are updates ( as identified by a version number sent back from the central server), then they will be downloaded and installed replacing the existing files. If the install directory is not writeable then the system will ask the OS to elevate permissions ( UAC on windows, whatever else it is on mac). If this is not possible then the patch system will be installed into the user’s home directory/profile. After updates to the patch system, the launcher will invoke the patch system.

The patch system will download a file list and version info from the central server and compare the data archive version to a stored version that is in it’s profile data. If the last patched version does not exist, or is different then the server version the patch process will start. During patching the system will download a complete list of files for the entire data archive, complete with MD5 checksums for each file. The system will scan compare these checksums against the stored checksums for the last patch on each file. If a checksum does not match or does not exist the file will be downloaded via HTTP and installed. Files that have local checksums but are not listed in the server list will be deleted. In a similar manner to the launcher, if access to the installed files is not allowed, the OS will be asked to elevate permissions, and if that fails, the files will be saved into the user’s profile directory.

When patching is complete the patcher will execute the current main client app ( from the install dir, or the profile dir ) and run the game. The game client will be made in such a way where it will check for resources in the profile dir first before using the install dir, allowing for the use of the most current content.

A tool will be made to build up the required data archive for storage on the main server. Each file will have an entry with full path, URL, and MD5 checksum. Each file will then be compressed using gzip and copied to a separate folder structure to be uploaded to the update server.

1.5.2 Distribution

As previously stated the main deliverables will be mostly platform independent. Only a small platform specific launcher will need to be made in order to give the end user an acceptable starting experience for the host OS. The use of an automated update system can allow the initial deliverable to be a very small package including just a version of the launcher, letting it download the rest of the application as part of the normal update system.