ID:37089
 
A few nights ago, Garthor, Nadrew, Fizz, and I got into a discussion about a game concept. Basically you play on a server that emulates a battleship. Other hosted servers are opposing battleships. Via inter-server communication (possibly through a master server to keep things clean and validated), the two ships engage in a big sci-fi naval battle.

References to Space Station 13 were made more than a few times, since gameplay would be similar in some aspects. The idea's been sticking out in my mind for the past few days and, well, I want it to happen. I doubt it will, but I'm still trying to get a group of people interested together to start working on it. This is sort of a really, really rough "design document" that hopefully conveys the general gist of the game.

The interesting thing about having multiple-server communication is that we can eventually have more than one type of server. Right now it would just be battleships (perhaps different battleships, but battleships nonetheless). It's certainly feasible to include planet or space-station server types later on (with gameplay working on a larger level for planets, a'la Sim City).

Anyway, here are some notes I scribbled down on the thing:

-=-=-=-=-=-=-=-=-=-=-=-=-=-

Each hosted server represents a single entity. For the purposes of this document, we'll be discussing the battleship server type, though more may become available as things progress (space stations, planets, etc.) All entity servers connect and validate through a single master server.

Red Shirts – Obviously battleships are going to require a large crew to run effectively. Chances are, however, that you will not have 30 players to a server. That's where the Red Shirts come in; They're your generic throw-away NPCs that perform menial tasks and take the place of players should none be available. Red Shirts are generated and removed as dictated by player joins and disconnects. Command privileges over Red Shirts will be given to anyone of the same role as the Red Shirt in question. The Captain is given command over all available Red Shirts.


Ship Layout

Ships will consist of rooms, corridors, and infrastructure. Rooms won't be defined by /areas, but instead will be recognized by relevant objects within them (or lacking that, a dummy indicator flag obj.). The boundaries of the room can be determined by checking the relevant object's orange() and acting as a sort of “fill” tool (MSPaint, Photoshop, whatever) with an open-space tolerance of 2 or 3 (that is, any boundary with less than 2 or 3 open spaces within it is considered a wall of the room.) This is done to keep with the dynamic nature of the ship design, since rooms can be added, removed, or modified during runtime and the game needs to be able to recognize those changes and act accordingly.

For simplicity's sake, power and data are supplied via one cable (ships of the future run on super USB!) which is “in” the walls or under the floor and can be exposed with the proper tools. Wires can be spliced, rerouted, and clipped and may be connected to devices as needed. Data packets literally transfer along them (each section of wire receives the packet and forwards it to the next section.) Technicians can use this to their advantage and, for example, provide an emergency power supply to shield generators should the default supply not be enough.


Potential Roles:

Captain
The Captain provides direction to the rest of the ship. The overall, long-term goals of the combat are put forth by him. The Captain also has free reign over all Red Shirts available to the ship and decides how many should fill each role. The entire ship and all of its functions are open to him, including those that no other role can access (Scuttle, partial self destruct, and terminal safety overrides, for instance.)

A Red Shirt may not fill the Captain position. If the role is empty, it becomes available as a player choice. In the meantime, Red Shirts are set to wander/panic until calmed by a player with command privileges over them or a new Captain is assigned.

Sensor Operator
Due to the dramatic distances between the player-ship and the opposing ship, players must rely on sensor data in order to understand the current combat situation. There are no “omni-sensors” in that there are no devices onboard that can simply be fed a target name and reply with exact and accurate health, energy, ammunition, manpower, and location data. Instead, there is a large suite of sensing equipment made available to Sensor Operators, so that they may gather and interpret any recorded data. The Operators then pass on that information to be used by the rest of the ship accordingly.

Potential Sensor Types:
-Electromagnetic
-Radiowave
-Proximity
-Heat
-Infrared/Ultraviolet/Visible Spectrum


If a Red Shirt fills a Sensor Operator position, the server interprets the data with a random error-rate (from light to severe). Data posted this way will always be less up-to-date than if a player was doing so.


Gunner
Gunners further interpret data provided by Sensor Operators and instruct the gun batteries placed under their direction on where to fire (and when, and how much, etc.) This holds true for both long-range weapons and short-range defensive devices. A player Gunner may attempt to target specific regions of a ship or use their fire to force an opposing ship into a certain course. Enough variance within the weapons settings should make the job more interesting than simply turning up everything to maximum power, setting the target to the enemy's bridge, and spamming a fire verb. Much of a Gunner's effectiveness relies on the accuracy of the target data they're provided.

Red Shirt Gunners will take a random registered and validated (by a Sensor Operator) target and fire at it as often as the weapons they control can safely fire. Specific targets may be focused on if a player instructs them to do so, but accuracy will always be better if a player Gunner is behind the controls.

Engineer
An Engineer will spend most of their time balancing between retrieving and storing resources, traveling to various work sites, and putting those resources to use. If a portion of the ship becomes damaged, an Engineer can be dispatched to begin repairs and damage-control. They have the ability to affect the ship's topology, though major changes require large amounts of manpower and time (which is likely better spent on smaller, more pressing tasks than renovating.) Terminals can be tweaked or repaired and conduits may be rerouted or disconnected by an Engineer.

If a Red Shirt fills an Engineer position, they wander the ship until a damage report is registered and announced. The job will be processed much more slowly by an NPC Engineer than its player-equivalent. Changes to be made to the ship (building a wall to seal off a very large hull-breach, for instance; or setting up a secondary command center after having lost the first one to a fire) will not be available if no player Engineers are active.

Fighter Pilot

Should a ship come equipped with a fighter bay, smaller one-man fighter ships will be available. Players can sortie in either the immediate space surrounding their home battleship, or the proximity space of an opposing battleship. Left unchecked, fighters can cripple starships by targeting specific areas of the hull and repeatedly damaging them, potentially disabling critical systems. Pilots may also fly slightly larger freighters in order to deposit troopers intent on boarding and capturing/disabling the enemy starship.
Potential Available Ships:
Fighter Ship
Freighter/Troop Transport
Sensor/Utility Craft
(Possibly combine this with the Freighter? Worked for BSG.)


Red Shirts will scramble fighters if instructed to do so, but will mostly serve as “fodder” while bigger and better things happen around them. Expect sufficiently skilled player Pilots to penetrate the Red Shirt fighter-wall you've established on the perimeter of your battleship. Red Shirts will also attempt to deposit troops on enemy ships when commanded to. More complex missions will only be available through players (Scanning runs, precision operations, and so on.)

Trooper
The only role afforded a weapon in their default kit, Troopers provide both a necessary defense and a powerful offense if used properly. No number of gun batteries or high-energy shields can save a battleship from being captured by a group of Troopers that have successfully boarded it. Troopers needn't be front line grunts, however. They can also serve a more specialized role as covert operations specialists. A lone Trooper slinking through the innards of a Starship may strike with a deadly accuracy that an entire platoon storming the halls can never hope to achieve. Troopers also stand to defend against opposing insurgents, ensuring that the other crew is not threatened from within their very own ship.

Red Shirts may be assigned to Trooper roles and will happily serve as sentries (a potentially boring task if nothing's going on) until otherwise commanded. Red Shirts may also accompany a player Trooper on a boarding mission, but cannot initiate one on their own.

(Feature Creep: Instead of forcing player Troopers to get on troop transports that may or may not be destroyed in transit (thereby killing the player for attempting to fulfill their role without actually getting to do anything), it may be worthwhile to place them in a 'queue'. When a troop transport successfully boards an enemy starship, the Troopers in the queue are informed and given the option to join the party or remain where they are.)

Medic
I'm a bit ambiguous as to whether or not I should allow this as a player role. Medics provide in-field and long-term care for wounded crew. This role could be exceedingly dull, however, if no one is actually hurt. If the battleship's shields are holding up and there are no boarding parties onboard, it's unlikely that anyone will need a Medic's services. When the time of need does arise, though, Medics can treat wounds on-the-spot that would otherwise debilitate a crew member. Given the proper equipment (such as that found in most Medical Bays), they can restore a patient to near or perfect health. Perhaps a DNA system like the one found in SS13 would provide some distraction during down-time, though I think perhaps additional drug and bacteria systems might add to the fun.

Red Shirt Medics should be sufficient for most starship's needs, unless the majority of the crew is wounded, in which case one or two player medics might help remedy the situation faster. Their only limitations are their pathfinding AI.

-=-=-=-=-=-=-=-=-=-=-=-=-=-
I really liked the ideas you guys were coming up. Should be fun if you ever get it made.

People in Chat: Development team from hell, amirite?
Red shirts are a homage to startrek I assume.
The only problem is that server hosts can easily lie about where their ship is to the other ships. So somehow they will all have to be connected to a central server.
GoodDoggyTreat wrote:
The only problem is that server hosts can easily lie about where their ship is to the other ships. So somehow they will all have to be connected to a central server.

Well, that's the reason for the master server. Any events that influence events external to the ship (rather, any non-internal occurance), are sent to the master server for validation and processing. The ship-server only tracks its position as a means of keeping traffic overhead down, it still receives periodic position and status updates from the master server that "keep it honest".

Would hashing or otherwise encrypting the communications between servers cause much processor overhead? Am I right in thinking this would help to deter "packet spoofing"?
Evre wrote:
Would hashing or otherwise encrypting the communications between servers cause much processor overhead? Am I right in thinking this would help to deter "packet spoofing"?

Probably wont take up too much CPU, and it is a definite must. Even the most idiotic of script kiddies can packet spoof.
Hashing and encryption together would be useful. I have a decent encryption algorithm in FE5, and Mike H (under Airmpaster) has Crypto.RC5.preview.
Sounds like a hell of a lot of fun.

Boarding Action anyone? :D
That does sound fairly easy. Two servers could engage in a battle, someone else starts up a third server and suddenly you have three ships in a fight to the death.

I like the concept a lot, but it would take a -lot- of effort.

You could even take into account small one manned fighter type servers. One decent hit from a larger server (battleship) would kill it thus causing a server shutdown but, it'd be fun for those who don't want to work in a team, and are just after some hard-code text-based battle action.