Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

When a game is implemented with concurrency (as most games are), does this necessarily, by its very nature, introduce an element of randomness into the game that is outside of the players' control?

Note that when I use the word "random", I'm not meaning to launch into a philosophical debate about the deterministic nature of the system. I understand that concurrency is deterministic in the sense that the operating system decides which processes to allow time on the CPU and in what order (or the JVM controls which Thread's turn it is to execute, etc). But my understanding of this is that there is no way to control or predict whether one thread's next command will execute before or after another.

The reason I'm asking is because this seems like a fundamental difficulty for game development where a game is supposedly designed around a player's skill. Consider a game like League of Legends. Assume that two players are battling it out. It's a very close contest between the two and it's coming down to the wire -- so much so that whoever gets their last attack off will be the one to kill the other and win the game for their team.

If the players are implemented using concurrency and the situation really was like this, is it essentially out of the players' hands at this point? Is the outcome of this match all up to whatever system is arbitrarily deciding which player's thread/process will execute next? If not, what am I misunderstanding about concurrency? If so, is there any way around this problem so that a game of skill can always be a game of skill, especially in those most crucial moments?

share|improve this question
    
Aren't players in LoL usually...actual players, with their games running on separate computers? –  melak47 Nov 16 '12 at 16:02
    
Wouldn't the server implement their actions in terms of separate threads? –  asteri Nov 16 '12 at 16:04
2  
Probably not. They won't use separated threads for separated players. But separated threads for separated tasks. As analyzing input is one task, probably on just one thread. And even if it were on separated threads for players, you could just sync it. –  Gustavo Maciel Nov 16 '12 at 16:05
2  
I do like it when FPS games allow two people to kill eachother :) –  melak47 Nov 16 '12 at 17:27
2  
You dont't need concurrency to create a situation where "it is essentially out of the players hands". Imagine 2 players, each player presses the hit-button at the same time and will hit the other player in the next frame. Now it depends on which position in the entities array you are, that decides who gets updated first, if you are before the other player, it can happen that that player hitting the other will kill him so he wins. Voila there it is: "random" .. Each of them was about to win, but the position in the entities array decided who wins. –  Maik Semder Nov 16 '12 at 17:28

1 Answer 1

up vote 5 down vote accepted

No, it does not.

But my understanding of this is that there is no way to control or predict whether one thread's next command will execute before or after another.

If this were true, it would be next to impossible to create game software that functioned reliably. As it is, there are ways to ensure that key operations perform in a reliable order.

whoever gets their last attack off will be the one to kill the other and win the game for their team. If the players are implemented using concurrency and the situation really was like this, is it essentially out of the players' hands at this point?

If there is a single authoritative host, one of the commands will reach the host system before the other and will be processed first. One player may win purely due to better network latency, just as in real sports the player with the fastest reflexes may win. But it won't be affected by the concurrency on the host computer.

In a peer to peer game, the results will be processed side by side on each machine and will all take effect. So the results should be the same everywhere, regardless of how each computer processes them. Again, if one side happened to submit a command more quickly than the other, than that may convey an advantage.

If not, what am I misunderstanding about concurrency?

All that you're misunderstanding, is that concurrency - when handled properly and safely - only applies to independent events, and that these events usually have a prescribed order before they even reach the game software (dictated by the network traffic, for instance). At the point where the events interact, such as both operating on a single game state, they must stop being concurrent and start being serialised. It is certainly possible that a badly programmed game could introduce some sort of error or bias when it comes to combining these events, but it's much more likely that any advantage would be introduced between the player and the game by network latency or other physical factors.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.