What Happens if a Player Stops Playing?
Start course
2h 36m

In this course, we begin building a game in Solidity, and more specifically, we begin to look at defining the mechanics and the components of the game.


In the previous lecture, we actually finished our game. But even if we can play it for now, and maybe we can play it with friends or with colleagues, what happens if somebody's just stops playing? Now, in this lecture, I want to go ahead and implement some logic in order to get the money back out if our playing opponent, for whatever reason, just suddenly disappears. Obviously, at the moment when we start the game, we have to end it. And in our case, I want to implement something in order to give the opponent like three or five minutes. And if it doesn't react in this time span, then we are going just to abort the game, and we are giving the players the option to get the money back out that they paid in order to start the game. Okay, and it's quite easy, it's not as hard as it sounds like. All we have to do is we have to create a new state variable that says when was the last move? And we are adding some minutes to give the players the opportunity to move. And if those minutes are over then we do not allow any more game moves, we just say the game has stopped. It's an emergency cash out, and we give the people, we give the two players the opportunity to get their money back. All right, enough talking, let's start implementing. So, we have a new state variable, actually we have two, and I'm going to add here one uint 'gameValidUntil;' And if you've paid attention before, then you know that in solidity we are always saving timestamps, and those timestamps are in seconds since 1970. So, it's basically a UNIX timestamp, and it's time zone independent. And we are going to give the player some 'timeToReact', and that I set to three minutes for now. That should be fairly enough in order to send off a new transaction and get in mind, even on the main network. And when we start the game, join game, here where we say game active, then we set the 'gameValidUntil = now +' the 'timeToReact'. So, 'timeToReact' will be a three times 60, that is 180 seconds if I'm not mistaken now. And now, the variable now here, this one will be the current timestamp plus the 180 seconds. And that gives you the new 'gameValidUntil'. And once we try to set a stone, we require that the 'gameValidUntil <= now'. And that way the next player always has the opportunity to play until the timestamp is larger than the gameValidUntil now. Now that one is pretty clear, I guess. The last thing that we have to do is we have to implement the 'emergencyCashOut' functionality. And the 'emergencyCashOut' functionality gives you back the money that you paid, very similar to the withdrawal, 'setDraw' functionality. And in a way, but only if the game is not valid anymore because the time passed so long. So, we have a require here that this 'gameValidUntil < now'. And I think here I made a mistake. The 'gameValidUntil >= now' because we set it to a future timestamp. And as long as we haven't reached the future timestamp, then we can play. And once the future timestamp is reached, then we have to pay out. And there, we can actually just call the 'setDraw' functionality which tries to give you back the money. But there is another important part which we forgot, which is we also have to require that the game is still active. Because once we are having a winner, once we finish playing, then we set the active to false. And obviously, the game must still be active in order to get the money back, or else we have a winner and then maybe the winner didn't claim his prize, it's 0.2 ether. And we want to avoid that somebody in the meantime gets the 0.1 ether's back by calling the emergencyCashOut functionality. So, we go and require 'gameActive'. And that way we should be pretty safe. All right, that's it for this lecture. And in the next one, we are going to do something very interesting, totally different than actually three in a row game. We are going to talk about the high scores and we are going to implement a linked list for the high scores. It's going to be a huge lecture, going to be very interesting how to implement this on the Blockchain. And I'll see you in the next lecture.


About the Author

Tom is a CTO, senior back-end developer, and systems architect with over twenty years of hands-on development experience in a variety of languages and systems. He has a CS master's degree and has been working with Ethereum and blockchain technologies since 2016.