On Radiation, Maps, and Sieges
Preface:
Station sieges are set to be a landmark feature in Starbase, but there are many facets of them which remain murky or as-of-yet wholly undeveloped. Additionally, there are a handful of requisite systems which are clunky or could use polish. In this thread, I’d like to describe a system that would hopefully smooth those rough points, utilizing existing concepts and systems as well as a few new ones.
Broadly speaking, these concepts are not exactly new, but I find it helpful to get my own thoughts into some form of coherent order.
Radiation
Detectable radiation forms the basis of many game interactions, including the majority of those listed here. It is imperative that radiation and its detection be carefully balanced to provide options for play and counter-play alike.
Generation of Radiation
The generation of radiation should come in three forms: active, passive, and ambient. The distinction between active and passive radiation is made as some cases do not need to be frequently calculated and updated, as they produce a static emissions value by simply existing. However, this distinction does not necessarily extend so far as to make them unique sub-types of radiation; each type is merely a layer used to determine the strength of emission in a particular area. Additionally, distance could and should play a part in detection, reducing the strength of the radar return over great distances.
For performance reasons, some simplification may be needed. Radiation sources should likely be omnidirectional and detection should likely be without occlusion (excepting titan asteroids and moons). Each client could periodically calculate the emissions value of its hosted constructs and nearby objects, and upload it to the server for distribution. Distributing it directly to nearby peers is possible, but it may be less than ideal if the maximum detection range ends up exceeding the peer connection range.
Active Radiation:
Radiation is actively generated by (most) devices that generate or consume electrical power, and the magnitude of emission would be exponentially proportional to the quantity of electrical power generated or consumed. Devices like generators would be a constant source of emissions while active, whereas a device like a laser cannon would produce a spike of emissions while firing (ignoring upkeep charge for the sake of comparison). This is also the sort of radiation that an active transponder, radio transmitter, or (active) radiation scanner itself would generate.
Making the magnitude of emission be exponential to the quantity of electrical power is a conscious decision made to add options to play. As an example: A player would need an array of at least twenty solar panels to match the output power of a single generator unit, but if the radiation emission is thereafter equal between the two, the solar panels would continue to be a non-option for all but the most stringent edge cases. This would also allow players to make the trade-off of having a larger number of generators run at a lower consumption rate to reduce their detectable emissions, as opposed to running fewer generators at a higher consumption rate and producing a stronger emissions value.
Optionally, the generation of detectable emissions could be biased slightly towards generation devices over consumption devices. This would make the system slightly more forgiving, and allow mechanics like coolant dispersion to generate less of a detectable emission (if at all any).
Passive Radiation:
Radiation could also be generated passively by some devices and objects, like fuel rods, hot coolant, active endoskeletons, or plating made of a particular type of material (exorium, for instance). These emissions would generally be weaker than devices which belong to the category of active producers, but they could contribute a noticeable emission if accumulated in the same area. As passive radiation would be a binary result, and as the game already handles excessive debris, performance impact should hopefully be minimal.
Ideally, a special inclusion for asteroids would be made. This would enable them to produce radiation signatures at a magnitude matching their composition and size, which – apart from being generally useful data – would also add noise to detection.
Ambient Radiation:
Ambient radiation is produced by the general environment, calculated by the particular region of space with some degree of randomization to keep things interesting; as an example, an exorium hot spot region would produce more emissions than a region devoid of any asteroids at all. These emissions are omnipresent throughout the region, and form the baseline of radioactive emissions. It’s important to note that this would not need to be a rigorously tracked or synchronized feature, as it should be relatively uniform and unlikely to give an advantage to any particular player.
The intent behind ambient radiation is two-fold: It provides a basis for wide area mineral scanning, and it acts as a dynamic ‘cover’ for spaceships. A very low power spaceship could feasibly blend into the background radiation of an exorium field so long as its operator is careful to manage their emissions, but they may be more detectable if they cross into a region of ice (or some other material that produces lesser ambient emissions).
Optionally, this could also work its way into a rudimentary form of ‘weather system’ (especially considering the existence of belt lightning). Periodically, regions of space could be subject to a form of radiation storm that greatly boosts the background emissions in those areas and obscures even large ships - or the opposite, reducing background emissions and making it impossible to hide.
Counters
The option to conceal radiation emissions is an interesting one, and one that bears consideration. For example, a stealth ship could benefit greatly from some form of heat sink which would - for a time - contain those emissions, and there are some materials such as lukium which have been said to block radiation. It could be computationally expensive to have a system of occlusion like this, but certain alternate versions of devices could be made of these materials and simply produce a lower active emissions value. Alternatively, to reduce duplicate assets, a sort of multi-purpose item like lukium cladding could be designed, which would apply to any particular device to reduce its emission characteristics without significantly altering its visual characteristics.
Radiation Detection
Since radiation will invariably play a significant part in gameplay, I feel it needs to be readily accessible to the average player, and not outright rely on player-designed systems such as ISAN. That being said, YOLOL outputs can and should exist where preferable, allowing expansions to the system as desired.
As before, I see a benefit to having at least the two types of detection, being passive and active scans. For the initiated, these would be roughly equivalent to sonar – but first, the devices themselves.
Modularity
Scanning would rely on three distinct devices: a listening device, a broadcasting device (these two could also be merged), and some form of terminal for visually interpreting the data. This could exist as a simple UI window unattached to any device, but that seems less cool.
The listening device would be a static device visually similar to a mast sensor, and is the component that stores and calculates positioning of emission sources. For players only wishing to use passive sensors, this and a terminal are all that are required.
The broadcasting device is one that periodically produces a waveform within a directional cone, nullifying the majority of ambient noise and measuring active and passive emissions sources as it travels. It has an internal capacitor that must charge between pulses, which naturally can consume more or less energy depending on the configured sweep of the scan, and acts as a limiter on polling frequency. These could be aimed via traditional turntables and cradles, though a purpose-built cradle would be preferable. It’s possible that these devices could have a wealth of modularity of their own to allow players to deep-dive on them (eg, a specific shape of radar dish), but that’s scope creep.
The terminal would be a device which allows players to visualize the radiation detection mechanics. It could also automatically tag known vessels and stations (eg, those belonging to your company and those with public transponders). The terminal would allow players to pan around the visualization of radiation sources, pivoting around the ship which the devices are mounted to. For performance reasons, this may need to be a UI window instead of something realized in the physical game world, but I also think it’d be mega rad if it was visualized as a sort of spherical holographic map. Bonus points if it can be scaled up and down to fit ships of varying sizes, with YOLOL inputs to control the displayed orientation. See 'Visualization' section below.
Passive Scanning
Passive scanning is a complement to visual scanning (that is, using your eyeballs to look for stuff – very technologically advanced stuff), and produces no detectable emission beyond what is required to power it. Polling rate could be tied to a minor increase in consumed power, but it may also be preferable from a performance perspective to limit their update frequency. They produce a ‘fuzzy’ but usable radar image within their effective range, but as they are strongly subject to the whims of ambient emissions, accuracy quickly falls off beyond a certain distance. This means that – while at range – stealth ships or stations/capital ships with low emissions output can feasibly go undetected.
Passive scanning forms the basis of all radiation detection, and produces a radar image in a full sphere around the sensor. However, its effectiveness tapers off after a relatively short distance.
Optionally, if a ship stays still for an extended period of time, successive passive scans could ‘enhance’ each other and provide clearer and clearer images as time goes on, simulating the use of pattern recognition to filter out background noise.
Active Scanning
On the other hand, though active scanning can produce only a small slice of the sphere, it does so with much longer range and better clarity than a passive scan by nullifying a significant portion of ambient emissions within its sweep angle. A player using an active scan is much more likely to find hidden stations, ships, or capital ships, but also risks their own position as the scanner will produce a distinct emission of its own – kinda like sonar.
Visualization
I’m not sure there is a truly simple way to visualize scanning, but I’d be happy to take cues from other games. EVE Online has a similar system in directional scanning, which represents the scanning envelope as a cone, and highlights things such as ships and wrecks. Barotrauma uses a traditional passive/active sonar system, but periodically introduces visual glitches and anomalies in the form of currents and flora clouds, among other things. Both are exceptional examples, but Starbase poses an interesting challenge as it is both short range and has few non-player-driven elements – that is to say, anything that is moving is a player – and so if the radar is too clear, it effectively becomes a 5km wide ESP. However, a visualization which is too cluttered and chaotic renders the scanning practically useless. The intent should not be to completely obscure real radar targets, but only to inject a small dose of chaos to sow doubt and enhance the experience for both parties. Was that blip on the radar an enemy player turning their generators on, or was it just anomalous noise? How slowly does a ship have to move to stay completely invisible on radar?
I think the key is in the ambient emissions layer, and it being visualized as a sort of ‘static undercurrent’. By introducing a variable baseline, the game can have areas which have more or less ambient noise on the radar output, making them naturally safer or more dangerous to operate in. It creates additional gameplay options for ship designers during creation and new scenarios for their pilots out in the field, and makes stealth a viable alternative in gameplay: Pirates can sneak up on miners, miners can sneak past pirates, etcetera. I’ve put together a rough visualization for this, but I’m sure there are things that could be done better. You may need to right click and open this as a new tab to view the full resolution.
Here, the brightness and the size of a particular ‘blip’ corresponds to the strength of the radioactive emission and the bounding box of the object emitting it: A small, bright, and sharp dot indicates something that is almost certainly a ship or station with strong radioactive emissions, whereas a large, dim, and diffuse dot likely indicates a large asteroid or debris that is producing only weaker emissions. Variations between these extrema exist according to natural properties – eg, a small asteroid made of a highly radioactive material might look like a ship from afar – and differentiating between the two is a skill that players will need to develop. Throughout the visualization, ambient emissions make up a considerable portion of apparent detection, but it’s important that they be indistinct enough that they can be seeded at random without needing to be replicated across clients. Additionally, the fluctuation of the baseline would mean that they appear to fade in and out over the course of time (especially at a distance), or even move naturally, and this inconsistency would be ideal to ensure that they do not provide an advantage or disadvantage to any player.
Here, I've put together a mock visualization of strong ambient emissions causing display artifacts and masking the same set of emission sources. It's important to note that I would consider this to be an example of extremely high ambient emissions, and that ordinary gameplay would fall somewhere on the spectrum between the above and below examples. You may need to right click and open this as a new tab to view the full resolution.
Game Map
A very decent version of a game map exists at isan.to, but its information is limited and for obvious reasons it is much more preferable to have the map be part of the game itself. Still, we can iterate upon their design to eliminate a lot of busy work.
Note: A game map and an emissions scanner should be considered distinct features, and the former should not contain elements of the latter.
Fog of War
As the map does not track other players, it would be devoid of details and a player would not be able to locate stations, ships, or players by simply panning around it at random. By default, the map would only have markers for important developer stations like Origin, the moons, the moon city, etcetera, and there would be no option for omnipresent player-generated public markers in order to cut down on visual clutter and the like.
Optionally, there could be a ‘layer’ to the map to show or hide player stations previously discovered by the player.
Precision
The map would be designed with some limitations to labeled resolution, and would be broken down into sectors of a predetermined size – say, 10km3 just to make it easy. While a player could zoom in and view these sectors more finely, there would be no output coordinate data within them. X/Y/Z coordinates are a popular request, but I believe it suits gameplay more to not output precise coordinates via any particular means, as it would potentially dissolve the market for map data by undercutting the need for their saved waypoint data.
Transponders
Transponders which are set to broadcast publicly are visible on the map when they are within the player’s sector. Extra data such as the characteristics of a ship or station need not be made available, unless it is preferable to their operator.
Waypoints
In its most basic form, a waypoint is little more than a pointer on a map, and contains no information about the area or the circumstances in which it was created. It can be created on the spot via the universal tool or via a navigation data logger, but waypoints created at either are interchangeable. However, a navigation data logger possesses the singular ability to write navigation data – waypoints – to navigation chips, allowing the distribution of navigation data through a physical item which can be bought, sold, traded, etcetera.
Using a navigation chip via the usual warp terminal allows a capital ship (or other warp-capable ships) to warp to the precise spot at which the waypoint was saved, as opposed to the sector-wide randomized landing. A navigation chip would be able to store many waypoints, and the data on them could be modified at will via a data logger or similar device (ie, you can’t just type in a random location and get a waypoint). As physical devices, a captured navigation chip is a potential goldmine of information for would-be pirates and for factional warfare alike.
Optionally, waypoints could generate an on-screen marker for the player to navigate to directly. Sectors selected in the map could also have such a marker, but it would point to the general area of the sector rather than any precise location.
Surveying
Working in unison with the aforementioned active radiation scanner, a navigation data logger could ‘enhance’ a saved waypoint by surveying the surrounding area. Beginning a survey and utilizing the radiation detector would, over an extended period of time, scan the surrounding area and commit details of the waypoint’s environment to the navigation chip. Both of the volume and the duration of this scan would naturally be dependent on the ship performing the scan, as it is their radiation detector which is being utilized. A ship using a high power active survey would finish more quickly, but generate vastly more emissions which other ships could detect; conversely, a low power passive survey would take significantly longer and perhaps not detect as much of the environment, but it would be the subtler option. This survey would include notable details such as estimations of ore yields and gaseous concentrations, and potentially include player constructs in the area such as stations, capital ships, and regular ships. It is important to emphasize that the survey would only indicate estimations, both of ore yields and individual player activity, and would not necessarily describe their locations with any specificity. The exception to this would be constructs with either public transponders or safezones active, on the understanding that both are readily apparent to the unaided eye anyways.
Optionally, for the purposes of detecting stations/capital ships/etc. it could be possible to have an “enhancement” phase to the scan. Initial scanning would only indicate that there is a safezone in the sector, but its exact location would only be slowly revealed over time, or if the active scan happens to illuminate it. As a visual, imagine a point map which is slowly reduced to a single point (the station/capital ship). This would give defenders time to detect and attack the encroaching scanner before it is completed, in order to preserve the anonymity of their location.
As a sidebar: Ideally, this would utilize the same radiation detection mechanics as the rest of the game – no power means no radiation means no chance of detection – and players would have the ability to partially or perhaps even wholly mask their presence in an area if they invest in it. More on that some other time.
Company Usage
It would be ideal if companies were able to share waypoints with their members so long as it is beholden to a granular permissions system. For lack of a better option, I think a station-mounted device that accepts navigation chips and can thereafter broadcast the waypoints to company members within range would work. This would not only make company waypoints a valuable physical asset which is worth protecting, but perhaps also eliminate some crude bypasses in sharing limitations.
Sieges
As a final note, I think these systems would lend themselves well to sieges, but this has already dragged on for quite a while, and so I’ll focus on the process of beginning a siege more so than the siege itself.
Capital Ship Navigation
Currently, capital ship navigation suffers a well-meaning but unintuitive process of operation, requiring the player (or another) to explore an area first before they are able to move their capital ship anywhere at all. While this has opened a niche market in the trade of navigation chips (and one which I would like to preserve via the aforementioned waypoint chips), I believe this comes at the expense of the flow of gameplay. Instead, navigating with a capital ship would be overhauled to allow unconstrained travel, permitting the player to navigate via the map in a ‘click and go’ manner (or, schedule a warp, etc.). The precision of these warps would be constrained by the same precision of the map: without a waypoint saved, the capital ship will warp to a random location within the selected sector.
Starting a Siege
Currently, a capital ship will automatically detect all stations within a very wide radius of its location, and allow a player to start a siege on them even if they do not know the station’s actual location. While obviously this feature is not in its final design, I believe this sort of ‘magic’ detection should be curbed. Instead, I would prefer to see capital ships require a definitive location to siege, established either via its public transponder, a saved waypoint, or a sustained scan (see the aforementioned section about ‘enhancement’ phases) that has illuminated a station or capital ship in the area. From there, a siege would carry on as usual.
Tactical Map
Tactical planning is foundational to a good battle, but Starbase currently offers no real means of coordination. The game map could be leveraged to do so, allowing players to place temporary markers to indicate objectives, etc., or perhaps even extending to a form of grease pen that enables players to literally draw up battle plans to share with their company members. For sieges, this would almost certainly require some form of ‘preview’ of the station or capital ship in question, and it would need to be carefully designed to prevent unfair gameplay: being able to explore a station in precise detail from the safety of a UI map and find hidden emplacements, defenses, etc., would be extraordinarily unbalanced.
Last edited:
