Quote:Original post by ravyne2001
Without very robust mechanisms in place, hoping that 2 or more clients simply passing input between each other will stay in sync is crazy.

It's what RTS games have done for a decade, and it works, so it can't be that crazy. You just have to make sure your simulation is deterministic (it's particularly useful to isolate the simulation from the renderer, and might be handy to avoid any floating point in the simulation code depending on what environments you're going to run in), and make sure that no player simulates a turn until they're sure they've received all the inputs from every other player from that turn, and that's about it.

Quote:Aside from that, p2p systems are ripe for cheating. If I'm only recieving input, I can ignore inputs that cause my character harm, or generate false inputs that cause you harm. Someone could hack their client to not take damage and to launch multiple attacks with no reload time, for instance. If there's no authoritative entity to call them out, then how can they be stopped?

The inputs need to be at a slightly higher level - it would be "player has activated the 'try to attack' event", not "player has successfully attacked" and definitely not "player has caused 63 points of damage to the other player". (It doesn't need to be at the level of keystrokes and mouse coordinates, but it should be an intermediate level between the GUI (which isn't trusted to only allow valid commands, particularly since you can press buttons to e.g. train units just before the simulation has caught up with the point where you ran out of money) and the simulation itself (which buffers all the commands, sends them over the network, and then processes them all by checking for sensibility and performing the world updates).)

That stops the problem of faking incorrect inputs - when the only data sent over the network is equivalent to what a player can perform by using their keyboard and mouse, nobody can perform actions that would otherwise be impossible. And if you ignore some inputs from other players, your copy of the game will go out of sync and that'll be detected and you'll get disconnected from the game. The main possibility for cheating comes from the fact that every player has knowledge of everything in the game, so they could do something like remove the fog of war and see what their enemy is doing, and you just have to avoid that by protecting the client code in some way (and kicking any obvious cheaters from your network).

Wouldn't keystrokes + mouse coords be the best way to go? It seems that it would save a lot of bandwidth.

no, you need to send commands such as (of course they would be in a binary format):

move A to x,y
B attack A

because there is more than one way to issue a command. You could use the mouse, you can use hotkeys, or you could be an AI player who doesn't use the interface. This also allows for easy creation of replays. Plus if you allow multiple resolutions you can't use the screen x and y coords, you need to send world coords anyway. Oh and related in the same way you can't use screen coords because you can move your view around. There are lots of similar reasons why you shouldn't send raw input data.

Quote:Original post by Daniel Miller
Wouldn't keystrokes + mouse coords be the best way to go? It seems that it would save a lot of bandwidth.

What Glak said, particularly about having no way to convert x,y mouse coordinates into world coordinates unless you know exactly the resolution and camera position of every player, and that's especially hard to do when the camera is moving in between multiple clicks in a single simulation turn. And if you didn't do that perfectly, it'd be annoying for players if their direct input was delayed by hundreds of milliseconds before converting screen-space to world-space coordinates - when they click on a point on the ground, they want their units to walk there exactly, regardless of whether they're moving the camera around. (It's alright if there's a delay in the world responding to their actions, as long as it matches what they clicked on.)

Also, you probably want AI players and they don't have mice or keyboards at all - it's convenient if they can generate "move A to tile x,y" messages that are the same as the network messages which are generated by real players in response to key/mouse events by the GUI. And players might want to remap hotkeys to be more convenient for them. So just do all the unit selection, screen-to-world conversions, key-to-command mapping, etc, on the client, to generate the "move A to x,y" messages which then get sent over the network. (Then every player receives that message and eventually simulates that turn, and they find the right unit (or ignore the command if the unit doesn't exist any longer or if it's in the wrong state for movement (e.g. it's garrisoned in a building)) and do the pathfinding and run the unit AI and everything.)

It's actually pretty damn impossible to cheat in a meaningful way with the simultaneous simulation method (outside of obvious shroud clearing cheats) because each client verifies that the other simulation is in step. You pass some CRCs over the network. If the simulations get out of step you error out and end the multiplayer match.

Cheating and trying to keep the other client thinking that the simulation is in step and that the moves are legal without it crashing out is a "crazy" challenge. When all you are passing is user input rather than unit movement, you can't really exploit anything dealing with unit behavior/combat/movement.

I'd argue that with a server you are running a much higher chance of cheating because the server can cheat without the client knowing. But whatever, both are viable strategies; like I said both are widely used and both come with their own special problems.

Quote:Original post by Excors
Also, you probably want AI players and they don't have mice or keyboards at all - it's convenient if they can generate "move A to tile x,y" messages that are the same as the network messages which are generated by real players in response to key/mouse events by the GUI.

In this model you just simulate the AI on all clients; otherwise one machine only can run the AI. Basically, all you need to implement is a network safe deterministic random number generator and the rest is easy. With that in place the AI can independently simulate on each machine and come up with exactly the same results on all clients. The RNG allows the AI do be "random" within the context of the game environment and yet run the same for each simulation (because each simulation is exactly the same).

-me

1. The game has a fixed resolution (it is 2D, but it can scale to fit the screen). Clicks will be sent in world coordinates, not in screen coordinates.
2. There will be no AI players. That makes a lot of things easier!
3. Players can fully customize hotkeys, so mapped input is sent instead of raw input.
4. Players must use hotkeys.

Since my game is so simple, it should work. :P

Quote:Original post by Daniel Miller
1. The game has a fixed resolution (it is 2D, but it can scale to fit the screen). Clicks will be sent in world coordinates, not in screen coordinates.
2. There will be no AI players. That makes a lot of things easier!
3. Players can fully customize hotkeys, so mapped input is sent instead of raw input.
4. Players must use hotkeys.

I think it would work.

Yep. That's exactly how you do it. Noted in my above post, it's not actually hard at all to implement AI opponents (outside of the normal challenges involved for RTS AI). The network paradigm doesn't make it difficult to write an AI.

Network messages generally look something like:

OrderTypeTargetObjectOrderSpecificData

You just need an ID system for objects that works across the network (pointers will obviously not work because everyone's memory will be mapped differently). This is actually really important because it means that hashmaps with pointer keys are not multiplayer safe because the ordering of that hashmap will be different for each client. You need to have all your data structures index objects by the network safe Object ID key.

-me

Quote:Cheating and trying to keep the other client thinking that the simulation is in step and that the moves are legal without it crashing out is a "crazy" challenge. When all you are passing is user input rather than unit movement, you can't really exploit anything dealing with unit behavior/combat/movement.

But you do have to be careful not to rely on the GUI for input validation, otherwise you won't get that nice cheat-free property. If the player isn't allowed to construct a certain unit because they haven't researched the right techs yet, you're not going to display the button on the GUI, but you must double-check inside the simulation code (after it has received all the messages from the network) that any build command is an allowable unit. (I'm mostly saying that because I think Age of Empires 2 might possibly suffer from that problem, although I'm not at all certain and have never tested it myself, and nobody knew how to edit the game's data files while the game was particularly popular so it didn't really matter anyway, but it's still something that you need to be slightly careful about even when you have the deterministic simulation model working.)

Quote:In this model you just simulate the AI on all clients; otherwise one machine only can run the AI.

That's what I was thinking, but the AI still has to interact with the simulation in some way and so I was thinking you could reuse the network command system to handle commands generated locally by the AI, particularly since it would stop the AI from accidentally cheating; but, then again, maybe that's not easier at all.

Yes, good point about the GUI checks. Never ever ever have game logic in the GUI. Outside of cheating, this actually continually plagues me as an AI developer; AI does not use a GUI so if you have control logic in the GUI you end up having to duplicate the logic in the AI and that gets _very_ annoying from a maintenance point. BUG: AI cheats. Me: diaf, move your damn code to the unit instead of being in the GUI. =)

Quote:Original post by Excors
but the AI still has to interact with the simulation in some way and so I was thinking you could reuse the network command system to handle commands generated locally by the AI, particularly since it would stop the AI from accidentally cheating; but, then again, maybe that's not easier at all.

But the AI is part of the simulation. If every client is simulating it then there is nothing to send across the network. Yes it interfaces with units in the same way (sends them move orders & such) no that information does not get replicated across the network. Because you have a network safe RNG, and since you, being supar smart, just use that RNG to do all of the AIs fuzzy decisions, then you are guaranteed to have the AI produce exactly the same results on all client without those AI ever having to communicate.

-me