What is your #1 EVE priority at the moment?

[Dr Zaius]

Ask ten players what they want and you'll get 10 answers, plus a whine. Still, some issues just keep coming up over and over again and never cease to get attention.

If you had to choose only one issue to be addressed in 2010, which one would it be?

[pward]

Even though I'm not playing, from your list I would have to say remove local, with (of course) a caveat. I would suggest to make local operate everywhere as it does in wormholes. If you don't talk while someone else is there to listen, you aren't visible in local to that person.

It's the equivalent of a planet wide sensor array in each ship. If I were in lo-sec or zero-zero; the first thing I would tell the onboard AI to do would be to disconnect that circuit so I was in full stealth mode. Worst case, I would have to use my engineering/mechanics/electronics 5 skills to short circuit the transmitter at the least, if the AI has something against disabling the comms device.

When in Jita (unless it's against CONCORD law or something equally painful) I would nix the channel as well just to avoid seeing the spam. It is nice to have available in other systems, such as when another player wants some assistance/advice with something and doesn't want to go to the help channels. But even then, it's elective to monitor and use, but it's still available if you want to use it.



Second on my list would be scrapping walking in stations... it's an unnecessary waste of programmer resources. If you think the spammers and whatnot are bad, wait till you can dance "nekid" on the bar in the spaceport... (Pardon me while I suppress these flashbacks of SWG cantinas, WoW towns and cities, etc...)

[Dr Zaius]

As much as I'm inclined to vote for lag as the number 1 issue in EVE today, I'm going to follow pward and vote to remove local. This is a 180 degree turnabout for me as I've always said that removing local would be a bad move. However, I've come to the conclusion that local in fact causes a lot of the other problems often seen in EVE. Removing local might actually help to mitigate lag to some extent because people might not automatically seek to blob the instant they see other players in the system. Of course, it might not work out that way and removing local might have no effect on lag or blobs at all, but there are still plenty of other good reasons to do it.

All that said, lag is something CCP absolutely has to do something about. The constant database crashes and horrendous lag in fleet fights is killing off EVE's endgame.

[pward]

Honestly, I think they should reduce lag by taking out the caps from the game above freighters/jump-freighters. The "I have been playing for years and need another bigger badder ship to abuse the noobs (anyone not having played as long as I)" should have it's limits. Whats next on the drawing board above titans... death stars? "Check it out, stations that can move around the system and cyno jump..."

Take away all but dreads (or reduce POS structures to be BS killable within reason and take the dreads too), and then zero zero space becomes more cooperative to get things done. Doomsdays weren't the pancea for blobs the devs thought they were going to be. By all means, introduce more T1, T2 and T3 ships, and eventually T4 and T5... But keep them to battleship and smaller.


Also, something needs to be done about the idea that there is an endgame. EVE doesn't have one specific end game. There is no checkmate, game over, we are done here, result to achieve. No reset the board and try again so we can choose different endgame tactics. EVE just is. Whatever you want to make of it while playing. If you get bored with one path, try something else in the game that tickles your fancy. I'm not trying to diminish lag as a problem, or to demean any particular play style. But really, there isn't going to be a new instance so there isn't an end game to this, just "what's the biggest ship I can fly to do the things I like doing".

[Dr Zaius]

Most definitely do not agree with you on that. If I'm going to invest years and years training a character, there better be something juicy at the end of the road to make all that effort worthwhile.

Besides, no one is using a mothership to "abuse noobs." Cap ships are used in fleet fights against other cap ships 99% of the time.

[pward]

Most definitely do not agree with you on that. If I'm going to invest years and years training a character, there better be something juicy at the end of the road to make all that effort worthwhile.

Besides, no one is using a mothership to "abuse noobs." Cap ships are used in fleet fights against other cap ships 99% of the time.

MOMs, probably not, unless you count giving out frigate sized drones to their fleet-mates... (they still do that right, just not so many at once?) or bringing reserves into the fight in their holds (gee that sounds real handy to keep the blob going), allowing jumpclones (another blob friendly effect), etc. MOMs are nice for logistics and other support tasks, but all of the caps start to be an I win button in nullsec for those who can afford one. (Assuming the opponents can't afford one, or parity.)

So when you grow tired of your titan, what will you want then? What kind of hyper-massive blob will be required to take one of the next generation ships down? How daunting of a task is it to fly something of that magnitude competently, for a new player? (Should be about a year to have the supporting skills much less actually piloting one.)

I still think the caps were over the top, and should have been reserved for the empires alone. Regardless of what gets done, there would still be issues with blobbing, since being the firstest with the mostest has been a rule of warfare for quite some time...


I almost want to suggest stealing a storyline idea from Silent Death (miniatures game). The reason you can't bring big fleets together is that it attracts "the bugs" (I forget their specific name). Combat on a large scale wakes up the local nest to come get some food and resources from the combatants. That was the "game mechanic" that limited normal fights to 500 points or so, keeping the games easily playable. All of the models produced were "destroyer" class or smaller, because the battlewagons and carriers could awaken the bugs all by themselves... (Rogue Drone infestations anyone?)

[Dr Zaius]

I've not lost a carrier in 0.0 yet (knock on wood), but I lost one the same day I launched it in low-sec. Unless you're flying with a blob, I don't suggest prowling around low-sec with a cap unless you plan on losing it. Once that cap is spotted and reported in local, people flock to the system to get in on a kill mail like flies.

I sort of like your idea about bugs. If more than, say, 800 pilots congregate in any given system, it wakes up the sleepers and they come looking for a fight. Of course, all those sleepers would crash the node too, so...

[pward]

And then the tactic of bringing the biggest number of targets will be a weapon of it's own. We bring 799 pilots in throw away frigates, just to jump your 2 carriers and their attendants, then watch the fireworks...

[Dr Zaius]

Exactly. Players will find a way to game just about any mechanic, no matter how well designed. Still, I can't help but feel there is something that could be done to improve the lag/blob situation.

[pward]

In essence (as I'm just guessing) the problem is telling all the other participants in the grid, that every one of the 200 (400/800/1200) other people on the grid exactly what you're doing (along with hundreds of missiles/projectile-animations/drones/etc.) tends to clog up any hardware you're trying to run it through.

Two players fighting one another takes X amount of bandwidth for their actions to update the other guy. (Not to mention the server so it knows when you're out of ammo, or blowing up...) So that's 2X throughput for each player, to and from the server as well, so that's 4X for the server. Add one more participant, and it's 3X for each player, and 9X for the server (1X in then 2X out to the other two for each player). Ten participants is 10X per player (one outgoing, 9 incoming updates), but 100X for the server to route it back and forth... Even if X is relatively small, for the server it starts to get exponentially big, assuming this is a relay type server communications arrangement.