Goals of Xpilot.IO
Xpilot.IO will be a multiplayer space combat game playable in the web browser. There will be large, customizeable maps and various game modes like free-for-all, capture-the-flag, king-of-the-hill, zombie mode, etc. Currently the gameplay demo is a simplified, single-player game against AI components, in a rather small and ugly map.
With the help of financial backers, I will create a game server that uses web sockets to communicate with clients. Most of the game state and physics calculations that are now done in the client will move to the server, which will make the client run even smoother.
Artificial Intelligence Education and Research
The original XPilot, created in the early 90s for Unix based systems, has been successfully used as a testbed for artificial intelligence controllers. The realistic physics, challenging flight dynamics, and simple controls, make it an ideal and fun platform for testing out neural networks, cyclic genetic algorithms, and other controllers.
While XPilot has been used in the Connecticut College computer science curriculum for many years, it is becoming increasingly difficult to install XPilot on modern Linux operating systems. Xpilot.IO will solve this by making a client-side AI interface available that exposes information about the game state--other ships, bullets, walls, etc--and allows you to control the ship, mainly: turn, thrust, shoot.
The Early Gameplay Demo is programmed entirely in Elm. It uses the SVG library to draw everything. All objects in the game, including bullets, wall, and thruster embers, are stored as GameObjects, which are stored in a standard list. Every tick of gameplay folds through the list, calculating physics and checking for collisions.
The current Elm version has several problems. The walls of the maps are ugly and can only be rectangular. The collision detection just looks at the bounding box of an object, not its actual polygonal shape. Because all the objects are stored in a list, the list grows and shrinks drastically and sometimes causes game-halting garbage collections.
While there is currently no game server, the HTTP server that serves these pages and the Elm code is written in Haskell, using Servant and Lucid. PostgreSQL and Opaleye are used to record statistics of the players, such as how many kills they have, or how long they've played. See the Stats page if you're curious.
With the help of financial backers, the physics and collision detection engine will be moved to a back-end server written in Haskell. Using websockets, the server will send and receive gamestate updates from the clients. Players will be able to join a current game or create their own room, selecting the map and game mode.
The client will have less to do, but will still do some physics calculations to aid with lag compensation. A static array will be used instead of a dynamic list, to keep garbage collection under control.
We might switch from Elm to PureScript + WebGL to improve graphics performance and to be able to use Monads and Purescript's mutable array.
There will also be touchscreen controls for those with tablets.