open All Channels
seplocked Features and Ideas Discussion
blankseplocked Real Space Initiative
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: first : previous : 1 2 3 [4] 5 6 7 8 9 ... : last (11)

Author Topic

ThaMa Gebir
Gallente
SUECHTLER Inc.
Saints Amongst Sinners
Posted - 2007.11.24 11:52:00 - [91]
 

Originally by: Adunh Slavy
Originally by: Phyra
Lovely idea!

Any Dev love it too yet?


Not to my knowledge. Someday maybe, this is more marathon than sprint. :)


Yeah, and I am knackered already...

Goumindong
SniggWaffe
Posted - 2007.11.25 23:49:00 - [92]
 

Edited by: Goumindong on 25/11/2007 23:49:34
Ive finnaly read through the entire O.P. and i havent seen any indication that PvP would ever occur and/or it would be impossible to avoid gankers.

You have one of two situations:

1. You can knock someone out of warp into a system: But how do you find them they are at a random disatance away from the star. They allign and prep for jump and with top notch skills you will have 30 seconds to warp to them and tackle them before they get out. Roughly

I.E. everyone needs highly skilled probes in order to have PvP and even then, not going to happen

2. It will be impossible to avoid getting ganked since people can pick and choose who they want to intercept as they come in and if its something they dont want to deal with that lands in their system they jump away. If its something they do, they kill it.

You need chokepoints to make eve work.

Adversarial games are based around control of strategic and/or tactical objectives. In chess, strategic objectives are the four center squares, in checkers its the edges. In Othello its the corners. In Go, its the center line. In Eve, the strategic goals are moons and stations[I.E. systems], and the tactical goals are stargates.

In order to have a fun adversarial game you must balance different actions around the tactical objectives which provide advantages. In the board games above this is done by forcing movement. Similar for eve.

In your system we either have no tactical objectives. There are no stargates to hold to gain advantage over an opponent. Or, we have tactical objectives that cannot be broken, since you cannot jump in on an opposing gang, you cannot force them to move, you both cannot force them to give up a tactical advantage and cannot avoid that advantage if they so choose to execute it.

This would result in a stale and boring game.

Also, there is no reason to go into the oort clouds in high-sec. People are in high-sec because its safe, if they didnt want to be safe they would go to low-sec.

Adunh Slavy
Ammatar Trade Syndicate
Posted - 2007.11.26 00:39:00 - [93]
 

Originally by: Goumindong

Ive finnaly read through the entire O.P. and i havent seen any indication that PvP would ever occur and/or it would be impossible to avoid gankers.

You have one of two situations:

1. You can knock someone out of warp into a system: But how do you find them they are at a random disatance away from the star. They allign and prep for jump and with top notch skills you will have 30 seconds to warp to them and tackle them before they get out. Roughly

I.E. everyone needs highly skilled probes in order to have PvP and even then, not going to happen

2. It will be impossible to avoid getting ganked since people can pick and choose who they want to intercept as they come in and if its something they dont want to deal with that lands in their system they jump away. If its something they do, they kill it.




Thanks for the comments, Goumindong.

I usually am very responsive to people that post in this thread. It is apparent that you have not read the entire idea and/or taken into account all the details. Had you, you would not have said these things, your "I.E." is a clear indication you have not as are other statements you've made. Also, there is an addendum consisting of posts 32 through 35 that supercedes parts of the first nine posts. Additionally, other ideas, waiting on yet another addendum, have been presented in the thread by my self and others. Understandably, it is a lot to read, so I can't hold that against you, however would suggest you catch up a bit.

Gedanken experiments can only go so far, it is as ever, open to balance.

Goumindong
SniggWaffe
Posted - 2007.11.26 01:54:00 - [94]
 

I have read the entire O.P. and addendum/amendments. There is no information in either which fixes the problems as i expressed it. If I missed something which does, which creates tactical objectives then please inform me.

But as it stands, its not in your idea.

Goumindong
SniggWaffe
Posted - 2007.11.26 02:15:00 - [95]
 

Edited by: Goumindong on 26/11/2007 02:17:20
Quote:

The directional scanner will change such that any ship or drone found within 2.0 AU of the local star, becomes a warpable object. This range can be increased to 5.0 with a new skill. The accuracy of the scans will drop a pilot 20 to 200 km away from the target, scan accuracy determined by existing skills, essentially giving each ship a built-in snoop probe for use only at the local star. The directional scanner will also have a time requirement added to it such that with no skills it would take 30 seconds to complete and at lvl 5 it would take five seconds to complete, the skill used for this time would be the current signal acquisition skill. (Having skills or a way to make the scanner go to zero seconds would be bad as some players will just sit there and smack the button all day long. That is not an issue with the current directional scanner since nothing it finds is warpable.)


Step 1: Jump to system/Pulled into system

Step 2: Select Celestial Object >5 AU from star. Warp at random Drop safe > 5 AU from star. [10 second warp for everyone, i hope your guys are fast]

Step 3: Warp to safe

Step 4: Initiate Jump

Or. [From the other option from the other perspective

Step 1: Make Save > 5 Au from star

Step 2: Get ready to pull people in. Allign towards star and open directional scanners, all gang leaders continue to scan every 5/10 seconds

Step 3: Pull People in

Step 4: Scan them. If you want to engage, warp to them and engage. If you dont, allign and leave.

-------------------------

Result: No tactical objectives.

I am not joking you pretty much have to land on the same grid as the attackers/defenders to make this work and if you are landing on the same grid then its gates[and if you use the 60 second allign thing in that situation its even worse because the only ships that could reasonably survive would be nano ships]

Adunh Slavy
Ammatar Trade Syndicate
Posted - 2007.11.26 03:11:00 - [96]
 

Originally by: Goumindong


<steps>

I am not joking you pretty much have to land on the same grid as the attackers/defenders to make this work and if you are landing on the same grid then its gates[and if you use the 60 second allign thing in that situation its even worse because the only ships that could reasonably survive would be nano ships]


Please make sure to read the addendum posts 32 through 35, also make sure to read these posts, 50, 51, 52, 54, 55, 56, 58, 59, 60, 64 and 70, they all speak to the same general concern you have. Also, can you think of any additional solutions to the problem as you see it or just prefer the status quo?

Goumindong
SniggWaffe
Posted - 2007.11.26 03:52:00 - [97]
 

Edited by: Goumindong on 26/11/2007 03:54:25
Originally by: Adunh Slavy
Originally by: Goumindong


<steps>

I am not joking you pretty much have to land on the same grid as the attackers/defenders to make this work and if you are landing on the same grid then its gates[and if you use the 60 second allign thing in that situation its even worse because the only ships that could reasonably survive would be nano ships]


Please make sure to read the addendum posts 32 through 35, also make sure to read these posts, 50, 51, 52, 54, 55, 56, 58, 59, 60, 64 and 70, they all speak to the same general concern you have. Also, can you think of any additional solutions to the problem as you see it or just prefer the status quo?



I read them, they dont address the problem.

As i see it, in any system where we grant that the ships are mobile within the systems within a reasonable time frame it will be impossible to near impossible to intercept a moving gang.

In any system where they are not so mobile, the setup force as supreme advantage.

Both of these systems are unacceptable.

Take a look at any of the board games above. In the simplest of ways Eve, on a micro and macro level is a lot like them. Assets are moved strategicially in order to achieve goals. Assets moved strategicially cannot occupy the same space [i.e. they must fight if they cross paths].

You are not thinking about eve as if it were a game, but as if it were a simulation. Instead of starting from the start point of "What do i want the system to achieve" you have started at "What can i achieve with my system". You are designing around around a system instead of desinging a system around the goal and because of this you dont achieve any of your so-called goals, but just serve to create a mess. I mean, why is blobbing any more or less prevelent in your system? With less information about when and where you can be pulled from warp as a gang jump joinging a gang and being as large as possible is even more important than it is now. It doesnt make eve any bigger, it just makes more places for people to not go.

Start simple.

What exactly do you want to achieve with an intersystem travel mechanic and why?

Adunh Slavy
Ammatar Trade Syndicate
Posted - 2007.11.26 05:32:00 - [98]
 

Goumindong,

It's good to see the obviousness of the title, "Real Space Initiative", has not been lost. The goal is basically to open up space, to make space more accessible to all players, while at the same time allow for non-consensual PVP. The basic premise and starting point is the removal of gates. All that follows is how to deal with that.

You are obviously hostile to the general idea and that is your right, just as it is mine to take measure of it. If you have recommendations, then make them. If you don't like the idea of removing gates because it doesn't satisfy your views on what Eve should be, then that's fine too. You prefer the status quo, I and others, do not. But to say "it's just going to be a big mess" is nothing more than an invitation to start a psising match; a game I will not play.

As for starting simple, it is not a simple issue, this thread endeavors to explore the alternatives. If you have ideas, feel free to share them, if you do not like the ideas, then we see that you do not like them and have appreciated your visit.

Goumindong
SniggWaffe
Posted - 2007.11.26 17:19:00 - [99]
 

Originally by: Adunh Slavy

It's good to see the obviousness of the title, "Real Space Initiative", has not been lost. The goal is basically to open up space, to make space more accessible to all players, while at the same time allow for non-consensual PVP. The basic premise and starting point is the removal of gates. All that follows is how to deal with that.



See, you started off with the "solution" and then tried to get there. Do not start with the solution, start with the problem.

As i see it you say

Problem: Its too easy to get killed when flying in space.

Such the goal is: Make it harder for people to be engaged in pvp.

Is this not the problem/goal? If its not, please tell me the exact problem and the exact goal.


ThaMa Gebir
Gallente
SUECHTLER Inc.
Saints Amongst Sinners
Posted - 2007.11.26 19:59:00 - [100]
 

Originally by: Goumindong
Originally by: Adunh Slavy

It's good to see the obviousness of the title, "Real Space Initiative", has not been lost. The goal is basically to open up space, to make space more accessible to all players, while at the same time allow for non-consensual PVP. The basic premise and starting point is the removal of gates. All that follows is how to deal with that.



See, you started off with the "solution" and then tried to get there. Do not start with the solution, start with the problem.

As i see it you say

Problem: Its too easy to get killed when flying in space.

Such the goal is: Make it harder for people to be engaged in pvp.

Is this not the problem/goal? If its not, please tell me the exact problem and the exact goal.




I think that is where the general problem lies with the status quo. It is a solution that I personally don't like. Gates. It makes with the current architecture a big problem with loading lag etc, not to mention that "we" feel that space could be opened up more in and of itself.

Granted we have not fully explored the situation it would create and we appreciate input, hence why we have opened this forum thread. We do not want to just have people in here saying "It wont work, that's it, live with it". Suggest something that you feel might in this architecture work to "force" PvP.

We have explored the idea for 0.0 with the scan improvements which are also explained in the referenced threads with basic examples, not hard numbers.

Please consider what we have mentioned here.

Goumindong
SniggWaffe
Posted - 2007.11.26 20:08:00 - [101]
 

Originally by: ThaMa Gebir
...


I dont think you get it. I am trying to run you through the design process from the right direction isntead of you running through from the wrong direction. This way, you can understand how to go about creating a system you will be happy with and that will work for eve.

I get it, you dont like gates. But i dont understand why you dont like gates, and what removing gates is supposed to accomplish. Instead of designing around the system of "no gates" design around the problem you see and goals that you wish to accomplish.

For instance, if you dont like grid load issues on jump in, that is why you have 60 second cloaks, just extend them to 2 minutes and/or make an alloted time as you wait that you dont appear on grid/cant act.

So am i right that that is the problem you are trying to fix and the goal you are trying to accomplish? If not, then what is the problem you are trying to fix and the goal you are trying to accomplish.

ThaMa Gebir
Gallente
SUECHTLER Inc.
Saints Amongst Sinners
Posted - 2007.11.26 20:24:00 - [102]
 

Edited by: ThaMa Gebir on 26/11/2007 20:24:40
Yes, that is right to a certain extent what you say there. I cannot and would not dispute that. However the entire idea behind not wanting gates is to alleviate not only that problem but also to "open up space" as one sees in films like starwars etc.

This is only a hypothetical thread, it is not to be a dictation of what will happen in the future, rather a what "I" want to see.

The reason we have begun with the solution is because we are not (least I am not) familiar with computing etc. It is just what I want to see, the solution, and we are discussing what we could do "if this, if that, when etc" to keep the game as close to original mechanics as possible but with the features we have mentioned here.

Kind Regards ThaMa.

Deep Throat
Amarr
AJAX.
Posted - 2007.11.28 12:01:00 - [103]
 

"See, you started off with the "solution" and then tried to get there. Do not start with the solution, start with the problem."

OK. Lets start with the problem.
-The problem is what Goumindong said that this system under discussion would eventually lead to; A STALE AND BORING GAME.

Somehow I think Goumin does not think that the current game system is exactly that, and hence all his opinions seem to be hostile and biased to any changes to the current system.

Therefore, lets examine weather or not the current system is in fact, very good or stale and boring.

-The current landscape of the game is that of large roaming 30 man plus gangs, that with the aid of the tech2 ships have but one goal and that is to gank and run, on very few occassions do these gangs fight since most of their ships are set up for speed and electronic warfare.
-in addition to this we have the fleet fights which tend to become a blobfest were both sides call in endless backups until the system is at 400 to 800 in local and everyone plays at 3fps and either doesn’t see any enemy at all or waits 30 minutes to lock 1 target and another 30 minutes to fire a single shot on that.
-lastly we have the camping of chokepoints which is the dumbest gameplay ever, where a large number of player gather around and sit on 1 gate for days and weeks, never moving, never doing anything but killing the soft targets and running from any organised resistance.

A quick summary; STALE,BORING,UNIMAGINATIVE, UNTACTICAL grinding game of either tech2 recon-dictor blockade grief,lagged out wanna-be-fleetbattles or totally dumbstalelazy camping of 1 gate blocking whole areas or regions all together.

So, if u can agree to this in principal, that the game is at its lowest atm and changes are desperately needed to bring the game back to what it once was, a kickass combat game and move it away from being a game of farmers, pos-engineers and dumb-campers…that it currently is.. what can be done?

In my opinion the solution to the problem lies with a few factors;

Nr.1: removal of local channel
-this feature alone is responsible for most of this game´s shortcomings, it’s a lazy and dumb defence tool and a instant intelligence that requires no action or discipline or wit to aquire. It automatically removes any stealth or manuver or tactics and enables even the dumbest players to avoid any danger

Nr.2: the basic physical landscape needs to change[routes and gates]
-which is the fundamental core of the idea in this thread.

The Change to this is fundamental and would require but one principal framework… to offer multiple options to player X entering area A, yet maintain the limited principals of the current system… in short offer multiple option without the options being indefinite.

You could do this in 2 ways, one would be to simply add more gates to each system and therefore expanding the optional routes by 3,4,5 to the currently only 1 route avaialbe to player X entering area A.

Or u could change it entirly, which is being proposed here. As far as I can see the idea being proposed here, follows exactly this principal I mention.. it offers mutliple options yet they are limted. And to catch travellers and or engage an incomign gang is still doable and fast, yet it requires a little bit more skill than just sit at a gate.

As I understand it, players will spawn close to sun after jump-warping, and they will spawn in random locations(perhaps this could be limited to 5 to 10 locations… and players wanting to catch incoming traffic can either use tools or the scanner to find them quickly and engage.

Sounds solid to me, although takes a little bit to read through the whole idea as its expressed here.



Ma Zhiqiang
Minmatar
Huang Yinglong
Posted - 2007.11.28 15:20:00 - [104]
 

I'd love to see this happen.

Adunh Slavy
Ammatar Trade Syndicate
Posted - 2007.11.29 00:03:00 - [105]
 

Edited by: Adunh Slavy on 29/11/2007 00:04:06
Hi all,

I am starting to do the next revision, summary, what have you. I can present it one of two ways, as either lots of posts in this thread, like the first nine posts, or as perhaps a Word document and save it up on Eve files.

Which would you prefer?


Goumindong
SniggWaffe
Posted - 2007.11.29 01:44:00 - [106]
 

Originally by: ThaMa Gebir
Edited by: ThaMa Gebir on 26/11/2007 20:24:40
Yes, that is right to a certain extent what you say there. I cannot and would not dispute that. However the entire idea behind not wanting gates is to alleviate not only that problem but also to "open up space" as one sees in films like starwars etc.

This is only a hypothetical thread, it is not to be a dictation of what will happen in the future, rather a what "I" want to see.

The reason we have begun with the solution is because we are not (least I am not) familiar with computing etc. It is just what I want to see, the solution, and we are discussing what we could do "if this, if that, when etc" to keep the game as close to original mechanics as possible but with the features we have mentioned here.

Kind Regards ThaMa.


The problem is that you cannot both maintain an "open space" enviornment in a game and still have a multiplayer PvP game unless all combat takes place over strategic resources. You have to have some sort of nodal choke in the system to make movement strategic. This would be O.K. except that all PvP would be either a camp at a strategic resource, or a huge fleet battle at a strategic resource.

Huge fleet battles can be fun, but i have a feeling that the resulting system would not be ideal for the myriad of play styles that CCP needs and wants to support.

If fleet lag/grid load lag were not an issue, it would be interesting to let ships jump to a system from any adjacent system or anywhere in an adjacent. But they all have to land land at a single choke, or varying choke for each intersection. This may also presents problems, though possibly not with the increase in possible routes.

You dont have to be familiar with computing to start from the problem in the design phase, but you do have to think of the system as a game and not as a movie.

Adunh Slavy
Ammatar Trade Syndicate
Posted - 2007.11.29 05:20:00 - [107]
 

Originally by: Goumindong

The problem is that you cannot both maintain an "open space" environment in a game and still have a multiplayer PvP game unless all combat takes place over strategic resources. You have to have some sort of nodal choke in the system to make movement strategic. This would be O.K. except that all PvP would be either a camp at a strategic resource, or a huge fleet battle at a strategic resource.

Huge fleet battles can be fun, but i have a feeling that the resulting system would not be ideal for the myriad of play styles that CCP needs and wants to support.



I am glad to see you use the words " i have a feeling" and we can now put this into proper context. It is your opinion this would not work. We get it. As for the myriad of play styles, a lot of us see things devolving to one play style and it is getting old and worn. We think Eve and CCP can do better. If they listen to us or not, is not as important as knowing that we tried.

We're enjoying the imagination, the collective thought process, the sharing of ideas and playing with the what ifs. The preface states this clearly in the first paragraph, we know the chances are slim, but we're going to play with the idea anyway. Maybe CCP will do something one day when there are 100,000 people connected at one time with 3,000 people in Jita, have fun at those gates, lag or not. Who knows what will happen, I'd wager CCP doesn't know what would happen either, except that they could have more barley pop, mmm barley pop. Anyway …

We are not looking to be "run through the design process" as you say. We are brainstorming, looking at what the possible issues would be if there were no gates and what we can do game wise about that. You think it won't work, fair enough, we think it can work given the proper combination of mechanics and balance. Instead of saying "Gates suck, get rid of them" we're actually trying to figure it out, as opposed to making generalizations that this will not work.

You've said this, "unless all combat takes place over strategic resources" … gates are a strategic resource too. We're looking to remove gates, plain and simple, no magic ulterior motives, no wanting to make it easy or hard on any one. Do not assume we have some evil plans up our sleeves, although once someone did ask me, what to do with all the old gates … leave them there, make a new mining laser and let people go nuts mining scrap metal chunks - ok, so an evil plan for miners, you caught me in collusion with miners, damn, got me.

The style I am using to drive this public thought experiment may not be to your liking, perhaps its authoritative tone rubs you the wrong way, if that is so then don't let it get to you. Gedanken experiments are simpler to run in present tense with an indicative or imperative mood. That's all that's going on there.

Quote:
You dont have to be familiar with computing to start from the problem in the design phase, but you do have to think of the system as a game and not as a movie.


As for familiarity with computing and design, I do that for a living and I get your point, we continue to hope you get ours. You have to see where we are before you can suggest where we should go. Keep in mind, we are not dealing with a new system here, we're having to envision with legacy elements, because if we ever want a snowball's chance, then we have to make the idea as compatible with the existing system as possible. Does that gimp us, throw a wrench in the process, sure it does, but that's always to be expected with legacy systems. One must envision with legacy in mind, and envisioning is where we are. You're welcome to help, but to continue telling us it won't work is more futile than us continuing with the idea, after all, we are crusaders and gates are evil.

Phyra
Caldari
NEXT Incorporated
Posted - 2007.11.29 11:59:00 - [108]
 

Errrrm guys?

Could you please realize that Guomindong is actually trying to be helpful?

I have yet to see anything in his posts that is plain hostile to the idea.

There are a multitude of playstyles, yes, and his concern is that quite a few of these would be adversely affected by the system you have developped so far. And that is just a valid criticism, isn't it?

The discussion could develop in these directions a) we are aware about the changes, we like them and PVP needs to change that way or b) what can we add/change so that PVP can stay almost the same as it is or c) what role do we want to give to PVP anyway? (and then on to a) or b)) -- and maybe there is a d) and e) that I didnt think of.

Anyway I like the idea and I hope the thread move back on the constructive track. :)

Phyra


Adunh Slavy
Ammatar Trade Syndicate
Posted - 2007.11.29 17:28:00 - [109]
 

Originally by: Phyra

Anyway I like the idea and I hope the thread move back on the constructive track. :)



Hi Phyra,

I'd have to agree you're generally correct, and your suggestion here is a good idea. :)

Goumindong
SniggWaffe
Posted - 2007.11.30 00:34:00 - [110]
 

Edited by: Goumindong on 30/11/2007 00:37:04
Originally by: Adunh Slavy


I am glad to see you use the words " i have a feeling" and we can now put this into proper contex
Killboardst. It is your opinion this would not work. We get it.



You misunderstand. Its my opinion that a system that promotes large fleet battles over strategic resources and only large fleet battles over strategic resources would not properly cater to the large number of play styles that Eve harbors.

A system with no control points and no way to get forces into a battlefield[and force them into battle] will result in a system where the only combats happen where strategic assets are controlled. Battles will be fewer, because the reduction in places where combat can be had increase the ability to gather information. Losing fights will be fought less, the one who would have lost would simply retreat.

Take a look at the ocean as a good example. Speeds are limited, space is contiguous. The ocean feels open, but you cannot skip places on it, and you cannot co-exist in the same space as another ship. If i want to stop you from getting to a specific location, i set myself up between you and that location.

Eve has no such limitations because its space is not contigous with a warping mechanic. And this fact intimatly changes how combat works. You cant cut someone off in eve without choke points. You do not have to fly past mars to get to Jupiter from earth. You just land on Juputer.

On a base level, all fighting, whether its hand to hand, ship to ship, gang to gang, or fleet to fleet, occurs on a contiguous plane. You can cut someone off by standing in front of them, or moving your fleet in front of theirs. The only thing that changes is how much space is involved[in various factors. But eve does not have this due to both game limitations and hardware limitations.

This is why you have to have chokes of some sort, because without these chokes, the only combat will be at strategic resources. Because being at the objective would be the only manner in which to interject yourself between your self, and your opponent.

Does eve support that? It does with POS's. But it doesnt with anything else, since with any other activity you can[and should] just run.

Quote:
You've said this, "unless all combat takes place over strategic resources" … gates are a strategic resource too.


No, gates are a tactical resource. Systems are held temporarily in order to secure an objective, they are not objectives themselves since you cannot effectivly "garrison" them or block incoming ships.

Quote:
You have to see where we are before you can suggest where we should go.


Then why wont you look at where we are?

I want to help, becauase i like the game, and enjoy playing the game, and enjoy designing games. I want the game to be the best it can, and it wont be the best it can by not putting design ideas through their paces.

If you want to design a new mechanic to replace the current mechanic you have to design the new mechanic the way you would design any other part of the system. This is why I am saying start from the problems and goals instead of the solution.

Adunh Slavy
Ammatar Trade Syndicate
Posted - 2007.11.30 07:11:00 - [111]
 

Originally by: Goumindong
[
I want to help, becauase i like the game, and enjoy playing the game, and enjoy designing games. I want the game to be the best it can, and it wont be the best it can by not putting design ideas through their paces.



Then get specific and stop with the generalizations, they don't help and only distract. Get into the spirit of the idea as we have presented it. If you do not wish to do so, then please feel free to start another thread and present your own ideas. I will spend no more time debating if the sky is green or red with two color blind monkeys, me being one of the banana peelers, you being the other.

I'm sure others that read this thread would also like to see this end, so I am ending it. I am done with this distraction. Smile

Goumindong
SniggWaffe
Posted - 2007.11.30 17:16:00 - [112]
 

I have been very specific, both with the problems in your design and with the method through which you have to design.

This is why i asked the questions regarding what the goal was and what the problem was.

ThaMa Gebir
Gallente
SUECHTLER Inc.
Saints Amongst Sinners
Posted - 2007.12.01 09:22:00 - [113]
 

Originally by: Goumindong
I have been very specific, both with the problems in your design and with the method through which you have to design.

This is why i asked the questions regarding what the goal was and what the problem was.


Ok then.

Allow me to put this thread and a certain mechanic into a different context.

Problem; Gates, chokepoints, lag. How to stop the chokepoint lag at the gates.

Solution; Remove gates.

Problem; How do we force pvp.

Solution; We introduce an extension to the existing mechanics to make it easier to scan people out and hold/bottleneck them into a certain area of the system they arrive in. We have used numbers plucked out of the air admittedly, but it is basically an example of our thoughts.


Problem; I want space to "feel" more open.

Solution; I think like Star wars, I want to fly between star systems using my own power rather than relying on gates that are frankly too old, I mean some of them are over 100 years old ffs. They gotta be suffering from old age sooner or later, and you never know, they may hurl you out into the great unknown when they fail at their job...Wink

Solution;

ThaMa Gebir
Gallente
SUECHTLER Inc.
Saints Amongst Sinners
Posted - 2007.12.01 09:40:00 - [114]
 

Edited by: ThaMa Gebir on 01/12/2007 09:44:01
To add to my previous post here.

The targets around Eve are actually pos's, stations, moons etc. Correct?

The Gates are just a means to an end, as you yourself said Goumin, they are a temporary objective to achieve the main objective.

I would like to look into this further.

The current mechanics are skewed atm towards the gate holders, correct?

You have the campers (such a harsh word, yet so descriptive) with bubbles, 'dictors, sniping battleships etc.

Now if you want to hold the system you have to only hold the gates. Which entails hours of camping with the possibility of the enemy not actually running like lemmings into your camp. Thus boring, IMO.

Ok, so we shake things up a bit. We make the main objective (said station, pos etc) the main objective, with no secondary objective or such. Creating tactics. The defending fleets have to defend station, pos' etc to make sure that they keep sovereignty.

This makes the points of interest the warpable objects in the system the focus, not the gates.

If the defending fleets cannot defend said station or pos, then frankly they do not deserve to hold that system.

How to make it easier for the defending fleets to defend the area and find out exactly is around and where?

We introduce to the existing mechanics an extension, in this case the scanner towers (I would imagine equivalent to the lookout towers one sees in missions) which are massive sensor towers which are to be anchored at pos's the home team has dotted around the system.

It allows all ships of the alliance to scan better and faster, it disrupts the Hyperspace that invaders ships use to arrive in the system, and drops them closer to the star. Combined with the scanning increase of the home alliances ships it allows the home team to find them quicker. (example; invader drops within 250k km of the star, he starts to calculate the time until next jump, or before he can warp off or whatever, say 60 secs, like the cloak).

The home team can scan in this time and practically warp in on top of said chap. Possibly.

It all depends on skills and resolution of scan towers and how many they have in system.

Is that at all understandable?

I hope you see where we are going with this...

EDIT; If said person is actually going to move on to another system then the defenders have a hard time of catching him, admittedly, but it could be part of a ploy to draw out forces and then have another group coming in behind them, or that they are testing the reaction time of said home team, or any number of things...

Goumindong
SniggWaffe
Posted - 2007.12.01 21:23:00 - [115]
 

If the points of interests are POS and Stations then no PvP but massive fleet pvp will occur.

This is unacceptable.

Adunh Slavy
Ammatar Trade Syndicate
Posted - 2007.12.02 03:46:00 - [116]
 

Preface - Version Five

It's time for a new addendum, call it a summary, call it version five of the idea, since it is. I post it in this thread since it is now the ideas home. Post one of this thread will be updated to point to this post and its associates, making up this latest revision.

Being the editor gives me some liberties to pick and choose ideas. Also being editor I am forced to pick and choose ideas because to go though all the possible combinations of all the ideas in this thread, would take considerable time. That said, what follows is the core idea originally posted with its addendum and the ideas that came after the addendum, in some cases incompatible ideas are dropped, (some of mine and some of yours perhaps,) or not mentioned simply for brevity and/or to maintain the overall vision. Once again, I will not say to whom an idea belongs or reference other threads or even other posts in this thread directly.

Some parts (Oort cloud, local, alliance defense addendum) are pretty much the same as they have been, but have been partly rewritten. The Oort Cloud add-on has been renamed to "Outer Orbital Ring Territories (OORT)" so as not to use the term "Oort Cloud" improperly, although slyly remains misused. The name for the concept's version of local chat has been changed to "Open Space Chat Relay (OSCR)".

I've split the idea into separate sections a bit differently from last time, starting from the general to the more specific followed by Modifiers and Balance Limiters. In the initial posts of this thread, I attempted to give the entire idea in one shot and mention all the little details along the way, that worked pretty well, but was difficult to "index". At this stage in the experiment, I think we can look at the idea in a slightly different way since the main pieces are now conceptualized by most. The editorial layout of this new revision may be difficult for someone who is brand new to the idea, which is why the starting posts in this thread will not be changed and/or start a new thread - so that others can examine the progression of our collective thinking. Future discussion, from me anyway, will reference this new version as being more authoritative than the previous versions.

One a last preface note, this newer version contains all the add-on features, OORT, changes to local, etc. There are two reasons for this, first and foremost, it's just more fun. Secondly, we know CCP has some changes in store for the backend, Fan Fest slides indicated some alteration in architecture though no specifics were given. We'll still maintain our test, to not require core architectural changes to the backend, but we know something is going to change. In the idea revision that follows, the only thing that will fail this test is the change in local's behavior. Chat may be decoupled from system granularity as it exists today, eluded to by the fan fest slide regarding new cluster plans, so let's take advantage of it.

Preface over, off we go …

Adunh Slavy
Ammatar Trade Syndicate
Posted - 2007.12.02 03:46:00 - [117]
 

The Map and Basic Navigation

Beacons and Navigational Computer

Navigation will be controlled by Navigational Beacons (NavBeek) in each system. These beacons do not need to be actual objects in space, though having them floating about would be more realistic. Each NavBeek maintains a communications link with adjacent NavBeeks using the current map topology. Auto-Pilot route planning will behave exactly the same as it does today.

When a player wishes to travel to another system, they would initiate a Navigational Computer (NavComp), which is a built in module on every ship. The NavComp will take some time to calculate the jump, once the calculation is complete, the player may then initiate the jump and travel to the desired adjacent system. When the player jumps, the ship will align to the adjacent system's icon in space, and when up to speed (75% of max velocity) the ship will start the jump, behaving in general the same as current warps.

Auto-Pilot

The Auto-Pilot will behave much as it does today. The player may use it to only plan a route or may also use it to control the ship. In the case of the later, as the former needs no explanation, the player would turn on the AP and the AP would start the NavComp, when the NavComp is complete, the ship would align and then jump. It would repeat this process over and over again until the ship arrives at its final destination. Pretty straight forward, done. The key here is the order of operations, NavComp, then Align, then Jump, maintaining the weakness of AFK flight versus manned flight wherein alignment to something warpable would be given priority by the wise.

The In-Space GUI

Basic GUI navigation will be the same as it is today. To travel to another system a player would interact with either a "solar system icon" in space, or a "solar system icon" on the overview. When the player clicks the icon, the selected item window will show all the same buttons with the exception of "warp to". The warp to button will be changed to "Calculate Jump". Clicking this will start the NavComp but not align the ship. When the NavComp has completed, the current "jump" button will be enabled, clicking this button will start the alignment as described previously and then when the ship is up to speed, jump.

One change of note from current, gates are, astronomically speaking, very close to our ships, so gates appear to "move around" us as we travel though systems. With this, adjacent system icons will "move with" us instead. Those who recall the bug with the undocked view of the un-flattened star map (partly fixed by the way) will realize that this can be done more or less on the fly.


Adunh Slavy
Ammatar Trade Syndicate
Posted - 2007.12.02 03:47:00 - [118]
 

Jumps Dissected and the IVVS

When the player clicks the NavComp button a few things will happen. First, the random position near the destination star will be determined and applied to the player's data set to be saved to the data store. Also a random Velocity Modifier will be added to the player's data set, this number will be an integer between negative three and zero. This can be done server side, no need for the client to know these numbers prior to session change. When the NavComp is completed, a time stamp will also be added to the player's data and the server will signal the client that it can now jump, lighting up the jump icon. These new values will constitute a data structure known as the "Inbound Vector and Velocity Set (IVVS)". This data structure is attached to the player's server side data set and is saved to the back end upon session changes. This is done for the purposes of gang jump cohesion, described later.

The client will start to jump and the client will at first see what looks like current warps. During this time client will get an acknowledgement of the session change from the backend. At that acknowledgement, the client will begin to morph the current system's background with the destination system's background, fancy space bending and other frills perhaps the warp tunnel slowly rotating, etc can be done. This jump phase graphic will not be very long in most cases, three or four seconds, but will extend in cases of a delayed session change, something we all get from time to time, thus creating a latency tolerant seamlessness.

Adunh Slavy
Ammatar Trade Syndicate
Posted - 2007.12.02 03:48:00 - [119]
 

Jumps Dissected and the IVVS Cont.

The IVVS will be completed at this time by the server process hosting the destination system, while the client is in "jump". Vector will be determined by the random numbers saved to the IVVS prior to the jump, and the use of current jump gate coordinates in the destination system. Vector will be extended out to 600 AU from the destination point. The reason for this long vector is to create a link into OORT, described later. Also, since the Pythagoras Theorem (I'm not a math guy, but think that's the one,) is going to have to be invoked at least once for velocity or vector, we can choose vector instead of velocity and get more out of it. The advised choice, in calculating vector, is that the origin point be done as a batch process across all systems at once, during a server side patch deployment, and one need never bother with it again. Doing so would cut down on server side processing in all jumps and in all jumps dealing with alliance defense, described later.

Since we know the distance is a constant, 600 AU, velocity is easy. We simply divide 600AU by 60, and that determines how fast any ship is moving when it enters the system 10 AU/s. The reason for "60" is because this is the number of seconds used for the current gate-cloak timer. Instead of players having a gate-cloak immunity, they will have a warp immunity until they "land". So, our constant for jump-warp velocity is 10 AU/s. For purposes of balance, we modify the velocity value by the Velocity Modifier saved to the IVVS prior to the jump. Now the inbound ship will have a random amount of warp time, something between 60 and 80 seconds, this randomness is not under the player's control, nor is it under the control of any player that may wish to scan down the inbound player. The reasons for this will become apparent in the Directional Scanner section and the OSCR section.

When the session change is complete, the client will receive the signal from the server and the server will update the client with the IVVS data so that the client knows how to position the ship in space, the client will also slowly phase out the morphing effects, load the new system "space map", update the overview with warpables and show the normal warping graphic, moving the ship along the proper vector. Using the IVVS data set, both client and server can move the ship to the appropriate destination and at the appropriate velocity.

Adunh Slavy
Ammatar Trade Syndicate
Posted - 2007.12.02 03:49:00 - [120]
 

Gang and Fleet Jumps

As described in the Jump dissection, the IVVS is partly populated to the player's data set prior to jumping. We want to do this so that a gang boss, fleet commander, wing commander or squad commander (FC) can "gang-jump" his command. When jumping a gang, only the FC needs to invoke the NavComp. When the FC's NavComp has completed all players in the FC's command will get their IVVS data from the FC's IVVS. He may then "gang-jump" all those in the FC's grid, just as gang-warp behaves today. At that time, all ships will align and make their jumps.

Players, if they wish to arrive at nearly the same time, will need to, be in the same grid, all align their ships getting them up to speed prior to the FC giving the gang-jump command. Likewise, when the FC's NavComp completes, all players in that command will also have their "jump" button enabled and may jump them selves. Since all players in the command will share the same IVVS data, a fleet may choose a more staggered approach, sending scouts and the like first.

There is always going to be some inherent disassociation with regards to gang-jumps. Some clients update faster than others, session change durations are not predictable, players get disconnected, any number of variables and unforeseeable problems can occur. Given a perfect environment, anyone that jumped at the same time will arrive at the same time, but this is just not going to always be possible. This however is no worse than what we have at gates today, even an FC saying "jump on 3. 1, 2, 3!" does not result in everyone changing session at the same time. So even though we must admit it is not perfect, it's good enough.

Once each client has received the session change request acknowledgement from the server, they will enter into the jump and be treated as individuals until they land, they will however all land at the same place and at the same velocity having used the IVVS from the FC. Time will be the variable as described in the preceding paragraph. The Alliance Defense section may change this behavior, see that section for more information on that.

(I played with some time stamp ideas on the IVVS, to bring gangs back into a warping group sharing a warp tunnel, but as yet have not come up with a scheme I like that also marries nicely with alliance defense. Maybe this can be addressed by others in this thread, consider it an open question, not that all of this isn't an open question mind you.)



Pages: first : previous : 1 2 3 [4] 5 6 7 8 9 ... : last (11)

This thread is older than 90 days and has been locked due to inactivity.


 


The new forums are live

Please adjust your bookmarks to https://forums.eveonline.com

These forums are archived and read-only