Sensors 3.0

[Ripper]

Here's my updated Sensors 3.0 post:

 

NovaQuark has not provided details on how sensors work. Everything mentioned in this thread is speculative.

 

In order to understand sensors, we need to know what is being transmitted to the player's client. We know that Dual Universe is going to be a "Single Shard" universe with no zones. All players will be able to interact with all other players. This doesn't mean that the game client needs to (or should) receive the coordinates of EVERY other player in the game, all the time.

 

Here's a key point to understand. The player only needs to receive the coordinates of the players they can detect or interact with. All other player coordinates are unnecessary, and since this data would be unused by the client, are unnecessary packets that would be sent over the network. Here's an example to consider. You have a friend that lives on the other side of town. You know he exists somewhere, and is doing something right now. But you don't need to know his exact latitudinal and longitudinal location. But, what if your friend calls you on your cell phone and say lets meet up at the local coffee shop? You still don't know where your friend is until you actually travel to the coffee shop and get within visual range. Once you see him, you know exactly where he is.

 

This is the same for the game client.

 

So what does a game client need? First, it makes sense to transmit the coordinates of all players within a given omnidirectional range. If a player spins upon an axis, they need to see ALL players as soon as they get within view. This means you cant perform the database query when the player turns right. The response will be too slow. The data already needs to be on the client. This isn't something new, and is done by all multiplayer games today. This paragraph is just informative.

 

What is a good range?

 

That depends upon a lot of factors. Remember we haven't even begun talking about sensors.

 

If a player is on foot and just looking around, then at a minimum, he should see everyone within 2 kilometers.

If they're using a sensor, then maybe that radius should extend to 10 kilometers.

If the player is in a ship, the visible range of a fighter is about 5 kilometers.

But at 5 kilometers, a Dreadnaught will still be visible, and a Death Star would fill your screen.

 

NovaQuark will need to determine what this range will be, but at a certain point, extremely large items will pop/fade/transition into view.

 

Then there's sensor range. Some sensors will allow users to detect objects outside of the visible range.

 

As you can see, the larger the radius implemented for coordinate packets, the exponential growth of detectable users and the exponential growth of bandwidth usage.

 

This will be a balancing issue for NQ.

 

NOW TO SENSORS:

 

Definition

UniqueObjectID: A unique identifier within the game server that differentiates your object's SQL record from an identical object owned by someone else. It is NOT the PlayerID, so it will not divulge any actual player information to the scanning player. It would be programmatically used to distinguish between "Blip1" and "Blip2" on a radar.

 

===== Sensor Elements =====

Sensor Elements do NOT have to be omnidirectional. Hemispheres, cones, cubes, planes, and beams should be possible.

Sensor Elements ARE different than Display Elements

Sensor Elements detect all core units or avatars within a defined 3D "Area of Influence"

Sensor Elements ONLY need to return the "UniqueObjectID" from the core unit or the player's Avatar.

Sensor Elements should be "dimmable", so the builder can restrict their range. (such as limiting detection to within an air lock)

 

Advanced Sensor Elements can return more information than the UniqueObjectID, depending upon how NQ codes them. Examples would be PlayerName, PrimaryOrginization, ElementType, etc.

 

===== Radar Display Elements =====

Radar Display Elements will only need to know the UniqueObjectID

Radar Display Elements will be hard coded by NQ, to display the XYZ position of known UniqueObjectIDs

 

Advanced Display Elements may take additional attributes such as "Friend or Foe" designation

Advanced Display Elements may take additional "Color" attributes

Advanced Display Elements may have the ability to provide different icons "on screen"

 

===== The DPU =====

The DPU can be used for filtering UniqueObjectIDs provided by the sensor to the Display

The DPU can be programmed by the player to filter however they like.

 

===== Flow of Data to the Display =====

Information is passed from the Sensor --> to the DPU --> to the Display

 

===== Weapon Elements =====

Weapon Elements have their own hard coded sensor

Weapon Elements attack ALL ObjectIDs passed to them by a DPU

 

===== Flow of Data for Weapons =====

Information is passed from a DPU --> to a Weapon Element

The DPU obtains that list of ObjectIDs however the player decides, including from a sensor.

 

 

AUTOMATIC CONSTRUCTS:

 

Some constructs have the ability to activate when a player approaches them. Not ALL constructs are intended to function this way, which necessitates a means to distinguish between the two types of constructs. We already know the construct AND script are downloaded to the players client, when they approach the construct. The player can then interact with the construct's controls. In order to have a construct take action when the player approaches, there needs to be a means for the construct to use a sensor even when the player hasn't interacted with the construct. My suggestion would be to include an "Active Scan" Sensor Element. This element would initiate the script when the player enters the area of influence of the sensor.

 

===== Active Scan Sensor Element =====

The "Active Scan" sensor activates a construct when the player gets within it range.

The "Active Scan" sensor only starts the script on the client PC. All other functions are handled by other elements and DPUs.

 

 

===== The Door =====

The Door Returns an "Open" or "Closed" value for all players.

The Door can accept an "Open" or "Close" value from a DPU.

 

 

===== Flow of Data for an Automatic Door =====

The Player approaches the door

The "Active Scan" sensor activates the constuct's script on the players client.

A standard Sensor Element detects a player in its field of influence.

The Standard Sensor Sends the playerID to --> the DPU

The DPU can determine the RDMS rights of the player, and will open the door accordingly.

The DPU sends --> "Open" to the door.

The Door exhibits an "Opened" State to ALL players.

 

 

 

There's quite a bit of information to digest here, but that's how I would implement sensors in Dual Universe.

[Kuritho]

Could you... clarify it?

Flowchart?
Anything?

[CyberCrunch]

That is a great concept how sensors could work in the game. It is very important that they are designed modular for many different use cases, not only inside ships!
The way you described the data-flow is exactly how I think NQ wants to build them, especially that they could reuse the data, that the client needs anyway to display things ingame (without active sensor modules)!
 
However there are a few things I would like to add:

===== Radar Display Elements =====
Radar Display Elements  will only need to know the UniqueObjectID
Radar Display Elements will be hard coded by NQ, to display the XYZ position of known UniqueObjectIDs
 
Advanced Display Elements may take additional attributes such as "Friend or Foe" designation
Advanced Display Elements may take additional "Color" attributes
Advanced Display Elements may have the ability to provide different icons "on screen"
 
===== The DPU =====
The DPU can be used for filtering UniqueObjectIDs provided by the sensor to the Display
The DPU can be programmed by the player to filter however they like.
 
===== Flow of Data to the Display =====
Information is passed from the Sensor --> to the DPU --> to the Display

I very much dislike the idea of "hard coded" elements. Display elements should be screens where you can display anything you like. The element itself would only define the size (like 400x400px).
The display should be controlled by a DPU that is using LUA-UI library to visualize the input data. There are already a lot of libraries especially for that purpose: http://lua-users.org/wiki/GraphicalUserInterfaceToolkits
These tools work like Swing(java) or Qt widgets, and you could easily program something that looks like a radar-display. (or use the script of someone else)
Thereby the data flow can be much more modular:
===== Flow of Data to the Display =====
Sensor(detected IDs) --> to the DPU(process sensor-data) --> to the DPU(radar-widget) --> to the Display(400x400px)
 
The great advantage is that everything could be customized in much greater detail, and even mix informations from different modules!
 

The same with weapons: Let them only input xy-rotation and shoot commands. If anyone wants auto-attack, they can script that!
 
 

===== Active Scan Sensor Element =====
The "Active Scan" sensor activates a construct when the player gets within it range.
The "Active Scan" sensor only starts the script on the client PC. All other functions are handled by other elements and DPUs.

If I understand this correctly, the server would need to constantly check if the player is close to a DPU and than activate it. Why not use a remote-control item that the player has to carry around. If he triggers the remote-control a predefined DPU gets activated. (if in range)

[Ripper]

Thanks for the input Cybercrunch.

 

I understand what you mean by not liking a hard coded radar display element.

 

Remember that ALL elements will have DPUs that have some functionality hard coded (per the LUA devblog)

 

Maybe the radar could be a widget.

 

I doubt there are many players that could write an LUA script to represent 50 simultaneously moving objects in 3d space. Even game programmers use a 'trick' instead of doing all the math.

 

And

 

To your suggestion about carrying something to activate a door... consider carrying a garage door opener for every door. I wouldnt want that.

 

Or consider automatically detecting a random player not in your org. Maybe you want to broadcast a generic greeting to his ship.

 

This detection would be done client side. The results (door display "opened") would be part of the hard coded door, and it would be server side to represent an open door to everyone.

 

Entering an area client side would be no different than clicking a button client side or pressing a key, thereby activating the construct.

[CyberCrunch]

Oh well, it seems you are right about the radar-element. After revisiting the devblog I even found this picture:

So we definitely will have some sort of "hard coded" functionalities in each element. But as the picture shows players can still chose how they want to implement the enemyAt() function in their design.

 

In regards to display UI, there will definitely be predefined widgets for each element. (like the fuel tank widget from the February devdiary) And as Shynras already posted in this thread: https://board.dualthegame.com/index.php?/topic/10939-guide-to-html-css-for-the-ui/

we will definitely be able to "customize the behavior in LUA" and "reskin them with HTML/CSS" to quote what JC said in the video!

 

I really need to study the devdiarys more carefully instead of making wild speculations on how I would implement the UI interfaces! XD

 

The reason I don't like fixed modules, is that they tend to limit the usability of certain modules.(eg. radar only in ships for combat)

On the other hand this gives NQ more control and prevents abuse of modules that were intendet for completely different things....

I guess these topics have been thought through for several years now, and NQ knows much better what they are doing than we members who are only thinking of what we want in the game ourselves.

 

Anyways, in regards to the door problem:

To your suggestion about carrying something to activate a door... consider carrying a garage door opener for every door. I wouldnt want that.

Or consider automatically detecting a random player not in your org. Maybe you want to broadcast a generic greeting to his ship.

This detection would be done client side. The results (door display "opened") would be part of the hard coded door, and it would be server side to represent an open door to everyone.

Entering an area client side would be no different than clicking a button client side or pressing a key, thereby activating the construct.

This functionality would definitely be "nice to have" at some point, but for release I'm very happy with the key-and-lock design.
Besides that it's more complex to implement (even if it's only running on the client) I think NQ could introduce this feature as a valuable element for orgs in the later game...
There will still be lots of new things coming, especially after release!

[Begogian]

This is very cool and in-depth, very nice job. I think sensors will be awesome and I wonder if maybe it would be nice to have a way to code our own sensors. Different sensors for different jobs, some maybe the devs haven't even thought of yet.