[DEVICE] Radio transmitter/receiver

All discussions related to the DCPU and in game hardware (equipment, vehicles)

Re: [DEVICE] Radio transmitter/receiver

Postby ubernox » Sun Mar 23, 2014 6:26 am

croxis wrote:
ConnorY71 wrote:
croxis wrote:Once a signal has reached a lower limit (maybe make this a server setting for performance tuning) the signal is removed from game memory.

Radio waves are one thing, but what if I shot a laser off into space? There's very little probability that it will hit something, so it could easily make it across the map without dying out. Is there a way for the game to deal with this without shitting itself and going into meltdown?

Depending how one wants to model it, a laser still spreads. IIRC the lasers we shoot at the moon for measurement spread to about a 3kmish diameter beam. Iirc its something like 4 times the area at twice the distance. Still super small at our scale but pointing a laser at jupiter is still a healthy spread. It could operate under the same cone mechanics as a dish, just a very tight spread.

Laser based comms can be balanced so that they only make up a small percentage of communication so even with cross-system range they wont consume that many server resources. Ships are not going to magically know where other ships are, the virtual computer has to either have predetermined position data or calculate it using a telescope or some other active/passive sensor system. This alone will probably limit long range coms to stationary bases or orbital stations. Short range comms for ships on the same grid can probably use ray based collisions. If there is a collision then the comm wont be stored in memory.

It isn't going to be possible to make this 100% realistic. Even if light waves were simulated the game loop with individual bits modeled the game logic loop will probably be running no faster than 60 Hz. A low baud rate could make it possible but the same effect could be done simply I think. If the transmission was stored as a binary string along with its time stamp and additional meta data such as wavelength. A ship enters the transmission cone midway, the server would calculate where in the string the ship will start "hearing" the transition and begin streaming the string from that point to the appropriate ship hardware listeners. The string could also be streamed through filters before getting to the hardware to model noise or other factors if those were gameplay elements. The server will also be telling the appropriate clients what the hardware is hearing as well. Don't want the clients to get the full or unfiltered string.

I'm still worried about performance issues with this. There is risk for a lot of transmissions and a lot of collision detection checks using the method I thought up.

And people can still exchange skype/xmpp/aim/whaetver usernames and start chatting out of game and not worry about time delay.

then don't have laser-based communication, or at least don't simulate them accurately. There is only so much processing power in the world, guys.
User avatar
Posts: 17
Joined: Wed Nov 27, 2013 1:54 am


Return to Hardware

Who is online

Users browsing this forum: No registered users and 1 guest