In C$++,$on Ubantu, using only #include #include #include #include #include $,$ or library for fork$(),$ no mutex is allowed. Implementing a simple multiplayer game in which players can move around a game board and collect items is your task. The following elements ought to be present in the game:

$1.$ A two$-$dimensional grid of squares is used to represent the game board. Every square can either

be either empty or have a collectible item for the player.

$2.$ Using the keyboard's arrow keys, players can navigate the board.

$3.$ A player gains points and collects an item when they move onto a square that has it$.$ Several players may be present on the board simultaneously. However, you will use two players when you implement it$\mathrm{.}4.$ Several players moving and collecting items concurrently should be supported by the game. The following procedures can be used to determine board size:

$1.$ Choose a random number from $10$ to $99.$

$2.$ Take the generated number and multiply it by $5.$

$3.$ Next, divide $2375$ by the number that was produced.

$4.$ Take the mod of the corresponding number with $25$ after the division is complete. Add $15$ to your number if it is less than $10.$

$5.$ After you get a number that is less than $25,$ make a $($n x n$)$ board and begin playing your game. You can use threads to implement this game by creating a thread for each player that manages their movement and item collecting. Each player thread may be in charge of determining whether the player has gathered any items and updating the player's position on the game board.

Mutexes and semaphores are prohibited in order to maintain thread safety and prevent players from interfering with one another's movements. Nonetheless, using a message passing mechanism between the player and main threads could be one strategy. When a player moves or collects an item, their thread could be in charge of communicating with the main thread. The main thread could then use these messages to update the score and game board. Each player thread could send messages to its own message queue in order to prevent conflicts between them. After receiving updates from each player, the main thread could poll these message queues and modify the game state appropriately.

This will guarantee that the game board is only ever updated by one player thread at a time. Based on the player's score or other game$-$related variables, you can also use thread attributes to determine each player thread's priority. This will guarantee that players who perform better or have higher scores are given more priority in the game. Lastly, the game logic, including creating the game board, displaying the user interface, and adjusting each player's score, can be handled by a main thread.