[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Rob Kaper wrote:
> > 1) With most OpenSource packages, the developers write it because they
> > want to *use* it. Nobody wants to play the game they just wrote
> > because they already know all it's little secrets and are heartily
> > sick of the sight of it by the time they are done.
> Not completely true for "classic" games that withstand the jaws of time. I
> want to play Monopoly under Linux with my friends and that's why I'm working
> hard on Atlantik (http://capsi.com/atlantik/) and I will still want to play
> it in two years.
Indeed - and that probably explains the tendancy for OpenSource games to
be things like Monopoly, also those things don't have such demanding artwork
needs as (say) Quake.
> > 2) A package like Python or Apache has dozens - if not hundreds of
> > contributors. Most games have to be written by a crew of between
> > one and three people with maybe a couple of occasional contributors.
> That is true for most open source projects, though. There are also
> countless utilities that have a single maintainer. And some games (FreeCiv
> for example) have built a decent developer base.
There are a few - but having a single author produce something like a quality
modern game is asking a *LOT*. A quarter million lines of code is a heck of
a lot for even quite a large team to put together...then consider artwork,
music, level design, playtesting...
> > 3) Artwork is by far the biggest job in producing a modern game. It has
> > proven almost impossible to attract artists to the concept of doing
> > work for nothing. There have been *long* dicussions about this all
> > over the place - the conclusions are always the same - there are
> > almost no OpenSource artists out there. Music and sound effects
> > present similar problems. Programmers *rarely* make good artists.
> > The artwork my son and I did for my Tux games is just pathetic
> > compared to even the worst commercial work.
> True. Tuxracer looks nice though.. but indeed nothing like commercial games.
TuxRacer *is* a commercial game. <sigh>
It looks good because they had commercial artists work on it - who eventually
needed to be paid and to have $30k-per-seat modelling tools.
> > 4) Games are short-lived phenomena. People play a game for a few weeks
> > or months at most - and then move on. It's rather depressing to
> > spend two years of your free time writing a big OpenSource game -
> > only to find that your fame lasts for a month and then nobody
> > downloads it anymore. Better by far to write a simple KDE utility in
> > just a few weeks an see your work appreciated, used and extended for
> > years to come.
> That's also why most "hardcore" Linux guru's can do without games, I
> suppose. I don't need a new Quake-alike game every 3 months. The classics
Right - I hardly play games on Linux at all - we have a Nintendo 64, a Playstation,
a GameBoy and a Game Cube (no X-box though!).
However, if Linux is to ever have more than a *tiny* percentage of people using
it then we need to attract hard core gamers. Some people argue that we don't
*want* a large market share - but without it, we'll have increasing problems
with issues like not being able to play DVD's, not being able to work with the
latest digital cameras...these are things I really care about.
> > * I try to come up with game concepts that don't need much artwork. That's
> > proved to be almost impossible. Games that don't have much artwork seem
> > to always look crap - that's not really a suprise I guess.
> I had some tricks to circumvent that. Of course my game looks like a KDE
> app, but the gameboard is pretty custom. However, I copied some of the GUI
> effects from kwin decoration themes which really looks nice.
> > * I try to build games that are somewhat like successful commercial titles,
> > without directly cloning them. This gives the game a better chance of
> > being liked.
> Likewise. Atlantik plays Monopoly-like games and the server includes the
> actual Monopoly game. I guess developing a proven concept (a "classic")
> makes most sense.
Yes - but 2D pictures of game boards hardly equates to the difficulties of
having people build fully immersive 3D worlds, fluid character animation,
context-sensitive music - which is what most modern games demand.
I'd *love* to do something like "The Sims" for Linux - but the sheer volume
of 3D modelling, animations, sounds, music...it scares the pants off me. I'd
happily tackle the coding though - that would be **fun** !
> Are you really sure that the game you are developing is your biggest itch?
> That's the key, it really is.
Well, some of the reason I got into this was to get my (then 8 yr old - now 11 yr)
son to divert some of his game *playing* energy into something more productive.
It seemed to me that building a game would do that - and it's worked out very
well. He's learned math skills that are 5 years ahead of what he's being taught
in so-called 'Gifted & Talented' math classes at school - he knows how to drive a
man's text editor ('vi' :-), how to record audio, how to do basic 3D modelling,
write simple C code...it's been good. Father/Son bonding - that kind of thing.
Also, my job is 3D rendering for flight simulation and I need to keep my skills
abreast with the latest rendering techniques - and that means games.
It's fun too - but I might well have written other things than games if I'd
had a completely free choice of OpenSource project.
> > It's very depressing - but we *NEED* commercial games for Linux.
> Well, we need commercial-quality games. Unfortunately at the moment that
> means actual commercial games.
Yes - exactly.
> Hopefully the open source development
> movement continues to grow and start attracting artists in the future. We
> lack the resources now, but in theory we could do it - under the right
That's the key - artists - but then we've been down that discussion path
1e6 times already.
----------------------------- Steve Baker -------------------------------
Mail : <email@example.com> WorkMail: <firstname.lastname@example.org>
URLs : http://www.sjbaker.org
http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net