| Pages: [1] :: one page |
| Author |
Thread Statistics | Show CCP posts - 0 post(s) |

redeyehunter
Minmatar Shinra Lotka Volterra
|
Posted - 2007.02.23 14:10:00 -
[1]
Hello All,
I am just putting forward an idea for a new way to do fleet battle. You may as why, and the simple answer is unplayable lag in large fleet engagements.
Here it goes.
When fighting fleets engage are engaged in a system that has sovereignty and a Conquerable Station or Outpost, the proportion of defenders and attackers should be set to what the system can handle at a playable level. for example if a system can safely play 100 people, then lets say 60% Attacker and 40% defender alliance. (defenders normally have tactical advantage, and attackers need more firepower to break.)
It is very simplistic but I would rather go down fighting, then to be lagged out and find myself in a pod. What happened in JV1V recently would be a good example of what too many people can do to a system.(from info i got even GMs could not fix that)
Questions that even I ask .
Q:what if you get your ship blown up? A:if defender get new ship at station, or pod yourself out of system to let someone else in, if attacker pod yourself or leave system to let someone else in. (note this someone else could be a logged out character in system. Also nice way to deal with log on traps)
Q:what if I logged out of system and the limit is reached? A: Well, you should have though of that first before logging out in a war zone. Maybe a mechanism that let you move yourself 1 jump out of system might help, but thatĘs a Dev call.
Q:what if my alliance has numeric advantage over defending alliance? A: well; until system can cope with 1000s of PVPers in system slogging it out, this seems to be a logical way. Remember Node crashing hands a tactical disadvantage to defenders and attacker randomly(randomness is not what this PVP is about, itĘs about solid tactical fighting), attacking form attackers can get slaughtered jumping in if they are the ones lagged out. I also think that it is unfair that a highly skilled player with loads of training i.e. fleet command 5 should be crashed out. Crashed out means reforming fleet 90% of time and your skills advantage is rendered void, due to numbers and the pot luck chance defenders and attacker have at re-entering system. Besides if you fleet has numeric advantage you will always have someone ready to jump in when you one of your members dies in the disputed system.
I think the above idea is in the spirit of what EVE Fleet PVP was designed for. With the reality of hardware limits (both bandwidth and servers) it would represent a good compromise in my opinion. But what I want to hear is your opinions especially Devs, maybe you see problems that I can not possibly know of.
|

Jaketh Ivanes
Amarr Riggers Incorporated
|
Posted - 2007.02.23 14:20:00 -
[2]
Sounds to much like an arena idea... not a bad idea, but a bit agenst EvE imo.
What would happen if a system capable of holding 100 players allready had 80 defenders.. should 40 of them suddenly dissapear in thin air? And if someone in the defence fleet got killed, would one of the "reserve" then reappear out of thin air? Where would they appear? If its where they got remove, i hope it was not right in the middle of the enemy's fleet 
|

redeyehunter
Minmatar Shinra Lotka Volterra
|
Posted - 2007.02.23 16:03:00 -
[3]
In post above I did say would be nice if those logged of would be given option to move to a system 1 jump out. Alternatively they could just wait it out till space becomes available. Remember I am not saying other system which do not have player owned stations have this limit
In any case you make good points keep it comming guys
|

Iasius
FinFleet Lotka Volterra
|
Posted - 2007.02.23 16:34:00 -
[4]
Attackers should be able to take a system that has weak defenses. Defenders should be able to repel attackers with suprior numbers. When enemies would to get it on with big numbers and do either the eve cluster and a node bombs destroying the game. Best thing i can think of is a ticket system evenly divided between enemies. And pod death's to a same system station mean a new ticket needs to be attained to undock.
.
A dev asked 2 weeks ago why a node crashed after a battle with 460 people in system 46DP-. Players themselves can use the eve starmaps to see what is happening in systems. After 5 minutes the dev found out by chatting in local why the node crashed.
|

Steve Bennett
FinFleet Lotka Volterra
|
Posted - 2007.02.23 17:37:00 -
[5]
Most people's knee jerk reaction to this is "no, this would go against fundamental model of Eve".
However, as made clearly evident by the JV1V event, Eve does not work with its current model. The original Coalition of the South (LV, V, Chimp, KOS) learned this when trying to assault C-J (both times), and the new coalition (as well as LV) noticed with JV and pretty much every large battle in the current war (neither side ever really wins because the real battle never occurs, they just survive the lag better).
I think a big bonus of this model is that it supports alliances/players fronting the biggest & best (read: most powerful) ships they have. If you can only bring in 60 ships, you'll probably bring in a damn high amount of capital ships. And I think this is exactly what the Eve devs have always intended Eve to be. I know I get excited when I'm bringing my best gear, and I see a few faction battleships next to me.
There would be some game-mechanics issues .. such as - how do you tell who is the attacker/defender? Could you circumvent the limitation by splitting your alliance into several small alliances, and having them all attack at once (each getting the 40 ship cap)?
I think this will take a long time to impliment, but its absolutely crucial. I think a lot of players are leaving the game until this is fixed (I know LV is pretty displeased, as well as many ASCN pilots). I'm sure many of the coalition PvPers are displeased when they win by default when they COULD (or WOULD) have won by merit/tactics/whatever if the game could handle the intended battle. --------
|

redeyehunter
Minmatar Shinra Lotka Volterra
|
Posted - 2007.02.23 18:51:00 -
[6]
Edited by: redeyehunter on 23/02/2007 18:48:20 Edited by: redeyehunter on 23/02/2007 18:47:49
Originally by: Steve Bennett
There would be some game-mechanics issues .. such as - how do you tell who is the attacker/defender? Could you circumvent the limitation by splitting your alliance into several small alliances, and having them all attack at once (each getting the 40 ship cap)?
Defender would definately be the one that holds sov. The sov alliance (maybe plus friends) is allocated so many seats in the system to defend. Attackers are basically war decing parties. (at least war dec would mean something in 0.0) so if system can hold 100, then 60 seats reserved for war decing alliance attacking sov system of enemy. Of course if there is no war you could have others enter system, but sov alliance always hold 40 seats.
Again I am just thorwing ideas out there.
|

Mister Spanky
Caldari GoonFleet GoonSwarm
|
Posted - 2007.02.24 01:23:00 -
[7]
Edited by: Mister Spanky on 24/02/2007 01:24:43
A simple solution to the current problem of "Gate Blobs" would be to introduce "Jump Gate Interference". This 30km sphere of static would prevent you from targeting ships within it or activating Warp Disruption Bubbles or Cyno Generators anywhere near it.
This would force battles away from the gate and encourage a more strategic approach to fleet warfare. Pirates may have objections to this suggestion but I'll deal with that issue later. let's concentrate on breaking up the blob.
Gangs, wings and fleets should have an optimum number of pilots and exceeding that optimum number should result in a "pilot stacking nerf" which reduces the bonus effects of their gang modules. If the gang is ridiculously over the top then the nerf would become a penalty and the gang mods would be rendered useless.
Forcing combat away from the gates and breaking up large gangs in favor of smaller and more specialized groups would go a long way to creating the "Chess in Space" gaming strategy most people would like to see the game adopt.
To assist in this process it would be necessary to make a few changes to other items, like giving Gang Bonus modules additional secondary benefits to encourage their use and allowing Warp Bubbles to be set up in a system between gates so that the Pirates can continue to have their fun. 
Another idea that would help reduce gangs would be to introduce a "Warp Gravitation Factor" so that the more people you have in your gang the greater its potential "Fleet Mass" becomes. This in turn effects how long it takes to get your gang into warp and the speed at which you travel while warping. If your gang is ridiculously large you may not even be able to warp at all.
This could then lead to the development of new Gang Modules like a "Warp Drive Accelerator" and a "System Scanning Matrix" which would allow the pilots in your gang with scanners to co-ordinate their searches and allow for the rapid scanning of entire systems (again good for Pirates, too). It would be cool if this scanning operation were to appear on the system map like a radar screen so that everyone in your gang could see it happening in real time and watch the enemy ships "ping" on their map as each one is found.
Chess in Space!
---------------------------------------------------
|

redeyehunter
Minmatar Shinra Lotka Volterra
|
Posted - 2007.02.24 11:43:00 -
[8]
Originally by: Mister Spanky Edited by: Mister Spanky on 24/02/2007 01:24:43
A simple solution to the current problem of "Gate Blobs" would be to introduce "Jump Gate Interference". This 30km sphere of static would prevent you from targeting ships within it or activating Warp Disruption Bubbles or Cyno Generators anywhere near it.
This would force battles away from the gate and encourage a more strategic approach to fleet warfare. Pirates may have objections to this suggestion but I'll deal with that issue later. let's concentrate on breaking up the blob.
Gangs, wings and fleets should have an optimum number of pilots and exceeding that optimum number should result in a "pilot stacking nerf" which reduces the bonus effects of their gang modules. If the gang is ridiculously over the top then the nerf would become a penalty and the gang mods would be rendered useless.
Forcing combat away from the gates and breaking up large gangs in favor of smaller and more specialized groups would go a long way to creating the "Chess in Space" gaming strategy most people would like to see the game adopt.
To assist in this process it would be necessary to make a few changes to other items, like giving Gang Bonus modules additional secondary benefits to encourage their use and allowing Warp Bubbles to be set up in a system between gates so that the Pirates can continue to have their fun. 
Another idea that would help reduce gangs would be to introduce a "Warp Gravitation Factor" so that the more people you have in your gang the greater its potential "Fleet Mass" becomes. This in turn effects how long it takes to get your gang into warp and the speed at which you travel while warping. If your gang is ridiculously large you may not even be able to warp at all.
This could then lead to the development of new Gang Modules like a "Warp Drive Accelerator" and a "System Scanning Matrix" which would allow the pilots in your gang with scanners to co-ordinate their searches and allow for the rapid scanning of entire systems (again good for Pirates, too). It would be cool if this scanning operation were to appear on the system map like a radar screen so that everyone in your gang could see it happening in real time and watch the enemy ships "ping" on their map as each one is found.
Chess in Space!
I like your ideas, in particular how to deal with gate blobs and pulling targets out with strategic laying of mid warp bubbles. All is good so long as it means that the game will be playable and as lag free as possible.
|

Elenit
|
Posted - 2007.02.24 12:34:00 -
[9]
Originally by: Mister Spanky
Gangs, wings and fleets should have an optimum number of pilots and exceeding that optimum number should result in a "pilot stacking nerf" which reduces the bonus effects of their gang modules. If the gang is ridiculously over the top then the nerf would become a penalty and the gang mods would be rendered useless.
1 Fleet should be better (in terms of fewer client & server overheads) than multiple fleets.
Originally by: Mister Spanky
Forcing combat away from the gates and breaking up large gangs in favor of smaller and more specialized groups would go a long way to creating the "Chess in Space" gaming strategy most people would like to see the game adopt.
The only effective way to get people away from gates is to implement a system that doesn't use gates. Reserves for either side need to come from somewhere. Jumping into a system shouldn't just be pot luck.
Far more needs to be done that allow tactics (ala "Chess in Space") to operate. There needs to be far more logistical warfare. Think anchorable objects in space with area of effect (not POSs) but something that give short term advantage. The Jump Gate interference idea is a great one - but don't make it static. Make it require TLC (Fuel, logistics ships to energy transfer).
Your ideas for new gang modules are good - but hook them into these anchorable modules. For a start it should make the system use less overhead - as communication would be established between the anchorable module and the ship module.
I think of it as I'd like the story to unfold;
Officer Pimp is reporting to his supervisors, "The Logistics team have been hauling the Jump Portal generator into place. It's anchored 8 ly from PQ1TY and the guys are ready to start powering up the module. The Omega team have stockpiled the deployment modules and as soon as they get a green light from the strike team they're ready to jump." " We will open 2 portals into the system - the first at Planet 1 and the second, 90 seconds later at Planet 7," Pimp says pointing at the system map on the overhead projector. "30 seconds before the supression field is up we will generate our own cyno and our capital fleet will jump."
"Where's the location of their reserve force," asks a figure from the darkness. Pimp swallow nervously, "Their support fleet is 5 ly away - 6 jumps north of the PQ1TY. As soon as Omega jump into system they will deploy the cyno suppression fields," he answers. "Their reserves will have a 5 minute window of opportunity to jump in their capital fleet. While the supression fields are being anchored and fueled - the strike team will provide cover for Omega."
Pimp updates the system map on the projector, "Once the capital fleet is in the system the logistics team will resupply at the carriers. Squad Alpha will deploy the Warp Attractors 50km from our capital ships. This will drop incoming ships at optimal range for the support ships. Squad Bravo will deploy the sensor inhibitor network which will affect the enemies sensor capabilities." "Meanwhile the strike team will locate attack and destroy the anchored enemy sensor boosters that covert ops have bookmarked. The sensor boosters have been scanned and are fueled with 1500 units of stront giving them shields of 1.5M HP - so it'll take 10 mins to destroy each one" (1 unit of Stront gives these things 1000 HP). You get the general idea... Note: This only talks about an attacking force and only lightly touches what a defending force can implement. Not a bias - just brevity due to limited characters in a post.
|

isAzmodeus
|
Posted - 2007.02.25 16:00:00 -
[10]
Change gate mechanics so that it splits the battlefield.
1) An idea would be to limit the mass/objects that can jump through a gate in a given amount of time. Maybe 30-40 BS or 80-100 frigates or some scale of ships and mixtures in between. This would prevent large jumps of 200+ ships inside of a minute. Make it so that only 40-50 BS could go through each minute. This would make it impossible to crash a node by mass-jumping.
2) Of course, this would give system defenders an unreasonable advantage, so another change would have to be made. Allow gates to be "hacked". This would require time (about 15-30 minutes per hack), but each successful hack would clone the gate. It would create a temporary second location the gate sends to. 5 minutes before the gate is open for transit, it would appear in the defending systems' overview, giving defenders time to redeploy accordingly. These gates would last for 3-4 hours. Now, the defenders would have 2 gates to cover. The attackers can now get double the mass of ships in the system, but in 2 separate fleets. If the attackers want to send more ships in, they hack it again. Eventually you could have an attack spread along 8-10 different "gates" in the target system, with the defenders split to cover each one.
3) Each temporary "gate" is actually an instance that could have its own node. When people warp to another battle gate, it transfers them to a new node. This would let massive numbers of ships be in a system, but still transfer between spots and not overload a system. No one would ever try to just fly to another warp spot, anyway.
4) Create a fleet-jump command for these gates.
Hopefully, this would allow for massive fleet engagements spread along a large "front" in the system. Ships can transfer in between as necessary. Now, the node will probably crash if everyone all warps in and transfers to the same battle site, but the initial engagement and getting into the system will be fought, and in sufficiently low numbers that tactics and ship/mix will have an effect, instead of just insta-popping primaries.
|

Neuromandis
EPSILON TEAM Ushra'Khan
|
Posted - 2007.02.26 00:55:00 -
[11]
How about preventing more than 1 fleet per side per system? Or something to that effect, anyway...
That could be circumvented by having non-fleet people, but that would first of all mean no gang bonuses. Apart from that it could go even further, and use some kind of mechanic to prevent non-fleet vessels from engaging fleets that are slugging it out. I don't exactly know how, and it sounds like a can of worms for exploits, but it MIGHT be an idea.
You could also have a complex way to define what a "side" constitutes. Maybe standings, maybe war declarations... I am not sure.
A starter would be preventing non-fleets from attacking a POS or outpost. Another would be that once you have a fleet inside a POS you would not approach it with lone ships - maybe put a cap on how many people it can protect inside its shields.
I am not sure what would work around gates, though...
|

Malachon Draco
eXceed Inc. INVICTUS.
|
Posted - 2007.02.26 08:38:00 -
[12]
I don't see how you can implement something like this without it becoming exploitable. What do you do if the defender masses 100 people in a system before a fight? How would an attacker be able to enter then? Does the system kick 60 defenders out?
Secondly, certain ships (particularly titans) take a lot of force to kill, how would you suggest attackers kill a defending titan if its only 60 attackers vs 40 defenders? Or even worse, how would defenders ever be able to kill a titan if they only get 40 vs 60 attackers?
How do you do a POS siege? 60 vs 40 with a POS helping the defender is hardly fair.
I understand your frustration, ASCN went through the same problems with crashing nodes and getting obliterated on login in TPAR, TCAG and GQ2. But I dont see a solution that artificially limits the number of hostiles in a system. -------------- In completely unrelated news, after careful research, the Guiding Hand Social Club concludes that no member of the Guiding Hand Social Club is guilty of corptheft. |

Reggie Stoneloader
eXceed Inc. INVICTUS.
|
Posted - 2007.02.26 09:06:00 -
[13]
Aye, we all lost ships to node crashes in GQ2, it was infuriating. You're right about the problem, but I can't get behind the solution you propose. Many of the above counter-arguments are valid.
It's a real pickle, and I'm sure the CCP code jockeys have lost plenty of sleep over it.
|

Iasius
FinFleet Lotka Volterra
|
Posted - 2007.02.26 12:30:00 -
[14]
Breaking up huge blobs is a top idea but to do that orientates around gates and camping them. As far as i understand it its not so much per system as loading a grid in space within a server node. Yes a huge fleet jumping into a system is very laggy but that is not due to going into a new system more loading a grid with 100+ people already in it. And even when the grid has loaded (I have waited 30 minutes once!) It can still be laggy.
This matching of loads on the system against very mobile fleet blobs means the server cluster has to be very dynamic in reallocating resources to ship traffic patterns. On a high level node server density - number of servers per node needs to be remapped every downtime against a profile of how many people over 3 days, weeks and months are putting a load on particular systems.
And very simply drop SQL server. I beleive its fat API cant give low latancies to the ram drive database store. Get Db2 on AIX 
|

Mister Spanky
Caldari GoonFleet GoonSwarm
|
Posted - 2007.02.26 13:02:00 -
[15]
Originally by: Iasius Breaking up huge blobs is a top idea but to do that orientates around gates and camping them. As far as i understand it its not so much per system as loading a grid in space within a server node. Yes a huge fleet jumping into a system is very laggy but that is not due to going into a new system more loading a grid with 100+ people already in it. And even when the grid has loaded (I have waited 30 minutes once!) It can still be laggy.
That's a good point. I can't see a solution to in-system lag but personally I'd prefer to lag in the system facing the enemy than sit staring at a blank screen for half an hour as I try to jump through a gate. There may not be anything you can do to save your ship but at least you can see something
Quote: This matching of loads on the system against very mobile fleet blobs means the server cluster has to be very dynamic in reallocating resources to ship traffic patterns. On a high level node server density - number of servers per node needs to be remapped every downtime against a profile of how many people over 3 days, weeks and months are putting a load on particular systems.
Yes, you're right about this too. The only solution is more effective behind the scenes management. I'm not criticizing CCP for not doing enough because anyone who thinks they don't want their game to run like a rocket is an idiot. The only thing I can think of that would help would be if CCP actively collaborated with Alliance Leaders to prepare particular nodes weeks in advance of any major conflict but you can just imagine the tin foil drama that would cause.
Quote: And very simply drop SQL server. I beleive its fat API cant give low latancies to the ram drive database store. Get Db2 on AIX 
I don't know anything about that sort of thing so you've got one up on me there. However, I can use a spell check better than you, especially when the words I've spelled incorrectly show up underlined in red in my post box so, meh we're even!
Joking aside, I still think my idea about moving battles away from the gates remains valid. I also think that battles should last much longer than they currently do. Lag might not be such a problem if your ship is harder to kill and there's a chance that it will still be there when the grid finally loads.
I know Kali buffed defenses considerably but I think it could still go a lot further than that. Perhaps not by introducing another HP buff though. Maybe it would be better if you could use multiple gang mods instead?
---------------------------------------------------
|

Malachon Draco
eXceed Inc. INVICTUS.
|
Posted - 2007.02.26 13:12:00 -
[16]
The first issue is really finding out what causes lag. I've heard so many theoriesand so much conjecture, and none of us seem to know for sure what exactly is causing the lag.
If its clientside graphics lag, then the option should exist clientside to disable all graphics beyond little crosses and such. I've heard rumors some people actually have engineered their own clientversions with such 'minimalist' graphics just to use in fleetbattles, but not sure if there is any validity to that rumor.
If its serverside lag, perhaps it would be possible to buy a few dedicated highend systems that can replace any single node/system. Instead of having just 80? nodes and varying the number of systems per node to help with loadbalance, introducing a small number (1-3) of even more highend nodes to use for the most epic of conflicts in a system might solve some serverlag?
But in principle, I don't see a solution here in the form of artificial limits of numbers of players on each side, or in a particular system. Either the system should be adapted to reduce the number of people that an alliance WANTS to bring, or the software/hardware is changed to accomodate the large numbers we see in conflicts these days.
-------------- In completely unrelated news, after careful research, the Guiding Hand Social Club concludes that no member of the Guiding Hand Social Club is guilty of corptheft. |

Iasius
FinFleet Lotka Volterra
|
Posted - 2007.02.26 13:39:00 -
[17]
Edited by: Iasius on 26/02/2007 13:45:26 Edited by: Iasius on 26/02/2007 13:45:06 ooh if i could engineer my eve client to show no textures at all but 3d boxes i would. But i suspect ccp would not like that haw haw. -edit- Nah im pretty sure its not my eve client. I have been shooting at stations with 150 other ships and the lag was really quite low with my eve client rendering all the ships fine.
I generaly think that its the intense io of tens of thousands of queries to the eve cluster nodes that create the lag. I know nothing of how good the software is, done in Phython. I guess there could be memory leaks as they have to do downtime every day.
|

Mister Spanky
Caldari GoonFleet GoonSwarm
|
Posted - 2007.02.26 16:22:00 -
[18]
Edited by: Mister Spanky on 26/02/2007 16:20:37 Everything causes lag in fleet battles. The dumb way the new fleet system re-calculates bonuses every time you jump through a gate is a major problem that could have been avoided for starters.
Edit: Also Iasius, I hope you didn't take my comments in my last post as a flame because I was just messing with you.  ---------------------------------------------------
|
| |
|
| Pages: [1] :: one page |
| First page | Previous page | Next page | Last page |