At 10:26 PM -0400 4/24/05, Robert Steely wrote:
I just want to use RB to develop a *simple* FPS that can be played
over the internet and won't require a 3 thousand dollar, dual 2.5
GHz G5 PowerMac with 2 GB of RAM and a top-of-the-line graphics card
just to get minimal frame rates. And it's got to run on all
RB-supported platforms.
Users or no users, I'll do it because I want to learn about network
communications (UDP in particular), I'm interested in 3D graphics,
and I love to program in RB. :)
OK then! Let's roll up our sleeves and get started! (And by "we" of
course I mostly mean "you"... ;)
I would suggest you start by selecting a genre (in the traditional
sense, i.e. a subject matter and tone). No need to make yet another
Quake clone (especially since Cube, which Frank pointed out, seems to
be doing a super job of that already). Also, you won't have an army
of artists working for you, which makes it very hard to do things
that involve animated people.
So, consider basing it on vehicles -- perhaps even very simple
vehicles with no moving parts, like spaceships. You could perhaps
dust off Offworld and reincarnate it as a network space combat game,
for example.
Another game I heard about, years ago, involved flying cubes around
in some sort of abstract space. Sounds silly, but the people I spoke
to said it was a lot of fun -- all in how well it's done, I suppose.
If flying in 3D isn't your cup of tea, then how about pinning the
vehicles to a floor, and making a tank game, like old Battlezone or
Spectra (?) of yore? You could do better graphics today, but the
basic idea of outfitting your tank, then doing battle in an arena
with a bunch of teammates and opponents, is always a winner. Tanks
are very easy to model, and there's no reason the obstacles in the
arena couldn't be cubes, pyramids, and other easily-modeled shapes.
Speaking of tanks, who remembers Bolo? That was a classic
multiplayer tank game in the early Mac days. A neat feature of that
game was that you can have a significant impact on your environment:
you could blast holes in walls, make craters (which would fill with
water, if near a water source), lay mines, and so on. So there was
often quite a bit of strategy, laying traps for your enemies and so
on.
Anywho, I'd say start with that: pick what you want your game to look
like, and ask yourself where/how you're going to get all the art
assets you need... once you have a good answer to that, the rest is a
simple matter of programming.
- TCP sockets or UDP sockets for communications? Or maybe a
combination of the two.
Mostly UDP for a game like this, I would think.
- If I use UDP, is multicast safe? I'm concerned with packets being
dropped by routers that don't handle multicast UDP. Does that happen
a lot?
I think so, and I don't think you need multicast anyway. It'll be
point-to-point communications. And packets will be dropped anyway --
your code must be prepared for it.
- Separate server and client applications or combine both together.
That's a good question. I can see pros and cons on both sides. The
best thing about having a dedicated server is that anyone who
launches the game can discover any other players who are playing.
The drawback, of course, is that it requires the central server to be
up and running indefinitely. Peer-to-peer games don't need that, but
players still need some way to find each other.
- Datagram composition: i.e. time-stamping, error correction, what
types of data to send when, how often, via what means, etc.?
Right, those are key issues as far as the networking goes. I think
the basic ideas are:
- Each "update" packet contains a timestamp and status info for all
the units (or at least, all the units the player can see). Ignore
any update that's older than one you already had.
- From these, you compute where each object should be *now* (where
now must be sometime after the timestamp -- of course you have your
game clocks all synchronized somehow!).
- If the computed position is different from the current position,
you have more tough choices. If you just jump it there, players will
notice and the animation will seem jumpy. Better might be to reduce
the difference between ideal and current position gradually, but
fairly rapidly, say over the next 0.25 sec, so it doesn't jump. But
this will sometimes mean inconsistencies, like objects appearing to
pass right through a wall or bullet or whatever.
Also, be sure to compress these data packets as much as you can --
the network is by far the most serious bottleneck in a game like
this, and reducing the amount of data you're shoving around will help
a lot.
Keep us posted on your progress, ask lots of questions, and release
early and often -- I look forward to seeing your game!
Best,
- Joe
--
,------------------------------------------------------------------.
| Joseph J. Strout REAL Software, Inc. |
| joe at realsoftware dot com http://www.realsoftware.com |
`------------------------------------------------------------------'
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
|