f13.net

linky (http://myeve.eve-online.com/ingameboard.asp?a=topic&threadID=635828&page=16#476l)

A lot of you seem to want to patch up the old system, which is what we've been doing ever since it was released. Many of the ideas you've posted would indeed improve the current mechanics. However, we think it's pretty much broken at the core. The sovereignty system doesn't "feel right". Just to show you how much of a change we're willing to consider I'll post a little draft of one of our ideas.

Borders:


From wikipedia:
Borders define geographic boundaries of political entities or legal jurisdictions, such as governments, states or sub national administrative divisions. They may foster the setting up of buffer zones. Some borders are fully or partially controlled, and may be crossed legally only at designated crossing points.

EVE has borders; this is where most fights take place and what really matters when holding systems. Stargates are borders; we’ve got different types of borders. Within constellations, between constellations and between regions. We want to create a new system to improve the dynamics of space dominance and make the borders actually mean something. The current mechanism is flawed and the task to gain control over systems, constellations and regions is a tedious timesink that no one seems to likes.

Capturing:


Claiming space would revolve around capturing gates. In order to claim large areas of space you'd have to start small and "spider out". You'd start by capturing a system, then a constellation and finally a region. An attacking entity would have to follow the same trend, by first disrupting the control of the region, then the constellations one by one, and finally the systems.

In order to increase the possibilities of fun and well coordinated battles, as well splitting up blobs, we want to introduce simultaneous goals in 0.0 warfare.

    * Capturing a system would require a presence at every gate.

    * Capturing a constellation would require a presence at every constellation gate.

    * Capturing a region would require a presence at every region gate.



Disrupting control over a system, constellation or region will require presence at multiple gates, but obviously not all of them, since then the defenders could just blob up at one of the gates.

Capturing will probably not be hit point based, as that goes against the anti-blob objective. We'll probably want to introduce a system where a certain amount of ships needs to be present to take over the gate. We could base it on ship size, so you might need 20 crows or 10 ruptures or 5 battleships (Random numbers) to begin the take over. We could also scale it, so you need very many people to capture region gates, a bunch of people to capture constellation gates and just a hand full to capture a system gate.

Of course there will also have to be a "reinforced" system. The defenders should be able to choose when to defend.

Border control:


Is something missing from EVE. We want give the sovereigns the ability to monitor and defend their borders. Allowing them to anchor defenses as well as tools to see who, when and what has been using the gates. The sentry guns will primarily be gate defenses, they'll have high locking times and will have to be manned by players.

We'd probably only want anchorable objects at region and constellation gates. Outpost systems could get beefed up gates etc.

Treaties:


Although I’m sure we’ll have evolved somewhat in 20k years, currently borders and peace are negotiated through treaties. We want treaties to work like free form contracts, but with regards to space and gate control.

An alliance holding every constellation except for one would be able to negotiate a treaty with the corporation holding that constellation. Basic stuff like monthly payments, collateral and such negotiated and signed upon.

Give me your thoughts on this idea, also keep posting your own ones, lots of good stuff.
Nozh
Game Designer
CCP Games

And cue twenty pages of outrage from dread/titan/etc pilots.  :awesome_for_real:

That sounds awesome.

I havn't really participated in POS warfare at all yet, mainly because it sounds boring and laggy, this sounds like a hell of a lot of fun and would do wonders to split up blobs.

Player-manned stationary gate guns... that sounds like a hoot.

Wow, thats shit I've always dreamed of having in an MMO, and thought Eve was shitty for not having when it was set up perfectly for it.  Guess we'll see how they actually do it.

It actually sounds like a pretty good anti-blob mechanism though a "reinforced" system sounds lame (if necessary).

My question is, would they reset 0.0 space upon the implementation of such a system?  Seems likely to me, and that'd only serve to piss folks off.

But it would also mean BAT could join in the land grab!

Does sound better, but I think there are a few analysis flaws that don't take into account human nature :P

This type of system (finally) allows for defense in depth--but humans are never going to do that. "Blobs" will simply convert from on grid blobs to in system blobs for whichever current system is hot--and as soon as there is a contact call, folks are going to simply warp to the contact fight, bringing us right back to blobbing again.

Hopefully, smart tactical commanders will use this to their advantage and force defenders off into the wrong places via probing thrusts and such, but while there are definitely some tactically smart folks playing this game, in general the mob mentality isn't going to go away--it'll stay spread out until any contacts are reported, and then will simply re-blob unless they go even deeper into this concept.

Haven't spent a lot of time thinking about it, but the only game mechanic I can think of to counter this mentality would be to only control use of a warpgate if logged in ships are within 100k of that warpgate--meaning that folks would be forced to stay out of fights to block flanking attacks--extremely useful tactically, but boring as hell for players :(

Gate camping is already a central activity of PvP.  This would make it *the* activity.  PvP should be away from the zone lines.  People should get the oportunaty to actually load the zone and control their ships.  People shouldn't be explioting the zone lines to avoid combat.

Yeah, this sounds like a big issue to me.  Stock the gate with lots of crap, put up a bunch of guns and blast anyone that comes through while they wait for the grid to load.

This does increase the usefulness of Cyno capable ships by a lot though, as to enter enemy territory you are going to have to cyno in and then assault the gate to let the rest of the fleet in.

They want to make taking space less tedious and time consuming by making it so that you require a presence on multiple gates? Multiple gates in multiple systems? multiple systems in multiple constellations?

It's already hard keeping track of who is camping 3 gates in just one target system.

"Who is on the gate, no the second gate, we need more ships in gate 1, fuck you moved from gate 3 nono you fucks the second gate on the first not the third"

Also, PoS warfare will forever be required. PoSes are needed for forward staging bases and safe spots that you can hide in, dodging enemies in their systems. Taking down and defending moon mining / economic PoSes are also not going to go away.

Yes, but at least this way territorial control won't revolve around POS spam. They ought to become more as secondary strategic objectives rather than the focus of fights.

I think i like the system described. It makes a bit more sense if you think of it in terms of a medieval city-siege. You have a town which is walled-up and can only be accessed (pragmatically) via a number of gates. In order to defend the town, the defenders must man every gate in order to prevent the aggressors sneaking in. Losing one or two gates doesn't spell defeat for the defenders, but it allows the attackers to get more and more people into the town, taking the fight to the streets, etc... Conversely, the defenders fight back, reinforce the weak spots and take the gates back, driving the attackers off and/or isolating those that managed to break through.

The question then is, how do you get control of the outposts?

If you capture a system/region with an outpost, do you automatically get control over it or do you now have to spend hours taking it down and waiting for reinforced mode to go away?

I like the idea that you don't have to kill an outpost itself, but you have to control the system it's in. With the extra guns/power the outpost can provide to defend the systems, you should see more outposts at the edge of the regions/constellations to help hold your control over the space. Once that system is taken, then the outpost should belong to the new owner of the system.

Edit: but of course it would take awhile to plant new defenses, once the old ones are destroyed, so in that sense it's in 'reinforced mode' making it easier for the previous owners to get it back.

(Of course, the 0.0 carebears will cry if their stuff gets stuck at a now-hostile-outpost .. )

This sounds wicked. It introduces a LOT of potential for strategic operations. I admit, I have been on one giant Op (last night) and one smaller sucide Op (bat run). But in the giant one last night, there were only maybe 3 facets of the strategy: Scout, sniper, and the rest. Communication wasn't very good since the only one talking was the FC and I guess his XO. My Squad Commander, and the Wing Commander in the branch I was in never gave any orders one time, either in voice of fleet chat.
This represent, to me, a HUGE area for improvement. With the separation of blobs, you introduce the need for someone to be in command of each Wing, something that's *already* supposed to be happening, as evidenced by the way the Fleet is set up. This allows each Wing to have an operational plan, set by the FC, and to work independently of the rest of the fleet toward the same goal.

Essentially, I would love to see a well-organized fleet take advantage of the tools provided in game already. I have no plans to ever join another operation like the one last night. It was boring. In the small amount of time where we weren't just sitting in space waiting, I spent a ridiculous amount of time staring at a 1 frame-per-20-seconds screen, hoping one of my launchers would fire.
Blobs (and drones) suck ass.

The need to take on multiple targets simultaneously will drive up demand for those of us comfortable leading gangs and fleets: get your FCing practice in early!

The idea seems sound, especially as a starting place.  I have been on exactly Zero blob-type fights or POS killing engagements, so I don't know just how boring they can be.  But, that seems to be the issue here... will the extreme logistics/communication of the new system be more fun than the current blob-kill the POS system.  I think this is a step in the right direction, as right now borders really are quite meaningless on a day-to-day basis. 

As to the 0.0 area, I think it would be pretty easy for them to let Alliances get immediate access anywhere they have an Outpost.  From there it really would not take them long to "capture" all of the space that they currently "claim".  This may not be as true in the South I suppose, but in the North it would seem rather easy.

As to the gate-PvP issue... I have never been a fan of zone-line PvP or choke-point PvP where people have to warp into the chokepoint... but I really don't see any other possibility with the game design EVE has.  Warping is just a fact of life, and warping from a gate to a station is not much different from warping from one system to another.  EVE has no "open field", so it seems doomed to a life of chokepoint PvP.  Any time you move grids you will face a similar issue.  I think the EVE guys are targetting the thing they CAN address - Number of people per grid.  I have loved the 30-50 ship battles I have been in, and if that is what most of 0.0 turned into it might just pull more people out.  I gave up the whole "watch my machine process for minutes" play style back in Shadowbane.

I think they should improve alliance management (I'd call it government) too, if they do all that border stuff.  The only gradients we have right now are "individual", "your corp", "your alliance".  There are no differences between corps as far as their rank within an alliance (maybe I missed them?), and it's also difficult to set up permissions or taxes or whatever for "other corps within the alliance".

Because it sounds like "defending the borders" will likely become the job of the corporations within the alliance, with each corp defending a small part of the border.  Yet they only have that "treaties" stuff that deals with foreign policy, and no interface for the same stuff for domestic policy.

I think you're going to find the people most open to a system of territorial control that doesn't center on POS warfare are the people who have been doing it, whether they've been winning or losing.  It just sucks, any way you slice it, nobody doing *any* part of it is really having any fun.  They do it because it's how you win, not because they like it.

--Dave

I've been avoiding the shit out of it -- lagfests are never fun, you walk away dissapointed because you got popped and didn't see/know it, or feeling lucky that you didn't die despite the lag, but theres never any real feeling of accomplishment.

While I think that the gate control mechanism would still allow for blobbing, it would make blobbing a lot less efficient.  If your blob is going from gate to gate, the enemy is just going to be right behind you un-doing your damage.

If they are going to put in tactical warfare of this scale though, I think they really need to replace local with constellation, you can't flank someone if they know you just zoned in and you're warping in from 50AU with a sniper fleet.

I really hope that we don't have to sit on gates or watch gates for intel (to detect the enemy), esp. if they remove local.  Nothing's more boring than that.  I really hope that they implement some sort of function where the gate will email the corp whenever reds enter and are aggressed or something.

The beginning of camping warfare.
You know, with POSes at least you shoot at something...

I tend to agree with Joe here.  Moving to gatecamps is not necessarily a "wow, what fun" solution.  Killing cynos is horrible, but jumping into hostile camps with fighters deployed and a titan on grid is hardly going to be like a breath of fresh air for attacker or defender.

The only upside is that at least it will be fleet vs fleet, rather than large POSes standing in for fleets.

All I really care about is getting rid of the lag shit.

Not gonna lie.

This almost, ALMOST makes me want to play.

Well, the EVE source code just got leaked (again) so maybe some enterprising freelance programmer will do CCP's job for them.  :grin:

I thought only a little bit of it showed up on the pirate bay. Is the full deal?

So, 8-1200 people in Jita hammering on the Market or 600 combatants flitting around a local area pell-mell are issues that will be solved with an optimized client?  Riiight.

Well, gridloading is something that does have a client-side component -- they dump several megs on you of data at once, regardless of whether you need it, before you can load.

However, that's really straining their side of things more than yours. Supposedly they're in the middle of fixing it, changing it, or optimizing it.

These guys really need to take a look at OpenTNL  :mob:

Why not implement some sort of data throttle? My cpu fan supposedly changes speed to reflect the heat generated, going faster when it's hot, and slower when not. So why not have an optional filter where the client will begin to filter out unneeded crap when lag hits? I will now go sit in the corner with a tall pointed hat on my head, for I am sure that this is pretty stupid.
But it sounds good.

If they are indeed moving megabytes of data when loading the grid, then they should just rewrite that crap. I mean, what do you need to transfer to a client when he loads the grid?

Lets pull some numbers from our ass. I'm assuming they use 32-bit data types mostly (probably could optimize these as well).

From the top of my head, for each player:

location:             3 floats
velocity:             3 floats
ship type:           1 int
player name:     32 bytes (?)
ship name:        32 bytes (?)
corp tag:            5 bytes (?)
alliance tag:        5 bytes (?)
turrets:              assuming 32 bit IDs for modules I guess the max would be 8 ints
armor %:           1 byte
shield %:           1 byte
structure %:      1 byte

Total:               137 bytes / player

I'm sure there's other stuff transmitted, so lets round that up to 256 bytes / player. Assuming 1000 players in a system, you need to send the stuff from 999 players to each one (if they can all see each other): 999 x 256 bytes ~ 250 KB. That's like 3% of eight megabytes. The server would then have to send out 1000 x 250 KB ~ 244 MB. Shouldn't be that big of a problem, the loading could still happen in seconds instead of minutes.

Not a bad first stab, but you are probably making an assumption that may not be correct:

We don't know that they don't actually network all physics data about the ships and modules down to the client as part of the data push. Things like max speed, acceleration, turning rate, resistances to damage types, all of the things needed to simulate the game client side for prediction/extrapolation purposes.

Worst case, the amount of data per ship could easily be upwards of 10-20k. It's theoretically possible that their early network code didn't abstract out ship types into what's called static data (stuff that never changes game session to game session), and are even transmitting the same data for all ships of a certain type over and over again.

You also can't ignore things that the client can inspect if they want, but normally don't--such as standings per player (god it would suck if they are delivering ALL the standings of a particular ship in the initial update, but I could see it happening), simulation data on things like bounding boxes, camera limits, all sorts of things that should already be client side, but bad networking strategies might require being sent every ship, per ship.

One of the things I tend to do when being bored in a game (ratting for example) is to try to reverse engineer what they may be doing network side based on what I see in the game. A couple of things I've noticed that look unusual:

--you get the damage to your ships updated instantaneously when the data arrives, but the client doesn't actually render the effect until a bit later (ever see you take a missile salvo damage, and then the missiles hit you on screen a half second later?). That implies to me they are running all calculations server side (which is good), but only transmitting the final result, so the client has to catch up each effect render. That further implies that when an event like this occurs, they have to send a lot of data so the client can accurately represent the effect (who launched the missile, missile speed/accuracy/turning rate, etc. etc).

--the client seems to do very little adaptive prediction--you don't see the effect change of a move until the server acknowledges it and returns a response. This implies a pretty simplistic event based networking model, instead of one that allows for interpolation and extrapolation during standard traffic conditions and server-client synchronization. That in turn implies that many of the more common optimizations for bandwidth (update priorities, static data, throttled bandwidth based on priorities and update size per packet, latest state data, and quite a bit more) probably aren't implemented either.

I can't imagine why they would transmit this data since their prediction is really basic. If you cut your connection things just continue in a straight line according to what speed they had when the connection was lost. So no turning or anything. Things will still keep firing. At least guns do, both NPC and your own. Can't remember what missiles do. None of the attacks will just do any damage. So it seems they send events like "start shooting", "stop shooting" instead of sending each attack separately. Although if they do this accurately, they need to indeed send the rate-of-fire of the person (and the module) that is shooting. But this shouldn't be done during the initial grid-loading since most of the time (especially in hi sec) you never see people shoot. Same goes with all the other modules. They shouldn't send any module data until its really needed.


I assume they don't do that because, A) it would be really stupid B) when you inspect someone it always has a delay. It feels like the client is waiting for data from the server. But if they somehow manage to indeed get 8 megs sent during the initial loading, then they must be doing something really weird.

Logserver.exe is provided with the client and is in the root EVE directory, and they ask people to include the output of that when sending bug reports.  If you want to look at what the client is doing, you run that, then you start your EVE game and do whatever, then exit the EVE game and the log will be available.

If they do send 8 megs of data it should be visible in the logserver logs.

This certainly gels with what happens in all but the 1000+ person fleet battles: you sit around with a blank screen for several minutes then bang the grid loads virtually instantly and the lag is then a fairly constant module lag issue of up to 20 minutes.  More on at least one occasion in the Feythabolis campaign.

The really big battles are a complete lottery.

I've been to a lot of big battles in a Covert Ops.  More than once, I've been unable to steer away from something, been completely uncloaked in the middle of the enemy fleet, stayed that way for 5-10 minutes, and not been killed simply because by the time anyone saw I was there, my recloaking or warp-out had kicked in and I was safe.  The mass battles are simply too damned hard on the *server*.  A battle is an N^2 problem, when N = 200+, the server just can't handle it.  Theoretically, if they could dynamically rebalance and transfer systems between server nodes, they could keep a handful of baby supers on hand to deal with big battles and the limiting factor would become client framerates and network throughput.

--Dave

Are they still running only dual-processor 64-bit AMD Opteron-based IBM BladeCenter LS20 blade servers? I would think they would have upgraded to 4 or 8 cores by now. You can get 8 core 18Ghz machines for dirt cheap. I would think their coding would be multiprocessor compliant if it works anything like web servers do.

Multicore doesn't help you much if you're using an scripting language that has a big 'ol lock around the interpreter, which has been a big limitation of python forever.  I don't believe stackless fixes that issue.  If they have to have everything in a node in the same process (would not be surprising) there's no benefit to be had from more cores except possibly density (running more server processes per box).

They went through a couple of upgrade cycles to stuff like that.  I believe Jita runs on a dedicated 8-core blade running as an SSI.  Sometimes if you give them advance warning of a battle, they can give it a dedicated high-end node the DT before and things improve.  But that just raises a workable N to about 600.

--Dave

Wait, doesn't stackless python mean they only can run one node on every core? It used to be like that, don't know if changed.

I'm less familiar with stackless, but with regular Python, the interpreter itself is not threadsafe/reentrant so there is basically one big lock around it.  Thus, in a multithreaded python program, only one thread can actually be running python instructions at a time.   This means that there is little advantage to running a multithreaded Python program in an SMP environment, unless it's doing heavy native computation without the lock held (typically pretty rare).

My assumption was each node is a single python environment, which would at best use a single core even if mulithreaded.  Presumably it *is* multithreaded -- otherwise I'd fail to see the advantage of stackless which brings inexpensive microthreads (aka greenthreads).  Of course cooperative, non-kernel-level multithreading is an enormous nightmare if you want to actually take advantage of multicore systems.  Oops.

This is pretty much the biggest advantage java has over most of the other popular scripting languages -- it actually *can* take advantage of multiple cores.  Sadly it's got tons of other issues... don't get me started ^^.  I'd love to see a lightweight scripting environment that is actually multithread/smp friendly.

I understand that's their current problem. If I understand their development thinking, they decided zoning was a huge exploit area and designated each solar system as a single zone, no exceptions. No breaking up zones. So "zoning" is a full wipe and load as you jump, which means it's hard to play zone-boundary games -- you can't wander back and forth like you can in, say, EQ. (Remember, this was all designed in like 2000 or 2001).

So they decided, based on projections of the universe size, number of players, and the sorts of numbers a "busy system" should encounter, that this would be easiest if each solar system was a single, unique thread. So a processor could run one busy system, or several empty ones. But you couldn't split a solar-system over multiple servers, as this would require some sort of zoning.

They used stackless python, which was perfect for what they wanted -- each system a seperate and totally independent thread, and they could microthread the crap out of each system. It worked really well -- until people wanted to start 300v300 fights, or pack 1200 people into Jita.

Their current problem is to fix it requires either zoning busy systems (which either means some serious rewriting of code, and the probably introduction of lots of godawful bugs -- especially duping bugs, which will fuck them hard if one gets out of hand), or rewriting stackless's interpreter to handle multiple processors (also another bitch job). Short term, they've been altering gameplay to try to (1) cut down on server calculations -- things like drone reduction and now the garbage disposal they're planning, (2) Thrown hardware at it, and (3) Altered gameplay to try to cut down on the blobs and get people the fuck OUT of Jita.

There is one thing that was keeping me thinking recently:
Would it be possible to implement "Bullet Time" for entire solarystem?
IF load gets twice as big as CPU power available to given solar system, make everything (reloading, acceleration, itp) in the system happen take twice as much time and slap a nice graphic effect on it. Problem with lag isn't with battles being slow, but with everything fucking up - waiting 30 minutes to load anything (and more frequently not loading at all), messing up of command execution queue and having to wait 15 minutes for your commands to be acknowledged. Gun firing once a minute instead of 6 times a minute would be much better than waiting for 15 minutes for them to start firing - extra time and no command lag would also make focus fire easier so people would die much, much faster, possibly balancing out slowed down game time.

Other than that, they should fix their design - people blob because blobbing give them advantage - both in firepower (having more guns makes winning easier) and strategic value (ie. being able to take down cynojammer in 4 minutes, faster than the enemy can form up and reach the system). There should be a hardcoded limit to how much dps POS Tower can take/heal and every other POS thingy should be balanced from it.
Some penalties for blobbing (in one grid, game should encourage attacking in several places at once) or crowd control weapons other than doomsdays would be nice.

Oh and while we're at fixing the game, they should make constellation chat behave like local and ditch the local althogether. With tools like BEACON, removing local would actually help carebears, probably more than it help gankers.

I doubt it, for the simple fact that the client is single threaded, and if your chat gets lagged the client will stop the graphics and wait for it.  I.E. it cannot play a "nice graphic effect" while it waits for data, it simply freezes as it waits for data.

Uhm, nope? Client is microthreaded and uses prediction quite heavily.

Joe, your idea about a max dps that can affect a tower, either inflicted or healed, is brilliant. If there is simply no point in bringing more than (say) 20,000 dps plus reserves, then there is a real point in multi-pronged attacks.

I suppose you would have to make the max_healing equal to the max_damage (what about hardeners, they lower max_damage so they should also lower max_healing so they would become useless) and limit the number of guns on a pos.
This means the attackers would still blob when there are carriers repping a pos and be at liberty to attack many more posses at once. So I think this would lead to multiple posses getting reinforced but the same blobs we have now when posses come out of reinforced. 

Right now very important part of blobbing is ability to finish the damn POS/module faster. After the change you wouldn't need everyone you can possibly get online, but merely enough people to kick other team ass. It's a huge difference. You're right - it won't fix blobbing completely, but it will limit it, and at least make alternative strategies worth considering (after all, the most optimal way of reinforcing would be going after several POSes at once and most optimal mode of defense would be simultaneously repping multiple POSes; in worst case it means that after every large attack at least one POS will change hands, and all other cases look...interesting;-)

Max healing would have to be equal to max dmg, otherwise we would create quite lame timelimit penalty for one of the sides. After all both sides have to be outside of shields to do their thing, so eventually the better one will get their way:)