hey all,
just some thoughts and questions on object oriented programming for irrlicht.
im about to start setting up my engine stuff, and going to use structs for things like the players and etc...
i did a lot of OOP in javascript, so here is pseudocode for what im thinking about....
player[x];
player[x].Name
player[x].Health
player[x].Ammo
player[x].Weapon
etc.... etc....
What i was thinking about is that this looks so much like database stuff it aint even funny.
Do you think an effective way for my game to run would be for the server to store each players information in a database, then i could just access every player's info via a for loop or something?
oop?....db's?....
At the end of the day, a database is just a way of storing such data as this. I'm not sure I totally understand what you are suggesting to do, are you saying you want to store the data in a database file format, parse that to Irrlicht and use it to fill in your data? No reason why not, it's just another way of storing the data and if that's an efficent way for you to do it then go ahead. You'd have to write/get the parser from somewhere however.
Technically speaking, all client-server apps work that way, and that includes the big game engines such as the Unreal engine, Quake engine etc.
They might not use relational databases by the way, and whatever organisation they use has to be highly optimised so as much as possible is accessed from RAM.
Transactions are not necessary, as long as objects are only owned by the server or by one client at a time.
Also, the clients will need to process their own game states. There's just too much latency if you replicate every player move to the server, process all the game logic on the server, and then send the results back to the client.
It's doable that way on a LAN, but not on the Internet.
Typically, the client performs and caches the player moves locally, then corrects the player position and reapplies the cached moves if the server disagrees with the client's results.
They might not use relational databases by the way, and whatever organisation they use has to be highly optimised so as much as possible is accessed from RAM.
Transactions are not necessary, as long as objects are only owned by the server or by one client at a time.
Also, the clients will need to process their own game states. There's just too much latency if you replicate every player move to the server, process all the game logic on the server, and then send the results back to the client.
It's doable that way on a LAN, but not on the Internet.
Typically, the client performs and caches the player moves locally, then corrects the player position and reapplies the cached moves if the server disagrees with the client's results.
-
Guest
Based on stuff that used to be publicly accessible (but I'm not sure it is now) about the Unreal Engine, as well as having had to deal with it when coding for AirfightUT:
1. Clients and server replicate member variables initially, and after that only when they change. These changes are combined into network packages so you don't such an enormous overhead.
All these packages contain a timestamp - it is essential that the game time on the server and on the client are in sync, or you'll get continuous corrections, as you'll see.
2. Client controlling a specific player buffers, performs and sends moves to the server after every frame. Moves aren't that big by the way - just velocity/acceleration/rotation/fire buttons and the timestamp. Note that this is actually done in the UnrealScript code. The moves are stored in a replicated array, and that means they're automatically sent to the server when they are updated.
(The player code also compresses moves so the buffer can be smaller but that's beside the point)
Client location and client rotation are also sent to the server with the same timestamp.
3. The Unrealscript on the server applies the latest buffered move and compares it with the compares the client location etc with the actual location, and if the difference gets too big, the server sends a command to the client to correct things like location, rotation, velocity, acceleration.
4. When the client gets the correction, it looks at the timestamp, and forgets all the moves that were performed before that timestamp. Then the server's location and rotation are copied to the client's variables and the moves from after that timestamp are re-applied.
The client experiences no apparent lag (i.e. the client does not have to wait for the server to update his position), but there will be jumps in the player position.
There's a trade-off here: lots of small jumps (maybe too small to notice) or fewer big jumps.
Since every correction uses the same bandwidth, the UnrealScript code makes the size of the allowed error dependent on the bandwidth of the connection - on a LAN the allowed error is smaller than on dial-up.
Note that all of this does not mention a database at all - but I've thought berkelydb might be usable for a game server - although I haven't had a serious look at it.
1. Clients and server replicate member variables initially, and after that only when they change. These changes are combined into network packages so you don't such an enormous overhead.
All these packages contain a timestamp - it is essential that the game time on the server and on the client are in sync, or you'll get continuous corrections, as you'll see.
2. Client controlling a specific player buffers, performs and sends moves to the server after every frame. Moves aren't that big by the way - just velocity/acceleration/rotation/fire buttons and the timestamp. Note that this is actually done in the UnrealScript code. The moves are stored in a replicated array, and that means they're automatically sent to the server when they are updated.
(The player code also compresses moves so the buffer can be smaller but that's beside the point)
Client location and client rotation are also sent to the server with the same timestamp.
3. The Unrealscript on the server applies the latest buffered move and compares it with the compares the client location etc with the actual location, and if the difference gets too big, the server sends a command to the client to correct things like location, rotation, velocity, acceleration.
4. When the client gets the correction, it looks at the timestamp, and forgets all the moves that were performed before that timestamp. Then the server's location and rotation are copied to the client's variables and the moves from after that timestamp are re-applied.
The client experiences no apparent lag (i.e. the client does not have to wait for the server to update his position), but there will be jumps in the player position.
There's a trade-off here: lots of small jumps (maybe too small to notice) or fewer big jumps.
Since every correction uses the same bandwidth, the UnrealScript code makes the size of the allowed error dependent on the bandwidth of the connection - on a LAN the allowed error is smaller than on dial-up.
Note that all of this does not mention a database at all - but I've thought berkelydb might be usable for a game server - although I haven't had a serious look at it.