| Pages: 1 2 [3] 4 5 :: one page |
|
|
| Author |
Thread Statistics | Show CCP posts - 6 post(s) |
Synapse Archae
Amarr
Demonic Retribution
G00DFELLAS
    |
Posted - 2008.09.18 22:55:00 -
[61]
I wonder if you could actually improve performance significantly in fleet battles by simply assuming all causality bubbles will intersect, and diving into the worst case calculations, rather than doing all this causality work in every frame only to find you can't actually isolate anything.
Also, rework fighters. If they seriously do all that because of following ships in warp, then just make them do soemthing else. Its not worth all that lag for one damned feature.
Originally by: CCP Garthagk
While these forums may not give you everything that you want, they will usually let you post.
|
Korizan
|
Posted - 2008.09.18 23:11:00 -
[62]
Originally by: PirceHat
Edited by: PirceHat on 18/09/2008 22:18:48
That actually explains why fighters lag the shit out of stuff. Because they can follow people in warp there causalities bubbles include a whole set of events that generally don't exists for other ships.
CCP should consider halving the number of drones carriers can drop and giving them a double damage bonus, same with Motherships.
Also I doubt its exactly "on line" of code, a for loops are at least two :p. It is probably however, very short.
I would rather love to see what equations he uses, dynamical systems are fascinating :p.
Although fighters and drones could and would use these functions I am not inclined to believe the base functions are the root of the problem.
THe rationel behind this is that both fighters and drones are essentially controlled by the computer and inherantly should have less bubbles.
ANd secondly I believe drones should be causing the same issues.
IF the lag is only in certain instances, ie when fighters warp I would suspect a problem with the coding, not with with the base thoery controlling them.
So it is a question of a design flaw or a flaw in the implementation (a bug in the code).
If it is a design flaw then you have to ask do you change the design or remove the feature.
BUt more of a concern is if it is a bug in the coding, what else could be effected by it.
By reducing fighters you could be masking a bigger issue.
Never a easy answer and as always pure speculation based on the info we have which is very little
|
Lyvanna Kitaen
Minmatar
Noonday Sun Corp
|
Posted - 2008.09.19 03:34:00 -
[63]
Originally by: Sarah Tuttle
I think I understand what he is saying. What I don't understand is how any computer on earth can handle that kind of load and relay it correctly to 30,000+ users at the same time.
You don't really have to transmit everything to everyone on the server, only those who would be affected by the events in question.
|
Pant Alones
Surge.
|
Posted - 2008.09.19 04:32:00 -
[64]
I'm curious as to what the eve universe looked like before it was seeded with '42' 
------------------------
|
|
CCP Lingorm
C C P
|
Posted - 2008.09.19 09:08:00 -
[65]
Originally by: Korizan
Originally by: PirceHat
Edited by: PirceHat on 18/09/2008 22:18:48
That actually explains why fighters lag the shit out of stuff. Because they can follow people in warp there causalities bubbles include a whole set of events that generally don't exists for other ships.
CCP should consider halving the number of drones carriers can drop and giving them a double damage bonus, same with Motherships.
Also I doubt its exactly "on line" of code, a for loops are at least two :p. It is probably however, very short.
I would rather love to see what equations he uses, dynamical systems are fascinating :p.
Although fighters and drones could and would use these functions I am not inclined to believe the base functions are the root of the problem.
THe rationel behind this is that both fighters and drones are essentially controlled by the computer and inherantly should have less bubbles.
ANd secondly I believe drones should be causing the same issues.
IF the lag is only in certain instances, ie when fighters warp I would suspect a problem with the coding, not with with the base thoery controlling them.
So it is a question of a design flaw or a flaw in the implementation (a bug in the code).
If it is a design flaw then you have to ask do you change the design or remove the feature.
BUt more of a concern is if it is a bug in the coding, what else could be effected by it.
By reducing fighters you could be masking a bigger issue.
Never a easy answer and as always pure speculation based on the info we have which is very little
This is only the Movement/Physic engine. It does not deal with combat/damage calculations. Only on calculating where things are, where they are possibly going and any issues getting there.
Range of guns and other projected effects do not effect movement in the calculated frame so have no causality on the physics. This is pure movement/bumping/collision calculations.
Drones, corpse, missiles and other similar stuff is non-collidable so does not figure into these calculations.
If i activate a webber in someone then that effects if started on them at the beginning of the next frame and works on their session stats, changing velocity etc) this is then used for that frames Destiny calculation on movement.
Hope this helps understand.
As for the dumb client. What happens is that once the causality has been calculated the data is sent to the client and the client can then render the flight paths and collision reactions from the data, without needed to know as much information because it is using the same simulation engine as the server. The server calculates the causality and then the server and client both use the data to move objects round.
You will also see that the faster you go the more causality you can be involved in.
CCP Lingorm
CCP Quality Assurance
QA Engineering Team Leader
Originally by: Lord Fitz
Eve is to WoW as Wow is to an 8 player game of Unreal Tournament.
|
|
Onyx Asablot
M. Corp
Mostly Harmless
|
Posted - 2008.09.19 09:26:00 -
[66]
Quote:
- Originally, the random seed to generate the EVE universe was taken from the server's Epoch Time at the start of the universe generation. The guy in charge decided, the night before launch, to regenerate the entire universe at the last minute with the seed "42."
Clear evidence CCP favours Mostly Harmless alliance ;)
The NEW M.Corp Data Hub - Check it out! |
Bartholomeus Crane
Gallente
The Crane Family
|
Posted - 2008.09.19 10:46:00 -
[67]
Originally by: Kazuma Saruwatari
Originally by: Bartholomeus Crane
... cut away my long post ...
You, yes you with the very intelligent post. Why, in all of heck, are you not working for CCP and ridding us of the LAG once and for all?
See their "CCP is hiring!" there? Well send in your application NOW!
I offered CCP my services not too long ago, but have yet to receive a reply from Eyjo, maybe I should prod him again ...
I would like to point out though that I don't claim I can solve 'lag', just that I think that under assumptions, with certain drawbacks, it can be reduced, perhaps greatly. The underlying problem, I think, is and will remain intractable.
--
Quis custodiet ipsos custodes? |
Black Delphi
|
Posted - 2008.09.19 11:00:00 -
[68]
I clicked this thread thinking i had a brain...
now i am sad 
|
Bartholomeus Crane
Gallente
The Crane Family
|
Posted - 2008.09.19 11:16:00 -
[69]
Originally by: Faife
Quote:
I wonder if CCP has considered taking this approach one step further and introduce optimistic prediction in the non-general case as well, i.e., loosening causality when several causality envelopes intersect, perhaps even doing so recursively over different layers. This assumes that individual behaviour in the non-general case is predictable, which doesn't necessarily have to be so (although, to a large extend, I suspect it is).
you might be misreading. this would create more bandwidth issues as you'd now require updates on all objects in the now loosened (i'm guessing that's code for "bigger") causal-interaction space.
In fact, in the paragraph below the one you quoted, I did reference this as a drawback. I actually mention bandwidth as an issue as well below that. In fact, I think I made sure that I wasn't claiming a solution without any drawbacks at all. It will always be a give and take situation with all the possibility of creating other bottlenecks somewhere else.
Quote:
and i'm pretty sure it's not based on behavior but ship abilities, so a 150km snipest with 6 targeting spots waiting has a huge one (it can reach out and touch you across a grid), while a rookie ship with max_targets=1 has a tiny one.
I would argue that ship abilities equal behaviour if you look at the problem from a causality envelope point of view. Although I'm more familiar at looking at the problem as a sequence of probable state-spaces (think Markov chain).
However, you do raise why the lag problem is so hard to solve. I now know that the quote refers only to the physics engine, which limits its scope a bit (and much easier to solve), but the underlying problem with 'lag' is still that on the same grid, in for example a fleet battle, all actors may have interaction with all actors. Since CCP apparently draws heavy on my physics colleagues, one could describe this as a many-body problem. If determinism isn't relaxed, and without limiting the possible interactions (and I think we do want to shoot at each other), this problem is intractable.
Quote:
and i'm not at all sure what you're talking about when you talk about recursion. in the general case that's usually good for keeping code clean, and not at all for keeping code fast.
(your mileage may vary, i never saw the slides, etc)
I was a bit cheeky when I mentioned recursion, but I didn't mean it in a 'code' type of way, more in the problem solving type of way, in that I would use a similar solving methodology recursively on a smaller part of the problem.
--
Quis custodiet ipsos custodes? |
moola
Band Of Frogs
|
Posted - 2008.09.19 11:50:00 -
[70]
Umm would'nt fleet formations (all fly delta wing formation with pre set distances) cut out most of this problem ?, give some type of bonus for using the "pre sets". Bonus is to compensate a little for loss of freedom?.
Or have i misunderstood concept/process
 |
|
Yon89
Triumvirate.
|
Posted - 2008.09.19 12:13:00 -
[71]
Originally by: Black Delphi
I clicked this thread thinking i had a brain...
now i am sad
Agreed 
=============
SIG SIG SIG |
Bartholomeus Crane
Gallente
The Crane Family
|
Posted - 2008.09.19 12:33:00 -
[72]
Originally by: CCP Lingorm
This is only the Movement/Physic engine. It does not deal with combat/damage calculations. Only on calculating where things are, where they are possibly going and any issues getting there.
Range of guns and other projected effects do not effect movement in the calculated frame so have no causality on the physics. This is pure movement/bumping/collision calculations.
Drones, corpse, missiles and other similar stuff is non-collidable so does not figure into these calculations.
If i activate a webber in someone then that effects if started on them at the beginning of the next frame and works on their session stats, changing velocity etc) this is then used for that frames Destiny calculation on movement.
Hope this helps understand.
As for the dumb client. What happens is that once the causality has been calculated the data is sent to the client and the client can then render the flight paths and collision reactions from the data, without needed to know as much information because it is using the same simulation engine as the server. The server calculates the causality and then the server and client both use the data to move objects round.
You will also see that the faster you go the more causality you can be involved in.
I probably should have realised that this described the physics engine only. This rather limits the application of my idea, quite severely in fact.
It does explain why sometimes we get these Jojo effects when warping to a gate however.
Still, the dumb client remark is interesting. It clearly itn't as dumb as we were lead to believe. Even if only for the physics engine, it does appear to duplicate some functionality of the server.
Shamelessly rewriting my idea to suit the new circumstances, I wonder if not more functionality can be duplicated in the client, more precisely, the combat aspect. Ohh, the drawbacks could be legion, and the implementation would be, well, tricky, but lets just run with it for a while, just to see where we end up.
In a 'no-lag' situation, the difference would not be noticeable to the player, as the server would be in sync with the client. In this case, the duplication would be a waste of effort (on the client's part). In a 'lag' situation, the client will be ahead of the server, with the server trying to catch up (this is the opposite of what we have now), and would in fact be in 'desync'. This is where causality envelopes come in however, because if we look upon the 'desync period' as a Markov chain of statespaces, the server should be able, assuming non-erratic behaviour (rather big assumption, but it should be possible to quantify this), to predict what happens in that period. Meaning, the server, while catching up, needs only to check if the prediction was correct, resyncing when it wasn't (sending the negative delta correction).
Sounds good? Well maybe not, because in this scenario we're trading lag for desync, and whether desync is the lesser of the two evils is a judgement call. On the positive side though, this should happen only during laggy situations, which although too common for comfort, are still relatively rare. It also loosens causality (have to be careful with this word) between player action and game reaction, which can lead to, well, surprises. Also note that it doesn't offload the server, it only duplicates functionality, in fact, since the server now does prediction as well, the server needs to do more work (although this can be done concurrently, with the prediction thread chasing the resolving thread. Ohh, the race hazards you can introduce!), assuming computing power isn't the bottleneck. Moreover, it doesn't help one iota with 'loading the grid', as it doesn't change the fact that that data is still needed by the client. And finally, it assumes that the server will be able to catch up with the client.
Bottomline: a buffer against lag while on grid?
(I made my post a bit more accessible, as my previous one wasn't maybe.)
--
Quis custodiet ipsos custodes? |
Bartholomeus Crane
Gallente
The Crane Family
|
Posted - 2008.09.19 12:39:00 -
[73]
Originally by: moola
Umm would'nt fleet formations (all fly delta wing formation with pre set distances) cut out most of this problem ?, give some type of bonus for using the "pre sets". Bonus is to compensate a little for loss of freedom?.
Or have i misunderstood concept/process
Can't say exactly, but I would suspect it wouldn't. For one, formation flying would introduce more interaction between the ships in formation, in that the server would need to coordinate flight. Also, you'd have to check when players enter and leave formation etc. I guess it would be a bit like the gang system of old, with the server having to constantly check whether the bonuses (not writing bon-i, damn you SHC) still apply. There was a good reason CCP introduced the gang nerf.
--
Quis custodiet ipsos custodes? |
Bartholomeus Crane
Gallente
The Crane Family
|
Posted - 2008.09.19 12:52:00 -
[74]
OK, spamming this thread a bit, but another thing I noticed was the apparent sequentiality of the server frame. It looks like this is some kind of sequential loop for all ships involved. Very useful obviously from a time-keeping point of view, but I wonder if in 'times of lag' it wouldn't be useful to loosen the synchronicity of this loop. Basically give each ship his own private loop and allow for some asynchronicity between them. It would mean loss of causality between ships, basically desync again, but it would make it easier to farm out these processes among the cluster (or to Destiny).
Assuming you don't do this already, which would be a bit surprising honestly.
--
Quis custodiet ipsos custodes? |
Korizan
|
Posted - 2008.09.19 13:23:00 -
[75]
Originally by: Bartholomeus Crane
OK, spamming this thread a bit, but another thing I noticed was the apparent sequentiality of the server frame. It looks like this is some kind of sequential loop for all ships involved. Very useful obviously from a time-keeping point of view, but I wonder if in 'times of lag' it wouldn't be useful to loosen the synchronicity of this loop. Basically give each ship his own private loop and allow for some asynchronicity between them. It would mean loss of causality between ships, basically desync again, but it would make it easier to farm out these processes among the cluster (or to Destiny).
Assuming you don't do this already, which would be a bit surprising honestly.
Yawn... morning Barth, sorry still drinking coffee.
Well this thread started off as a disscusion about movement and has progressed to lag in general.
Now it appears we can say the when a client gets desync'd that is when the system has failed. but the question is why.
Is it just shear numbers or is it the pluthra of other data that the client has receiving or the pluthra of data the server(s) are having to handle or communication between the servers and I can guarentee I have missed some other points.
I would say all of the above.
For every little bit of code that happens it adds to the list till it reaches the breaking point.
Why when CCP optimizes one thing you don't always see a change but it might help say a 1000 more players run lag free.
It is simply a chain reaction.
So I submit it is not the root of all the lag in EVE, but rather a small issue that adds to the whole.
But then again every line of code every calculation adds lag.
THat is the real magic finding the balance and a non static world.
And I did find this thread very interesting just seeing and speculation on the theory and principles behind it.
A functional block diagram of the coding and server structure would be very interesting to look @ however I understand why CCP would definitely not want such a thing released.
But thanks Faife for bringing us this pleasent conversation and to all those who participated in it, to include (surprisingly) CCP.
|
AltBier
Minmatar
Freelance Unincorporated
|
Posted - 2008.09.19 13:34:00 -
[76]
Two questions:
Quote:
3) Using chaos theory equations of possible changes in a ship's behavior before the next time slice, fractally extrude out a set of event cylinders (with hemispherical caps) of the ship's possible influence before the next frame, within the 3D space.
Why cylinders and not cones?
Quote:
8) Yield to other causality bubble simulations in DESTINY and Sleep() for 1000ms.
Why sleep for a second?
|
RedClaws
Amarr
Dragon's Rage
Intrepid Crossing
|
Posted - 2008.09.19 13:56:00 -
[77]
I'm assuming this would be the most likely place to look if you were looking for the cause of desynchs?
|
Bartholomeus Crane
Gallente
The Crane Family
|
Posted - 2008.09.19 14:32:00 -
[78]
Ahh, the causes of lag, our most old and persistent topic.
Leaving aside the causes outside CCPs influence (internet lag, slow clients, etc.), what we're dealing with is a pipeline of possible bottlenecks, each point in the pipeline probably having some concurrent component, i.e. parallelism.
There's the hardware. Cluster and switch bandwidth is limited, and when lots of data are required, bandwidth will run out. There's latency as well, although fast, networks and switches involve delays as well. This shouldn't matter much with intermittent network traffic, but with lots of small packages, it does add up. I think this is the cause of the loading the grid phenomenon. If all goons want to jump through a gate into a 200 man gatecamp, both lots of data are needed, and lots of small packages need to be send. Result? Looking at a black screen for half an hour. Solution? Faster hardware, but that only goes so far, because bandwidth remains limited, and the internets will always be a bottleneck as well. I think CCP has this covered as well as they can.
Then there's dealing with all those ships when loaded as well. This is where parallelism and concurrency come in. Computer science has a problem here in general. Basically, hardware is way ahead of software, in that there are lots of cores available, but the way to efficiently use them is difficult. Anyone who had to deal with mutexes and all that, will know how difficult this is. Maybe Hybrid Transactional Memory will be the answer, but it will take Sun at least another year to make this happen. Then there are those that advocate non-algorithmic algorithms, but hardware support for that isn't even in development, and research is slow and far in between.
I'm a skeptic about it as well.
So we're stuck with the old ways, and clever things need to be done with (micro)threads, tasklets, pre-ordering, deferring, coroutines, continuation and all that jazz. I'm glad CCP uses stackless python, because it really is one of the few tools that work really well in a concurrent environment, and it reduces the cost of context switches etc. With the limited information available, I believe that a viable option would be to use more optimistic prediction and extending the parallelism to the client. It doesn't solve the underlying problem, i.e. the many-body problem, but it softens the blow by allowing more parallelism. However, from the examples I've given thus far, there's always a trade-off to be made. Parallelism and many-body type problems don't really match, in that all the interactions, by definition, make the problem indivisible. So, either you have to reduce the limitations (not always possible or preferable), or you have to soften the constraints. Either allowing asynchronicity, or replacing lag with desync (basically the same theoretically). The question remains how much players will put up with the counter lag.
Then there's the notion on this forum that somehow CCP has fallen for the Ball of Mud anti-pattern. I'm not as pessimistic and think of that statement as purely contentious. On the other hand, concurrent programs are notoriously difficult to program and maintain, and a single concurrent component can work as a contagion. At this point I could talk about optimising the Lagrangian and information theory, but that would be going to far (and be pretentious). It's anyone's guess how many components could be optimised and how much some of the perceived particular lag (drones, POS induced lag) is caused simply by it's interactions within the many-body environment.
As a famous football player once said: every advantage has its disadvantage. And that's the case here as well. Every smart extension to the system has the potential to fail, or disrupt the complex system (this is what chaos theory is all about). However, the moment you daren't risk disruption of a complex system, is the moment you've admitted defeat. Also, mucking about with complex systems is damned interesting.
--
Quis custodiet ipsos custodes? |
Bartholomeus Crane
Gallente
The Crane Family
|
Posted - 2008.09.19 14:46:00 -
[79]
Originally by: RedClaws
I'm assuming this would be the most likely place to look if you were looking for the cause of desynchs?
A desync, I believe, would occur when the client, or part of the simulation is lagging behind the rest of the simulation. Clear example would be you jumping to a gate, and then suddenly being jerked backwards, or arriving several times. In that case, the client has gotten ahead of the server in determining your position, and is being slapped on the wrist (corrected) by the server. Very benign example, at least if you're not trying to jump out while being shot at.
So, if you jumped your carrier to safety out of a big fight, and still get hits, this is the server catching up on shots fired at you when you were still in the fight. I don't think I'd be wrong in assuming that 'desync' exists because both the client and the server simulate the physics engine.
You'd handle desync by jumping out earlier (if you can that is), but remember, 'module lag' should be taken into account, because that's what you're dealing with. So if you know that module lag is, say, 5 seconds, you need to jump out 5 seconds before you would normally jump out. Lots of work for the grey noodlely prediction engine.
You could argue that most lag encountered is desync lag, but there are a number of others as well.
--
Quis custodiet ipsos custodes? |
BLAIYNE
Shadow Play
|
Posted - 2008.09.19 15:15:00 -
[80]
Blimey - an intelligent conversation about lag that hasn't decended into name calling.
Interesting stuff - keep it coming.
 |
|
Faife
Minmatar
Kinda'Shujaa
|
Posted - 2008.09.19 15:18:00 -
[81]
well, this explains why nanos are gamebreaking. at those speeds they start intersecting stuff like mad. a couple nanos attacking a fleet can really screw up the server
Please resize image to a maximum of 400 x 120, not exceeding 24000 bytes. If you would like further details please mail mods@ccpgames.com - Saint |
Julius Rigel
House Rigel
|
Posted - 2008.09.19 15:35:00 -
[82]
Originally by: moola
Umm would'nt fleet formations (all fly delta wing formation with pre set distances) cut out most of this problem ?, give some type of bonus for using the "pre sets". Bonus is to compensate a little for loss of freedom?.
Or have i misunderstood concept/process
As far as I understand this:
The problem is anticipating what could happen next. Even flying in formation, you still have the possibility of breaking formation and flying anywhere, thus still necessitating the bubbles.
Less freedom in formation should reduce lag, but we're talking at the level of an FC 'locking' you into formation, and not letting you fly around until the formation was unlocked. This would then allow the server to treat the fleet as a single unit, with a single set of possible movements.
But again, we are talking about the possible movements of each unit, so a formation in itself wouldn't help much.
And it's not theoretical physics if it has an application! 
-
Frigate racing is fast and fun!
Julius Rigel, NPC-PC equal rights activist! |
Bartholomeus Crane
Gallente
The Crane Family
|
Posted - 2008.09.19 15:43:00 -
[83]
Originally by: Faife
well, this explains why nanos are gamebreaking. at those speeds they start intersecting stuff like mad. a couple nanos attacking a fleet can really screw up the server
We'll, it's like I said on SHC, yes, I can see a way in which nanos can cause problems for the algorithm. Higher speeds means a large causality envelope (the ship can interact for more ships further away), which means a higher probability on intersecting other causality envelopes. In turn, this means larger microtasklets to send to Destiny, which take more time to execute, increasing the probability of lag. Crowded grids with faster ships make it worse as there are more causality envelopes to intersect, making for even larger microtasklets. Worst case scenario is when the whole grid needs to be handed of to Destiny. Are we then still talking microtasklet?
Compounded with this is the fact that faster ships travel larger distances per server frame, meaning a large margin of error to correct when the physics engine in the client needs to be corrected by the server. This leads to more severe desync, or at least more noticeable desync correction.
Whether nanos really push the envelope, so to say, I can't tell from my viewpoint, but it could. However, before this thread turns into another nano wambulance, I don't think nanos are being nerfed because of lag. At least, I don't remember reading it in the nano-nerf blog. I could be wrong though.
The usual disclaimer: I could be wrong ...
--
Quis custodiet ipsos custodes? |
Hoshi
Deep Core Mining Inc.
|
Posted - 2008.09.19 16:20:00 -
[84]
Originally by: Faife
well, this explains why nanos are gamebreaking. at those speeds they start intersecting stuff like mad. a couple nanos attacking a fleet can really screw up the server
Another fleet flying in close proximity (like most fleets do) would still be much worse. Nanoships seldom head straight for other ships (unless they are trying to bump) so the extending cone even if long would not intersect with many other cones most of the time.
----------------------------------------
A Guide to Scan Probing in Revelations |
Bartholomeus Crane
Gallente
The Crane Family
|
Posted - 2008.09.19 17:47:00 -
[85]
Originally by: Hoshi
Originally by: Faife
well, this explains why nanos are gamebreaking. at those speeds they start intersecting stuff like mad. a couple nanos attacking a fleet can really screw up the server
Another fleet flying in close proximity (like most fleets do) would still be much worse. Nanoships seldom head straight for other ships (unless they are trying to bump) so the extending cone even if long would not intersect with many other cones most of the time.
Faster ships have larger causality envelopes, probably elipsoids, as they can change direction mid-flight. Even while not flying straight for, you'd still have a high probability to intersect other causality envelopes, although the special case says nothing about the general case.
Simple case, a nano can cross the whole grid in several seconds. On a busy grid it will intersect many other envelopes. Add more nano-ships and every causality envelope will be intersecting through these nano causality envelopes.
I have no clue on how much influence this has in practice though, it could just as well be negligible, or relatively unimportant. I just don't know.
--
Quis custodiet ipsos custodes? |
Bartholomeus Crane
Gallente
The Crane Family
|
Posted - 2008.09.20 13:06:00 -
[86]
OK, I want to keep this thread alive, in the hope that CCP will provide us with a bit more insight into the algorithmic side of running EVE. I'd love to hear more about the combat engine, and how that ties into the algorithm given for example.
So, we were talking on SHC on how to reduce causality envelopes, in the hope that this could lead to less lag. Happily theorycrafting, we assume that smaller causality envelopes will lead to less causality envelopes intersecting, meaning smaller microtasklets, and thus to less lag. Although we only know about the physics engine routines, we assumed that this will produce less lag for the combat engine (bit of a stretch).
As I see it, there are several ways of doing this, but a combination would work even better:
Using game design choice. By using some constraints or incentives, ships will be 'enticed' to stay apart, thereby allowing a partition of the causality envelope space, meaning several smaller microtasklets to be run by Destine/whatever, meaning less lag. This boils down to reducing the blob in the sense of having large numbers of ships in close proximity. As a simplistic example, having two smaller blobs on opposite sides of the grid should be better for lag than having one large one in the middle. I don't have an idea what these constraints or incentives may be, but feel free to suggest some.
Nerfing speed. This automagically means smaller causality envelopes, and thus less chance of them intersecting, and reverting to the worst case, in that all ships on the grid need to simulated by one microtasklet. There has been lots of talk on this, but while the speed-nerf will be coming anyway, it remains to be confirmed if the speed-nerf will actually help with lag. I for one don't think the speed-nerf is being introduced because of lag, but it could ease it.
Buffing distance. This makes the causality envelopes smaller relative to the size of the grid, again leading to less chance of them intersecting. Not a complete solution however, since nothing stops ships from bunching up, producing the old problem, only in a larger playing field. However, increasing grid size, and increasing targetting distance, has the potential of spreading out the fight, and thus reducing lag.
Decreasing timeslices. Very interesting approach. By for example reducing the timeslices calculated by half, the server only needs to look half as far ahead. This would reduce causality envelopes as well, and thus decrease the probability of intersection, again, reducing lag. Rather nice idea (not mine BTW), because it can be done gradually. The moment the microtasklets get too big (chance of lag/desync), you can reduce the timeslice gradually. This increases the need for bandwidth and computing power, as you'll have to update all ships on the grid more often, and can possibly create bottlenecks there. However, the system does allow for the effects of lag to be countered by using up slack, when available, through bandwidth and computing power, and it's easy to limit it. If you run out of bandwidth or computing power, your back with lag again, but it's a buffer.
So there you have it, four ways in which to decrease lag, looking at causality envelopes only, given what we know from the algorithmic side of things. The first three all revolve about changing game mechanics, the forth doesn't. Personally, I think the fourth is really interesting, but probably all four together would work best.
Again, lots of assumption, and lots of theorycrafting, but what do you think? CCP? Anyone? Anyone? Bueller?
--
Quis custodiet ipsos custodes? |
Demitria Fernir
Caldari
Science and Trade Institute
|
Posted - 2008.09.20 13:44:00 -
[87]
Oh...the Awesomeness...It's so shiny...It burns...
10100110010100101010011010100101001100101110101001
I will Conquer My Signature
Somewhere in the future
10100110010100101010011010100101001100101110101001 |
Brayiel
The Double Cross
|
Posted - 2008.09.20 13:58:00 -
[88]
Should rename Eve to Donnie Darko in Space, let's face it all the "biggest" mmo's have catchy sounding acronyms. Why not DDIS, sounds cooool 
I didn't understand much of the OP in relation to the server, maybe one day we could have the fleet system and fleet command ships turn massive fleets of battleships into a lot fewer entities, turn 11 people in a squad into 1 entity. The 11 players that would have had spheres of possibilities now only have 1 sphere of probability. It would require some drastic changes to how fleet wars are fought, you would have to rely on players yielding some control of their vessels to squad/wing/fleet commanders which may be a dangerous road to go down.
Ultimately, if we want to see these huge fleets, which I might add look cool, perhaps the only way to reduce numbers without limiting engagement numbers is giving the players the ability to try and lower the lag, if you can give a fleet the ability to have 250 people in a fleet reduced to a few dozen entities I wonder what the effect on lag would be.
|
Niraia
Gallente
GREY COUNCIL
Pure.
|
Posted - 2008.09.20 14:06:00 -
[89]
Was this lecture recorded? I'd love to watch :)
 |
Zoiewu
|
Posted - 2008.09.20 14:20:00 -
[90]
Originally by: Niraia
Was this lecture recorded? I'd love to watch :)
exactly what i was thinking, Had a look but found nothing.
|
|
|
|
| |
|
| Pages: 1 2 [3] 4 5 :: one page |
| First page | Previous page | Next page | Last page |