| Author |
Client-Side Calculations and General Latency Issues |
Orion_Prime
Cadet
Joined: December 12, 2001
Posts: 1323
From: Missouri, USA
|  Posted: 2004-09-23 19:08
Everyone knows about the lag problems, this is certainly not news. After all, very few have not had their ships lagged straight into a planet (I even hit a star because of lag =/ ), so this is a universal pain.
I’m not sure how many members of the community have offered advice as to how to fix the problem, but I’m sure it’s been quite a few. However, what’s one more opinion on the matter? After all, this is the first suggestion I have made in many, many months, so cut me some slack.
The Problem
The problem, as I see it, is this: The server cannot quite handle the size and quantity of packets that it needs to deliver to all of the clients.
This has been a problem for a very long time. Many of you probably remember that laying an obscene number of mines would crash the server, and that’s why they limited the number of mines that can be in a given area at any one time. The powers-that-be have utilized many “quick-fixes” such as these in order to keep things running as smoothly as possible. So far, they have been met with only minor success, if any at all.
The reason I say minor success is fairly obvious: we still have lag problems, and big ones at that.
Summation of my Solution
Here is a quick summary of my solution. A more in-depth look appears below, but this will be more tailored towards the actual development team as opposed to the general community.
In short, I feel that client-side calculations will greatly assist in these lag problems. Now, I realize that the dev team has tried to stray away from these methods, but I don’t think that failing to utilize this will work anymore.
This will do several things for the general lag issues:
- Fewer packets because the clients don’t need as much data
- Smaller packets for the same reason
- Smaller and fewer packets means that the server won’t be quite as bogged
As to the level of how much these packets will be decreased, I am not certain since I don’t have access to that information. However, judging by what Gideon told me about all that needs to be sent to each player, I can guess that they will be reduced significantly.
That ends the summary, now here comes the nitty-gritty of it all.
Implementation
General Implementation
Client-side calculations will not require different code for the calculations themselves, but rather the same code will simply be located somewhere different. It will still use the same methods and procedures code-wise, but the clients’ computers will take care of it as opposed to the servers’ computers.
Basically, what I had in mind was this:
- Planets: Planetary information will be loaded when the client joins the servers. This information includes position, orbiting path, rotational path, buildings, units, technology, how many minerals are being produced every second, etc, etc.
This will produce a longer connect time, but it will be well worth it. Once this data is loaded, all the mundane calculations will be made by the client’s computers. This includes where the planet will be at any given time, how many resources the planet will have from second to second, etc. This means that the server will not have to continue to send packets containing this information to players who stay connected.
However, what if someone does something to the planet? Simple, any “drastic” changes (IE new buildings, new technology, people buy things from the star-port) and the server will send a small packet describing the change to the clients. That change is then worked into the calculations client-side and everything continues as before.
- AI-Driven Objects: This includes cannon fire, torpedoes, missiles, etc. From what I can tell, there are no random elements in these particular devices. IE Torpedoes track the same way every time. Therefore, you can put these “tracking calculations” client-side as well. That way, all the server has to send is the fact that a missile, for example, was created at (x,y,z) and has target (m). The clients’ computers then use the same AI code to calculate the path of the missile. If it is destroyed by a PD system in that path, the server will simply send a small “destroyed by PD” packet. If it hits the target (or another object), the client-side computers will be able to figure this out as far as explosion triggers are concerned. As far as damage is concerned, the server can calculate that and send it to the clients.
- Damage and Repair: When a ship takes damage, the server has to let all the clients know. This is unavoidable. However, auto repair of shields, armor, and hull (for the K’Luth) does not need to be reported. Clients will already have the equations involved for that sort of work, and will be able to do so without the server. When a supply ship repairs a ship, it’s the same thing. The server simply tells the clients that the ship is getting repaired by x number of drones and the clients will again do all the calculations required.
This means that if a ship is damaged, but continues to fight, the server doesn’t need to continue to send data to all the clients about its hull and armor if it does not waiver from the normal equations. Any changes to these formulas (repair drones, more damage) will be reported and the clients will continue calculating with the new data.
- Player-Controlled Ships: Some aspects of these can also be calculated client-side; most specifically, attitude. Instead of constantly updating position, the server simply needs to tell the clients of any change in the ships attitude. This means that instead of packets constantly flowing and tell of a ships changing speed, it will only need to send a packet of where the player set his max speed and the clients will calculate how long it takes to get there.
This goes for turning as well. The server will send the clients a packet when a player initializes, changes, and ceases a turn. Thus, if a player is turning the same way for a while (maybe flying in a circle for whatever reason) the server will only have sent one packet and the clients will completely handle that ship’s movements.
Those are the main aspects of the game that I can think of, however I’m sure there are a lot more.
Downside?
Well, I’m sure some of you are thinking “This is way too good to be true! What’s the catch?” Or maybe “Orion is a complete moron, what a waste of time and database space!” Well, whichever it is, there is a small catch: Hackers. With calculations being client-side, this means that it is possible to edit those calculations to your advantage. IE people will be able to write hacker programs and trainers that will give them the edge in the game. Now, they won’t be able to edit their profiles or credits; those will still be completely server-side. However, they might be able to edit the paths of their missiles etc to ensure hits and give them an edge in combat. Obviously most of the community are honest individuals who wouldn’t do this, but there are always a few in every game. This would mean that moderators and other authoritative people would have to be on the look out for this sort of thing. The RoC already forbids using exploits, but this may be a little harder to detect than a past-patch ship.
However, through careful observation and appropriate /reports by players, this problem can be eliminated by making examples of those who break the rules (IE zero tolerance banning for life).
Well, that’s all I can think of. I understand that this will take quite a bit of work from the programmers, but I feel that it will be well worth it. This is the sort of thing that, once it’s completed, will require little maintenance.
And this work will certainly pay off when you have a virtually lag-free environment.
Feel free to comment, however I ask that they be constructive comments as opposed to: “YES! Zero lag is TEH ROXORZ!”
Thanks.
-Orion_Prime
_________________
|
Grimith
Grand Admiral
Templar Knights
Joined: August 09, 2003
Posts: 836
From: Your local future farm.
| Posted: 2004-09-23 19:42
If I had the capacity and the reason to see all of what Faustus and the gang has in their heads about Darkspace...
If I had the position to know and understand how long doing anything like this might take...
If I had the knowledge that this wouldn't create any more problems for the programmers... that it would just be a cinch and wouldn't spawn any more difficulties on its own...
If I had the ignorance to not realize that there are people that are capable of manipulating things to their advantage so skillfully that it's extremely hard to detect what they are doing...
...then I would endorse this idea.
Alas, I don't have any of that, so I cannot go along with the idea. I don't have a clue about what's going on with everything, so I can't go along with saying that this is a great idea and that the developers need to implement this. I can say that the idea is interesting, and it's most certainly a better way of looking at it besides, "OMG! THERE'S LAG! FIX IT OR I LEAVE!" Still, I have to say that I don't like this idea.
_________________
|
Linna Yamazaka {Vice Admiral}
Vice Admiral
Raven Warriors
Joined: May 03, 2003
Posts: 415
From: killer
| Posted: 2004-09-23 19:46
I forsee other trobles with this soultion, It will casue more cpu usage on the player computer and some of them player computer already have trobles running the game as it is. So I will give this ideal two thumbs up for the ideal but two thumbs down for putting it to use. sorry good ideal but almost impossable to do, get to work, and graud from hakers and cheaters.
_________________
Two weeks™ Later and a new sig.
|
Shippo
1st Rear Admiral
Joined: July 04, 2004
Posts: 197
From: Texas, USA
| Posted: 2004-09-23 19:49
Wow. Insteresting aspect you have their. Hmm..the hacker part got me a bit worried but depends what you mean. Like the player actually doing the hacking or another person hacking into the computer..I'm pretty sure you mean the player him/herself doing it. I'm a trusted user and I would never do this. Anyhow, those are some great suggestions in a while to fix up this lag issue.
_________________
|
Captain Sternn
Grand Admiral
Joined: March 18, 2004
Posts: 225
| Posted: 2004-09-23 22:47
some interesting thoughts....perhaps alowing the client to do some of the calculations wouldnt be a bad idea ...however i would limit it to calculations that would do someone no good for someone to manipulate...even a small help would help.
_________________
|
Kaine Darkheart -SO-
Grand Admiral
Deicide
Joined: March 30, 2002
Posts: 458
From: Oshkosh, Wisconsin
| Posted: 2004-09-23 22:56
i stopped half way through cause its 11pm, but from what i read its got some very good ideas ans aspects
_________________
|
Tellaris
Grand Admiral
Galactic Navy
Joined: April 30, 2002
Posts: 830
From: Land of Chocolate
| Posted: 2004-09-24 02:13
Okays.
Possible prevention possibilites (I'm not a programmer, so I don't know exactly how effective this would be)
Server side examination of every individual file on the computer (related to DS). This DOES mean longer, MUCH longer load times... It would simply check for any changes to the standard files. If any change is detected, it replaces the changed file automatically, via the normal autodownload. The check could be preformed while the player is already in the game, and if any changes are detected, they are automatically disconnected. If it does not match exactly, the game disconnects you. (This excludes modifications made because of different system types) Check isn't preformed constantly, only once durring the game. This means a startoff of lagginess, however, it improves when the check is done.
Only other solution I can think of is leave everything server side.
_________________
Captain of the StarCruiser
I hit planets for fun!
Spellchecker, the POWER t00l
[ This Message was edited by: Baikon {DSAcademy} on 2004-09-24 02:14 ]
_________________
Captain of the StarCruiser
I hit planets for fun!
Spellchecker, the POWER t00l
|
Pope
Fleet Admiral
Joined: June 11, 2002
Posts: 2449
From: World of tomorrow
| Posted: 2004-09-24 02:18
Yawn.. Good morning Ladies and Gentlemen..
Differential Updates are being used already. If i understood Gid correctly yesterday, game data are also being compressed (i.e. bit redunancy eliminated, and other handish or semiautomatic optimizations to the message(s)).
If you let anything with more than one dynamic influence (Like Projectiles or Ships) up to the client to decide the /real/ Position about, then you either end up /totally/ out of sync with everyone else /real/ quick, or, if you use differential Updates - Oh, but they already do that.
You suggest the Client to do some parts of the game totally by himself, like Planet rotation and Orbit, tell you what, considering how outpowered some systems are, you'd have to use their RTC to get this done /anywhere/ near correct, which creates new problems (read: more client bugs and incompatibilities), and i don't think those Packets are the problem anyways..
So what it boils down to, like i said in the Lobby yesterday: Creates more Problems than it pretends to solve.
Basically, client-side authority over any serverwide-valid objects = BAD.
_________________
|
Thorium
Grand Admiral
Joined: August 05, 2004
Posts: 185
| Posted: 2004-09-24 03:36
aye hax are the down side but lag will be greatly reduced (and the mods will have something to do).
just take a page from online HL gameing... find hax, kill hax (never ending fight but better than lag).
_________________
|
|
English
Deutsch
Nederlands
)
