Some ideas for homebrew network gaming..

[Oobles]

I've been getting some ideas for some network gaming concepts together. Before I embark on the hard work of coding it, I'd be interested in some feedback regarding features, etc.

As some of the people that read these forums will be aware, I've spent some time working on some new networking methods. The hard core library writing is basically complete( in C, Java and C#). It's now time to find some ways of applying the code to the real world. The aim is to get some feedback from real developers and show that the methods I've developed are actually useful. I won't go into the details here, however, you can read more about them by reading the Argot White Paper(pdf).

The basic idea is a network gaming library which will be backed up by a server that allows games to connect and communicate easily. I've got a basic set of features in mind. I'm sharing them here, hoping that people wanting to write networked games will throw their 2c worth in.

Features:

* User will be able to log-on to the server from inside a game or possibly a shell application. The PSP would keep a config of a userid/password for the user.

* User will be able to navigate through various lists of areas and groups to find other people wanting to play the same game. Given that typing messages will be too slow, it might require some different user states to show that a user is ready to play.

* When user(s) are ready they can jump to game mode. A game will be created and players can choose to join the selected game.

* In game mode the game will get control of data sent between players. The library will provide both a single shot message(UDP), and a connected stream(TCP) to communicate with players in the game. This is where the Argot library should come in useful.

* Currently the idea is that all communications will go through the server.

That is the really basic set of features that will be supported. I'd like to make the library available to LUA and make it as easy as possible to get a networked game running.

I'll spend a bit of time working out a basic API and post that back soon. Any comments appreciated,
David. aka Oobles.

[weak]

nice idea, so here are some things that came to my mind

*) game browser

a (customizable) list of installed games with the ability to join games and maybe a waiting room to find players.
a list of all supported games with an integrated download function. games available for download should have some statistics like number of downloads, games played through the server, rating...

*) user browser

a list of buddies with instant messaging functions and showing if someone is playing and what he is playing

*) online scores

games should be able to send hi-scores to the server and the server should keep a list.

[chp]

Just a couple of comments...

• If you look at how online gaming works today, almost noone uses TCP for persistent communication. This is mostly because of the high risk of latencies introduced by the TCP protocol, since if a packet fails to transmit you will hit a brick wall as that packet is being re-transmitted, and it's nothing that your application can do about it. Unless you're using turnbased gameplay, it's not realistic to use with the latencies introduced, especially if you intend it to be playable on a global scale.
  
  A better approach is to use UDP as the transport protocol, and track your states on both client and server. This way you can keep your latencies under control since you do the replication yourself instead of relying on that TCP will deliver all data down to the client. Tracking whatever states that have been broadcast down to the client also allows you to manage bandwidth in more efficiently since you can decide which states that should be ghosted to the client and cut off when you hit a transfer-limit.
• Also, a good way of simulating a bad connection will be a godsend when you have to debug your application, and putting this in the connection layer will allow anyone who's developing their game to use this functionality. Dropping packets and introducing latencies will allow you to test your application in a real-world scenario.

[LuMo]

o) is this supposed for LAN? (ppl stick together with a server on a pc.)
o) could be also used by LAN -> internet -> LAN
where every LAN has its own communicating Server.

lumo

[Oobles]

I've been doing some interesting reading into P2P networking and dealing with firewalls. I'm still not sure exactly what type of system I'll build. If anyone has some other links to documents, I'm interested in..

a) P2P Network Routing.

P2P Network routing is an interesting problem. How do you manage the insertion and removal of new nodes in the P2P network. After you've inserted the node into the network, how do you ensure the quickest path to the destination without having the address of all members on the network.

b) Using UDP/TCP to peers behind firewalls.

I've found this very good article on UDP Hole Punching ( http://www.brynosaurus.com/pub/net/p2pnat/ ). However it also shows that this technique will not always work. The network requires a backup method to ensure data can be delivered to clients. This would require relay servers.

To answer some of the comments..

Weak, I've been working on a game browser concept already. I originally did this on the PS2 with software called Send0r. The PSP version should be more interesting and leave room for the game browser functions and IM style functions.

chp, I've been looking at UDP as noted above. It does come with some issues if you want P2P communications. If you've got any other additional links to information on this issue, can you post them.

LuMo, Initially the idea is for a P2P internet network with a central server. In theory it would allow for localised servers, however, I haven't got that far yet.


I might drop the P2P networking concept in favour of a single relay server to start with. That will give atleast something to start with. Other features can be added to the network a bit later as needed.

David. aka Oobles.

[LuMo]

i could support you with code for a very basic firewall implementation
with ruleset

greets
lumo

[weak]

P2P:

well, p2p sounds like a nice idea for file distribution, but i don't think it would work out very well.

pepople won't be able to play with p2p enabled 'cause there ping will most likely get far too high. that means p2p would have to be disabled while people are playing, making it almost impossible to handle the whole thing.
you'd be causing a lot of server load, mostly handling p2p nodes that drop in and out constantly.

i think a relay to a http location to download files is enough. i'd even make the content creators responsible to host the files.

UDP behind FIREWALLS:

why would you care about that? if someone wants to host a game server he's responsible for his network configuration. and nat shouldn't be an issue for clients.

[reakt]

b) Using UDP/TCP to peers behind firewalls.

I've found this very good article on UDP Hole Punching ( http://www.brynosaurus.com/pub/net/p2pnat/ ). However it also shows that this technique will not always work. The network requires a backup method to ensure data can be delivered to clients. This would require relay servers.

Can those of us behind firewalls not just make use of simple port forwarding?
e.g. as explained here: http://www.u.arizona.edu/~trw/games/nat.htm

Great idea this. I'd be very interested to have a look at the API when it's ready.