[Kde-games-devel] The Future of Game Development in KDE

[Dan Leinir Turthra Jensen]

On Wednesday 09 September 2009 13:59:35 you wrote:
> On Wed, 9 Sep 2009 6:31:34 am Dan Leinir Turthra Jensen wrote:
> > Right. It's that time where i tell you all what i've been pondering on
> > for a while now, so here goes:
> >
> > http://amarok.kde.org/blog/archives/1098-The-Future-of-Game-Development-i
> >n- KDE.html
> >
> > The writeup really says it all, so, go go go! :)
> 
> Sorry, but that link does not tell me very much at all about Gluon ... :-(
> 
> Also, I would challenge some of your basic assumptions.
> 
> Firstly, there *is* stuff around in Linux.  Pyglet www.pyglet.org is a
> Python-based, cross-platform game-development system.  At a talk
> given by its authors, I saw them develop a Space-Invaders-like game with
> music, sounds and animation during the hour they were speaking.
>
> Pyglet kills two birds with one stone by linking direct to binary libraries
> that are commonly used for sound, graphics, etc. on whatever platform it
> is on.  Thus it becomes cross-platform without having to take along a
> whole slew of libraries and it cuts out a lot of interpretive overhead.
> 
> Then there is a 3D game-engine/composer in Blender that seems
> quite sophisticated and has had a lot of recent work done on it.  I am just
> now reading a book (with examples) about it.

  You have, like a good few of the other repliers, misunderstood my 
intentions: Pyglet, while being a nice API, fails utterly at being nice to 
people who are scared of text editors. Blender has the same sort of problem - 
you are saying how you're reading a book about it and that it's really 
sophisticated. Yes, this is true, but it is also anything but intuitive, and 
seemingly deliberately so - very effective, certainly, but not exactly the 
easiest thing to just dive into and use. Unity3D, on the other hand, has a 
basic concept which is so straight forward that you can show it to a graphics 
artist and have them use it on their own hand within minutes (yes, i speak 
from experience).

> Secondly, as the maintainer of three KDE Games, I don't find the
> integration of sound and graphics into a game to be much of a
> problem, compared to writing the game engine, for example.
> 
> With graphics KDE Games has a good scheme for themeing in
> SVG worked out and libkdegames support for it.  Recently, two of
> the artists re-themed many of our games with Egyptian themes,
> for the KDE 4.3 release.  AFAIK there were not too many code
> changes required.
> 
> I recently did have to re-integrate the sounds in one of my games ---
> not because the sounds had changed, but because I had re-written
> the game-engine.  It only took about half a day to plug them in.

  Again, you are a coder - for coders the tools are more or less there 
already. What i'm talking about is the complete ecosystem, a toolchain which 
supports the entire team of people. Even when you say "there were not too many 
code changes required" it still means that there was coding required - again 
i'm pulling forward Unity3D here. When we worked on Puzzletive Garden at 
DADIU, the graphics artists could simply change the graphics around as they 
wanted, without having to bother the (always busy) programmers. The result was 
pretty clear: In stead of two teams completing the game project in that month, 
like had happened previous productions, all six teams completed their games. 
So, what i'm suggesting is not that the current solution does not work - it 
surely does, the amazing games in KDE 4 shows that already. What i'm saying is 
simply that we can do better for ourselves, and that in doing so we're likely 
to end up making it fun for others as well :)

> The hard part, in some games, is finding underlying KDE/Qt
> graphics and sound libraries that can perform well enough to keep
> up with the action.  For example, QGraphicsView has not been
> fast enough in some situations and I spent much *more* than half
> a day experimenting with Phonon to get it to play my sounds well.

  Which is why Gluon's composed of KGL (an OpenGL wrapper), KAL (a sound 
system, based on OpenAL - overkill for desktop applications, but basically 
specifically created for use in games) and on KCL (the control layer, 
abstracting away the annoying problems in input between the different 
platforms), as well as giving a bunch of convenience systems, such as a simple 
game loop. Think removal of boiler-plate code here.

> Which brings me to my third point ...  Having survived at the bleeding
> edge of our industry for many years, I have a well-developed sense
> of hype and your blog at amarok.kde.org set all my antennae jangling.

  Yes, i am using the hype-tastic powers of Amarok's reach to push this one 
out there, and it is not something i am entirely happy about having to do. 
Very simply the problem is this: We have exactly a month until the sprint is 
due to happen. If we don't get it happening before then, we may have a problem 
(and it's really something i'd like to see happening).

> No surprise then when I linked to http://gluon.tuxfamily.org/
> and found very little.  Clicking on the Documents tab, I found just
> good old "Lorem ipsum dolor" boilerplate.  Does Gluon have any
> substance?  What does it actually do?  Why should I believe it is
> "The Future of Game Development in KDE"?

  That is entirely correct, but the developers have decided to work hard on 
the libraries rather than build a website for it - but i would agree that not 
having a link on the website to the Gitorious project page is likely a bad 
idea. One slightly larger problem, however, is that our main guy is French, 
and as such writes documentation in, yes, French ;) So... 
http://gluon.tuxfamily.org/wiki/index.php?title=Main_Page_Fr is where the info 
can be found, until it gets translated (which i'm assured they will be later 
today) :)

> The logos are nice and the oblique references to quarks and color
> charge are fun, but not all that glitters is gold.

  But... they're all glittery and shiny and pretty! They're almost like 
looking into a particle accelerator! ;)

-- 
..Dan // Leinir..
http://leinir.dk/

                          Co-
                            existence
                          or no
                            existence

                          - Piet Hein