Since fairly early in my EVE career, the idea of large scale battles was interesting (since no other games offered similar). However the problems with them, the lag, crashes, disconnects, and the eventual introduction of TiDi, turned me off the idea. (Which then promptly limits a lot of your long-range, end-game plans.)
I suspect that if any battle with more than X players used a number of the ideas listed above (reduce drones to effectively 1 drone 5 times as powerful, turn missile damage into direct damage (no flight calculations, no delay, possibly with simplified damage application calculations), convert ships into spheres, oblongs or cuboids - then it might be possible to run a large battle in near-realtime.
Unfortunately weāre all well aware of the limitations CCP has in editing their own code, or coming up with new code that isnāt riddled with bugs. So for now weāll just have to wait for someone else to drive the technology.
In hindsight I believe I took the comment too seriously ā¦
ā¦ but I still believe that their problem isnāt performance per se.
In the end does (a probably reinforced) node now run fleet fights worth 6k-ish people ā¦
ā¦ at TiDi, but thatās still a massive improvement over the last 5-10 years ā¦
ā¦ but theyāre nowhere near max capacity per node.
Think BrainInABox. That was a project meant to fix a design flaw.
The original creators probably didnāt consider that their design would be a massive bottleneck eventually.
I strongly doubt theyāre anywhere near the potential limit per node.
They just canāt use the horsepower due to bad design.
Thatās also where UpWell and Triglavian stuff comes in, because thatās newer, better code ā¦
ā¦ and Iām damn sure that, when they can finally completely untangle and remove POS code, weāll be seeing a performance-uplift!
the biggest leaps in computer architecture in recent years have been to relieve bottlenecks. Multithreading was conceived primarily to ease the stress of backed up command queues, and code was developed to take advantage of massively parallel computing power as a result. Procedural rendering was intended for massive and detailed backgrounds from seed values and fractal algorithms rather than storing those backgrounds as bitmaps - which had the unintended but welcome side effect of making it āeasierā to fog distant or less visible elements.
The bottlenecks CCP are facing right now and have been for several years include but arenāt limited to the single-shard database with what is essentially a single pipe in and out, and that legacy code. The design philosophy behind the EVE server is that single shard, thereās no getting around that, all you can do is keep on top of that single-shard performance and keep throwing money at it. The other thingā¦ we all know what happened when they tried to simply tear that outā¦