ubuntu-gaming team mailing list archive

[Olaf Piesche <opiesche@xxxxxxxxx>]

In reply to Przemek's post:

>Linux must have a unified gaming platform, otherwise it will never be a
viable
>choice for gaming developers.

I disagree, to an extent. If you look at the commercial industry, we have a
large variety of APIs, frameworks and different middlewares. Just for 3D
rendering, on the 360 we have DirectX, on the PS3 we have LibGCM or PSGL, on
the Wii we've got yet another API reminiscent of OpenGL, the DS is again
different, and don't even get me started on the PSP. Direct3D is *only
unified between the X360 and Windows, which are only one comparatively small
valley of the entire landscape; *I do agree, that this has helped the
Microsoft platforms tremendously in the past, but that's not necessarily the
case anymore*.* That's one reason why higher level abstractions (read:
engines) exist on top of the particular hardware's restrictions and APIs.
Even on only one particular platform, there's a jungle of choices. There are
tons of different audio libraries, for physics you've got the choice between
Havok, Ageia, Bullet, or a dozen or so smaller libraries, I can't even count
how many products for animation are out there, and then there's AI and
pathfinding, video playback, and so on.

As far as full fledged game engines are concerned, again, there's a sea of
choices - yet still, many studios decide to write their own engines. The
reasons for that are sometimes different (Unreal Engine costing >$800k would
be a good one), but the landscape itself is very much the same: rugged
terrain with lots of rocks and slightly different looking trees to climb.
In many cases, the reasons are actually the same - the engine choices out
there don't satisfy the needs of a particular project. Unreal was considered
too slow to be a viable choice on several projects I've seen, CryEngine not
sophisticated enough in terms of its gameplay and AI possibilities, etc. pp.
Sometimes, changing an existing engine to fit a project's need would
actually take longer and be more complicated than just writing it from
scratch.
The big difference is, that most studios that build an engine do so for many
years and many projects to come, something that's not necessarily true for
FOSS projects.
Don't get me wrong, there definitely is such a thing as 'not invented here
syndrome' for the sole reason that it wasn't invented here. Many times, it
is for good reason, though, and it isn't decidedly an indicator for the
viability of a platform. We won't be able to unify FOSS development under
one or two engines - and maybe that's not such a bad thing afterall.


2009/6/16 Matt Raykowski <matt.raykowski@xxxxxxxxx>

> I think I tend to agree with Przemek on this. But again there are pieces
> that fill this puzzle. One of my core gripes when I got into open source
> game development was the lack of a cohesive system. DirectX encompasses
> everything - 2D, 3D, sound, etc. In open-source you have to cobble together
> a bunch of low-level libraries which leads to engine development and not
> game development.
>
> But there are also good, solid engines like NeL, OGRE, Irrlicht,
> CrystalSpace and Nebula Device which do the hard work of abstracting the
> low-level work into higher level APIs. I think it is advantageous that
> projects start looking at engines rather than reinventing the wheel (NIH
> Syndrome affects far too many FOSS projects.) It's great that these lowlevel
> libraries are out there for people who genuinely want the challenge of
> writing an engine - however as a game developer I'd rather be focusing on
> that.
>
> In addition to that these low-level frameworks provide no inherent content
> pipeline. You're on your own to either write one (aka a plugin to a modeler
> that writes to your own format) or put together a mismash of model formats
> (e.g. Cal3D, lib3ds.) I guess this is why I suggest that would-be engine
> developers embrace an engine and update and extend it.
>
> If we fall down the path of "lets create a DirectX for Linux" your version
> won't be good enough for me. So I'll start my own which won't meet someone
> else's specific needs. Then you have a higher-level version of the SDK hell
> that we experience with low-level libraries (see also "Welcome To Jungle".)
>
> I see this a lot in FOSS projects. For example there are a number of
> GPL-compatible scripting engines out there. You can embed Python, there's
> Lua, AngelScript and some people have even embedded Ruby. There's also
> SpiderMonkey. But when you say to yourself, "self, SpiderMonkey has this one
> annoying quirk. Self, we should write our own scripting engine and language
> that meets out specific needs." You end up writing a scripting engine and
> all development ceases on the rest of your game. Not coincidentally the
> server in this anecdote is no longer developed.
>
> I see this same thing occur at an engine level. Someone comes to the NeL
> projects and attempts to use it, starts to get a grasp on it and then comes
> back and says "your shader framework sucks" and they decide to go write
> their own alternative to NeL - not look into one of its competitors, but
> write their own engine. Not surprisingly none of these projects have
> succeeded, this is not a trivial task.
>
> Maybe I've gone over the edge into "rant" territory but I don't understand
> the incessant need for projects to reinvent the wheel. I don't understand
> how people come to the conclusion that helping fix the deficiencies in an
> existing project is somehow more work than starting from scratch. Isn't this
> the whole mantra, modus operandi and goal of open-source? Collaborating on
> projects to better them rather than striking out on our own?
>
> Here's some links. I'll be done for now.
>
> NeL
> http://dev.ryzom.com/projects/nel
>
> OGRE 3D
> http://www.ogre3d.org/
>
> Crystal Space:
> http://www.crystalspace3d.org/main/Main_Page
>
> Irrlicht
> http://irrlicht.sourceforge.net/
>
> Welcome To The Jungle
> http://blogs.adobe.com/penguin.swf/2007/05/welcome_to_the_jungle.html
>
> On Mon, Jun 15, 2009 at 11:17 AM, Przemek Kulczycki <
> przemekkulczycki@xxxxxxxxx> wrote:
>
>> On 5/12/09, Arc Riley <arcriley@xxxxxxxxxx> wrote:
>> > On Tue, May 12, 2009 at 5:43 PM, J Sloan <joe@xxxxxxxxxx> wrote:
>> >
>> >> Don't we already have something like that? SDL, anybody?
>> >>
>> >
>> > some low level window/input frameworks used in free software games:
>> >
>> > GLX (roughly equiv to WGL)
>> > freeGLUT (free replacement for GL Utility Toolkit)
>> > FLTK (C++ user interface toolkit for X and OpenGL)
>> > SDL (Simple DirectMedia Layer)
>> > GDK (GTK's window/input layer - small, efficient, and cross-platform)
>> > GTKGLArea (GTK extension to include a GL drawing area inside a GTK
>> window)
>>
>> Last time I checked SDL was nowhere as complete as DirectX. Correct me
>> if I'm wrong.
>> Game developers don't want to track 600 different frameworks for
>> creating games for Linux. (OpenGL, OpenAL, SDL, ...). Linux must have
>> a unified gaming platform, otherwise it will never be a viable choice
>> for gaming developers.
>>
>> Also I'd like you to read the following essay:
>> Playing the Open Source Game
>> By Shawn Hargreaves, July 1999
>> http://www.talula.demon.co.uk/games.html
>> --
>> ## Przemysław Kulczycki >><< Azrael Nightwalker ##
>> # jabber: azrael[na]jabster.pl | tlen: azrael29a #
>> ### www: http://reksio.ftj.agh.edu.pl/~azrael/<http://reksio.ftj.agh.edu.pl/%7Eazrael/>###
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~ubuntu-gaming<https://launchpad.net/%7Eubuntu-gaming>
>> Post to     : ubuntu-gaming@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~ubuntu-gaming<https://launchpad.net/%7Eubuntu-gaming>
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>
> --
> Matt Raykowski
> /s
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ubuntu-gaming<https://launchpad.net/%7Eubuntu-gaming>
> Post to     : ubuntu-gaming@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-gaming<https://launchpad.net/%7Eubuntu-gaming>
> More help   : https://help.launchpad.net/ListHelp
>
>