Yes, that's fine for my purposes. As I told the other person above, this is a learning exercise to explore what Bitcoin is capable of.
Understood.
The point of using Bitcoin is that we want its blockchain to know the program and the inputs and verify the output, then release funds depending on the output. It isn't enough that both you and I can run the program off the blockchain, because one of us could lie and say "hey when I run this program it says I won, so give me the money." Trustless here means you don't have to trust your partner to be honest and pay you if he loses. The blockchain resolves any dispute about who the winner is, and causes funds to be paid to them.
OK. So we have fairly unsophisticated but way too large (for current Bitcoin blocks) program to verify the result of the game. We could say it is doable with a future soft fork.
The only remaining problem is how to verifiably enter the moves of the players into that program. Do you want to do that (1) one by one (2) in pairs (3) entire game in one fell swoop? I guess we now have a "trustless move
After the soft-fork gets implemented the whole operation would be:
OP_OFFICIATE_CHESS_GAME
which pops two public keys of the stack and pushed one of three numbers {0,1/2,1} back onto the stack.
So you are back into square one of Bitcoin: at least 50%+ of miners have to have the correct implementation of OP_OFFICIATE_CHESS_GAME soft-forked operator. It isn't a technical problem but a political one.
More precisesly: it isn't 50% of all miners, but of those miners that implement and mine OP_OFFICIATE_CHESS_GAME a majority (>50%) have to use the correct implementation.