Why do we need `startWatching` function from WalletApi?

In plutus playground in game example there is a function

-- | The "startGame" contract endpoint, telling the wallet to start watching
--   the address of the game script. See note [Contract endpoints]
startGame :: MonadWallet m => m ()
startGame =
    -- 'startWatching' is a function of the wallet API. It instructs the wallet
    -- to keep track of all outputs at the address. Player 2 needs to call
    -- 'startGame' before Player 1 uses the 'lock' endpoint, to ensure that
    -- Player 2's wallet is aware of the game address.
    startWatching gameAddress

I don't like the

Player 2 needs to call
'startGame' before Player 1 uses the 'lock' endpoint, to ensure that
Player 2's wallet is aware of the game address.

Is there really no way to connect to game after game is started (lock function is called)?

Do we need this function at all? Can we go only with guess and lock functions?

I can understand how startWatching can make sense for light wallets/clients (that use merkle proofs to validate transactions) but don't understand how startGame function may be useful for full clients. (Actually I don't, light client still should be able to ask info from other need)

Solution

As you state correctly, the reason why startWatching is needed has to do with the capabilities of the wallets that Plutus contracts have access to.

In the first iteration of the emulator we went with the conservative assumption that Plutus contracts would only be able to do forward-looking queries of the blockchain state. That is, we assumed it would not be possible to scan arbitrary sections of the blockchain because of resource limitations of some of the wallets. The effect is that all contracts written against this restrictive wallet interface have to call startWatching before they can do anything interesting.

When the emulator was implemented, there was no specification of the wallet capabilities that Plutus contracts can expect - in fact, one of the motivations for building the emulator was to help us write the specification. And it's quite likely that the current, restrictive interface (forward-looking queries only) will be replaced by something more powerful so that the startGame endpoint won't be necessary anymore.