Tictactoe on cocos creator


#1

Ongoing…
github

There already have many tictactoe project in other blockchain platform. Now I just want to build very very simple flow of that game to run on zilliqa platform.

The compact features:

  • Host always go first.
  • Don’t tracking move.
  • Don’t have server or contract to notify who are online and ready for match.
  • No bet.

The flow will like:

  • Alice host new contract.
  • Alice change contract status top open. (need this step because contract state was empty until it has a transaction)
  • Alice give the contract address to Bob by some way.
  • Bob import Alice contract to his list.
  • Bob clicked on Alice contract.
  • Bob clicked join and waiting for Alice accept.
  • Alice accept Bob challenge.
  • Change to game screen.
  • If game ended, contract status will be changed to close.

Contract implement

  • contract TicTacToe(owner: ByStr20, checksum: String)
  • transition changeOpenStatus (b: Bool)
  • transition join (mess: String)
  • transition acceptChallenge ()
  • transition move (slot : Uint32)
  • transition refuseChallenge ()

Cocos application

  • I has bundled @zilliqa-js with some adapt to make it work on cocos environment (both native app and web).
  • The encrypted json of account was be store inside app. My design is create new one then send some zils from main account. In worst case like some one hack my hosting and inject some bad code, you won’t loss everything.
  • Each player will deploy their own contract. Send it address to friends by hand.
  • To make sure 2 players are using same contract (it mean same client version). I include the checksum of code in init call. If the code in hosing side was changed game will show out of date and require deploy new one. If the code in challenger was out of date, we won’t send the challenge.


#2

It’s wonderful that you are working on a game tutorial to show people how to make games on Zilliqa through Cocos SDK. I’m sure this will be the start of many other interesting ideas to come!

I have some comments and questions about the contract code:

  • Bob does not import Alice contract. Bob invokes a transition on Alice’s contract
  • I would recommend merging acceptChallenge and refuseChallenge into one transition since many of the logics used are the same. Maybe a transition called processChallenge(status), where status can be an enum Uint32 value of either 0 or 1?
  • Use events where possible. Client side like your game SDK is not able to receive the values in the send msg transition. You should use events https://scilla.readthedocs.io/en/latest/scilla-in-depth.html#communication
  • In your changeOpenStatus, it almost looks like you are reseting the game. It might be fun to allow the owner to reset the board by clearing all moves on the board, removing challenger, flipping the board status to open. Of course, only allow the operation when the game has been completed (i.e. a winner is declared).

I like the way you separate commonly used logics like checking three cells and getting winner by checking the possible permutations. This is a good example of how you can use library functions to simplify your contract logic!

Source: https://github.com/paladinlll/zilliqa-cocos-sdk/blob/master/sample/tictactoe/assets/resources/contracts/tictactoe.scilla


#3
Bob does not import Alice contract

I mean import Alice contract into Bob address list in cocos app. Then Bob can select one to invokes a transaction.

I would recommend merging acceptChallenge and refuseChallenge into one transition.

Yes. I first time I sketched the contract, it hadn’t had refuseChallenge yet. I’ll change it soon.

Use events where possible.

I checked it. And I think we need to wail for a web socket provider to support this feature.

It might be fun to allow the owner to reset the board by clearing all moves on the board, removing challenger

Yes, I missed a condition not_playing .

I’ll write another topic with instruction step by step how to how to make games on Zilliqa through Cocos SDK.


#4

However, we do not have support for web socket. We thought about this internally for a while, but the consensus within the team is to ensure security and stability in Q1 2019. For now, I would recommend doing it through JSON RPC calls.

Looking forward to seeing your guide!