It would be technically possible to include delays using the block number or timestamp. It's unnecessarily awkward to make the contract "wake up" in the future. Clients can withdraw winnings, and the contract can check their entitlement, possibly with an eye on the clock.
Speaking in abstraction makes it a little tricky be precise, so let's talk about rock, paper, scissors. Suppose each player places a stake for each round.
The following description is predicated on the assumption that there's a user-friendly Dapp that hides all the transaction details from the users ... so they can play the game.
The system can know there's a winner after two stakes are placed. A non-obvious problem is everything on the blockchain is visible to a determined adversary. It means a player can cheat unless the "rock, paper or scissors" is stored in an encrypted way. During the betting phase, everything is hidden.
When all bets are in, the round would enter the settlement phase.
The clients would reveal the secrets they used to encode their bets (for round 123, my secret was 0x123). The contract would verify the secret is correct and the recorded information correctly decrypts to "rock, paper or scissors".
The contract would determine the winner immediately.
The winner would be required to claim their prize. That way, they provide the gas for transmission. This function would check the legitimacy of the claim.
In the settlement phase, it's possible a determined (and cheap) sore loser would refrain from the meager gas cost of checking in if they could determine that they lost (doable). That can be resolved with a rule that stipulates that they forfeit the round if they don't check in after a few blocks.
We can imagine a user interface that plays the game continuously, with previous rounds in settled or waiting states. Generally, payout would be immediate. When dishonest players participate, they would cause a brief delay settling specific rounds; always eventually resolved.
Hope it helps.