# Can there be a draw in League of Legends?

Just curious. Say both teams are playing 4v4 teamfight, while one of each is backdooring each nexus.

What could happen if both at the same time do the "destroying blow" to the nexus?

• Anything is possible just believe! This is highly highly highly highly improbable, likelyhood of being bitten by a shark level of improbable. They use milliseconds for timers so you'd have to have the auto attacks on separate timers line up on the same millisecond and do enough damage to kill the nexus Aug 27, 2014 at 18:05
• As evidence of this being at least possible in some online PvP game, there is a Starcraft 1 game (youtube.com/watch?v=00l7BvBApQE#t=167) where both players destroyed the others' last building at the same time, causing a loss to be registered for both players.
– xnor
Aug 27, 2014 at 23:02
• I have witnessed it in Dota once and the outcome was the Announcer "Radiant Won" but the actual game result (counting toward win/loss ration) was a Dire win. Aug 28, 2014 at 9:48
• And here's a simultaneous first blood in LoL, where one player is displayed as getting first blood but the other gets first-blood gold: youtube.com/watch?v=ey4kGO90Vtg#t=15
– xnor
Aug 28, 2014 at 18:03
• Not sure why no one posted the meta-question here: meta.gaming.stackexchange.com/questions/9901 tl;dr this is not off-topic. Aug 29, 2014 at 20:02

So let's get the obvious thing out of the way:

### Yes. It is indeed very possible to destroy the two nexuses at the same "time."

That's because of how "time" works in computer games: discrete intervals that are by no means "tiniest amounts of a second".

This is how most game servers are written, due to the nature of modern computer networks being packet based (that is, in bursts of bits as opposed to a continuous flow of data):

``````while the game is running:
collect the players input
update the game state accordingly
if anybody has met the winning conditions:
declare them winner
stop the game
send the players the new game state
``````

This loop can be implemented in many ways — especially the "update the world accordingly" part — but the fact remains that this is a loop, and it only runs so many iterations every second.

A typical performance targets here is 30 or 60 updates (or ticks) per second, or an update within 33 or 16 milliseconds (that's short, but certainly not microseconds short!). So long as the Nexuses... Nexi... final bases go down in the same tick, then they've gone down at the same "time." Example with made up numbers:

``````Tick number         96987 96988 96989 96990 96991 96992
Blue team nexus        69    60    55    30    15     0
Purple team nexus      45    45    30    25    10     0
``````

What Nexus died first here? You can't tell.

Further complicating the matters here is network lag and compensation thereof. From the Valve Developer Community comes this handy graph for the Source Engine:

Since packets take time to reach the clients, this means that the clients are playing in the past (and the amount of time they do come in the past depends on their ping), and their user inputs come from even further back. As a result, the server might have to essentially "rewrite history" around them.

In one player's "user input tick 105" packet, you can claim to fire a bullet directly through another player's skull. This other player's "user input tick 105" packet arrives a few moment later, claiming he stepped to the right. Whoops!

Of course the server can't keep things in limbo for too long; there is a grace time after which the server must finally update the world state once and for all, and if the second player's packet arrives too late, then the shot will still count as a headshot.

Nitpickers' corner. Actually in this case, the Source Engine will award the headshot no matter what; this is why heavies for example can kill you "through" walls.

So, at the end of the day, it still is possible to have both nexuses go down at the same time.

Now, since the Nexus can't move around, there is a bunch of optimizations that can or can't be done that muddle the waters significantly more. Unfortunately, this logic is all on the server-side of Riot's; unless a group of 10 players sufficiently close to their data centers can dedicate significant amount of time to SCIENCE, there is little hope that we can figure out how League of Legends actually resolves ties, as it's rather blindingly obvious that the game does not allow ties.

## No. It is blindingly obvious that you cannot draw a game.

Riot boasted that in January 2014 27 million players played League of Legends daily. Thus, the lower bound for the number of games played on the service daily is 2.7 million.

Nitpickers' corner. Depending on how you define "player" it is perhaps possible that some of the 27 million players won't actually play at all and just log in to check their profile page or the tribunal or whatever it is that LoL players do. On the other hand many more will play more than one game. At any rate, I don't have a better number to work on.

Now, it is true that I cannot find any report about the possibility of drawing League of Legends games on the internet. This discussion has happened already on the League of Legends forums multiple times (EU NE forums, EU W forums, NA forums, ...); if some player did experience a draw, we would know about it.

Let's guesstimate the odds:

• 1% of the LoL games ends with both nexi being attacked at the same time.
• 0.001% of the LoL games ends with both nexi being destroyed in the same tick.

That means the number of draws that would happen every day is 2.7 million × 0.01 × 0.00001 ~= 3. There would be 3 draws per day. The game as grown in popularity over time since 2009, so let's say that averages out to just 2 draw games per day. The game has been out for 1,768 days today, so that's 3,536 draws since ever.

How come we know of no single draw, then?

If draws are so rare, they would make for an excellent YouTube video at least, or for some interesting screenshots. "You won't BELIEVE how this League of Legends game ended!" So you can bet that people would post about them, write about them, upload videos of them. If nothing else, people would write about it in the threads that have come up earlier. Additionally, videos like this would include lines about the game ending in a draw, together with all of the unusued lines, but they don't.

The silence is deafening.

## So what?

The only rational explanation is that there can't be draws in League of Legends and that the game server, somehow, resolves ties and awards victory to one and only one team.

There are several ways in which this could happen, and we are unlikely to know which one is being used, everything else being equal:

• Ties can be resolved always in favour of the same team
• Ties can be resolved with a coin toss
• Ties can be resolved to the team with more kills/gold/whatever (although you then need to handle ties for this stat, too)

If I had to guess, I'd agree with a variation on the team "favour team X over team Y every time", as it's the simplest solution to deal with a situation you clearly don't want or can't handle.

• Given how things have gone on other answers, I'm not going to respond to comments; sorry. If I think you have a point I'll simply edit the answer accordingly.
Aug 30, 2014 at 9:56
• So, same conclusion/answer as all of the other answers and mass upvoted and all others mass downvoted. Granted it is better detail, but still... Sep 2, 2014 at 20:45
• I think this answer goes into way more detail than is necessary... that said, as a developer, I agree with everything written here (including how ties are most-likely resolved) Sep 2, 2014 at 23:28
• I think some of this is a bit speculative. But it is an amazing explanation on how things roughly operate, and answers the question brilliantly.
– user106385
Sep 11, 2015 at 5:13
• Actually, blue team wins. Everything that ends in a draw ends up being coded as a blue Win (eg: double kill on first blood = blue team killed first). That is, assuming it's at the exact same time
– Oak
Oct 30, 2015 at 7:01

The event you describe, due to the reasons stated by badp, cannot happen.

However, if you destroy the enemy nexus and your team surrenders immediately after, their nexus blows up, but the game screen moves to your nexus, which explodes too and YOU end up losing the game.

Personally witnessed this happen several times.

• It is better to link to the "reasons stated above" (whether stated in answers or comments), as the answer order is not fixed.
– unor
Aug 31, 2014 at 13:57

It can't happen. In a computer system, everything essentially rotates with 1 thing happening at a time. It just happens so fast that you don't notice only 1 thing happening at a time.

Someone may say this might not be the case with a server, but the server will still process 1 nexus before the other.

Now, let's say theoretically they do in fact get attacked at the same time. The server will still process one before the other and you could actually argue that the one that blows up first will be randomly determined since the you have no idea where in the state of things what object is in line to be effected next.

EDIT: Fine for those who really want to point out the single situation it could be occur IF the developers foolishly decided to code it this way.

1) We are assuming there is a state change loop.

2) After the state change loop we will assume there is a game process loop.

3) They would have to code in specificially something like `if (nexus1.isDead() && nexus2.isDead())`.

Even with this info, I will stand by my answer because of how unrealistic it would be to code for this since the game currently does not allow ties at this time.

• @Vality I think you might be confused about what lockless threading is. This has nothing to do with locking. It's simply when does 1 condition get reached first. Whether something is locked or isn't, 1 condition will still be reached first. Aug 27, 2014 at 19:45
• @Vality Since there is not ties in this game, the only reason to do this is to make it random between the 2 sides I suppose but I still don't find that plausible. The only way locking could apply is your bitfield scenario as well as game update loop and game (reaction? or whatever it would be called) loop. Aug 27, 2014 at 20:04
• @Vality Fine I'll admit it's not impossible, but Lockless loading still doesn't matter. Lockless loading only matters if like you said there is only a single variable for it but lockless loading doesn't matter if there are 2. Either way it is the same scenario irregardless of locking. Aug 27, 2014 at 20:11
• @dphil You are right actually. I should have thought on that more carefully, this could occur even with a lock. Thanks for the correction. Aug 27, 2014 at 20:13
• I feel like I got trolled... even though my answer came to the exact same conclusion as the others, i get downvoted to -5. Sep 2, 2014 at 14:51