For those of you who are currently creating an online game, or are seriously considering getting into the field:

I am curious about what kind of development environment you are using or are evaluating, and what type of game you are developing (small project, large project, 2D, 3D, side scroller, puzzle, RPG, etc.) If you are already developing an online game, what kinds of issues have you been dealing with and what would you do differently on your next project?

I'm working on a tick based space strategy game for entertainment mainly...if that qualifies....its written as client/server if you mean along the lines of a bbg then I haven't played with that yet although I have several 2-3 page game concepts for some.

1) I would add a way to write a way to display completely custom error messages that can be sent through winsock and will automatically move the state back if it was a user error. (I will be doing this shortly with a shorthand for each game state and a message box text)

2) Start testing even before the project is 20% done...I've found people have the strangest errors in dealing with winsock.

3) Have the server automatically close the connection if it recieves strange data. I had someone write a program to try to give him 10000000 of each resource and it kept sending the same packet in an infinite loop.

I think thats about it so far...but I'm only about 25% done...so 65% more to go before I reach the other 90% that will be left.

I'm leading an online (team combat) RPG project at Morphecy Games and so far I think the main issues were:

GOOD
+developing a network game forces you to develop modularily (ie. you just don't use variables like playerLives - you have to all the time remember that there are N number of players in game)

+Our protocol is UDP - and it's very good (we first tried DirectPlay, then UDP, then TCP/IP and then again UDP :)

+Use some money to purchase stuff that has been earlier (we bought UDP library for $25 - and it's just amazing how much time it would have take us to develop that kind of library - that's why we chose the UDP)

TROUBLES
-Creating "game listing server" can be hard issue and might be expensive to keep up (but fortunately it seems that we just might get this by free, as the developer of our SDK is creating a free game listing server for use by all their customers, so this really can cut our expenses :)

-There must be dedicated servers or players won't ever buy our game (we haven't got this far yet but I'm afraid that we need to get our game so popular that people will play it a lot and attract other players as well - if not, this is something that can seriously damage our business)

I am curious about what kind of development environment you are using

C++, Winsock(UDP), DirectX8 (Sprite Interface), MySql for communication between webpage and server program (User data and stats).


what type of game you are developing (small project, large project, 2D, 3D, side scroller, puzzle, RPG, etc.)

2D gravity fighter type of game. I have no artist and the project may never get finished (DON'T SAY THAT!). I've been working on it for 2 years in my sparetime. Progress is slow. I'm in a lazy period right now.


If you are already developing an online game, what kinds of issues have you been dealing with and what would you do differently on your next project?

The biggest problem is that I'm not sure about the game design. I'm alone on this project and have no one to talk design with. So I just code blindfolded. Game Design is the hardest part of the game.
The biggest code issue so far has been the collision detection of the tiles. If the ship hit the corner (vertex/point) of a tile which side of the tile did it hit ?

Originally posted by boywonder
I'm leading an online (team combat) RPG project at Morphecy Games and so far I think the main issues were:

GOOD
+developing a network game forces you to develop modularily (ie. you just don't use variables like playerLives - you have to all the time remember that there are N number of players in game)

+Our protocol is UDP - and it's very good (we first tried DirectPlay, then UDP, then TCP/IP and then again UDP :)



Be careful with UDP because most DSL/Cable routers delete these packets. ( people won't be receiving/sending any data )
Provide a tcp/ip way too to be safe.


patrice.

Be careful with UDP because most DSL/Cable routers delete these packets. ( people won't be receiving/sending any data )
Provide a tcp/ip way too to be safe.
Heh, quite "harsh" comment. Actually - it's not that "most" routers "delete" them. It is that IF there is lots of traffic going on then TCP/IP just might be priorized higher and more packet loss occurs for UDP. But anyway, here's a short list of games which use UDP:

Battlezone I
BattleZone II
Dark Reign 2
Delta Force 2
F-16, Mig 29
F-22 Raptor
HalfLife
Sid Meier's Alpha Centauri
Soldier of Fortune
StarCraft
Tribes 2
Quake World
Quake II
Quake III
UnReal Tournament

references:
http://moat.nlanr.net/NATimes/NAT.2.1/gamesUDP.html
http://www.blitzbasic.com/bbs/posts.php?topic=19338

UDP definitely is the best choice for most games.

I'm working on a 3d space dogfighting game using torque (and a game pack which allows any torque licensee to create thier own space games easily)

Torque uses udp and a client server model.

Its reasonably easy because the networking is practically in-built to the engine design.

I'm not too concerned about the whole issue of keeping servers and such going.

.Z.

Here my router : Dlink DI-604 :

UDP paquets go through only in LAN , when playing over the internet UDP paquets are ignored ( erased ).

We could reproduce that on different routers.

patrice.

You are filtering outbound/inbound UDP packets. I believe this is turned off by default.

Originally posted by Nick Bischoff
You are filtering outbound/inbound UDP packets. I believe this is turned off by default.


Hoo ok, this is actually turned on by default the DI 604.

patrice.

@guys: this is going off-topic...

anyway - I just listed a quite famous games using UDP (hmm... forgot Everquest from the list... it uses both TCP/IP and UDP) and it's pretty sure that if there would be high risk for using UDP I think those big games wouldn't use it.

@patrox: definetely if your system ignores UDP then definetely it has very big troubles in general use of web (ICQ for example uses UDP) and definetely if you router ignores UDP packets it certainly isn't "most DSL/Cable routers" - at least my DSL router doesn't ignore those packets. But I must mention, good concern though. In some cases UDP can be problematic - but generally it doesn't matter (at least big online games use it successfully) and I'd like to continue this talk somewhere else :)

Originally posted by boywonder
@guys: this is going off-topic...

anyway - I just listed a quite famous games using UDP (hmm... forgot Everquest from the list... it uses both TCP/IP and UDP) and it's pretty sure that if there would be high risk for using UDP I think those big games wouldn't use it.

@patrox: definetely if your system ignores UDP then definetely it has very big troubles in general use of web (ICQ for example uses UDP) and definetely if you router ignores UDP packets it certainly isn't "most DSL/Cable routers" - at least my DSL router doesn't ignore those packets. But I must mention, good concern though. In some cases UDP can be problematic - but generally it doesn't matter (at least big online games use it successfully) and I'd like to continue this talk somewhere else :)

Every one of them has an option to use TCP/IP. And Starcraft's internet play is 100% TCP/IP.

Thanks for the replies. My reasons for asking this question are twofold:

1) For a brief moment or two I was thinking of adding an online element to the design of my current game project, but I have now decided against it. The addition of such an element would fundamentally alter the gameplay in a way that I do not like. I was interested in the various technical and logistical issues that you might have been dealing with.

2) I am close to moving forward on the development of a product to help developers with online game development, though the concept is more for projects that fall under a mix of the following categories: arcade, advergame, small to medium sized, puzzle games, strategy games, etc. Are any of you working on or planning this kind of game? If so, what have your expereiences been like?

+Use some money to purchase stuff that has been earlier (we bought UDP library for $25 - and it's just amazing how much time it would have take us to develop that kind of library - that's why we chose the UDP)

what's that wonderful udp library =) ? is it high level or only a library that has that packet-arrival-checking and other things TCP has and UDP has not (by default)?

@CoLSohl: my point here was: check others work before doing it al by yourself - that can be quite good for your business. but now as you ask, I don't know what "high level" means, but yes - it contains for example following things:
*reliable AND unreliable (which TCP/IP doesn't have by default) packet sending
*built-in ping and Ppcketloss tracking
*internal game time system
*automatic control for any-number of players (including checks for lagging out, joining, leaving, kicking etc.)
*Internally designed for client/server architecture, broadcast message support
*in-build functions for cubic splines

and many so other things - but main point again was not to compare TCP/IP and UDP, whatever you choose remember to check what others have done earlier.

Cubic splines in a network library? whatever next!

.Z.

Originally posted by CoLSoN
what's that wonderful udp library =) ? is it high level or only a library that has that packet-arrival-checking and other things TCP has and UDP has not (by default)?



i would recommend openPlay from apple, it works on mac/pc/linux it's great and it's free.


pat.

boywonder you didn't tell me what that 'wonderful library' :)
patrox i'll check openplay

by high level I mean if you have to work with socket wrappers or something like that, or you just work with classes like 'Client' or 'Server' and have methods like Server::KickClient(name) and so on.. direct play is higher level than winsock

Regarding udp vs tcp, there is a nice paper about it on gamasutra - http://www.gamasutra.com/features/19990903/lincroft_01.htm

In short:

UDP doesn't resend packets when error occurs (you need to check for that yourself and resend if needed)

UDP doesn't care about packets order (again, you need to implement it yourself)

Problem with TCP is that it resends a packet until it arrives.. and it waits each time before resending a packet which didn't arrive... this way if one packet has got problems with arriving you might not get any data transfer for seconds!

Regarding "compatibility", yes, some programs and hardware can cut-off UDP transfer, but for real-time games it's a must. Most games have got info that in case UDP transfer is not possible you should contact your Internet provider about it etc. (check manuals/faq pages)

You won't get far with TCP (You can test bzflag (www.bzflag.org or so) - it has got a possibility to turn UDP on/off... with UDP turned off (TCP) game lag is much larger and gets much worser with poor connection)

Hope it helps.

Originally posted by MirekCz
Problem with TCP is that it resends a packet until it arrives.. and it waits each time before resending a packet which didn't arrive... this way if one packet has got problems with arriving you might not get any data transfer for seconds!

And to elaborate on that point (I skimmed that article and didn't see this mentioned), there are cases where you might not need all the data, and TCP can be a major problem vs UDP. If your game server sends out a packet telling the client that someone has moved, but that packet doesn't make it through, and then 1 second later it sends a complete game state update to the client, and that packet DOES make it through, you are left in an awkward situation. You have the data for the complete update, but you don't have the data for the incremental update. The data in the incremental update is completely irrelevant at this point, as it's taken into account in the complete update. With UDP, you can choose to ignore the missing packet, but with TCP you are forced to sit around waiting for something you no longer need. Instead of getting one out of two useful packets, by the time you get both packets neither of them may be useful.

Don't get too caught up in the TCP vs UDP arguments. Pick one that seems right for your game, and go with it.

Despite what some zealots will say, the choice isn't clear-cut. There is no "one protocol fits all" solution. UDP won't make your game great. TCP won't make it suck.

Do your research so that:
1. You know what you need; and
2. You know which one will support what you need.

Will some games benefit from using UDP exclusively? Absolutely. Will some development teams spend so much time implementing a UDP-based communication system when their game would've worked perfectly well with TCP? You can bet money on it.

No one is giving out awards for choosing either protocol. And no one refuses to play a game because it doesn't use their favorite method of low-level Internet information interchange.

-David

My two cents is this,

if you have 30-1min+ period in between 'turns', since we all know real time games are broken down into turns or the rough equivalent use TCP.

if you need as close to 'real time' as possible to run something like an FPS use UDP.

In an RTS Starcraft/Brood Wars just put in the 45 second drop window which makes TCP work just fine as well as a better solution, imho anyway, than what the article mentioned. So if you implement this you really don't need to use UDP unless you feel it will help your game for whatever reason.

So like anything else in programming, you have two cults. Just like the Java and C++ cults...both work fine but people will argue about which is better in some cases to the end of time.