Slashdot Log In
CCP To Discontinue EVE Online Support For Linux
Posted by
timothy
on Sun Feb 08, 2009 03:21 PM
from the adam-also-discontinued-support dept.
from the adam-also-discontinued-support dept.
maotx writes "CCP's recent support for EVE Online in Linux is now set to be discontinued this March. Released last November along with the Mac OS X client, it has failed to share the expected continual growth as seen with Mac client. Feedback on the EVE Online forums, which includes the e-mail in which CCP announced this decision, suggest that the client was not preferred for Linux users as it did not support the Premium graphics client and did not run as well as the win32 client under Wine. For those who wish to stop playing EVE Online, CCP is offering a refund towards unused game time. Select quote from the e-mail: 'The feedback and commitment we obtained from players like you helped both CCP and Transgaming with our attempts to improve on the quality and stability of the client. Many of us in CCP use Linux and are convinced of its merits as an operating system.'"
Related Stories
[+]
Games: EVE Online's Linux/Mac Client Goes Live Tuesday 205 comments
The official EVE Online site has details of upcoming patch 'Revelations 2.3'. Along with a number of bug-fixes to the PvP-focused Massively Multiplayer Online Game, this game fix will offer up compatibility with Mac OS X and Linux. Though the Mac client is a native port, Linux will require the used of Cedega. The post suggests that if you'd like a preview of what the game will be like on your rig, you can download the client and tool around the test server. System requirements are also listed, as are the distributions of Linux they are specifically supporting: Ubuntu 7+, Suse 10+, and Linspire 6. Update: 11/04 14:32 GMT by Z : Fixed implication of native Linux client.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Makes you wonder... (Score:5, Interesting)
Re:Makes you wonder... (Score:5, Insightful)
makes you wonder how they failed to realease an official client that performs better than under WINE.
Parent
Re:Makes you wonder... (Score:5, Funny)
Parent
Re:Makes you wonder... (Score:5, Funny)
The usual way is implying that Microsoft paid them off to kill the Linux client. Considering the state of the Icelandic economy and the number of people actually using that client, I think that probably amounted to mailing them a really nice fruit basket.
Parent
Re: (Score:3, Funny)
Re: (Score:3, Informative)
CCP is a Microsoft house. Sure, individuals use other things within, but they're Microsoft from their high performance computing partners right down to the OS their EVE servers run and the Microsoft SQL servers they run.
That's all fine and so is claiming that it they can't justify spending money on the Linux client. At least they gave it a try. However, they also admit that they can only tell if an actual official client is connecting. If you run through something like WINE (or Cider on OSX), they don't bot
Re: (Score:3, Informative)
Just to clarify the difference in running clients here and WHY we run Windows clients in VMs instead of the official OS-specific clients, let me give an example of my experience:
My main system is a dual quad-core Mac Pro with 16gb of RAM and a GF 8800.
Running the official OSX client gives me around 15 to 25 fps, depending on where I am (in/out of station).
Running the Windows client on Windows XP SP3 inside of a Parallels guest on OSX gives me 45 to 65fps.
That's right. I get easily double and possibly triple
I don't wonder. (Score:3, Informative)
CCP is claiming that they can't count the number of wine users because wine reports 'as windows' and not as 'wine on Linux.' Bullet meet foot.
FTA,
What do you expect?
file "~/.cedega/EVE Online/c_drive/Program Files/CCP/EVE/eve.exe"
eve.exe: MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit
Throw away for a moment the fact that Direct X translation to OpenGl is super slow compared with native OpenGL.
Wine >> winex.
Cedega = winex + no devel
Re:I don't wonder. (Score:5, Interesting)
They use D3D because OpenGL is not particularly good to program with. OpenGL 3.0 is not the much-heralded "fix" to the crap specification that it was supposed to be.
I work better in OpenGL than D3D, but that's my own familiarity with the API rather than the quality. OpenGL has huge gaping problems. A few basic issues...
-everything's a fucking GLuint, so you have to wrap and cast everything to make it halfway tolerable (at which point it looks so close to D3D that, for the important platforms, you might as well have already done it in D3D)
-GLSL sucks, with weird and arbitrary rules
-GLSL shaders can't be compiled (there are ways to do this but they are best described as "skiffy" and less charitably described as "broken")
-no way to query for GLSL functionality (for example, the noise() function always returns 0 on most cards because almost nobody actually implements it)
-no coherent SDK-type documentation; crap organization of what documentation exists
-VBO trashes pointer setup. WHY?
-developing GLSL on nVidia cards is crap, because it's translated into Cg and doesn't correctly report errors on bad code
-developing anything generally is crap, because there's no analogue to the D3D caps structures that tell you what work on a given machine.
-using binding to do everything means you can't make what should be really, really simple assertions about the state of your render pipeline between two draw calls (this is just plain fucking unacceptable!)
Microsoft may be rah-evil or whatever your nearest GNU zealot wants you to believe, but D3D is a vastly superior API. It's pretty hard to fault developers if they choose to use the better API for targeting their primary platform, if they decide that being cross-platform isn't of interest to them.
You want more developers, have an API that doesn't suck. It is perhaps a very sad statement that WINE's implementation of D3D is a better gaming API than anything native that's currently available on Linux (yes, it uses OpenGL under the hood, that's fine--OpenGL is a decent binding to the hardware but absolute shit for actually developing stuff).
Parent
Re:Makes you wonder... (Score:5, Informative)
Wine isn't an emulator. Seriously, wine is a native implementation of the win32 api. Saying that wine is an emulator is like saying mono is a .net emulator, or that glut is an OpenGL emulator. An API isn't code, its a specification. Win32 is a specification not code, Wine is just an implementation of that specification on Linux.
Parent
Re:Makes you wonder... (Score:5, Informative)
... or that glut is an OpenGL emulator.
Given your other examples, you probably meant mesa in place of glut.
Parent
Re: (Score:3, Interesting)
A brief look at the Transgaming forums show that actual development of Cedega has stopped. Wine is the better choice these days.
Re:Makes you wonder... (Score:4, Interesting)
Because their official client was actually the Windows client running under Cedega from Transgaming which is built off of wine.
As a linux user who does play games I can tell you the reason I don't play EVE Online is because they announced a linux client and before buying the game I read up on it and discovered they actually didn't release a linux client and instead were working with Transgaming to get the Windows client working on linux. Its called bait and switch, no thanks, I purchased ID Software's Quake Wars instead as it actually does have a native linux client. Its no where near the same genre and it would have been interesting to play EVE Online, but oh well.
Parent
Who would of thought that.. (Score:2, Insightful)
Sub par graphics and an inability to compete with its wine counterpart would contribute to its own death.
Bummer for them... (Score:3, Interesting)
I was about to ditch WoW + Crossover for EVE because of their support (and talking my WoW friends into doing the same). Now I don't know...
Re:Bummer for them... (Score:5, Informative)
CCP doesn't support Linux, but wine has done a good job of making sure it runs well. I've been playing for a little over 2 years and have never had any problems with wine.
Parent
Is it really so hard to support Linux natively? (Score:3, Interesting)
CCP is yet another Windows shop that would rather throw a lot of money at a crummy DirectX wrapper than look over the fence and embrace native Linux development.
Re:Is it really so hard to support Linux natively? (Score:5, Insightful)
To your title: Yes.
Its easily a support nightmare.
OTOH, i am very sure that CCP looked at their stats, counted the number of linux cusomers and made some quick calculations that showed they will never make the money they would need to spend.
Parent
Re: (Score:3, Insightful)
They use DirectX, so pretty hard.
Re:Surprisingly hard (Score:5, Insightful)
Yes, but by standardizing API's and kernel goo it would make it easy for so-called proprietary vendors like CCP to support Linux. According to som in the Linux community it is fact better to provide random API's that change all the time--that way proprietary vendors get scared off.
The fact that Linux is so hard for vendors like CCP is seen by some in the Linux community as a feature, not a bug. Hopefully, those very same people in the community are cheering CCP pulling out of native Linux support, as it clearly shows their plan is working as intended.
Parent
But they have a flawed argument.. (Score:3, Informative)
For the same reason it is a pain for commercial apps, it is a pain for OSS too. A disproportionate amount of effort in various projects is invested in spinning on API updates...
Most things have calmed down, but audio frameworks for some reason stay in a state of significant flux. Today's 'correct' API is pulseaudio, which will abstract the underlying mess, but who knows what tomorrow brings. I'm still haven't followed esd and arts lately to see if they have relevance. dmix and the like I bunch up in als
Re:Surprisingly hard (Score:5, Interesting)
Ohh my God, another "Linux architecture is hard, therefore vendors have problems" apologist.
Listen, CCP was never hiding behind a fact that so called "Linux client" is just a Windows client with Wine wrapper. And frankly, with Wine or Crossover Games you would have more success than Transgaming (which from mine point of view is completely shite). Transgaming based client has hard time with ATI video cards, with exsotic sound card settings, etc. Of course you can tweak it, but what's the point then? They have nice forum where people already exchanging with ideas how to get EVE running on Linux.
There are one space sim (rather funny one), which has real *native* client. NEVER had problems with that, even on open source ati drivers on Radeons. So propably it is not that hard to do that...natively.
Parent
Sure thing boss. (Score:5, Interesting)
- GCC Plugin Wiki [gnu.org]
That is the first that comes to mind. I believe Linus himself has been quoted as saying something along the lines of "We don't promise a stable kernel ABI and if that means breaking binary drivers, oh well, in fact we might change the ABI just to break them on purpose!". Can't find the quote though.
And if you still aren't convinced, just browse the comments right here at Slashdot every time there is a story about some driver somewhere. There indeed exists a group of people who want to purposefully mix shit up hoping to scare certain kinds of developers away.
Parent
Re:Sure thing boss. (Score:5, Interesting)
What a find! Wow... just wow:
A gcc-based scripting interpreter could by default check for a mandatory license statement (header) in every source file, so that "stock gcc" could deny running plugins (scripts) with a non-matching license header/marker telling the user that stock gcc only runs plugin scripts covered by the GPL.
In addition, SDK users could -by design- be required to explicitly set up each individual plugin to be covered by the GPL, e.g. by making the proper "init" calls at startup, along the lines of setLicense(GPLv2);
In order to make it harder for non-GPL'ed plugin SDKs to be used with gcc, stock gcc could by default also require each plugin to provide a certain set of hooks that provide licensing information to the host, so that stock gcc may refuse to run such binaries that do not provide the required information.
Furthermore, it would be possible to require all plugins to be statically linked with the corresponding plugin SDK (making the plugin itself GPL'ed thereby), thus whenever the checksum/hashes of linked in files doesn't match (the ones of the SDK), gcc could refuse to run any such plugins.
This whole license/checksum/hash verification stuff sounds conspicuously DRM-like to me. But of course it's okay if it's used to force more code under the GPL, right? right?..
Parent
I didn't say they were wrong (Score:4, Interesting)
But the by product of the kernel developers actions does two things:
1) Establishes a tone and attitude that one should randomize your API to fight off proprietary software.
2) Actually works... see also this article.
If you you agree with that attitude, that is fine and I respect that. However, this article is an example of that attitude working. You cannot be for things like binary games like WoW running on Linux and still promote an attitude of actively making their life difficult. If you are doing it under the idea that it will encourage them to open-source, you will have to accept when companies choose to abandon Linux instead--as in this case.
Parent
Re: (Score:3, Insightful)
But the by product of the kernel developers actions does two things:
Bullshit to the first one. The logic is as follows:
Re:I didn't say they were wrong (Score:4, Insightful)
That is all nice, but the byproduct of that process is that it is a bitch to write drivers for the kernel. Since the kernel development process is seen as a role model for how to develop open source projects, others follow suit. Result? There is no consistent application stack to build against--thus supporting the amorphous pool of code that comprises your average linux distro is a very, very expensive process.
The only way out is to open source your code. Some companies are cool with that, but many are not. Clearly the WoW guys are not. If you want the WoW guys back, you'd make it easy to sell profitable applications that run on linux. However, that would require a shift in the culture and values of the entire linux ecosystem and I'm fairly positive that such a shift would never, ever, happen.
Parent
Re:Surprisingly hard (Score:4, Informative)
Given that Linux is yet to even standardise on a single unified sound output API
That's a troll argument. It doesn't have to be unified, as long as the systems talk to each other -- which they do.
For games? Use OpenAL. That's a no-brainer, that gets you 3D surround, and handles plugging into whatever they've got, hardware or software, any OS. Then the user, or the distro, can configure OpenAL to use ALSA natively, or use Jack, or whatever other layer they want to put in there.
whatever KDE went with that I forget,
KDE wrote a wrapper for all of the above, plus native ALSA (on Linux), and whatever Windows/OS X provide.
For codecs, you have
the same set of codecs you have on Windows, if you're licensing them. Or, if you'd like to save yourself some money, you use Vorbis/FLAC, available both in native libraries and through gstreamer/SDL.
This is as retarded as people claiming that the fact that both GNOME and KDE exists means Linux will never be a good desktop. OH NOES, choice, whatever shall we do. JUST PICK ONE! And no, you don't need the community to pick one for you -- close your eyes and play pin-the-tail-on-the-audio-library.
They all work. The existence of others, especially when the one you want (OpenAL) will plug into all of them, is not something you even have to think about.
a nightmare of communicating to customers what extra libraries they'll need
Or you include those libraries with the game -- it's really not that difficult to configure the game to use your libraries instead of the system libraries. Or you distribute a demo under a license that allows redistribution, and let the distros work it out -- when people want the full game, they put in a key and download the rest of the content.
But really, how is it a "nightmare", even if you had to spell out dependencies? How is it in any way harder than "communicating" what version of DirectX you need on Windows?
Linux will get people bothering to provide native support when
when people who might potentially port start looking at what's already there, and how hard it's not. If an indie game with close to no budget can provide native Linux support (think: every Introversion game, every Penny Arcade game, a few from Chronic Logic...), I would think that a company with 300+ employees could find one who knows at least as much as one of those guys.
Parent
Re:Surprisingly hard (Score:4, Informative)
Given that Linux is yet to even standardise on a single unified sound output API, how can we expect anything more?
That's odd, I could have sworn that I had access to OpenAL, SDL, and probably others in addition to DirectSound and oh wait, what's this? Windows has another way to play sounds? Say it ain't so!?!
This is a complete non-issue and I sure hope whoever modded you up gets smacked in the metamod. The solution is as simple as using either OSS or SDL, preferably the latter. You can ship SDL libraries with your application, and elect not to use them if the user has appropriate libraries, if you choose. Ship your application with SDL configuration as well, tell it to use every possible sound output in some rational order, and it will pick one. I suggest starting with pulse, then esd, then alsa, then oss. If you like you can try some others down below there (KDE has "arts" BTW. It's poop. Or maybe there's something new and even worse in KDE4?)
It's even a bigger non-issue if you just make it easy to package, and offer a demo. Make it so that the distributions willing to distribute non-free applications can at least distribute your demo within their licenses, and you don't even have to distribute the game or the patches. The distribution will do it for you.
P.S. SDL is not a codec, although you can play video through it. Nice try. You can use ogg audio or video for free, and bundle the libraries with your application. So this is another dumb argument that we see all too often.
The documentation argument would be good if Microsoft's documentation weren't complete shit. The biggest developers get help from Microsoft, and everyone else just makes it work somehow to some degree because they have to.
Parent
Re:Is it really so hard to support Linux natively? (Score:4, Interesting)
Why don't you pick up a random Linux game that was made 5 or six years ago and see if it runs on a random Linux box. Just go grab some Doom or Quake demo and put it on some random box with a different distro than the one the demo was tested against. If you can even get the thing to install and launch, sound definitely won't work.
The original official Quake III and IV Linux binary releases still run fine on my bleeding-edge Linux box (yes, it uses PulseAudio). The same goes for Uplink, Defcon and Darwinia. Your point was what, exactly? That most studios that release game binaries for Linux are too incompetent to statically link them?
Either you're a troll, or you need to practice what you preach.
Parent
Re: (Score:3, Interesting)
Why don't you pick up a random Linux game that was made 5 or six years ago and see if it runs on a random Linux box. Just go grab some Doom or Quake demo and put it on some random box with a different distro than the one the demo was tested against.
Just for giggles, I fired up the 'ole Castle Wolfenstein version of Enemy Territory. Popped up, full sound. No biggie. Most other old stuff is archived or OSS that's been updated - I'll have to dig around for the older stuff and see what it does.
I wonder how well Doom would work on a WinXP box? Not that I'm trying to obscure Linux's faults by pointing at Windows. However, Windows is the PC gaming platform of choice at this point so it represents what the industry and players are used to.
Having said all
I guess it's EVE Offline (Score:3, Funny)
...if you're running Linux ;-)
I use Linux heavily (Score:5, Interesting)
and do all of my development work on it... and periodically I reboot into Windows to play Fallout 3.
I like Linux for development, but the fact is that it is not as good of a gaming platform as Windows is.
Windows has better video drivers, and it has a tons of teams at Microsoft working on things like directx that directly support gaming. Aside from that it has an enormous industry devoted to developing windows games.
Oh, and sound just works on Windows, did I mention that? That's pretty important for games. I have surround sound working on my Linux install, which took some doing, but as soon as I plug in my USB headset so I can use skype, the Linux sound system explodes. That means that even if left for dead was on Linux, I still wouldn't be able to play it.
Really, I don't see what the big deal with dual booting is and since people like me are just going to dual boot, I can't imagine why any game maker would waste money on a Linux port.
If I can play my game even marginally better on windows I have no reason not to get the windows version.
Re: (Score:3, Interesting)
Really, I don't see what the big deal with dual booting is and since people like me are just going to dual boot, I can't imagine why any game maker would waste money on a Linux port.
I used to dual boot. Then I got a few games working on the Linux side. I didn't have to reboot to play. I could just flip over to a new virtual desktop, goof off for awhile, then go back to what I was doing. I didn't have to interupt anything on my Linux system. I didn't have to waste drive space for a "game" partition. And eventually, the Windows partition went away and never came back.
Those times that I do need Windows for work involves a VM. I don't play games in Windows. But then, the days of be
Dual boot is annoying. (Score:3, Interesting)
Especially when one has to shutdown, reboot, etc. Annoying. If we want to go back to Linux, then we have to do it again! Yes, we can get another computer but still... I hate rebooting. :)
Re: (Score:3, Insightful)
"Aside from that it has an enormous industry devoted to developing windows games."
Wouldn't count on that forever. Take for example EA not releasing Madden NFL on the PC this year.
Two reasons Windows may fail as a games platform:
- Piracy on PC's is more rampant than on consoles
- Cheating on PC's is rampant in multiplayer games
I gate consoles for gaming but the fact is closed platforms are proving to be inherently better for online games.
Not sure of the economics of the piracy issue but if you are sinking te
It ran on Linux? (Score:3, Insightful)
I saw tons of webpage ads for Eve Online, but I never noticed anything about it running on Linux.
If I'd known that, there's a good chance I would have signed up, partially for the fun and partially to support games companies that support Linux.
Is the real lesson here that they didn't properly advertise their Linux compatibility? Or is it just that I need to get glasses?
migration path (Score:5, Funny)
CCP is encouraging users of the Linux EVE client to upgrade to the OpenOffice.org Calc application.
Re:migration path (Score:5, Funny)
Parent
Re: (Score:3, Interesting)
BBH
Re: (Score:3, Insightful)
No, I didn't use it, even though I was probably one of very few who had even heard of it (publishers, take note -- if you don't market something, how do you expect the customers to come flocking to you?)
The reason I didn't was that it wasn't a native client. It was just a Windows executable running under Wine (in this case transgaming's tweaked winex, which is still wine).
If you don't invest the time to make a port, I do not see why I should invest the time to play it.
Re: (Score:3, Informative)
Released last November along with the Mac OS X client, it has failed to share the expected continual growth as seen with Mac client
Because you failed to read the sentence correctly.
Re: (Score:3, Informative)
Nobody is losing Eve via Linux/Mac at all. All they're using is a horribly supported, pitiful binary version of Cedega that ran 1000x worse than via Wine. It couldn't even support DirectX9, it was that bad. Wine on the other hand, is working on supporting DX10 soon.
I wish they'd take all that supposed effort in the "official linux client" and sent it towards Wine, really.
Re: (Score:3, Interesting)
Eh, not really. I don't know but I'm skeptical as to what Wine contributors could do to persuade them.
CCP is a company that does some truly groundbreaking programming, but mostly on the server-side and not so much on the client side. They do things a little slower client-side.
I suggested such on the forums over there, but CCP is in the business to make money...I'm not sure if they see the "long enough down the road" concept of making money via supporting Linux as a business case or not.
Re:Competing with itself?! (Score:4, Funny)
Also, since there's really not a lot of difference between BSD and Mac, hardcore linux users can easily partition and install BSD instead and run a modified version of the Mac program. What's one more distro to install?
ROFLMAO
Windows kind of has a POSIX API, and Linux kind of has a POSIX API, so why don't we just run a slightly modified version of the Windows client on Linux?
Linux is open source, so why don't modify the source code to run on it?
Leverage the POSIX layer in Windows to install the latest service pack on Linux, thereby fooling the Windows client into thinking it's really running on Windows?
Install Windows into Linux, forcing them to assimilate?
Z/OS is sort of similar to AIX, which is a UNIX, and Linux is "unix-like", so why don't we run Z/OS under Xen, then we can use mainframe-like power to evolve a native EVE client from random bit soup?
I still think yours wins.
Parent
Re: (Score:3, Insightful)
You have to read it in context with the first sentence. The sentence says that CCP is discontinuing support for the Linux client because it isn't doing as well as the Mac client. The sentence doesn't say they will be discontinuing the Mac client.
Wow...
Released last November along with the Mac OS X client, it has failed to share the expected continual growth as seen with Mac client.
Why is this so hard to understand.. Both released same time. One showing continual growth, the other doesn't and gets the axe. It doesn't say anywhere they held the performance of a platform with a larger install base as the baseline to judge Linux against (what an absurd concept). They just wanted to see _continual growth_. If they didn't want Linux client growth, they probably wouldn't being running these ads on Slashdot every other day. You can't say they didn't try.
Re:I felt a great disturbance in the Force... (Score:5, Funny)
Fixed. This is Eve Online we're talking about after all, and not World of Warcraft...
Parent
Re:Epic fail (Score:5, Informative)
They, uh, did.
That was why it worked better in Wine. Cedega wasn't anywhere near good enough.
Parent
The game is broken anyway (Score:4, Interesting)
I recently cancelled my two accounts for EVE because I was getting disillusioned with the game in general and CCP's motives in particular. Things that struck me as odd in the game:
1. The enormous amounts of time need to train skills in the game to be anywhere near able to play on a level playing field with experienced players. This has nothing to do with true skill at the game. Although CCP claims that this is to make it easier for new players to compete with olde rplayers, I suspected pretty early on that the real motivation behind this was that CCP uses this as a mechanism to get people playing longer, i.e. to make more "guaranteed" money from players as they try to compete with more experienced players.
There is no real rationale in the game for the so-called Tech 2 (and soon Tech 3) skills. They just make things longer to complete.
There is already a term in the EVE universe about this "timesink", an activity designed to make the player spend enormous amounts of time waiting to be able to do something during which CCP makes extra money out of the players.
2. Lack of content. The player versus computer missions are so similar to one another, and so lacking in anything interesting that doing missions is referred to as "grinding", i.e. something unpleasant that takes time, like doing homework, filling out taxes etc. Mining in the game is so boring that many players actually get an extra account simply to do this because it is so boring.
3. Terrible UI. The game's UI is so spectacularly bad that it is a wonder that anyone can achieve anything with it. In effect it usually means having so many windows open that you're left with a tiny portion of the screen in which you can actually play.
4. Player versus player. The one area of the game which really is interesting is almost totally off bounds to new players, who don't have the trained skills to be able to compete. There is also an increasing tendency in Eve for players to congregate in huge gangs, called "blobs" which makes casual play for a solo player extremely difficult, and this trend is only increasing.
5. Technical issues, referred to partially in the parent post, and somewhat alluded to in the topic title. Network disconnects are frequent, overburdened laggy servers are a frequent problem and UI glitches are very common. What often makes things worse is CCP's attitude towards its own failings. CCP trumpeted its development of a unique technology to fix the server lag issues, but they have simply worked around the problem by assigning more resources to areas of the game that are usually more frequented, leaving other areas sometimes even more starved of resources than they previously were.
I can't get over the feeling that CCP are a bunch of technically gifted con artists, given to the same PR misleading statements and untruths that other companies are. I think the main reason they stay in business is because they appeal to the geekiest of gamer who appreciate the game's complexity and are willing to turn a blind eye towards all the inconsistencies in it.
Parent
Re: (Score:3, Interesting)
4. Player versus player. The one area of the game which really is interesting is almost totally off bounds to new players, who don't have the trained skills to be able to compete. There is also an increasing tendency in Eve for players to congregate in huge gangs, called "blobs" which makes casual play for a solo player extremely difficult, and this trend is only increasing.
As the CEO of a 6 man corp that regularly finds itself at war with other corps/alliances that range in membercount from anywhere betwee