Slashdot Mirror


CCP To Discontinue EVE Online Support For Linux

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.'"

17 of 299 comments (clear)

  1. Re:Competing with itself?! by FLEABttn · · 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.

  2. Re:Did anyone use the Linux client? by reeeh2000 · · Score: 2, Informative

    I attempted to use it. I found that it did not work very well. The UI was vary packed and difficult to use. I had to remove the chat window just to see the ships controls. All in all, it was so poorly done that I didn't use more than a few hours of the 14 day trial account.

  3. Re:Bummer for them... by pilot1 · · Score: 4, 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.

  4. Surprisingly hard by CarpetShark · · Score: 2, Informative

    Given that Linux is yet to even standardise on a single unified sound output API, how can we expect anything more? Just to load and play a sound, you need a sound API, and codecs. For sound, you have alsa, OSS, and layers on top like NAS, ESD, pulse, SDL, JACK, whatever KDE went with that I forget, etc. Arguably, some or all of these may fail to meet requirements. For codecs, you have gstreamer, (probably) SDL, etc., and a nightmare of communicating to customers what extra libraries they'll need, even if one of these works. Linux will get people bothering to provide native support when Linux people bother to provide decent APIs and docs, and unify around them.

    1. Re:Surprisingly hard by SanityInAnarchy · · Score: 3, 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.

      --
      Don't thank God, thank a doctor!
    2. Re:Surprisingly hard by drinkypoo · · Score: 3, 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.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  5. But they have a flawed argument.. by Junta · · Score: 2, 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 alsa which I think you don't touch directly as an app developer because a higher layer controls it...

    --
    XML is like violence. If it doesn't solve the problem, use more.
  6. failed to show growth... by d0n0vAn · · Score: 2, Informative

    Failed to show growth my ass. Ubuntu was by far the easiest distribution to get Eve up and running. Hell, I even got Eve to run on my netbook. It wasn't lack of interest. Tell the fucking truth: CCP couldn't get it right and they never released a native linux client. Their support was terrible. That's why they failed.

  7. Re:Competing with itself?! by poetmatt · · Score: 2, 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.

  8. Re:I use Linux heavily by Anonymous Coward · · Score: 1, Informative

    ...and many game companies are not going to invest their time and effort to support your operating system, just to pick up a handful of customers

  9. I don't wonder. by waveclaw · · Score: 2, 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,

    The Eve Online Linux client is as native as notepad.exe.

    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 development updates + horrible hacks and workarounds for certain games.

    The Eve-Online client is still a windows program. It is unsurprising that the best windows API on Linux would work better. CCP picked Transgaming to do the "porting." They once had the leading implementation of DirectX on Linux, but their tiny team worked on their private and increasingly hacked up fork of ancient wineX code.

    Duplication of effort and waste all in the name of greed. And now it's the Linux users who get to pay.

    --

    "You cannot have a General Will unless you have shared experiences. You cannot be fair to people you don't know."
  10. Re:Makes you wonder... by shaitand · · Score: 4, 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.

  11. Re:Epic fail by MooUK · · Score: 4, Informative

    They, uh, did.

    That was why it worked better in Wine. Cedega wasn't anywhere near good enough.

  12. Re:Makes you wonder... by onefriedrice · · Score: 4, Informative

    ... or that glut is an OpenGL emulator.

    Given your other examples, you probably meant mesa in place of glut.

    --
    This author takes full ownership and responsibility for the unpopular opinions outlined above.
  13. Re:Makes you wonder... by Seumas · · 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 bother to tell. And since their official versions for both linux and OSX are complete ass, people often only run their accounts via Windows clients in virtual machines.

    So their claim that "the growth for the linux client just wasn't there" is wholly inaccurate as they're not taking into account the number of people who WOULD use the official linux client if it wasn't a piece of shit and was actually playable.

  14. Re:Is it really so hard to support Linux natively? by Seumas · · Score: 2, Informative

    Their calculations are meaningless, because they don't take into account Linux or OSX users using the windows client inside a virtual machine. Not because we want to, but because the official client is always somewhere between working like shit and not working at all.

    For instance, the OSX client has not been able to LOG OFF for a few months now. That's right. You can't log off and log in to another account like you can on every other OS. If you try - the best that will happen is nothing and the worst is it will launch another instance of the client each time you click "LOG OFF". Instead, you have to quit. Wait for it to shut down. Then start it back up again. Then log into the other account.

    Not a massive problem, but shows the general attitude toward clients other than the Windows client. They claim the new OSX client is going to be great (finally will support Premium content which Windows users have had for something like 18 months) -- but we'll believe it when they see it.

    I think it is clear to most people that they were just trying to gain some quick attention a year ago when they put out the whole "we're on every platform!" press releases.

    If they had put actual effort and resources into the clients, people would use them and the linux and OSX client base would be growing quite rapidly. Instead, they put out half-assed crap and then use the fact that nobody wants to suffer with that total crap as an excuse to cut support entirely.

    CCP is a pretty cool little shop and I'm a fan, but the way they've treated the non Windows clients has been a complete joke.

  15. Re:Makes you wonder... by Seumas · · 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 the FPS running the native Windows version nested inside the OS in a guest on OSX with all the surrounding apps active than I do running the official client wrapped in Cedega.

    And on top of it, the Windows version running in this manner actually works. I can leave the window/focus without it crashing almost every time. Instead of encountering random crashes every few minutes or hours or days, I have encountered one crash. Ever. Even the "log off" button works.