Sensors, Scouting and Stealth in Battlescape

Battlescape
1

If there is an area of the game that I am hoping for some complexity and depth, it’s sensing the situation across the star system. How much info should be automatically available to everyone instantly? Hopefully very little.

Here is how I see it possibly working:

Facilities would have long distance broadcasting abilities (that could perhaps be partially disabled) that can broadcast some basic info about detected enemies and allies instantly across the whole system. Perhaps it would require line of sight, but satellites around a planet would allow broadcasts to be relayed in all directions. These satellites could be disabled, creating blind spots, (but disabled satellites would automatically set off a warning to all).

Sensors work by picking up EM/heat/light with line-of-sight and distance/intensity limitations. By switching off ship systems you can reduce the intensity of your EM signature. Using thrusters and much more so using warp increases the EM intensity greatly while they are active.

Ships would broadcast it’s own sensor data to nearby allies.

A module could be installed on a ship that rebroadcasts sensor data it receives to other ships at a greater range, creating a local sensor network.

Edit: Limited data would be broadcast system wide from player sensors (or just from rebroadcast equipment) so that basic data about the sizes of detected forces in the area is available to all.

Broadcasts can be intercepted by the enemy (allowing them to see what you see) using some kind of hacking/electronic warfare system. Enemies can then create false data (to a limited capacity) and broadcast that to you (or just eject decoys that would look like ships until close range).

Anyway these are my current ideas and thinking, what does everyone else think?

1 Like
2

I do believe what you’re describing is what the gameplay concept (from INovae) is about:
see http://imgur.com/gallery/0SoYN

3

I’d prefer to see something that doesn’t involve lots of configuration. Movement doesn’t involve fuel because movement is so fundamental to gameplay. Similarly, being able to see is an essential part of playing a game, so I wouldn’t do much with the sensor system.

The pattern that I’ve mentioned before is that players who team together see together. Place a limit on team sizes,but allow hierarchical teams. I can see the sensor data of those on my team and of those on the team that I lead. So at most I can see the sensor data from the individuals on two teams.

Because I want sensors to be reliable and predictable, I would not place a limit on sensor data transmission range, eliminating things like repeaters, sending data only to nearby ships, etc. I would also not allow hacking for the same reason.

If there are decoys, then the decoy effectiveness is directly correlated to the resources put into the decoy. If I put a ship’s worth of resources into a decoy, then it perfectly simulates a ship on sensors. If I put a fraction of a ship’s worth of resources into it - plus a little bit, then it will be spotted as a decoy from much farther out.

Decoys would never be entirely autonomous, requiring activity on the part of players to some degree. For example, perhaps a decoy can be told to go in a direction, but each turn of each decoy must be initiated by a player. Once people realize that decoys behave this way, players might start mimicking the common decoy maneuvering behaviors. Or traveling in a pack of decoys, etc.

If a facility has sensors, then a team can hook into that facility with a line of sight system. If a team member has a line of sight to such a facility, then it gains the benefit of that facility’s sensors. If a sensor system requires active control, then a single ship must dock with the facility’s sensor array. Meanwhile, anyone with line of sight can gain benefit of that facility.

Facility sensors would be easy to damage or destroy while also being expensive.

A more limited form of facility sensors has them not allowing the line of sight feature, requiring docking to the sensor array. That makes the docking player into a sensor operator for his team. Such a sensor system must involve a number of manual controls to make it work, otherwise players would just park a mule at the facility. Regardless, the operator should have tasks that include affecting the sensors of other players on his team. That is, players would request sensor tasks, sweeps, pings and so forth so that they see the most interesting sensor data.

Another thought is that the sensor operator does some sensing stuff for a while, then transmits a snapshot of what he has seen to his team. That snapshot is not real time, but it’s highly-detailed for the specific information the operator is working on. Snapshots can only be sent once every N seconds.

4

On the matter of decoys: Spending time getting people together and flying off to fight some enemy fleet, then getting there and finding empty space just to fly all the way back again is no fun.

It’s important that getting into an actual fight with other players is worth more in terms of rewards to your team than small surprise raids and guerrilla tactics; otherwise people are going to end up groping around in the dark for hours chasing shadows, which is also no fun.

Stealth should mostly be for finding the enemy’s stuff so you can show up with your own stuff to blow the stuff out of their stuff. :wink:

Knowing where the fights are should be the easy bit!

1 Like
5

Ok, I think this is a valid criticism, gotta know where the fights are. There would be a limit on how big a force you could spoof on an enemies sensors. Perhaps you could only effect the size of an existing group of ships on enemy sensors (make it seem bigger or smaller than it is).

6

That’s why scouts exist - to ensure that you’re employing your forces intelligently.

One way or another, the game needs to make things unclear to players. They’ll then need to take action to make things clear. That might be decoys, or hacking, or just limited sensors. There are many ways to obfuscate things, and my preference is to just limit the clarity of sensors. The inverse square law provides the bulk of that effect, but other techniques should be employed so that player skill has a role as well.

My only reason for not agreeing with @WalrusFist’s suggestion of limited range sensors is that players can always talk to each other regardless of range, so limited range sensors would just be a considered a nuisance.

7

There should be a way to actively broadcast sensor data to everyone, perhaps with a ‘spotting’ mechanic like in Battlefield/Planetside 2. But making everyone’s sensor data available to everyone passively seems a little dumbed down for my taste. At least someone should have to make sure data is getting where it should go, even if it just requires 1 person in a group to have a particular module installed, or something.

1 Like
8

Well, I see two ways to go:

  1. Sensors are fundamental to gameplay and everyone gets their group’s sensor information automatically (this is the ARMA 3 model, by the way)

  2. Sensors are specialized gear that somebody has to equip and actively operate. Players have their local sensors, of course, but the only shared sensor data comes from the guys with dedicated sensor ships.

I consider the former more appropriate for Infinity:Battlescape and the latter more appropriate for an MMO.

1 Like
9

How about this:

-Limited range sensor scanning.
-Unlimited range line-of-sight sensor linking.
-System wide ‘there’s a lot of explosions going on here’ sensor pings.

Would mean anyone could find and get to a fight in progress, enemy players could still try and be sneaky on the way to places, and you could still get cut off from the rest of your team if you go someplace stupid without support.

2 Likes
10

I’m OK with @Naiba suggestion’s, but I don’t see why the data transmission should be limited to a line-of-sight? Unless you’re meaning not receiving information when you’re on the far side of the moon and that it blocks the data signal.

1 Like
11

That’s what line-of-sight means.

An optional tweak to a plain line-of-sight system is to have the signal ‘refract’ around the body. If the two parties are sufficiently far away from the body then they can still link. Only if one or both of them are close to the body is the link blocked.

Eg

A and B are the only pair that can link.
(The red bit shows a kind of shadow of A’s signal)

This may seem like an unnecessary complication, however I think if your sensor sharing or whatever it is that might use a line-of-sight system keeps blinking on and off because of bodies that neither party is anywhere near, that would be annoying and doesn’t really improve gameplay.

With this, you get the gameplay tradeoff of sensor sharing vs hiding behind a body but without the annoying flickering of the link when a far-off body happens to pass between the two parties.

12

This is the kinda thing I’m thinking. Not all comms are blocked, but any automated sharing of sensor details/automatic npc distress calls etc are blocked if you don’t have line-of-sight or comms relays that can ‘bend’ the signal around a planet. (It would be really cool if we could actually eject com-sats while in orbit and leave them there)

If the time it takes players to get from one planet to another is really long, I would happily concede that it might get a little annoying going all the way to a planet to find someone just knocked out the com-sat as a distraction (However, with long travel times between planets, that opens up interesting interception gameplay, so wouldn’t be too sad about giving this idea up)

13

What you describe as a complication is more of a simplification of gameplay, IMO. Even if signals do refract, the angle should be marginal enough to be ignored when considering an almost singular point emitting the signal and a huge celestial body like a planet blocking the signal.

Your drawing describes more what happens for a lunar eclipse on Earth, but this works because the Sun is actually big enough to create that red cone.

I would rather have a game of hide and communicate, simply because it really gives scouting more purpose.

If A is an ennemy capital ship, its sensors will not detect D and C, hidden on the far side of the moon. And neither should D and C be able to detect A. B however can detect A and have a line of sight on D, but not C. B communicates to D, which in turns communicates to C that A is approching.

Provided the sensor range is limited, the blue area of “dark zone” is shrinked as A is farther away instead of closer… but at the cose of having a limited detection.

1 Like
14

I’m fully aware of this. My suggestion is purely to eliminate the issue of a link blinking on and off because some distant moon (or whatever) happens to pass somewhere between you. - This is in response to Naiba’s suggestion of unlimited range line-of-sight sensor linking (which I actually disagree with).

My diagram was not to scale. Neither is this one but demonstrates the idea.

So I’m just saying if an unlimited line-of-sight policy is used for anything, then my suggestion is that the LOS limitation is tempered by distance.

1 Like
15

I’m under the impression that LOS checking on the server complicates the net-code somewhat and with 100s of players on a server that might compound enough to cause problems.

So it would need to be done with some care and intelligence, base being ~100x100 checks per time interval, making it ~10k checks per that interval.

16

Another advantage of ignoring things as a function of size and distance.

17

From what I understand though, the current sensor detection system uses line of sight checking. So unless that changes or becomes limited by range, that calculation would already be in the game.

18

The current server hasn’t been stress tested with more than a dozen or two real players, I’m under the opinion that the server code has to be very optimized to run 100s of players in a single instance, or more games would be doing it.

Point being that the less real-time gameplay checks we construct around server code the better.

19

I really don’t think we need to worry about implementation. Just keep batting around gameplay ideas because that’s the most help we can provide to the team. @hrobertson’s idea to fiddle with LOS calculations is one that I certainly never thought of, and it’s good to hear these things. It may fit into the game’s infrastructure perfectly or not at all. We don’t know which it is and it doesn’t matter. The INS guys can make that call. We only need to discuss such things from the gameplay standpoint. Does it make gameplay better or worse, and what are our arguments supporting our view? The INS guys will read our musings and take what they like from it all.

When the developer forum opens, I fully expect it to be primarily a feedback forum where the developers will post something they want feedback on - a gameplay feature, a bit of artwork, a pricing strategy - and the members will speak their minds on it. I think the team already has enough strong opinions about how the game should work. The developer forum will be for tie breakers, for cases where nobody on the team has a strong opinion, or where the team wants to confirm their beliefs.

1 Like
20

@hrobertson Ok, now I understand better what you meant. If you’re afraid of a “blink” effect, one can also imagine that the last known position will remain for some time on the HUD, and slowly fade away the more you stay severed from the data feed.

And actually, with some thought, while I can agree with an unlimited link feed, it could also have a range limit as long as it is much higher than sensors.

Exactly my thought and why I’m not that much participating in most debates for now. From the gameplay concept seen on imgur, the dev team have already a strong idea on where they’re going and they certainly know more on their engine’s capabilites and limitations.

Plus they’ve certainly more than craving for some rest after this intense KS.

I’ll just wait and see for now.