Posted: 28th Jan 2005 08:54
Hi DysonB,
A web-deployed game as you describe isn't feasible in DBPro for many reasons, and you're right about the DBP multiplayer demos you found -- they're definitely geared toward everyone having at minimum an .EXE as a client. Some network-enabled games will allow a client to also act as the 'server' or 'host', and some allow you to use a separate machine for that role so you don't bog down your client doing double-duty.
If you're gaming on a network you want data transfers to be short and sweet -- as much information as possible exchanged using the fewest bytes possible. This involves more than the obvious stuff, such as exchanging positions of objects in the game (tanks, mines, missiles, etc.)... it goes right down to the protocol you use to transfer the data. For example, TCP/IP guarantees delivery of the network packets in the order they were sent, but has considerable overhead when compared to UDP, a "datagram" protocol also built over IP where if packets get lost or rearranged in transit... oh well. Internet games will often use UDP and build in protection or optimization for those problems.
If you were thinking of plunking down your .EXE on a server someplace and letting everybody "just run it" from their client, remember what actually happens when you run a program on a PC -- it gets loaded into memory on *your* computer. So if you've got a 10MB .EXE file on a server and 6 people "run" it, you're going to have 60MB of data MIMIMUM going out over the internet to the clients. From there, everyone is running the program on their own system in their own address space -- as memory (physical and virtual) is changed, it's only changed on their system, and doesn't reflect what's going on with other copies of the game.
I've oversimplified some stuff above and much of it you probably already knew anyway... but, point is, try as you might, if you put an .EXE on a network for people to run, they're going to be "downloading" your program one way or another. Since DBPro executables are statically linked, you at least avoid any annoying installation programs, registry mods, etc., for people who download your game (they've just got to have the correct DirectX version).
Back in the old days of game design, before the internet (gasp!), we wrote multiplayer games where all clients executed as processes on a single (mainframe) computer and talked to each other through shared memory and semaphores that synchronized the updates. Even then, most of the game executable was still loaded into private memory space by each player. It was easier to share the game info that needed to be shared, though. What was sorely lacking were nice graphics and the ability to play people really far away.
Really what you're left with now isn't that bad of a situation -- get all the system-intensive stuff like graphics pushed out to your game "client" and then have fun devising the best "shared memory" mechanism you can come up with using the network. IMHO, DBPro and DirectX have cut so much development time off the 3D programming end of gaming that there's plenty of time to handle the somewhat trickier job of sharing the game data correctly over the network.
