Chapter 1. Introduction

Table of Contents
Design Goals
About The Developers

In the beginning there was Elite, an amazing (for the time) single-player space trading and combat game for the 8 bit microcomputers popular in the 1980s. The objective was to survive, make money and annihalate the competition in order to attain the coveted "Elite" status. Though Mote was originally intended to be an Elite clone for Linux, this goal changed to provide a sort of spaceborne equivalent of Ultima Online, catering for both gung-ho pilots and shrewd business people! If you are looking for an Elite clone we suggest Freespace 2 LINK TO FREESPACE; if you are in need of an (inferior and non-extensible) space-based roleplaying fix immediately, then Freelancer and Station Terminus are both available.

Note To Reviewers: This document is a simple wrapper created around some document portion entities that I did ages ago, therefore, some information may be out of date due to the current sourcecode checkin blackout. I've done my best to update things from the traffic on mote-dev but I've probably missed something. Anyway, this is what some end user documentation produced in SGML using the Docbook DTD would look like (stylesheet customisations aside). Why Docbook? Well, it is tailor made for technical documentation and is quite capable of handling the idiosyncracies of Mote (the need to include stories for example). The files are small (plaintext) and can be rendered into both pretty HTML and splendid printable output (DVI to PostScript) via the splendid jade and jadetex backends. The DTD is also available in an XML flavour these days; in fact to change to XML I merely change a couple of lines in the preamble as I've kept all the tags and attributes XML compliant. If it's good enough for GNOME it's good enough for us.

This simple document is a very poorly structured as I merely pulled together some of my "finished" entities (mainly those without graphics, as I haven't got those sussed yet- at least not graphics that work in many possible output formats). If you like the look of this, I can quite quickly sketch my idea of an outline for some more in-depth documentation for which I already have some finished entities. What it won't cover (at the moment at least) is source code documentation or APIs as they are both being covered splendidly by AndyC.

I'll also try and create a glossary and maybe some customizations to make FAQs and the like clearer to read in source form (than my current evil abuse of glosslist that is) and work out a decent way of splitting up any further documents (I was thinking a set of books, each on a specific topic (getting started, design notes, tech reference and others as necessary) that could all draw on a set of common entities. Enough from me.

Design Goals

Note To Reviewers: The information in this section is derived from the "Mote white papers". I realise these may be very out of date and are now even more so after the MoteCon but I'm only about halfway through ploughing through the mote-dev traffic to generate a new set of notes. Once these notes are completed I'll revise this section. Until then bear in mind that if I found any blanks I glossed over them.

Early in the project it was decided that network play should be an option. Therefore Mote is to be split into two distinct parts; the client (which handles 3D rendering and user input) and the server which stores the state of the universe. Two basic game types are supported under this architecture.

Single Player

In this case the Server will run on the localhost along with the client and other "players" will be provided by AI extensions. Specialised missions, story and action will be supplied to make this a creditable alternative to online play.

Multiple Player

In this case the Server will be specialised into two types- Galaxy and Universe running on dedicated hardware. Multiple Galaxy servers handle client connections and local game state for a group of solar systems whilst the single Universe master server handles global game state (such as player rankings and economic data). A form of load balancing and some game resilience is therefore achieved as Galaxy servers may run for a time without access to the Universe machine. In order to make up player numbers or provide services (automated trading while logged off for example) AI code may be introduced by the game administrators.

In both types of game there shall be several available actions all used to obtain extra score and/or money and other advantages. How the game is played depends on the player and their particular skills; in general it should be possible to achieve supremacy in all gameplay styles, or a mixture of them.

Combat

Conceptually the most simple, the player battles their way to the highest status, serving the highest bidder. Suitable for a lone player.

Trade

The player uses features of the game's economic services to make money by shipping goods, investment and other less honest means! Suited for a single player or a team forming a Corporate entity.

Piracy

Stealing should be a path to quick riches and a potentially quick death, as snatching the fattest prizes also incurs the risk of a fleet of heavy cruisers turning up in your space volume. Suitable for the suicidally insane.

Spook

The player allies themselves with a governmental organisation or powerful corporation, giving them access to the latest technology, some extra funding and heavy backup at the expense of some personal freedom. Suited for a single player who wishes to get ahead quickly.

Within the game the known universe shall be dominated by a variety of human groups with a sprinkling of mysterious aliens and other strange artifacts to keep interest. These groups shall wield both political and economic power and maintain military units to keep these safe. The known universe itself shall be organised into a peaceful "Core" with rich trading opportunities and stable politics and an anarchic "Rim" where unusual (and profitable) actions shall take place. Conditions in this universe will be dictated by both political, military and economic forces, all of which may be influenced in various ways by a skillful playwe. For example, in the middle of a territorial skirmish between two governments an enterprising player could make a quick buck from gun-running at the risk of being attacked by an enemy side. Gun running actions may give one side a superior weapon system, so shortening the war and stabilising the political situation.

To support the gameplay in both single and multiplayer, Mote shall provide the following services as extensions in addition to the 3D modelling and combat handling code that is an obvious necessity:

Game News

In some way the game should inform players of changes in the political situation and other upheavals to plan their actions accordingly.

Marketplaces

Used to trade anything that can be assigned a monetary value. These are most often physical goods but services and other ephemerals (including information) should be allowed.

Hyperspace gates

These are provided to allow underpowered ships to move around freely in the "Core". Travellers in the "Rim" should make their own arrangments!

AI (Automation)

These routines will provide anything from automated trading to gun-turret operation for a price.

Natural Resources

These are the basis of trade and manufacturing and should be distributed at game startup for players to mine or steal.

Group Entities

These allow such things as governments, fleets and corporations to be formed, each member having access to some shared resources.

Game Events

Actions that occur at pre-defined or (in the case of multiplayer) administrator defined points. These may include the destruction of a too-powerful dynasty, discovery of new technology and anything that doesn't fall into the other categories.

This basic design is expounded in the WHITEPAPERS SECTION and will be altered as necessary. In particular there is very little detail on actual game mechanics, rather the existing design deals with requirements refinement.