Irrlicht Engine

First, you don't need mods. You're starting from an assumption that your design and implementation will suck.

Second, you're effectively asking your employees to pay for computers and connections out of their takehome pay, so you'll get a lot less than you'd be able to buy yourself for the same money. Their hardware will suck compared to a rack of dedicated servers with fat pipes.

Third, you can't trust them. Quis custodiet ipsos custodes?

Fourth, you've still got the problem of co-ordinating a consistant global world state across multiple peers. When two of your "peer servers" try to propagate conflicting data about common objects, how do you resolve it? When one your mods goes rogue and starts injecting garbage into the world, who sorts it out? How do you cut a rogue peer out of the network?

Again, if the answer is: "I don't care", then that's fair enough, but at least do the work to understand the problem and make your decisions up front, rather than being bushwhacked by them later.

well, seems that this project generated a lot of discussions, well, i have planned everything about this project, first we've got to do lots of more important things than a network code. and i won't quit on p2p ideea that easily.

It's certainly a thought provoking idea. If you're at all inclined to accept advice, then I'd strongly suggest that you have no more important task than determining your network requirements. Not code, not even design at this stage. You have to know what problem you want to solve before you can design a solution.

Your first decision should be whether you want a game that can be played competitively. This is not a trivial decision. If the answer is no, then you are effectively creating a co-operative storytelling whiteboard. If the answer is yes, then you have a serious problem to solve regarding world state consistency.

I agree, i was gonna post this last night but i was too tire, the most important part of this type of game to get out of the way is to figure out your networking, because it is part of the main framework of the game, it is like programming an game engine, but leaving out the code to connect it to the engine. You cant program an online type game the same as you'd progam a normal game, your objects all have to handled through handles passed to the server, everything is has got to figure out what to send and were, heres an example:

suppose you want players to walk forward if "w" is pressed, then here is what you'd have to hypothetically do (of course this is in a server/client network but the background point is still relevant)
In a typicall setup this is all you'd need




do you see the difference?[/code]

This is not good for action intensive games, as it can be very laggy. But it is good idea to keep world consistant and avoid cheating. Most action games I think would just send the position to the server, and other things.

well yeah, my point was its a different setup than most normal programming.

Actually nevermind your setup is very good...Hmm i think I will implement sending Key Presses into irrNet, and add some kind of custom net key press handler inheretence...

thanks, ive never done a multiplayer game, but in the distant... erhm, let me rephrase.... very very distant future, i hope to make this mmo, and its the uber 1337 awesome one that everyone dreams to make, so, while i work on my small casual games right now, i have been trying to study multiplayer a little at a time.

BlindSide wrote:This is not good for action intensive games, as it can be very laggy. But it is good idea to keep world consistant and avoid cheating.

Which leads us back to decision #0: do you intent the game to be played competitively? If the answer is yes, then you have to design in robustness, working from the assumption that the client is a robot.

Most action games I think would just send the position to the server, and other things.

Not necessarily. World of Warcraft has the client send position data (which leaves it open to speed and teleport hacks), but that's in part because the relative position of players isn't split-second critical, and it's more important for each player to be able to move around smoothly, even when the network is lossy.

For a twitch game, it can (somewhat perversely) be better to have the client only send requests, and the server do the movement calculations, as that keeps the positions of each player (on each client) more consistent. Remember, while the sending client can immediately update its position, that information has to then propagate to the server and back to the other clients, leading to everyone very smoothly chasing each other' ghosts.

In the case where the client is trusted to send states rather than requests, it's important that you design in paranoia on the server (or the peer clients in this case). It has to reject or correct movement or state data that's patently invalid. So a client can send whatever states it likes, but the madness should be stopped from reaching other clients. In the extreme case, the server (or peers) should drop the rogue client out of the game world. In a P2P game, that could lead to fragmenting of the world into alternative overlapping realities, where players are effecting what happens on some peers but not others.

P2P might look easy, but it's actually far harder to make it robust than a client/server architecture. There are very good reasons why nobody uses it for real games.

Of course, if the result of your decision #0 was "I don't care if people cheat", then all of these problems go away, but you have to accept that (if your game becomes popular) that people will cheat. It's futile to hope otherwise, and counter-productive to rail against them when it happens, or to perform witch hunts to try and catch and exclude cheats. Accept them, or design out the possibility.

thanx for this last good posts, i'll think about the net code (p2p or client/server), now i'm working on much more important things than that

iZOTOPE wrote:i'll think about the net code (p2p or client/server), now i'm working on much more important things than that

I doubt it.

Your network requirements and architecture (note: not code) will be the hardest thing to fix later if you bollocks them up.

Ah well, it's your project.

Client:
if w is pressed
send a w press action to the server
start moving player forward

Server:
if item sent
check id
if w pressed is message
extrapolate and verify player's movement
send out player position/rotation/etc update to all clients

Client:
interpolate player's current position and update based on current position and server's update

Or something like that.

iZOTOPE wrote:thanx for this last good posts, i'll think about the net code (p2p or client/server), now i'm working on much more important things than that

This is just my opinion, but the net code is extremely important and needs to be planned from the beginning. At least for a twitch game. For a turn based game not so.

yea, it needs to be planned, but just for now i'll use a simple net code to test the project.

iZOTOPE wrote:yea, it needs to be planned, but just for now i'll use a simple net code to test the project.

*Shameless plug* If you want easy net code use irrNet! *Shameless plug*