As of the 0.22 release, basic multiplayer in ScrumbleShip has been implemented. June 22, 2013 marked the first round of true multiplayer testing. Dirkson successfully made ships sync across clients, and sent single block updates. Wazubaba, Jacob, Synergiance, and a couple other people logged in and built together interactively. All builds are persistent and saved by the server. This has resulted in an ongoing accumulation of interesting player-made architecture.
By default, the current versions of the game client log in to the test server automatically upon execution, though players may still access the singleplayer version from the game's main menu. The multiplayer client features chat support. Players can communicate via text, and in-game text is forwarded to the ScrumbleShip IRC channel, and vice versa.
Players can generate asteroids, and each generated asteroid is named automatically by a procedural name generator capable of producing coherent and often compelling names such as "Fusebase."
The current player model stand-in is a flame, and balls of fire can be observed flying between asteroids and constructs on the test server. Players cannot currently physically interact with each other. However, player-vs.-player combat is planned, with damage to the player models on a per-voxel level, as it is with all other materials in-game.
The Future of Multiplayer:
Multiplayer will continue to be phased in over time with increasing complexity, eventually culminating in a persistent universe where players can plot orbits and burn trajectories to fly between planets, and jump between solar systems. Currently, players can build cooperatively in a persistent space. Over time, more simulation code will be implemented, introducing gameplay mechanics including:
- resource scarcity
- multiplayer mining by players and AI
- fabrication of all components from raw materials in 3D-printing factories
- player damage simulation
- ship flight physics
- kinetic impact and structural stress physics
- airflow simulation
- and much more.
As these game mechanics are implemented, battle will be phased into the game. At first, battles will probably take the form of individual deathmatch, capture-the-bridge, and do-the-most-damage sessions between two or more players. Battles will take place in real-time. Players can either command their own ship, issuing orders to AI crew and other players, or help crew someone else's ship. As AI clones are phased in, they will be able to man weapons, pilot fighters and boarding craft, use laser rifles in combat, etc. Players will be able to do anything clones can do, and more.
Over time, multiplayer will evolve from individual battles to a persistent, open-world setting. Players will host servers, which will take the form of solar systems which they have a hand in designing. These server-solar-systems will be linked to other systems by warp gates. Ships can also be fitted with large, expensive warp drives.
Some of the solar systems will be "safe" systems, where battles are by invitation only and will be "simulated" - at the end of the fight, both ships will be undamaged. Players can wager in-game money on the outcome. Conversely, some solar systems will be dangerous, with PvP battles occurring at any time and ship destruction permanent. These systems may have some attractive feature to make them worth the risk.
An economy is expected to develop, both player- and computer-driven. Some basic raw materials will be available for sale from populated computer-controlled planets and space stations. Players will likely fabricate and sell more complex ship components out of materials they purchase, or mine and refine.
Secondary economic services are likely to arise as well. For instance, players may pay other players for taxi or towing services, mercenary work, and much more.
Player Companies and Guilds
Companies will also rise and, hopefully, thrive. More can be found about companies here.
**Warning: Technical Content!**
When multiplayer battles become possible, there shouldn't be any technical limit on battle size, but there probably will be a practical limit based on client hardware, server hardware, and available bandwidth. Most calculation will be done on user hardware, with the server merely checking random frames to ensure that no funny business happens, so combat should scale pretty well hardware-wise. Thus, bandwidth or client memory will likely run out first.
The server won't transmit voxel data, but will rather re-create it on each machine; thus, the server need only transmit and store a handful of bytes per block, and that data is easily compressable.