- making communication infrastructure worthwile
- making it simple and transparent to use
- not penalizing casual players, but providing advantages to strateges who care about it
- making it not a strict on/off affair but something more continous
- making comms jammable
- making communications something you can trade with
- bonus target: making some useful engine-implementations possible
the basic idea is that every ship needs some amount of communications bandwith to transfer all its relevant (and in-game viewable) data in real time.
So a small fighter does maybe need 1megabit/second to transfer all its status data in real time
and a big battleship may needs 1gigabit/second to transfer everything.
This amount should be roughly proportional to the amount of memory the ship needs on the RL computer you are playing LT on (more on that later).
Bandwith is proportional to distance, so close up you have practically limitless bandwith, but further away you get lower throughput.
So what happens if you dont have enough bandwith available?
The fidelity of your data gets lower.
So when you run out of bandwith, the amount of data sent gets reduced to maintain the real time capability. It also reduces the precision you can give orders.
So on full bandwith you may get all positional data, rotational data, exact energy statistics etc.
basically everything you would know if you sit in the ship yourself.
On somewhat reduced bandwith your data gets more abstracted, you only have basic data, approximate position, supply state. Kinda halfway between an RTS and the map view from one of the X-series game. Your control is ~at the level of an RTS game, go there, attack this, mine there etc... but not as precise that you can remote control turrets or control the precise course of the ship.
On very low bandwith available it gets boiled down to 4X like detail.
General position of the ship(s), supply state, health state, amount of ships...
so a fleet gets boiled down to a blob on the system map without much positional detail in it.
Ordering gets abstracted even more, move to this planet, mine this asteroid field, attack this fleet etc.
so after establishing bandwith and the associated ramifications, how do we actually transfer data?
The in-game devices are logically transmitters.
Transmitters provide some interplanetar and interstellar communications capability.
The interstellar capability is for a given module size always lower than interplanetar.
Because it makes actually being at a combat always advantageous (except you have an big, high-bandwith 4C ship in your fleet, acting as router. And also acting as a big, juicy target )
bigger ships have bigger transmitters, bigger energy needs and bigger signatures and are a bigger beacon if communicating.
Communications can be jammed, reducing bandwith available to all transmissions affected.
By any means that seem fit, targetted jammers against specific ships, area jammers affecting everyone in the area.. you get the idea.
This gives you an advantage by attending combats, you have better control over your ships.
But getting you into danger.
Or you can stay out of your combats, but may loose connection to your ships.
This also makes routers viable.
You may set up an large station, containing lots of interstellar transmitters, holding your empire together.
To provide long-range communications to smaller ships and even fleets which dont have enough bandwith themself.
The C4 ship class comes quite naturally from this, C4 ships would mainly consist of transmitters and generators to keep them running, providing high-bandwith comms inside the fleet and to the rest of the faction.
Of course they shine like a sun when in action, as they are putting mega or gigawatts of radiation into space...
every ship should have some (from a gameplay perspective) indestructible or at least self-repairing communications device. This device is also powered by some emergency energy source.
So in practice every ship has an always functioning basic communication device, which cannot be disabled permanently from outside forces.
The pilot may deactivates it from outside communication, but this only deactivates long-range comms and non-faction contacts.
Basically going stealth, as comms devices should emit radiation based on the bandwith needed/provided/used.
so now that the underlying mechanic is defined, how do we actually control it?
Edit: The whole "pipeline" structure of communications is equivalent to real-world VLAN or SDN
For those too lazy to read the link:
pipelines are abstracted constructs designed to deal with streams between stations and ships. Designed to be easy usable and easy to manage and overwiev.
Initially i designed it with ware transport in mind, but communications is predestined for an equivalent system. Instead of freitghers you assign transmitters / bandwith to the pipelines.
Every ship and station is a node in a network of different streams or channels.
These channels can have different levels of access.
You may set up an channel for everyone, the „public“ channel, which everyone can access, the Internet of LT resides in and one uses to communicate with unknown or far away NPC's to whom you may not have an direct link but the public channel.
Or you may set up an channel only for your own assets (which should happen automatically) or even sell bandwith to an NPC customer (or buy bandwith from an NPC).
Im currently not sure about if bandwith allocation should be fixed.
So that you cant sell 20mbit/s for an channel you already sold 50/60 mbit or if everything should be allocated dynamically and by assiging priorities to channels
(default: owner channel > sold channel > public channel)
so that you may sell 70mbit of an 60mbit channel and the channels get allocated by necessity and priority.
Both may works, i just word out my thoughts on this.
Channels automatically connect.
So when you are in range of an station that provides the public channel, and you have enabled the public channel on your ship, you automatically connect to it.
Limiting micromanagement to selecting the channels you want to connect to, and not on router switching.
You may also create firewalls and crossovers of channels inside network nodes.
So you may connect the public channel to your corporate network through an firewall, providing the same services the public channel has but only for your own ships (or approved NPC's).
Crossovers are limited by the bandwith of the node through which it is routed.
So if you want to connect your corporate network to the public network with an 1Gbit/s node you may only ever get 500mbit/s transfer rate. Ever. (500mbit in from your corporate net + 500mbit out to the public line = 1Gbit).
You can assign any node any channel.
So if you dont want the public channel on your secret military base, just deny it in your connection to the „main“ private channel inside the settled areas.
(if it even has a connection to „mainland“, which is advisable. As otherwise you only command your base while being there, instead from everywhere inside the „mainland“)
Advanced (optional) Gameplay / Hacking
this section is not vital to the rest of the proposal and can be removed without affecting the main proposal.
its based on the thoughts in here
channels, such as when one NPC communicates with another, or the player commanding an fleet, can be backtracked.
Basically where the information comes from and where it goes.
This requires hacking (however this is implemented) one of the endpoints or one of the nodes actually involved in transferring the data. By backtracking the channel in either direction some bandwith need gets added to the channel, representing the tracking programs and their information streams.
This channel widening can be detected and acted upon, basically backtracking the backtracker.
To make it actually a game, and not an „i win“ function.
If this connection goes through a firewall, you have to hack through it. If you fail in hacking the firewall you either simply cant proceed or get maybe detected.
you may assign an specific point-to-point connection from the station containing an blueprint (/prototype/however it is called now) to arbitary production stations or research labs.
So you can either produce on stations without shipping assembly chips(/blueprints/....) to the stations or produce assembly chips there, increasing your chip production rate.
But this comes at a cost:
the p2p link takes a lot of bandwith, limiting the communications capability of all stations routing the link and it makes you vulnerable in cyberspace.
Via combinated backtracking and hacking an enemy hacker may establishes an link to an station of his choosing, siphoning construction data.
Enabling either straight up production of the good or enables production of assembly chips.
It does provide the complete blueprint data, to make stealing it still an necessity to get the physical copy to get full access to the technology.
P2P links are just digitalised assembly chips, not the full tech data.
Hacking communication channels may enables other stuff that comes with hacking.
Such as subsystem control, sensor readouts etc....
but i wont go into depth for this here.
as i earlier said, i'd make the bandwith needs for a ship roughly proportional to its RL memory needs.
Because now we get an clear metric of how far we can LOD ships.
If you only have low bandwith to an ship you can LOD and abstract it away, as the player nevertheless has more information about it than what comes through the comm lines.
So it can as well be LOD'd
- making communication infrastructure worthwile – done, you get rewarded for building comms
- making it simple and transparent to use – i regard it as simple, as you dont have to manage more than you want to
- not penalising casual players, but providing advantages to strateges who care about it – casuals may only use the Public channel (with limited bandwith) and strateges can build high-bandwith connections to the assets they need to control tightly
- making it not a strict on/off affair but something more continous – we have different grades of connection quality, removing the simple on/off issue
- making comms jammable – done
- making communications something you can trade with – you can trade channels with NPC's, for mutual benefits
- bonus target: making some useful engine-implementations possible – done (ehehe)
in the light of the current devlogs (14/15.5.2014) i developed an new addition to my system
Discrete Data is everything that is not real-time dependent
Maps, Eventlogs, Blueprints etc.
Those are stored aboard Ships, Stations and planets in Databanks.
this storage is limited, and different kinds of data need different amounts of data
- ship type signatures take the least amount of data, as every other datatype contains one or more instances of this type.
an event log may has 2 signatures in it, for the 2 ships participating in a fight (or any amount of signatures...)
this data is not per-ship but per ship-type. (not about han solos YT1300 freighter but about the shiptype freighter YT1300)
(im a bit torn about this myself, but im adding it in because it has to be in here out of logic)
- Event logs need a bit of storage space (they are essentially just a piece out of a Map)
- Map Data need an medium amount of space they are snapshots of the streamed data you'd have to transfer in real-time otherwise
- prototypes cannot be copied, blueprints need an considerable amount of space
the more bandwith you have available the faster the transfer becomes.
(transfer time = data packet size / bandwith)
copying takes roughly the same amount of time as transferring it.
Data is initially bound to an specific piece of hardware, which is protected by hardware means of illicit copying.
this means that you can only access it directly, that means only the ship or station carrying the data disk can access its data.
if you want to be able to access the stored data remotely you have to transfer it to an general purpose databank.
the general purpose databank is much less efficient in terms of volume/mass density but it provides the convenience of remote access.
prototypes do not permit copying of the actual research data, but only allows databank copies of the actual production data.
this production data can then be sent by pipeline means to other locations or be used locally to make assembly chips.
but the convenience has an drawback: as the data is not encoded in non-networked hardware anymore, it is hackable.
so you trade security agains convenience.
data is now an thing with an physical location, instead of being something abstracted that is available everywhere and can never get lost.
so if you loose your databank station which contains all your maps and blueprints, you loose all of it.
this has different ramifications:
you cannot store all your map data in the smallest ship you can find.
you actually have to store your data, and this needs an databank installed in your ship.
if you have enough bandwith to an database willing to store your data you can move your less important map data there, ready to be fetched when you need it.
if you are in range of your database you always get an index of all systems you have data about including connections (if known).
nothing about the actual systems. only that they exist and that there are connections between them.
when you zoom in to an actual system the data then gets streamed to you, refining on the go as you receive more of the data.
your ships may also access this data, based on where they are and which access rights they have (see next paragraph), with otherwise the same limitations the player has.
this also makes secrecy before your own people possible.
you may not include the map data to your secret military base in your mining barges.
but the ore freighters most likely have the data to valuable ore fields.
so to obtain secret military data one would actually have to hack an military ship, which would need the data themself in the first place.
or they hack through an number of routers, trying to find an ship that has the data.
you may transfer your construction data via your communications net, but that makes you more susceptible to data theft, as there are more points of entry for thieves to get in.
either physically or through hacking
Typed Communication Links
you can determine which type of information can go along a pipe
want a link dedicated for trade information?
only market data can pass
want a standing link to your map vault?
make a pipe which is limited to map data.
you can include or exclude any number of types of information (how many types will it be in the end)
and also give them priorities inside the pipe.
(in case you are just commanding around your fleet in a combat and one of your traders starts to clog the line with trade data from the fought system...)
get used similar to firewalls, but you can determine under which conditions NPC's can communicate through the link
only want friends to communicate through?
set the condition to relation > 80%
want to have them pay for it?
relation > 80%
5cr / minute
this makes trading and selling of communications capability very fast and easy
if you want to facilitate trade and get some spoils of it,
create a trading information line
put a paywall between it and the public line
and charge anyone who wants to use it.
if the AI creates such lines this should be "advertised" to the player, for example when he wants to get trade data the network gets analysed and scanned for faster routes through the network
then a small "pop up" could be created in the corner of the screen
[faster trade data 5cr/min]
minimising hassle for the player
actually, paywalls could just be a setting on firewalls
condition set to "only faction" -> firewall
condition set to "x cr/min" -> paywall
finally i'll quote Bele here
Code: Select all
<@Bele> its a pretty neat idea <@Bele> I hope Josh doesn't decide we need this <+Cornflakes> i intend to convince him :lol: <@Bele> we've had enough feature creep <@Bele> convince him to patch this in later :D
communications channels are pipelines that can be traded and allocated at will.
not enough bandwith reduces the amount of information you get from ships