I don't want to give too many details, as I think with a little bit of effort, you could write it out yourself. Just giving some tips. Others are welcome to pitch in with suggestions, better way to model this etc.
A good way to proceed might be to have a struct called Contest (defined inside a smart contract ContestHost), which has the intrinsic properties associated with a contract (name, description, entryFee, startblock, endblock, array of contestants, current staked ether, isActive, etc). Since there is no built in concept of dates etc, you can think of substituting it with a startBlock and targetBlock concept. Look at the below AuctionHouse sample to understand this better.
This struct Contest would be used by a contract (say ContestHost) which has an array of Contests and a mapping between Contest and some particular property (to make it efficient to access each contest).
This contract should have a function to start a contest (returns a unique uint id), one to join a contest by sending ether and address, and maintain a total stakes for each contest.
Finally, you can look at these links to get a better idea.
Auction House: https://github.com/dob/auctionhouse/blob/master/contracts/AuctionHouse.sol
SCHEDULING OF TRANSACTIONS FOR DELAYED EXECUTION IN THE FUTURE: This could help execute "ContestClose" transaction at targetBlock. https://www.ethereum-alarm-clock.com/
Random Number Generation (some say it is slow, but it is guaranteed to be random): https://github.com/randao/randao
Withdrawal pattern for safe payout: https://solidity.readthedocs.io/en/v0.4.24/common-patterns.html#withdrawal-from-contracts
UPDATE: Also, you have mentioned that there might be a off-chain third-party API function that you need to call every 5 minutes, to update the status of each player.
You should consider using a side-chain to host your entire smart contract (such as Matic Network, which is a Proof-Of-Stake side chain which is 100% compatible with the Ethereum mainnet and just requires ONE line of change for the deployed network provider).
The costs can come down significantly (100 times around) so this can make it very economical, and once ETH2.0 becomes fully functional (or considering that a Cardano side-chain for solidity code might come up very shortly), you can then move it onto the relevant mainnet.