Return to “Suggestions”

Post

Communications Pipelines

#1
after talking in bad news messages network and internet of LT about communications i came up with a couple of ideas.


Goals
  • 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
Basic Theory

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.

Advanced Theory

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.


Gameplay

so now that the underlying mechanic is defined, how do we actually control it?

Via Pipelines.

Edit: The whole "pipeline" structure of communications is equivalent to real-world VLAN or SDN
Spoiler:      SHOW
Image some explanation to the image:

the blue ships are civilian ships which all have the "public" channel node on them (the blue circle)
they automatically forward the channel to every ship in range (lower right corner)

the civilian ship on the left is not in range to any station or ship carrying the public channel, so it doesnt connect to anything.

the middle gateway station serves as entrypoint for both the military datanet and the civilian public channel.

while the military datanet can access the public channel through the firewall the public channel is not accessible for ships without military access behind the firewall
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

Channel Backtracking

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.

Blueprint Transferring

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.


Other stuff

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.


Bonus Points

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


Archieved Goals
  • 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)
Edit:

in the light of the current devlogs (14/15.5.2014) i developed an new addition to my system

Discrete Data

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
you can transfer data via the pipelines network, with the same limitations that you would expect from real life.
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...)



Paywalls

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 :think: :squirrel:
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


TL;DR:
communications channels are pipelines that can be traded and allocated at will.
not enough bandwith reduces the amount of information you get from ships
Last edited by Cornflakes_91 on Thu Jan 28, 2016 9:02 am, edited 13 times in total.
Post

Re: Communications Pipelines

#2
On-board with this, of course. :thumbup:

It's a minor point, but I'm not sure if I want ships to be able to transmit across interstellar distances.

"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."

I think you meant to say "it does not provide" here. :ghost:
Post

Re: Communications Pipelines

#4
Cornflakes wrote: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.
Self-repairing because the comms module has an assembler at its core that allows for limited repairs.

Emergency energy source because at least a minimum amount of ship power is always provided for a ship by its Heisenberg Extractor.

(ditto to every other essential system)
Post

Re: Communications Pipelines

#6
Cornflakes_91 wrote: i think some minor communications for interstellar should be provided in every ship.
not something that lets you control your fleets with tactical precision, but something that lets you at least care for your empire
Agreed Cornflakes.

Communication with NPC's is an important aspect of the game for myself, and anyone else interested in empire building.

Interstellar communication is needed to some degree. I don't feel like returning home to my core system, finding that a rival empire has moved in, without me getting some sort of feed back from my NPC minions.
My Signature
Post

Re: Communications Pipelines

#7
Zanteogo wrote:
Cornflakes_91 wrote: i think some minor communications for interstellar should be provided in every ship.
not something that lets you control your fleets with tactical precision, but something that lets you at least care for your empire
Agreed Cornflakes.

Communication with NPC's is an important aspect of the game for myself, and anyone else interested in empire building.

Interstellar communication is needed to some degree. I don't feel like returning home to my core system, finding that a rival empire has moved in, without me getting some sort of feed back from my NPC minions.
We're both proposing interstellar communication. The difference is just in the range that information can be sent by what Cornflakes calls a transmitter in this proposal.
Post

Re: Communications Pipelines

#8
Interesting...

Edit: and this http://fractalsoftworks.com/2014/03/02/on-trade-design/

On ipad ATM so hard to elaborate, but this is one very very good reason why josh needs to implement a comms system using routers and bandwidth and pipelines and such: to allow for the possibility that traders can keep up with the news being broadcast around the LT internet so that they know about events that might allow for profitable trade ventures. Not just traders. It other kinds of agents too.

To keep with cornflakes bandwidth idea, the more bandwidth that is available, the more news stories can be sent across the network and the more detailed they will be.
Post

Re: Communications Pipelines

#9
Without going into too much detail, I think this is an interesting idea worth exploring in combination with some other similar ideas.

In particular, I'm thinking of ThymineC's CPU Allocation suggestion. What that suggestion shares with Cornflakes's idea of communications bandwidth is that both become economic gameplay: you have limited resources and must make choices of what to prioritize.

If those choices are designed to be interesting, then you have the possibility of good gameplay.

So the implementation does matter. But just on its face, if there's fun in allocating bandwidth to different channels, and that allocation can't be switched instantly (otherwise it's not a meaningful choice), then managing this aspect of a ship -- or fleet -- could be one more form of satisfying gameplay in LT.
Post

Re: Communications Pipelines

#10
Flatfingers wrote:Without going into too much detail, I think this is an interesting idea worth exploring in combination with some other similar ideas.

In particular, I'm thinking of ThymineC's CPU Allocation suggestion. What that suggestion shares with Cornflakes's idea of communications bandwidth is that both become economic gameplay: you have limited resources and must make choices of what to prioritize.

If those choices are designed to be interesting, then you have the possibility of good gameplay.

So the implementation does matter. But just on its face, if there's fun in allocating bandwidth to different channels, and that allocation can't be switched instantly (otherwise it's not a meaningful choice), then managing this aspect of a ship -- or fleet -- could be one more form of satisfying gameplay in LT.

How about that:
It does not actually take time to switch channels or bandwith around but it takes time for the connection to reach full bandwith.

So that when you switch, you at first only have small bandwith, but this bandwith increases gradually to its maximum.

So you have an time delay for full capacity, but still some control when you are in dear need for it
Post

Re: Communications Pipelines

#11
Cornflakes_91 wrote:How about that:
It does not actually take time to switch channels or bandwith around but it takes time for the connection to reach full bandwith.

So that when you switch, you at first only have small bandwith, but this bandwith increases gradually to its maximum.

So you have an time delay for full capacity, but still some control when you are in dear need for it
That would work -- as long as there's a cost to switch, you get the benefits of economic (resource management) play.
Post

Re: Communications Pipelines

#12
in the light of the current devlogs (14/15.5.2014) i developed an new addition to my system

Discrete Data

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 an piece out of an 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
you can transfer data via the pipelines network, with the same limitations that you would expect from real life.
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
Post

Re: Communications Pipelines

#13
M-may I becro nump?
Don't force a spherical transmission. Use a cone with adjustable angle + some spherical excess radiation (cone < hemisphere < inverted cone < sphere). The narrower the cone, the less dataloss per distance. You want long range communication? Build a big arse sender with an angle of .5° or so and point it to where you want a stable connection (Maybe through Jumpholethingie?). Via research you could improve/reduce the minimal angle, maximal angle, speed to change the angle, excess radiation, most certainly forgot an imperial carpton more..
[hypes internälly]
Post

Re: Communications Pipelines

#14
i dont see much useful gameplay in that.

it just sounds like a royal pain in the ass.

*flying next to my big-ass C4 ship*
"i'll communicate with my fleet headquarters now...."
*doesnt work because the C4 ship doesnt look at me right now*
"why cant i communicate with my base?! there is a big COMMUNICATIONS ARRAY right NEXT TO ME!!"


the cone stuff could be additional to spherical comms, modifying your visibility when communicating or energy needs of the device

but with pased array beam steering, i dont think that any limitations to cone rotation rate or data rate should be included.

why i think that it doesnt really matter? because my smartphone is using that right now with my router :roll:


maybe some special purpose unidirectional comms devices, which can only connect to a single target at a time, but have higher effective ranges.
making them suitable for point-to-point communications between fixed locations
Post

Re: Communications Pipelines

#15
Cornflakes_91 wrote:i dont see much useful gameplay in that.
Maybe you want to send information to the HQ without being a beacon for literally everyone within the next 120 Miles around you.
Cornflakes_91 wrote:*flying next to my big-ass C4 ship*
"i'll communicate with my fleet headquarters now...."
*doesnt work because the C4 ship doesnt look at me right now*
"why cant i communicate with my base?! there is a big COMMUNICATIONS ARRAY right NEXT TO ME!!"
Sender != Receiver
Cornflakes_91 wrote:the cone stuff could be additional to spherical comms, modifying your visibility when communicating or energy needs of the device
Whilst being in a civilian area you'd most certainly use the widest possible angle (ergo sphere) anyways, as you'd probably not plan to transmit on a long range. If you were scouting, you'd have to be closer to your own ship than to the enemy, if you wanted to stay hidden and keep a constant connection.
Cornflakes_91 wrote:but with pased array beam steering, i dont think that any limitations to cone rotation rate or data rate should be included.
I may be understanding this fundamentally wrong in multiple ways, but you could just insert the coordinates of where your base or station or whatever is and have the device position itself.
Cornflakes_91 wrote:why i think that it doesnt really matter? because my smartphone is using that right now with my router
I assume that
A: You are in close proximity to your router
and
B: You've got satellite TV
Cornflakes_91 wrote:maybe some special purpose unidirectional comms devices, which can only connect to a single target at a time, but have higher effective ranges.
making them suitable for point-to-point communications between fixed locations
That's actually what I'm saying, with the slight difference that i'd rather have it as a generalised system. Allowing with the same concept unidirectional long range and short range omnidirectional communication.

Grammatical, conceptual and other mistakes may occur.
[hypes internälly]

Online Now

Users browsing this forum: No registered users and 12 guests

cron