Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Games Entertainment

Maxis Developer on Linux Game Porting 364

friedmud wrote in to tell us about a comment from a Maxis developer, Don Hopkins, who did a partial linux port of "The Sims". You can find his post here (3rd one down, comment from Don Hopkins titled "Reality check from a game developer") in a LinuxGames.com forum. I don't know if I agree with his assertion that Wine is the best way to have games happen on Linux but his comments on the economics of Linux games development and especially the costs of keeping versions concurrent on multiple platforms are insightful.
This discussion has been archived. No new comments can be posted.

Maxis Developer on Linux Game Porting

Comments Filter:
  • by geekfiend ( 448150 ) on Tuesday October 30, 2001 @03:36PM (#2498798)
    The process of porting a game can be much less difficult if the developer chooses a multi-platform library. For games SDL allows this and for other sorts of applications, QT can do the same. The challenge lies not in porting, but rather the developer chosing to work with a propietary single-platform library (DirectX) versus something more portable, and argueably better!

    • Who says the decision is up to the developer anyway? I work as a developer and I don't get any choice as to which language or platform I code for. I would love to write platform-independent code, but I just don't get that option. Why would game developers have it any differently?
    • by drzhivago ( 310144 ) on Tuesday October 30, 2001 @04:01PM (#2498968)
      I believe some of the problems lie in the way a multiplatform library works. For games, if SDL isn't as fast on Windows as DirectX, why should it be used? I know its a bad example, because I think that SDL actually routes down to DirectX on Windows. Remember, users come before developers...

      But what about a UI library that doesn't draw the controls the same as the user's operating system? Look at Photoshop for Windows.. it looks like I'm using a Mac. I don't want that! I want an application that looks and feels like what I normally use. The best libraries will work like that, even though they have a cross-platform API. Linux versions will have the window manager look and feel. Mac versions will look like a Mac application.

      RealBasic for Mac does this pretty well. Using a single source tree, RealBasic will compile for both Mac and Windows. The Mac apps look like Mac apps, and the Windows apps look like Windows apps. That transparency is what will win.

      Of course, to make it easier for the developer can be a good thing. But to give the user a better experience is more important. Because if a user doesn't like your product, why bother?

      Greg
    • The greatest part od SDL is that it allows anyone, and I mean ANYONE to write a game or graphics app. Write it in perl, C, C++ python, Whatever.. SDL is the most portable and crossplatform multimedia system there is. Some may argue that Direct X is more powerful, but that's only based on the fact that it's an integral part of the OS it is targetted for.

      Right now companies are busy trying to wring every penny out of what they have. They could care lessabout attracting new customers or trying anything innovative. Any game development house that hasn't researched SDL or any of the non-platform specific systems is driving the nails into their own coffin.. I'd rather have my programmers using open source and ZERO cost tools than having to shell out several hundred thousand dollars every year for upgrades and license fees that are unneeded.

      The other problem is finding programmers good enough and smart enough to be able to write software outside a GUI and IDE.

      Universities today are cranking out CS degrees that can't comprehend a command line compiler let alone understand how to create a makefile by hand. and the fault lies directly in the hands of the professors.
      • by Osty ( 16825 ) on Tuesday October 30, 2001 @07:41PM (#2500260)

        Right now companies are busy trying to wring every penny out of what they have. They could care lessabout attracting new customers or trying anything innovative. Any game development house that hasn't researched SDL or any of the non-platform specific systems is driving the nails into their own coffin.


        That's really only true for Valve (Half-Life, Half-Life GOTY, Half-Life Gold, Half-Life Platinum, Half-Life You'll Buy This Too, Even Though It's The Same As What You Already Have, etc). Most other publishers might make a GOTY edition and leave it at that. However, if by wringing "every penny out of what they have" you mean making sequel after sequel, I don't see what your argument is. Especially since the good sequels do add innovative new features or items (let's ignore the Tomb Raider franchise, shall we?). As far as not porting to other platforms, I don't see how that's really an issue. Most game houses don't seem to have problems porting back and forth from consoles (PS2, PSX mainly) and Windows. They're not going to bother with Linux because it's such a marginal market. There's no money there, so why bother? And ignoring a valueless (monetarily) market is not going to kill a company. In fact, porting to that market just might kill them instead.


        I'd rather have my programmers using open source and ZERO cost tools than having to shell out several hundred thousand dollars every year for upgrades and license fees that are unneeded.

        Note that

        1. DirectX does not require a license for you to use it
        2. Nor does it require you to use Visual Studio as your development environment
        3. Thus, you can use Borland's free compilers (or buy the commercial versions), or use a gcc port like mingw32.


        The other problem is finding programmers good enough and smart enough to be able to write software outside a GUI and IDE.

        Because we all know that only poor, stupid programmers use IDEs ... (btw, all the Visual Studio compilers (for C++, VB, C#, Jscript, and so on) can be used strictly from the commandline, using makefiles or build scripts, and you can use any editor you want to write the code they compile -- vim, emacs, notepad, Source Insight, Visual Studio, or whatever)


        Universities today are cranking out CS degrees that can't comprehend a command line compiler let alone understand how to create a makefile by hand. and the fault lies directly in the hands of the professors.

        Red Herring. It's not a University's job to produce automaton that can write a makefile or compile the latest 'sploit by hand. If that's what you expect from a CS program, you'd do better to save money and go to a tech school (or alternatively, save money buy hiring a student out of a tech school). A properly educated CS student may not know how to write a makefile or use gcc from the commandline right out of college, but I can guarantee you that s/he will be able to learn how to do that quicker than your average self-taught or tech school programmer can learn to analyze the performance considerations of various search algorithms (for instance).


    • The way to make developers ditch DirectX in favor SDL is not by talking, argue, pushing, debate, but to show them.

      It would take one game to prove SDL's merits. A game with blisteringly fast 3D-engine, beautiful graphics, jawdropping soundtrack, pricewinning storyline. Put it on one single DVD that runs on any OS (Linux, *BSD, BeOS, AmigaOS, MorphOS, MacOS(/X), QNX, Windows and any other SDL-enabled OS) and get it out to the gameshops.

      This would go a long way to prove that you can reach "any" platform, that you can use SDL without any loss in quality or speed, and you can do this with little extra cost.

      Is SDL up to the task? Is the community?

  • by Glock27 ( 446276 ) on Tuesday October 30, 2001 @03:41PM (#2498832)
    What we need are elegant, cross platform game libraries (and languages) so one code base can be used.

    I think the best current approach involves Java, which can be either natively compiled (gcc 3.0) or run on a VM (JDK 1.4 should be quite good). Check out Arkanae [babeloueb.com] for an early preview. :-)

    299,792,458 m/s...not just a good idea, its the law!

    • Problem with Java in games is that most games require that which Java is worst at; a graphical interface.
    • Keep in mind that 1.4 is a long way off from being standard. It's in beta and while 1.3 is pretty well rooted among developers, the _industry standard_ is still jdk 1.2.2.

      That being said, at Java One I saw a game written completely in Java. It was definitely an interesting concept and it seemed to run pretty smoothly (it was a FPS-type), but it was damn ugly. That may be just that they didn't have the artists necessary for the models, but it sure wasn't quake3. The technology is almost there, but other posters are right, Java isn't great at graphics. Almost, but not quite yet.

      psxndc

      • Keep in mind that 1.4 is a long way off from being standard. It's in beta and while 1.3 is pretty well rooted among developers, the _industry standard_ is still jdk 1.2.2.

        This really doesn't matter, since most folk won't want to download any decent game (too large with all the multimedia resources). Therefore you can bundle the VM (JRE) with the game, of course checking to make sure its not already installed. This is actually good in the sense that you proliferate a modern VM to more computers. :-)

        That being said, at Java One I saw a game written completely in Java. It was definitely an interesting concept and it seemed to run pretty smoothly (it was a FPS-type), but it was damn ugly. That may be just that they didn't have the artists necessary for the models, but it sure wasn't quake3. The technology is almost there, but other posters are right, Java isn't great at graphics. Almost, but not quite yet.

        That was an art issue...you can do anything with gl4java you can do with OpenGL 1.2 (in other words Quake, or Doom 2).

        Did you see the Grand Canyon Demo [sun.com] at JavaOne? Pretty impressive stuff, also using gl4java! I think an Open Source Java flight simulator using the FlightGear [flightgear.org] art and other data is fine idea in fact. Anyone interested?

        299,792,458 m/s...not just a good idea, its the law!

  • just say no to ports (Score:2, Interesting)

    by capoccia ( 312092 )
    forget porting and forget emulating/re-implimenting.

    game developers need to write to a cross-platform gaming library like sdl. then all the os-specific and hardware-specific enhancements can be developed in the library by people who enjoy those sorts of things and game developers can spend their time developing games. and the users are happy because they can spend time playing games instead of being concerned needing a specific os.
    • by uchian ( 454825 ) on Tuesday October 30, 2001 @04:12PM (#2499019) Homepage
      Anyone remember when Windows 95 came out originally? It had no games, or at least the ones it did have sucked big time. Everyone moaned that Windows gaming would never take off because dos games were faster, and more dedicated.

      And now everyone uses Windows.

      Why?

      Because it was still possible to play at least some dos games under Windows (because it was built on dos), and with for a bit of hassle, Windows would close, your game would run, you finish your game and windows would reboot.

      Yeah, it wasn't neat, but it let people move to Windows 95 and still play their dos games. Once the user base was large enough, native games became available.

      My point is, the argument against Wine is exactly the same.What I want to be able to tell people is

      "Yeah, you CAN play all your existing Windows games under Linux! Try it and see! It's SOOOOO much better than Windows!!!".

      Y'see, if we could get people using Linux more, the user base grows. Then it becomes more feasible to make native Linux games. Then the user base grows some more... See what I'm getting at?

      If wine can play all windows games, we can get all those game loving people who won't try Linux because it hasn't got any games to try it and love it too.
      • You could also play all your old DOS games under OS/2, but that didn't make OS/2 a big hit.
        • OS/2 could also run Windows applications natively. This led in part to the demise of OS/2. If you could write an application once for Windows, and have it run on both Windows and OS/2, then why bother ever writing for OS/2 natively?

          So the consumer sees 10,000 native Windows titles and 10 native OS/2 titles on the store shelves, and thinks to himself "duh!"
      • MOD UP!!! (Score:2, Interesting)

        by gatesh8r ( 182908 )
        AMEN! I am SO glad someone in the /. crowd said this.

        I personally feel Transgaming is a Good Thing(TM); screw Loki for now until we have a -competitive- marketshare (I'd say at least 15%-20%) before native ports happen... we have the libs, yeah; we have the hardware; yeah... I hate to make this a "me too" post but everyone needs to get this point hammered down. Give the customer their PROGRAMS, and they will choose to come to Linux. Why??? Well, let's be the average Joe. Their programs don't have a need for 100 FPS (Why would they? They got a "deal" at Best Buy on an HP for $699!). Their OS is Windoze; it's not that they hate it, it's because they can't run their games (no matter how much you and I think they suck :-P) or Office (and fuck getting them to run StarOffice/OpenOffice/KOffice/Whatever because they're not intrested). Speed isn't an issue so much as it's a reasonable speed. It works the same, and Linux costs less... effectively, we have competition! Competition is also a Good Thing(TM). This would not only extend marketshare, but it would help break down the Evil Empire more. If the gov't is going to let Billy G. and his Borg get away with it, we can't say "Oh the gov't will get us back to normal again." This however, can, and we need to act.

      • Remember Windows 95 coming preinstalled on every computer you bought around that time? I'd say that had more to do with acceptance of Windows 95 than what games it did or did not run. A larger user base will help native games, but I'm not convinced wine is the answer. I don't think the Transgaming people really want to write self-depricating software.
  • Its a shame. (Score:5, Insightful)

    by Captain_Frisk ( 248297 ) <captain_friskNO@SPAMbootless.org> on Tuesday October 30, 2001 @03:42PM (#2498835) Homepage
    As much as I'd like to see more games ported to linux, so that I might be able to give up my MS habit completely, you have to agree that economically it just doesn't make sense.

    Having multiple target platforms is a serious headache, and Linux just isn't a big enough market. Most linux users are used to getting their software for free anyway, and probably have the technical savvy to score free versions of any software released. While I'm sure that there are plenty of honest people out there, the fact is that there are very few people who are going to pay for linux games.

    Also considering the generally degraded performance of games under linux and the continued acceptance of DirectX as the standard for graphics, all make Linux development difficult.

    I read recently that id doesn't want to release their next product under linux (historically they have been pretty good about that stuff) because its a support nightmare, and just really doesn't bring in that much revenue.

    I think in order to start getting more native Linux games, Linux needs to prove itself as a consumer OS first. Once Linux starts to satisfy peoples needs easily (thats so important) then i think more people will start moving over, and once they do, then the linux games will start rolling in.

    • Most linux users are used to getting their software for free anyway, and probably have the technical savvy to score free versions of any software released.

      No. Those are tech savvy Windows users. I argue that most linux users understand the value of their free software and contribute accordingly. If I like a distro I'll donate or buy a boxed set. If I like a game that is in Linux, then I'll pay a reasonable price for it.
  • by Xerithane ( 13482 ) <xerithane AT nerdfarm DOT org> on Tuesday October 30, 2001 @03:43PM (#2498845) Homepage Journal
    ... we have SDL. we have OpenGL. I fail to understand the logic that game companies harbor to not write cross-platform games. I've done some development with SDL and it's a really good toolkit. Sure, it needs some more work but everything does. OpenGL is awesome, and it's not controlled by one proprietary source.
    Taking some extra time to port to linux and ship it on the same CD as the windows version doesn't seem like a bad idea. His talks about Wine are fine and all, and I can understand that.. but I really dislike his dismissal of whether or not it is native. AFAIK Wine still requires Windows. That is bullshit. I want a game to run on Linux. Linux. Not windows, not wine. Wine is Not an Emulator, Right?
    It doesn't seem to take much to build a game using existing cross-platforms toolkits that rival Direct3d. OpenAL seems to be the largest gap to bridge.. but, this is a pointless rant so I'll end it.
    • Wine hans't required windows ever, AFAIK. It certainly doens't now.

    • > It doesn't seem to take much to build a game using existing cross-platforms toolkits that rival Direct3d.

      Maybe, but their code is already written for Direct3D, and that's what their developers know. They're not going to pour the money into training developers to use totally different tools and platforms, and pay for the development time to convert everything to OpenGL/AL/SDL whatever. Your points are valid, except in a case such as this - the code is already there, and they're not going to re-write it all.

      I just know somebody is going to say, "open source it, we'll port it!" or something like that. But think about it - if you were a company like Maxis, would you give away the source code to your best-selling game that you've put millions into (and received that much as well)?

      • would you give away the source code to your best-selling game that you've put millions into


        Actually, what consumes millions is not making the software, it's creating the data. There are some good open source libraries and engines for creating games, but what makes a successful game is the storyline, the characters, the virtual environments, etc, and those can be copyrighted.


        Unfortunately, in recent years game companies have begun to forget this. They are trying "advanced" features as selling points, rather than imaginative games. For instance, one old favorite of mine is the "Monkey Island" series. The latest sequel has a "three dimensional" GUI, but it seems to lack much of the imagination, originality, and sense of humor of earlier versions. Perhaps that story is just getting old, but I wonder if they really invested as much in creating a good story as they did in creating that new GUI.

    • I see you glossed over the fine points so let me restate it simply:

      Linux is not worth it. Not 5 years ago, not today, not tomorrow, not a year from now. I have a game developer friend, he was enthused with Linux before he had to port his companies game; now he detests it and much of the (Linux gaming) 'community'.

      OpenGL develops slowly and requires proprietary extensions for the newest video cards. Hardcore gamers are the last people on Earth who like to wait until their new-fangled video card and sound drivers are supported. Video card companies will support Quake because of it's mindshare. They don't support other companies near as well.

      The development and support costs FAR outstrip the benefits of having a native Linux port. The bottom line in a truly cutthroat industry is how much ROI can you get. Last I heard, Q3's linux version didn't do well enough to justify further Linux targeted box sales (late release, blah blah blah, excuses), and the Quake series is probably the biggest, most popular commercial game among the /. crowds.
      • didn't come out at the same time as the Windows version, most people hopped out and grabbed the first god damn copy they could.

        Only the absolute Windows haters would grab the Linux only copy.
      • Linux is not worth it. Not 5 years ago, not today, not tomorrow, not a year from now.

        Being a small buisness all linux network administrator for two different companies (concurrently) I feel your pain, even if it is a different realm.

        You might want to tone it down a notch, as your statement comes across way too ideological. There are many instances where SDL and OpenGL make sence for game developers, even if it doesn't for the "latest greatest see realistic blood and guts" games developers. It may even make sence for them too, I wouldn't dismiss it.

        In the market as it is today, I wouldn't want start the two year long development cycle for the killer game on ActiveX, only to find out that my compeditor reaches a larger market with SDL (PlayStation, Sega, etc...). I wouldn't want to try to make a name for myself in to a saturated ActiveX market and my compeditor actually make money on a more scaled back SDL production.

        I just couldn't justify that kind of decision to my Boss, VC's, or share holders.
      • by DGolden ( 17848 ) on Tuesday October 30, 2001 @05:27PM (#2499451) Homepage Journal
        Linux is not worth it. Not 5 years ago, not today, not tomorrow, not a year from now.

        People said the same about windows games. "Why develop for Windows when everyone has DOS?". Well, corporate IT was moving towards windows, so the savvier game developers saw that people would soon have windows everywhere - and if there's one thing that people always do, it's play games when they should be working. Now corporate IT (at least in here in Europe and (according to reports) in Asia) is moving toward linux on the desktop and server.


        OpenGL develops slowly and requires proprietary extensions for the newest video cards.


        OpenGL development did slow down a bit. It's speeding up again now, thanks largely to Mac OS X. There may sometimes be extensions, but that's still better than the whole bloody thing being proprietary and at the whim of MS, like D3D is. There's a well-defined process for folding such extensions into future revisions of the OpenGL standard. OpenGL was designed to be extensible.

        Also, the Direct* APIs are a bitch unless you code in MS-mutilated C++ - OpenGL has well-defined, easy to use, pure C and fortran bindings, as well as decent bindings for many other languages. - That's one of the reasons OpenGL is used for high-end applications, like CAD and scientific and engineering visualisation (my specialty). DirectX truly, deeply sucks for anything like that. OpenGL is also designed for very high poly-count stuff encountered in visualisation. OpenGL on linux is being developed enthusiastically, from the industrial side - visualisation front ends for $50000 numerical simulation software that used to run on SGI IRIX systems are now being run on Linux boxes. OpenGL isn't going to fade into obscurity anytime soon - the profits from a couple of licenses for the sort of software that really uses OpenGL can outweigh the profits from the sales of hundreds of thousands of copies of weenie windows games.
        • Wake me up in 2 to 5 years when Linux/X is actually ready for the Desktop. Until then I'll run it for the two things it's really good for: serving and unix development.

          And the argument isn't about OpenGL for $$$ CAD apps. It's about using it for $50 a pop consumer games that are obsolete and out of mind 6 months after they come out.

          • Huh. Linux has been running on my desktop for years now, even back when people were making similarly crappy claims about Linux not being ready for the Server.

            My previous post was countering stupid arguments like "people are using Direct3D for Games, therefore OpenGL is dead, therefore Linux is dead." - OpenGL isn't dead. I was attempting to illustrate that more powerful forces than the games market are keeping it alive - and as European governments start to use open source OSes on desktops (and they are doing so), then european games developers who want to make money will follow with linux games. The presence of OpenGL on Linux makes it very easy for them to do so, since chances are they already know OpenGL anyway.

            There have been an amazing number of illogical attacks on OpenGL on /. for the past while, usually from clueless teenage Windows gamers who wouldn't know an SGI if it bit them on the ass. OpenGL is the grown-ups 3D API, and it's not going away because people are writing windows games targetting Direct3D.
            • And my Desktop comment is in relation to games as a viable market. I think you'd have to agree. Does you using Linux as a Desktop make what I said false? No.

              I don't see why you attached your OpenGL comment to my post. I hardly tried to say OpenGL was dead. I just said it didn't make sense for game developement in most cases.
              To reiterate: *all of my comments are in relation to games on Linux* I hoped to Jebus that I wouldn't have to type out every exception and write a 2,000 word essay on my background and beliefs to jsutify my comments.
  • Do you think that installed base for Linux will be higher or lower than the installed base for Mac OS X in terms of gaming population? Do you think that it will be easier to port your games to Linux or Mac OS X? Will UNIX ever beat Windows for Gaming?

    P.S. Thanks for native build of "The Sims" on Mac OS X and supporting Linux in general.

  • I think the subscription is a dumb idea....why put the onus on the user to get the most up to date libs for his system? if TG would sell their wine implementation to a game studio so that it can be included on the cd, then the game studio only needs to make an installer for Linux, the Winx is included so the Linux user just needs to buy the game with the penguine on the box, not worry about how it is being implemented, the installer can look at the system, see the winex libs are all compatable, if not install the ones that are included on the cd, and put an Icon on the desktop. bam a game that runs and the user dioes not have to know how it works.....that is how to make good use of wine, by including it in the installer, not a subscription.
  • by Rosco P. Coltrane ( 209368 ) on Tuesday October 30, 2001 @03:54PM (#2498913)
    ... is only the first of a slew of revolutionary match-making games. Soon, the following titles will appear :

    - The Sims Warm Feeling : you have to prepare the ceremony. Choose the right cake, find an affordable ring, discover friends to invite who aren't drinking buddies, select an appropriate church (avoid the ever treacherous Vegas drive-in wedding !) : will your marriage be successful, or will she say no ?

    - The Sims Hot Waters : your mistress and you are busted ! dodge flying plates, try to watch the ball game amidst the shrieks : can you manage to stay married, or will you join the legions of single men again ?

    - The Sims Cold Feet : you can't take it anymore, your family urges you to take a decision. Work harder to pay attorney fees : can you make enough money to win your divorce ?
  • by k98sven ( 324383 ) on Tuesday October 30, 2001 @03:59PM (#2498946) Journal
    In my opinion, there is no future for linux gaming if wine is the only way to go..

    The problem is: at the moment, the best gaming API
    is Microsoft DirectX, like it or not, and
    the likelyhood of DirectX becoming a cross-platform API is zilch.

    So obviously, Wine is needed at the moment, partly as a windows-simulator,
    but also as an implementation of DirectX on linux.

    In the long run, however, It's unhealthy to be dependent on an API dictated by microsoft.
    We need a new, open, alternative.

    Perhaps SDL 2.0 [libsdl.org] or OpenGL 2.0 [opengl.org] is the answer needed?
    Linux needs a killer DirectX-killer-API, much in the same way DirectX was the
    MSDOS-killer that moved games development to windows.

    However, if wine is the future of linux gaming,
    we are (indirectly) giving that future to Microsoft.

    • Maybe someone with lots of money and an open source bent would pay Microsoft some odd millions of dollars for the source to DirectX 1.0 and go from there? It would be so buggy it would be unusable for the most part; but the OSS community would refine it and make it better. It wouldn't be an MS API but would be compliant to the DirectX spec.

      Not that MS would ever sell it, but stil...
    • Why does Direct X _have_ to be dictated by Microsoft? Why can't the OSS-community embrace and extend?

      The fact is that most development houses will only program for one API and they will choose the one that is reaches the largest parts of the market. If another API can reach an equal amount of people, while being clearly superiour and not costings lots of money for retraining, then you can expect to have game developers actually use it.

      If you can prove that an cross-platform API will make you sell substantially more copies of a game, without it being a support nightmare, you have a winner.

      Personally I think there is a bigger chance of having gaming houses try to make sure that their game works fine with Transgamings DirectX-implementation, than switching API.

      I really don't care if a game is native or not, if it works perfectly and seamlessly under Wine. It's not like it would look or feel any different, like the difference from at Qt/GTK+ -app to a Wine-app (like Word Perfect).
  • But he had a pretty interesting post on /. lately, as well.

    http://slashdot.org/comments.pl?sid=23108&cid=2491 410 [slashdot.org]

  • The issue of keeping the network protocol consistent on multiple platforms is BS. That being said there are still lots of issues.

    The truth of the matter is that no matter how rich your protocol, you still have only a small portion of your code, on both the client and the server, dedicated to the protocol. It is entirely possible to have this part of the code isolated from the rest of the code, and for it to be completely platform independant. It's also possible to allow for updates to the protocol code independant of the rest of the code.

    Most well implemented protocols have built in support for handling multiple versions of the protocol simultaneously (typically implemented through some form of extension mechanism or flat out versioning). I've worked on projects using extremely complex binary protocols which make games like Sims Online seem pathetic. It can be done.

    The real reality is that most game houses have not yet developed this expertise, nor are they likely to in the near future. Furthermore, even if they DID develop this expertise, heck even if it cost them ZERO $'s to develop on an additional platform, it still doesn't make economic sense. Why? Because no matter how hard you try, each new platform dramatically adds to the support costs for the product. You now have to support a whole new set of OS bugs, train your tech support people on how to support a new platform, etc.

    As everyone in the open source world knows, support costs are the real costs of software development. Until your userbase grows large enough outweigh the support costs, well, you won't get a lot of commercial software. So be it.

    • by smcv ( 529383 ) on Tuesday October 30, 2001 @04:30PM (#2499124) Homepage
      Why stop at netcode?

      "It is entirely possible to have this part of the code isolated from the rest of the code, and for it to be completely platform independant."

      This applies nicely to other stuff too.

      Have you seen the Unreal engine, responsible for Unreal, UT, Rune, Deus Ex and others? Video, audio, input, physics, etc. are implemented in C++ for speed. The game code ("when the player touches a gun lying on the ground, add it to their inventory" and so on) is written in UnrealScript, a compiled-to-bytecode language vaguely similar to Java. In the case of UT, you'd probably be surprised how much is done in Unrealscript (you could quite conceivably make a whole new game without changing the C++ bits, although you'd be stuck with a slightly older graphics engine that way).

      I believe Quake 3 uses a similar system (mostly so that auto-downloaded mods can't carry viruses because they run in a Java-applet-like "sandbox"). This is why the UT and Quake 3 Linux ports consist of a smallish set of replacement binaries (the UT one is around the same size as the latest Windows UT update patch), and require a Windows CD to install from.
  • Well... (Score:3, Interesting)

    by geomcbay ( 263540 ) on Tuesday October 30, 2001 @04:08PM (#2498994)

    I met Scott Draeker at the Game Developers conference on March 7 2000, about a month after The Sims shipped on Feb 4. I suggested that Loki port The Sims to Linux, because I was optimistic that it was going to be a popular game. He didn't seem to think so, and brushed me off, with a "go away kid, you're bothering me" attitude.


    Just goes to show what a stellar business-man Scott Draeker is. Maybe that's why Loki's business is in the shitter and all of the good programmers jumped shipped months ago. If I were the Transgaming folks, I'd be happy that Scott Draeker was poo-pooing my idea as he has shown time and time again that he has no idea what he is talking about and in fact is often doing the exact opposite of what the right thing is.

  • slow news day (Score:5, Insightful)

    by _|()|\| ( 159991 ) on Tuesday October 30, 2001 @04:09PM (#2498999)
    So let me get this straight. The highest modded [slashdot.org] post from yesterday's story [slashdot.org] is copied to another forum, and it makes today's news?
  • I think the problem here is between games being developed with the ideal situation in mind and the practical most efficient situation.

    The most efficient way to develope a game to run on multiple platforms is to be able to use a single feature-full API that will run on any platform. Currently, the only fully featured game API is DirectX. SDL with OpenAL/GL and other such combinations have many features and work well, but they still can't compare with the feature set of DirectX. It is most efficient to use the DirectX API and develope an application for one platform, Windows, and have it run verbatim on the other platforms such as Linux using Wine.

    Above is the most efficient and practical method for a game company to use, but the ideal method is completly different. The ideal method would be to develope a cross-platform gaming library which contains all features a game developer would need. Currently SDL with OpenGL and OpenAL is available for use, but this combination is still lacking some features. So I see two roads that can be taken. The cross-platform gaming library can be extended to included the needed features and a standard can be decided on which all game companies will use. Or SDL with OpenGL and OpenAL can be used as a base and all other features can be coded into the given application. Either way would result in a native application. In the end the ideal method will also turn out to be the most efficient and practical, but in the current time frame it isn't. The choice is up to the game company to decide which time frame they want to work with. Large companies can go for the extended time frame and work towards the ideal situation, but smaller companies as is the situation for most, will have to go with the smaller timeframe and use Wine.

    I hope the someday the ideal road will be acheived and everything will be native to all OSes. But until then, Wine will suit me just fine.
  • Feh (Score:3, Insightful)

    by Aqualung ( 29956 ) on Tuesday October 30, 2001 @04:12PM (#2499018) Homepage

    As an avid gamer and coder, I'd have to say that linux really isn't going to catch the gaming market in the forseeable future. Call me a pessimist if you like, but that's the way I see it. Gaming may be a large market, but right now, the market is firmly entrenched on a Microsoft codebase. As the guy from Maxis pointed out, it's not that the tools aren't there, or that they're not professional quality...

    Porting games really isn't a solution, as Loki found out... any gamer that's serious about playing isn't going to wait for the linux port to maybe make the rounds, if someone decides to pick it up... so they basically exist to serve two VERY niche markets... the "I won't run anything unless it's on linux" and the "I'd rather run it on linux" groups. Concurrent development for multiple architectures is indeed expensive and carries with it a lot of overhead, EVEN if it's planned from day one! While this may have benefits in the long term, as with the Sims linux code being used as a base for the Sims Online project, I believe that this is still the exception rather than the rule.

    So, you a cry, a killer app is perhaps warranted? Difficulties abound in this scenario as well... any game that becomes immensely successful automatically spawns imitation... play-alikes would be appearing on the Windows platform in VERY short order, capitalizing on a much greater market that has been overlooked, purposefully OR unintentinoally, by the original creators.

    Realistically, there's only one thing that will make Linux a commercially viable platform for which companies can develop games: Linus' plan for world domination(tm). The game companies will go where the money is, that is the simple truth... if the gamers come to Linux, the games will follow. Loki's "testing of the waters" showed that there isn't the demand yet to justify a supply.

    As for the discussion on how to get people to Linux... well, that's a whole different can of worms, and one that I won't open in this thread. I should probably (knowing /.) add the caveat that when I'm talking about games, I'm talking about modern, commercial-quality games, with Hollywoodian budgets and all the bells and whistles.

    Just my two cents...

    • Sensible, reasoned reply, with realworld economics taken into consideration.

      Kudos.

    • so they basically exist to serve two VERY niche markets... the "I won't run anything unless it's on linux" and the "I'd rather run it on linux" groups.

      Fine, call it a niche. But niche != nonexistent. Niche == opportunity for someone who wants to make some money.

      I'm typing this on my Amiga, so I just have to snicker when someone calls Linux users a niche market, implying it's totally unviable or something. If you wanna see unviable ... oh, never mind.

      • Just because the Amiga niche is even smaller than the linux niche doesn't mean the Linux niche is economically viable... and remember, we're not referring to the Linux community as a whole, we're referring to gamers who use Linux...

        Gaming on linux is much more difficult than gaming on windows... needed drivers often aren't there, unless you buy just the right hardware, you have to get the right drivers for the right game, set up the game to use the drivers, the list goes on, as opposed to popping the CD-ROM in the drive and clicking install. Lazy? You're damn straight... if I just picked up Quake9 or something like that, I don't want to have to spend hours futzing with drivers and config files and what not, I wanna frag something!

        Until you can dumb down Linux to the point where it really is just click and go, you're going to keep a large portion of the market away, myself included, and I'm a big fan of Linux... I'm more than happy to use two OS's for different purposes, and treat my gaming rig like a big overblown console, and be productive with Linux.

  • Bioware? (Score:2, Informative)

    Everyone knows that Bioware [bioware.com] is doing a native linux version(and they were talking about the possiblity BeOS port as well) of Neverwinter Nights [neverwinternights.com], but has anyone actually asked their motivation for it?

    I'd certainly like to know. Is it that they see a potential in linux gaming, or are they doing it out of good will? I'm unsure but it looks like they've snubbed directx and direct3d completely in favor of OpenGL.

    (before anyone asks "when is it coming out?" go here [planetneverwinter.com])
  • by Gedvondur ( 40666 ) on Tuesday October 30, 2001 @04:31PM (#2499127)
    One of the things I didn't see mentioned is that a lot of developers are writing for the console only.

    Consoles have a lot of advantages. They are stable same-same environments. Not a lot of variance, since there is only one manufacturer for each one. There have been some companies that have questioned making games for PCs entirely becuase of the wide variance in the hardware, let alone the operating system.

    Many companies make two versions now, one for their console-of-choice and another for Windows/Intel PC platform.

    Guess which one is the support nightmare. Pretty easy when you have to support several different video card manufacturers, even ones that don't exsist any more like VooDoo. Yet, the small, vocal, they-will-get-my-VooDoo-when-they-pry-it-from-my-c old-dead-hands crowd clamors for support and then whines when they can't get it.

    Different versions of Windows, cheap, God-awful systems from Best Buy and Circuit City, poor white box mail order, you name it, and its a problem on the PC platform.

    So, is it a Windows vs Linux thing? Not really. Unless Linux becomes the dominant desktop environment, or at lest has double digit percentage numbers, its a useless question. Developers don't REALLY want to develop on the PC to begin with because of the high support cost, and they are certainly NOT going to develop for a low desktop marketshare OS like Linux.

    Think about this anyway: If they did, they would only support it on Red Hat anyway,(market share and mind share again) and then you would bitch about that. This community will only be happy if there are NATIVE Linux games that work on every distro. Ain't gonna happen. Be happy there is still a market for PC games at all.

    • Guess which one is the support nightmare. Pretty easy when you have to support several different video card manufacturers, even ones that don't exsist any more like VooDoo. Yet, the small, vocal, they-will-get-my-VooDoo-when-they-pry-it-from-my-c old-dead-hands crowd clamors for support and then whines when they can't get it.

      I'd beg to differ... both Windows and linux have sets of standard-ish API's that developers can use in their applications to abstract away hardware considerations to the point where it's not an issue... DirectX, OpenGL/AL, SDL, etc... In this respect, gaming development in the console and desktop arenas are actually converging... while console developers can expect a common hardware platform which will behave identically on any given system, PC developers are rapidly approaching a common hardware abstraction which will also (ideally) behave the same on any given system. While the Linux API's may lag behind a little bit

      • Sonofabitch, I kicked my keyboard out of the damn socket =) To finish my post... while Linux API's may lag behind a little bit, the article's author states that the "quality gap" is rapidly closing between the two, and that linux gaming API's aren't what are holding back the developers.

        • I can see your point.

          I am not sure that the hardware abstraction is moving ahead, but I would also argue that that still is a long way off. There seems to be a great deal of incompatibility out there.

          Case in point would be the the recent release of Tribes 2. Tribes 2 is an OpenGL game that experienced a LOT of hardware issues on PC platform. I certainly don't want development on PC platforms to cease.

          There will always be platform specific issues. These will continue to pose a problem. It's not neceessarily the overriding factor but, it is a factor. PC hardware varies too widely and changes too rapidly to ever really be completly extracted from the developer. IMHO.

  • The problem I can see with contemplating Wine as a tool to port games to Linux is that it will always be dependent on the whims of Microsoft's DirectX API's. Furthermore, the emulation insures that overall games will rarely perform as well under Linux as they do under Windows.

    What might be a much better approach is to find a solid API that is compatbile with both systems. I'm sure somebody could write something far superior to DirectX and could provide compatibility for both Linux and Windows. The economics to fund such an endeavor might not be there but it definitely would be in the interests of Game Developers (so they could cooperatively fund some open source effort).

    Wouldn't it be nice if a game could be ported between Linux, PC, X-box, PS2, Game Cube, and Macintoshes with little need for changes to the code. Then it would make the task of supporting multiple platforms nearly trivial. Basically I'm thinking something akin to Java, but written very specifically for gaming.
  • Killer Apps (Score:4, Insightful)

    by NeuroManson ( 214835 ) on Tuesday October 30, 2001 @04:41PM (#2499177) Homepage
    What is it that allowed Windows to win the mainstream? What is it that allowed Apple to win the mainstream? A concept known as killer apps... Essentially, a program that allows the platform of choice to perform a duty and function that is NOT available/possible on other systems...

    Linux is good for server applications, but *really*, what can it do that Windows/Mac cannot do, other than not crash as often? Very little... Why is this? Between platforms, Linux does little more than ape most of what anyone running Windows/Mac can already do, and far FAR simpler... Can Linux be used optimally for graphic design and video production without any hassles of hopping between CLI and GUI? Nope... Can Linux be used for mainstream business applications and gaming without doing the same, or relying on emulation? Nope... Face it, Linux relies on a few adequate programmers attempting to reinvent the wheel, or emulating an OS that already exists with far less BS to fight through to get the job done...

    THIS is why Linux fails... This is why Linux isn't replacing 100% of Windows desktops...

    This is not a flame, this is constructive cricism... The problem with Linux is that there are plenty of people willing to rally around the banner, but very few willing (and able) to actually go to war for it... Linux, in order to fight against the two big shots, is to make some applications that are COMPLETELY unlike what is already on the market, and unique in what it can provide... Make something, ANYTHING, that can either (a) supplant existing applications (make a graphic editor far superior to what can be found on Windows or Mac platforms, with a GUI to allow you to use it, artists traditionally don't LIKE to have to haggle with CLI's just to draw, I'm an artist, I KNOW this), and (b) provide a program that is completely unique, anything that the existing Windows/Mac scene has completely overlooked... Use your imaginations, you want the OS to succeed, then FIGHT so it can, instead of pretending that just being crashproof is the lone cause for it's acceptance...

    What good does a bulletproof jacket do you in a world where everyone fights with rocket launchers?
  • Fixing a weak spot (Score:2, Insightful)

    by Zach` ( 71927 )
    Games are a big weak spot for Linux, so naturally it seems that making Linux an attractive game platform is an important long term goal for the community. Sure, some people don't like games, but no one can argue that games haven't partially driven CPU technology in the past and have almost totally driven low-end 3d technology.

    So how do we push Linux (and unix in general) as a usefull game platform? Obviously we need to present game programmers with a programming interface that they can use to port games to (or ideally write original games for). Like GTK+ is for GUI applications (or Qt, depending on your religion), we need the "GTK+" of the game world. Some kind of library that:

    1. Is portable
    2. Is extendable
    3. Can make use of hardware acceleration
    4. Can grow with future graphics/sound technology
    5. Is based on _some_ kind of industry standard

    Number five is VERY important. A standard has to be agreed upon or developers are just going to shrug Linux off as a bunch of non-standard API's each evangalized by their own creator but no one else.

    What we have been seeing lately, is too many chefs spoiling the soup. Everyone and his uncle has their own API they are trying to push, and no one is working together to agree on a standard.

    You aren't going to like this but I'll say it anyway. The reason Windows has caught on as a game playform is because of DirectDraw and DirectSound (and to a lesser extent hardware-accellerated OpenGL). Simply, developers don't have to worry about writing their own routines to allocate video memory, access the sound card's dma buffers, etc. etc., because Microsoft for once provided a pretty decent standard API to write to, that everyone could pretty much agree on.

    Everytime someone announces his own "KICKASS GAME API" we (the Linux/unix community) actually suffer a set-back. We slip farther from the goal of having a single, open, standard API for mainstream developers to rely on.

    Fortunately we have things like Mesa, which seems to "Get It". I'm not going to advertise Mesa more than I have to, suffice to say it meets all of the five criteria I mentioned above. Personally I believe time spent on writing APIs that essentially do what Mesa already does is time wasted. LOOK INTO MESA before you decide to write "Yet Another Graphics API".

    On the other hand, we have sound support on Linux. Currently it's a mess. Basically application writers need to directly access the sound driver in order to get any kind of noise working. We currently have no standard _OPEN_ API to work with, and for the most part sound capabilities under linux are limited to a single process using a sound card. This will not fly with game developers.

    Like the graphics world, we need an sound API that:

    1. Is portable
    2. Is extendable
    3. Is hardware-independant
    4. Allows more than one process/thread access to sound hardware simultaniously (a mixer)

    One thing I have seen that looks promising is eSound. Do your own research on it but it looks pretty nice, and it will get the job done if its developers continue to do "The Right Thing".

    It is important for us small-time game developers to look for APIs like Mesa and eSound, which are implemented properly and have potential to become some kind of standard, rather than latching on to one that has cool screenshots but only had a single game written to them--or worse, just writing our own game API.
    • by man_ls ( 248470 )
      Please mod this "Flamebait", because I am sure it will offend quite a few people.

      I'm a Windows user. Windows 2000 specifically, because of its more powerful command line interface and more crash-resistant GUI, but still a windows user.

      The problem in my eyes is that Linux has no central figure directing development. For those who would jump up and yell "Linus!" think again - he's doing the OS core but not terribly much else in this area. In the Windows world, where Microsoft is on 80-95% of desktops depending on how you count, MS drives the entire industry. DirectX is *the* API. It killed off Glide, and OpenGL doesn't seem to be doing terribly well either now. Why? Because it's standard. It comes with the OS and it comes preconfigured to *work* with the OS.

      I have psuedo-Linux (Cygwin/XFree86 running KDE 1.1.2) installed and am learning how to use it. I hope to one day shed my chains of Microsoftness and become Enlightened, but I'm struck by the complexity of it all. I just learned how to mount drives. I still don't know how to install software. Every time I try it tells me my GCC can't produce executables. No mention on how to fix this, however.

      Linux is, for many average *gamers* too difficult of a market to bother wasting time on. 9/10 of games are for a gamer, not a *geek gamer* which the Slashdot community is. With the exception of hard-core simulators (NOT the porn kind to all trolls), everyone the game company cares about is running Windows. Why spend $$$ porting to another platform?

      I don't agree with that personally, but it makes sense in a business way.

      JKoebel
  • What I'd much rather see, than Linux supporting lots of games is game developers using Linux to create bootable CD's on which thier games exist. If the game developer doesn't want to have support problems, then create the entire OS environment on the CD and distribute a bootable CD that just starts up the game. It's cheap for the vendor because they don't have to pay for Linux, and it makes a huge cut in support costs becuase they don't have to deal with installation problems on *any* os. The game is already installed and will interact with the OS perfectly... and to the consumer, it doesn't matter what OS is installed on their machine, or how fubar'ed the installation is. All that matters is that you have a machine with the minimum hardware requirements.

    Of course the biggest problem with this is knowing what hardware the user has - especially video cards - and making sure that a large number of video cards support a standard set of well known API's accessable from drivers written for Linux. Without this, the idea falls on its face.

    I know! It shouldn't be too hard to convince all the video card makers that it's in their best interest to release open source drivers for their cards... oh wait.... nevermind.
  • by JohnG ( 93975 ) on Tuesday October 30, 2001 @05:14PM (#2499352)
    What is really that attitude of the majority of Linux users regarding commercial games? At present I am writing a shareware game which will be released for Linux, Windows and possibly OS X. Of course the shareware game profits would be used to build bigger and better games with contracted artwork and possibly licensed engines.
    I'm doing the Linux port because I prefer to develop in Linux and the libraries are all cross-platform, but I don't really expect the Linux port to sell well. I also expect to get flamed for not releasing source.
    It occurs to me that startup companies could offer a great deal to Linux, but the community seems only interested in giving money to established companies and complaining that the new guys want to charge money. Almost every commercial/shareware game on happypenguin for example has a comment saying "it would be better with source code" or "I refuse to use it because its not free".
    • I generally use only open source programs. I don't use flash pluggins, for example, because I don't like close source standards for things on the internet. (There are open source flash viewers but no open source generators).

      But games are a different. Games don't need support. You can't make money off an open source game. Your business doesn't rely on a game to run. You don't really need a game at all.

      I look at games as the same as movies. They are entertainment. No one asks for open source movies. Sometimes I guess, it might be fun to have the source code to a game but it's not necessary.

      You will probably get flamed by people asking for the source code. People who do that are wusses. I think most people are more reasonable than that.

      • Thst's pretty much my logic behind it. I plan on redoing my game TutorShooter to use SDL instead of my PowerPak lib and re-releasing it, once again under the GPL, becuase I feel that educational materials be they "Edutainment" or not, should be free if possible. I also feel that Operating Systems should be free, as well as a few other things.
        But you don't HAVE to have games, you don't benefit in any way from having a non-educational game with the exception of pleasure and I think it is acceptable to pay to be entertained.
  • How about... (Score:3, Interesting)

    by Soko ( 17987 ) on Tuesday October 30, 2001 @05:17PM (#2499375) Homepage
    Game developers write the specs of gaming APIs they would die for and publish them, so they can be implemented by OSS, Microsoft, Sony, Nintendo and any other person/entity that cares to implement them?

    They would then control thier own destiny - as long as they could resist $ from marketing deptartments - and would have a common set of APIs to support in thier games.

    If a game didn't run on PlatformX because of a malformed API, the author of the API implemenation would be on the hook, not the gaming company. IOW, the game authors hold all the trump cards, no one else.

    SDL seems to be an atempt at this already, but is it coming from OSS developers or game developers? The difference is important.

    Soko
    • Speaking as a starting game developer, I can already see some problems:

      Conflict of interest, NDA's, IP issues abound. It would be tough for any game developer to really have a significant impact on a truly OSS library. The minute it became large, his or her employer would want to make it proprietary, and probably could do to the all the legal stuff. What motivation does any company have to share its code freely? Why give competition help? Now, former game developers or independant game developers might be able to do this, but its tough for industry developers. Of course, this is just my guess.

      Kevin
      • Think RIAA and MPAA like cabal, bud. These "associations" are comprised of competing companies, yet they seem to work together enough to get what they all want - especially from the companies who make the hardware that consumers need to get at thier wares.

        I said nothing about code either - just API specs that game deveolpers all agreed on and would develop to, then ram it down the throats of the OS developers. The $ in savings of basically coding a game once and then supporting that single code base will likely make them co-operate with each other until the spec is done.

        Soko
  • Instead of using Direct*, which forever ties your application to Microsoft's completely non-open and non-standard operating system, use SDL, or OpenGL, or OpenGL and SDL, or any other portable API.

    Notice how ID, the only gaming company around to actually follow this principle, can port their games to a zillion OSes very quickly and have it run extremely well on all OSes that they're ported to. The most expensive part of of doing Linux releases for ID is publishing...

    Tying yourself to a proprietary API makes anything you say about portability completely invalid...

    JMO

  • So there is absolutely no way to support any more than one client executable, because the clients and servers must be updated together in real time by downloading patches, just like Ultima Online and other games.

    So I guess what this all boils down to, is that Windows needs a Linux emu-- excuse me -- loader and API wrapper.

  • I'm also currently working on porting most of the Sims code as well as all of my Sims tools [simfreaks.com] to native versions for Linux and the Mac. The reason was fairly straight forward. Wine emulation can only go so far, requires a bit of a techie person to use and given the nature of most of the Sims users, it's beyond them. I know that's a blanket statement that will probably come back and bite me in the ass, but it's true.

    A native version is the way to go. I'm in the same boat as Don, although he's got more access to the code than I do. I generally go through him to get the code I need. When the issue of providing a Mac version came up because most of the utilities wouldn't work under VirtualPC, I looked toward some cross-platform library rather than emulating with Wine or whatever Transgamer is providing. I settled on wxWindows (between a choice of QT and wxWindows) just because of the licencising issues around QT (I'm not in a position to release any Sims code and bound by NDA to not).

    The big issue was the fact that The Sims was completely dependant on DirectX (even though they try to abstract it out in some of the wrapper libraries they have) so the first thing I did was to port all the graphics code to OpenGL. Don and I have been communicating as well and had some success with porting some of the lower level functionality of the game engine to use Python via SWIG wrappers.

    I think one of the key things here with any game development is that the commercial developers should look at writing portable code. Maybe they don't have to take the effort of writing the code for those other platforms (whatever they may be depending on what you call your base platform) but at least take the effort to provide those hooks with little effort. Don't tie yourself into a proprietary API and put the platform dependant features in the platform dependant code where it belongs, separate from the main code. But then that's just stating the obvious right?

    liB

  • I'm surprised no one's brought up Zork. This old slashdot article [slashdot.org] links to a great paper on infocom and zork. This was a time when there were many more home-computer platforms than there are today, and infocom found a way to easily port to any of them. The Z-machine was a virtual machine (unheard of on home computers back in the day!), and they only had to write one interpreter per architecture: instantly their library of a dozen games would be available on the new platform. Of course, the hardware requirements were simpler (i.e. text, no graphics), but for what it did, you would have never known it was interpreted. I think that eventually graphics will reach that point- we're just starting to get relatively cheap hardware ( O($1.0E2)) hardware that is getting closer to photorealistic and is today what text was then (relatively straightforward to implement decent useability). Any, check out the article, it's a great read.

BLISS is ignorance.

Working...