Irrlicht Engine

Hey, Long time since I posted something ...

Well, my question is coming from my engine's requirements analysis where I'm not sure if it should be supporting networking or not.
As I have almost no experience with networking programming and the online games I play have dealt with the problems quite well, it wouldn't be such an easy task I presume to list the main problems I could face if I'll be going this way.

So, as there are probably more experienced guys out there in this subject, I ask for your opinion in the problems I could face when developing a networking game (engine)?
A - Programming-wise.
B - Functionality-wise (I'm not sure if this is the right word so I'll explain; Lags, timing issues - problems like that).
C - ? Something I didn't think of..

Thanks!

With my very little experience you need to know what protocols will you use, if you use a server to save user or something, obviously if your engine support it, the refresh rate (taking care to not fullfill the bandwith), if you will use a secure conection, how many bit your protocol can loose in transfer, those are some things that come to my mind maby later i can give you more things to think about

Hello MasterGod,

First of I would like to say like many areas of programming for video games. Network programming can very tricky. I would say it comes down what you want your engine to support. Simple client/server and P2P connections wouldn't be to hard catch up on if you have a good knowledge of C++. If you plan on supporting MMO's then it would require years of network programming experience.

From what I hear Microsoft makes it fairly simple to use sockets in VS.NET.

I had a pretty easy idea to do a network but I havent gotten around to attempting it. If you are a newbie and are making your own client/ server set up I would try to do something where the information from the client is saved as a text file and then sent to the server where it reads it. Thats really simple but probably not what you want for the long run.

Putting your game on a network is hard. If you make it so all the clients just send info to the server than it makes it a tad easier but if you are doing an MMO, information must be processed on the server to prevent people from messing with the client and cheating etc. You need to understand the concept of resonance time and lag, and set up a system to allow for this lag of input from the client to reach the server and still seem like its instaneous. Then you will need to set up an authority concept for the server to make the decision if it should trust the input or not. The problem with resonance times is that 2 different players could do something in the game that contradict each other before the information is sent to the server so the server needs to counteract this contradiction to balance the game for everyone playing. Bottom line... its complicated. My best advice is to keep it simple and see what you end up with .

When dealing with networked real time applications, there are a few things to bear in mind while coding..

1. keep the packets as small as possible and to the bare minimum size
using bitmapped flags where feasible and the minimum size for any
values

2. create/maintain the packets in memory totally

3. have the server send a return packet to the client that initiated a
change FIRST. this helps gameplay "feel" instant for the players

4. have the clients perform as much of the math as possible to reduce
server loading

5. point to point using sockets is the way to go in windows

The hardest part for me so far isn't the transport of the data but the architecture of client/server itself. Usually you have for each class 2 versions - one on the client and one on the server. Those classes are usually similar but not identical. Then you have also the data which is send for each class (message data). That message data must be known by classes on both sides and is also often similar but not identical to the data within the client and server classes.

Think a lot about how and by whom those messages are created, send&received and handled. Also think about how you ensure that objects on client&server are created, updated and removed together. (Hint: Server always makes the important decisions and each object has a unique ID which is similar on client and server).
Also think about error-handling for each of those steps (Hint: You will need logging - the more the better).

Then there might be some difference between the sort of messages you have for typical in-game data (like position and rotation updates) and the administration data (join/leave, chat, maybe even level data like textures).

And it certainly depends a lot on what you need. If you can avoid needing realtime in your first network project, then it will get a lot easier. Other stuff to think about is if you need multiple channels or just one (if you want to send files in the background you need multiple channels, otherwise you will probably only need one).

There are also a bunch of network specific problems, but some libraries will already solve many of those for you. For example one problem (which I haven't solved yet myself) is that computers behind routers might cause trouble when they try acting as server.

I'm currently learning a lot about the problems in network programming myself. I had already worked on some network games, but never had to do all parts before on my own. It's tricky, but also very interesting :-)

Thank you all for your responses. It seems I have a lot to think of.
Cool.

Thanks again and have a nice day .