[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Anyone on this list?
Jan Ekholm wrote:
> On Mon, 28 Oct 2002, [ISO-8859-1] Gregor Mückl wrote:
>
>
>>Jan Ekholm wrote:
>>
>>>It would be nice to see some more traffic on this list, as the one other
>>>game-related list (opengl-gamedev) I know of is just about Windows games.
>>>
>>>
>>What should the extra traffic be about? Implementations, algorithms,
>>game theory or what else? Problem is that these topics may get very
>>project specific. And most projects keep those details to themselves,
>>anyway.
>>
>
> Ok, something I've been wondering about is where I could get data/info for
> my game about animating in 3D a running guy/girl with a rifle in his/her
> hands. I don't need something complex, just some frames of a wireframe
> animation. I'm no good at that stuff, so some list of coords that have
> been found to work would be ideal.
PLIB comes with a simple tool called 'ExPoser' that makes that kind of
thing a lot easier.
> Other thing: what do people use for simple multiplayer servers? Say, a few
> players on a local LAN. I planned on putting a central server in the
> middle, and routing all traffic through it. Is it worth adding the extra
> complexity that UDP drags in, or is TCP enough? Pretty frequent updates of
> small amounts of data (player position and some angles).
TCP is good for data that absolutely-positively must get there.
However, the protocol is complex and involves end-to-end handshaking
and so your ping times get large. However, if a packet doesn't make
it to the far end, your computer will eventually find out and retransmit
it. The computer at the far end will carefully keep the order of the
packets correct even if they arrive out of order due to retransmission.
UDP is lightweight and fast - but it's not error-proof - so your packet
might not get to the destination at all. Use UDP in cases where it
would be easier to send new data than to hassle with retransmitting the
data that got lost.
So, for telling the other computer where your player moved to - use UDP
for speed. If a packet gets lost - don't worry - the next position
update will fix that.
For telling the other computer that a bomb just exploded - use TCP
because you're only going to tell him that ONCE and the consequences of
the data not getting there are severe.
> Another thing: what can be said to be the minimum hardware a normal Linux
> user has? Can a 3D card be assumed? I don't have one.
Well, Linux users tend to be computer geeks - so their hardware tends to
be better than the general population.
What you can assume depends on your target audience. If you are aiming
at hard-core gamers - then you can assume they have 3D. If you are
writing edutainment for schools then you'd better assume a 33MHz 486
with a VGA card.
> Another thing: where can one find free/dirt cheap textures? I need a few
> nice bushes and trees, but all I can find is pics about an anonymous
> president. :) The best ones I've found so far have been from Combat
> Mission, but those of course not legal to distribute.
Look in other free 3D games. Go to HappyPenguin (www.happypenguin.org)
and click on 'Advanced Search' - set the search criteria to 'Supports 3D
Accellerator' and you'll find ~200 mostly OpenSourced games that you can
download and (generally) rip textures from.
Personally (although I GPL all my stuff), I'd prefer that people DIDN'T
rip artwork from my games because it has a tendancy to make all games
look the same. However, the principles of Openness trump my
preferences, so it's perfectly legal to take textures and 3D models out
of my games and use them elsewhere.
> Another thing: do people want to play games fullscreen or windowed? Must a
> game support fullscreen in order to be viable?
I don't think so - but it's pretty trivial to make a game work both ways
these days.
I strongly dislike games that *ONLY* work full-screen...but that's just me.
> Do we really have good audio hw support? Stuff like OpenAL is afaik
> software on Linux and hw on Windows. Why do most vendors eventually
> release (often) crippled and unsupported drivers that lack features that
> the Windows drivers have?
I don't know whether that's true or not. Doing audio in software is
no big deal on modern CPU's - I can't get excited about fancy audio
hardware.
> Well, I'm a serious gamer, but a PS2-gamer. :) Developing Linux games has
> its fun moments, and one of these days I'll actually get all needed things
> working so that I have something that works. But it's also a journey full
> of frustration, and those frustrations start (at the latest) when you have
> something that "works for me" and you want others to be able to test it
> and give some feedback.
Release-early, release-often.
If your game is any good at all (or even if it just shows some promise),
and providing you hand out source code, people will magically appear to
help out with those things.
> Does the GPL thingie prohibit me from charging for a game I create if I
> use normal Linux stuff like Linux, OpenGL, SDL, g++, python etc?
GPL says nothing about payment. You can charge for something that's
under GPL even if you didn't write it. However, you have to give away
the sources or you are in deep trouble - so people are unlikely to pay
for something that's under GPL unless you've done some nice packaging of
it or something like that. However, RedHat, SuSE, Mandrake et al are
making money selling GPL'ed code - so it's certainly possible.
If you intend to keep your game closed source then you must be careful
not to hard-link to anything thats under GPL. Remember that in using
GPL'ed code, you promised not to deny your end-users the right to the
sources to all the GPL'ed code you used.
If you actually incorporated chunks of GPL'ed code into your sources
or if you hard-linked to GPL'ed libraries then you must GPL your code
too - *AND* provide the sources whenever requested to do so.
> If that isn't possible (without giving out the source) then we already
> have a problem at that point.
It certainly is possible to sell software in binary form for Linux -
even using all the handy libraries that are out there. Just remember
that you promised to allow your end users to replace the GPL'ed parts
without your help in the future. If you link to (say) SDL - then
you must link to the ".so" libraries so that if one of your users wishes
to do so, they can edit the SDL sources and run your game against the
modified libraries.
The company I work for makes flight simulators using Linux PC's which we
sell (closed source) to the US military for millions and millions of
dollars. This is certainly possible.
> Why pay for shareware (or "full" commercial) if you can copy it for free.
Well, there are some (somewhat feeble IMHO) arguments from the GNU
people that suggest you could make money from service contracts
(unlikely) or that you could do things like sell the models, level
files, sounds, etc and give away the 'game engine' for free. That's how
ID software manage their business - the sources for their games are
typically opened up after a year or so of sales.
> Phew. Let's see if this list gets some life for a few mails now....
I don't approve of mailing lists having 'life' just for the sake of it.
If there isn't anything important to say - let's not say it.
---------------------------- Steve Baker -------------------------
HomeEmail: <sjbaker1@airmail.net> WorkEmail: <sjbaker@link.com>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net http://tuxaqfh.sf.net
http://tuxkart.sf.net http://prettypoly.sf.net