Warp Fleet Software Design

Version: 0.1
Author: Karl Robillard
Copyright: © 2006-2007, Karl Robillard

Contents

1   About this Document

This document describes the technical details of implementing Warp Fleet, as described in the Game Design document.

2   Overview

There are 3 programs:

  • meta-server
  • server
  • client

2.1   Program Implementation

Implementation will be done in 2 phases: rough-cut & completion.

The rough-cut phase will implement the basic features as simply as possible to get a playable game.

The completion phase will implement remaining features and improve graphic effects, etc.

2.1.1   Rough-Cut Phase

  • Battle mode only
  • Tactical Logic
  • All tactical displays except Damage Repair

2.1.2   Completion Phase

3   Local Directory Structure

This is shared by all 3 programs.

~/.warpfleet/client-config
~/.warpfleet/server-config
~/.warpfleet/meta-config
~/.warpfleet/banned
~/.warpfleet/scenarios/
~/.warpfleet/models/
~/.warpfleet/sounds/

3.1   Scenario Directory

Contains scenario files, design files, and star-name files.

3.2   Models Directory

Contains Thune models and PNG images.

3.3   Sounds Directory

Contains WAV or OGG files.

4   Meta-Server

5   Server

  • Configure for single battle or a war.

  • War Setup
    • Generate star maps and systems.
    • Generate fleets.
  • Battle Setup
    • Generate star system.
    • Players select ships.
  • Gameplay loop.
    • Run simulation
    • Serve clients
    • Update meta-server every 30 seconds

5.1   Server Configuration language

meta-server "meta.ultratrek.net"
port 4300
scenario "war01.scen"
player-limit 16
banned "banned"

5.1.1   Banned file

This is a list of names/IPs.

www.evilplayer.net
30.67.4.200

5.2   Scenario Language

scenario "Klingon Invasion of 2380" [
    description {
        The Klingon/Federation War of 2380.

        Klingons invade without warning.
    }
    war
    time-limit 5:00
    star-seed 3453288

    faction "Federation" [
       ;starbase-defeat     ; Defaults to true.
       control 50           ; Percent
       fleet-seed random    ; Defaults to random
       fleet-strength 100   ; Resource points
       ship-designs "designs-fed"
       ship-names "vessels-fed"
       star-names "stars-fed"
    ]

    faction "Klingon" [
       control 20
       fleet-seed 824000
       fleet-strength 100
       ship-designs "designs-kli"
       ship-names "vessels-kli"
       star-names "stars-kli"
    ]
]

5.3   Star Name Files

These are simple text files, one name per line.

Rigel
Sol
Vulcan
Alpha Proxima

5.4   Ship Design Language

beam "Phaser" [
    recycle 20      ; seconds
    drain 1         ; Power consumed during recycle
    hit-curve [...]
    damage 10
    damage-curve [...]  ; Unit scale
    sound-fire "phaser.wav"
    sound-hit  "phaser_hit.wav"
]

torp "Photon" [
    recycle 40      ; seconds
    drain 4         ; Power consumed during recycle
    speed 100       ; km/s
    turn-rate 60    ; deg/s
    life-span 4     ; seconds
    hit-curve [...]
    damage 10
    damage-curve [...]
    sound-fire "photon.wav"
    sound-hit  ["photon_hit01.wav" "photon_hit02.wav"]
]

ship fed-ca [
    vclass     "Enterprise Class Heavy Cruiser"
    model      "fca/fca.mgx"
    size       1.0
    turn-rate 10.0      ; Degrees
    shields    2.0      ; Strength
    power     10  50    ; SU & power
    thrust     4  1.0   ; SU & cost
    sensors    3  1.5   ; SU & rating
    warp      10
    structure 12
    weapons [
        ; Type Number  Facing/Arc  Display Position
        Phaser 2     0,180    0.0,0.8
        Phaser 2    90,180    0.2,0.6
        Phaser 2   270,180    0.8,0.6
        Photon 2     0, 60    0.3,0.3
        Photon 2     0, 60    0.7,0.3
    ]
    torps     20
    repair    4
]

ship fed-cl [
    ...
]

5.5   Scenario Generation

Scenarios are created procedurally using a few simple values specified in a scenario file written in the Scenario Language.

5.5.1   Sector Generation

Each sector is created procedurally from a single star-seed number.

Needs to be created:

  • Sector size (small/medium/large)
  • Number of systems
  • Coordinate of each system
  • Faction assigment of each system

Each new systems is kept a minimum distance away from existing system.

5.5.2   System Generation

Each system has one star and 1 to 12 randomly generated planets. Each planet is generated with the following attributes:

  • Distance from sun
  • Initial Azimuth
  • Orbital Period
  • Radius
  • Procedurally created texturemap

5.5.2.1   Planet Textures

Textures are procedurally generated.

  • Airless planetoids (Class D) - 1 rocky, cratered texture.
  • Gas giants, Jovian (Class J) - 1 cloud texture
  • Terrestrial (Class L/M) - 2 textures, land/water & cloud layer.

5.5.3   Fleet Generation

The fleet for each faction is created procedurally from a single fleet-seed number.

  • Number of ships

  • Number of bases

  • Place ships
    • Assign to task forces
  • Place bases

6   Client

6.1   Client Configuration language

video 1024,768,60
window
fullscreen
sound-volume 100
music-volume 100
joystick "/dev/input/js0"
meta-server "meta.ultratrek.net"
chat-keys [
   f1 "/a Hello"
   f2 "/a Bye"
   f3 "Cover me, I'm going in!"
]

7   Client Display Engine

OpenGL 2.1 will be required.

Thune GL draw lists and perhaps some custom C code.

7.1   Ship Silhouettes

Draw into framebuffer, first as a thick wireframe, then as solid black.

8   Network Play

images/network_diagram.png

Network Diagram

The client is only shown a part of the world the server controls. This state is called the Client World View. Because of network distortions, the client view may radically change at any time. In order to smooth the changes, an interpolated world view is also maintained.

The server sends world state updates to the client view - not input commands or events which the client would interpret. Commands require a valid state which the client might not or should not have.

Some input events are handled by the client before going to the server for immediate user feedback. For example, firing weapons can be shown but the result must come from the server.

Network Distortions:

  • Latency
  • Out-of-order packets
  • Dropped packets

Packet Digest

8.1   Network Flow

Server State --> <-- Client State
listen   hello announce
listen game-full   -- end
challenge challenge   --,
,--   prove prove
lobby scenario   --,
lobby   lobby-chat lobby
lobby lobby-chat   lobby
,--   play lobby
enter world-state   --,
,--   entry-done play
play   helm play
play   comm play
play position   play
play ship-status   play
play comm   play
listen --   quit play
play server-down   -- end

8.2   Network Messages

Each message description below has a brief summary line which contains the the number of bytes required, U or R to denote unreliable/reliable and tells who sends the message (client and/or server).

8.2.1   Helm Settings Message

13 U Client

Bytes Field Notes
2 msg id/type  
1 turn -90 to 90
2 warp 6.10 fixed point
1 thrust -128 to 127
1 shield_power 0 to 100
2 fire_bits Ship can have up to 16 weapons
2 target  
2 nav_ref  

8.2.2   Position Update Message

29 U Server

Bytes Field Notes
2 msg id/type  
2 ship_id  
8 x double
8 z double
2 rotation 6.10 fixed point
1 turn_rate -90 to 90
4 velocity float
2 warp 6.10 fixed point

8.2.3   Ship Status Message

21 U Server

Bytes Field Notes
2 msg id/type  
2 turn_rate 6.10 fixed point
1 thrust Structure
1 sensors Structure
1 power Structure
1 warp Structure
1 structure Structure
1 torps ammo
1 repair  
8 shields  
2 weapons_des Bit mask for destroyed weapons

8.2.4   Comm Message

7+ R Client/Server

Bytes Field Notes
2 msg id/type Two ids from client - All & team only.
2 ship_id  
2 text_length  
? text  

9   Simulation

9.1   Computer Control

The computer must be able to play the entire game by itself.

9.1.1   Strategic Logic

The logic must be able to:

  • Gather intelligence.
  • Defend systems near the enemy.
  • Coordinate attacks on enemy systems.

This is done by:

  • Launching scout missions.
  • Set up rendezvous at staging areas for concentrated attacks.
  • Simultaneously attacking multiple systems.
  • Feinting attack with a small force before attacking another system.

9.1.2   Tactical Logic

The squadron leader must:

  • Defend bases.
  • Coordinate attacks on enemy vessels.
  • Decide when to retreat.

The logic must be able to:

  • Listen to squadron leader.

  • Target ships (if not specified by leader).

  • Set controls (turn, thrust, warp, & shield controls) to

    • Inflict damage by coming to optimal firing range and attacking weak shields.
    • Keep strong shields facing opponent.

9.2   Damage

9.2.1   Damage Distribution Weighting

A custom distribution is built for each design based upon the systems present.

Make string of length equal to total system units, and fill it with the following characters:

  • P Power Core
  • D Main Drive
  • W Warp Generator
  • S Structural Integrity
  • N Sensor
  • A Armament

"PPPPPPPPPPSSSSSSSSDDDDNNNWWWWWWWWWWAAAA"

Each hit does "system = dist[ random( dist.size() ) ];"

10   Media & Data

  • Models
    • Fed CA
    • Fed CL
    • Klingon D7
    • Klingon FF
    • Romulan D7
    • Romulan WB
    • Starbase
    • Outpost
  • List of star system names.

  • Weapon Charts
    • Starbase
  • Fonts
    • Panel
    • Overlay/Text
  • System Displays
    • Fed CA
    • Fed CL
    • Klingon D7
    • Klingon FF
    • Romulan D7
    • Romulan WB
    • Starbase
    • Outpost

10.1   Resource Types

  • Font
  • Image
  • Model
  • Music
  • Sound

10.1.1   Font Format

True Type fonts are converted to OpenGL textures using libfreetype.

10.1.3   Model Format

Thune GL draw lists.

10.1.4   Music Format

Music will be .ogg files which will be played using OpenAL.

10.1.5   Sound Format

Sounds will be .wav or .ogg files which will be played using OpenAL.

10.2   Fonts

Role Typeface
Panel Federation Bold
Panel (small) Federation Bold
Overlay Bitstream Vera Sans Mono
Overlay (small) Bitstream Vera Sans Mono

11   Graphic Effects

11.1   Warp Effect

Use vertex shader to do logrithmic stretch on -Z vertices and Random rainbow colors around Z axis.

11.2   Weapon Display

The x,y location of the center of each bank is specifed in the script.

Beams weapon icons for each bank are lined up perpendicular to arc center-line, with the arc icon at group center.

Icons for each torpedo bank are lined up along arc center-line, with arc icon at front.

11.3   Shield Display

Show shield as a ring of fat dots surrounding the ship silloutte. Each shield area has five dots (for 40 total) which have 3 intensity levels to indicate damage (bright, dim, missing).

The order of intensity change:

Level  Method 1     Method 2     Method 3     Method 4

100    O O O O O    O O O O O    O O O O O    O O O O O
 90    o O O O O    o O O O O    O o O O O    O O o O O
 80    o O O O o    . O O O O    O . O O O    O O . O O
 70    o O O o o    . O O O o    O . O o O    O o . O O
 60    o o O o o    . O O O .    O . O . O    O . . O O
 50    o o o o o    . o O O .    o . O . O    O . . o O
 40    o o o o .    . . O O .    . . O . O    O . . . O
 30    . o o o .    . . O o .    . . O . o    O . . . o
 20    . o o . .    . . O . .    . . O . .    O . . . .
 10    . . o . .    . . o . .    . . o . .    o . . . .
  0    . . . . .    . . . . .    . . . . .    . . . . .

Using Method 3 - it will probably look best (most even distribution of gaps) when all sheilds have damage.

Will also need 'shields up/down' sequence where dots are lit in order around ship.

12   Support Libraries

12.1   Server Libraries

  • Podomo - Provides resource system & network code.
  • Thune - Scripting & bytecode languages.

12.2   Client Libraries

  • Podomo - Provides resource system, network code, GL 'engine', & GUI.
  • Thune - Scripting & bytecode languages.
  • GLView - Provides window & OpenGL context.
  • OpenAL

..Tool Libraries

13   Tools

13.1   Model Creation

Any application which creates OBJ files can be used. Wings 3D is recommended.

OBJ files are converted to Thune draw lists using the obj_to_gx.t script.

13.2   Automatic Shield Placement (ASP)

This tool makes it easy to place the 40 shield nodes around ship models.

  • Load model - scale to unit size.

  • Fix forward and aft centerline node - all others are chained using verlet integration and constraints.

  • Node Placement:
    • Allow user to manually fix some nodes and allow others to flow. (easy)
    • Can do collision against mesh edges and auto-shrink (complex)

13.2.1   Manual Placement Options

  • Tension Adjust
  • Mirror Toggle