I am creating a dApp that services a game. The "house" in the game is my game server that creates the smart contract using Web3.js. It also owns all the non-fungible assets at the start of the game, all the tokens. My current intention is to create a smart contract that inherits the Open Zeppelin ERC721 smart contract. This smart contract will handle the awarding of the non-fungible assets, aka the tokens, to the various players as during the game.
I just finished this article on the Open Zeppelin ERC721 token implementation:
The article states that the ERC721 token works with external contracts that handle the spending logic, and that the address for that "agent" contract is put in the main contract's "allowed" map so the contract knows they are an "approved" spender. If I understand things correctly, the ERC721 token acts as the managing entity for token ownership record-keeping and facilitating the integrity of token transfer and allowances, while another smart contract handles the logic involved in spending/transferring tokens.
Is there any harm or risk in not using the external approved spender strategy? Instead, why not simply have a public call in my ERC721 derived smart contract that does the transfer directly when called by the contract owner, which would be the "house" in my case? I'm trying to figure out why this extra layer of complexity, that of using another smart contract acting as the "approved spender", is necessary or is recommended?