CS [4|5]113 Fall 2022

Distributed Operating Systems

PokemonOU

Here we describe to you the requirements and expectations for your final project this semester in distributed operating systems. You will create an asynchronous distributed game of Pokemon OU. Many you have played Pokemon Go or one of the 25 Pokemon series Games. In this project, we will use principles of distributed operating systems to implement a “world” where trainers (nodes) and pokemons (also, nodes) can interact.

Games Play

Game setup

You will have an NxN game board. On the board, you will create P pokemon and T trainers and assign them to a space. Each pokemon and trainer should be assigned a unique emoji. Pokemon can be chosen from the animals list. Trainers can be chosen from the people list. Pokemon may be assigned to the same space on the board. Trainers cannot be assigned to the same space as pokemon or other trainers, every starting space for a trainer is unique. Once all trainers and pokemon are placed, the game follows a few rules.

Games play

Trainers and animals can ask the server (or spaces) to see the contents of the spaces around them (through gRPC messaging). Each player can move up to 8 spaces — up, down, left, right, north east, south east, north west, south west. Trainers should run towards pokemon and pokemon should run away from trainers. Trainers and pokemon can choose the best move; no AI/ML techniques are needed, just a valid move. To complete a move, a trainer or pokemon must tell the space (or server) that they are moving. Moves should be performed asynchonsously. Trainers must never occupy the same space as another trainer. Trainers can occupy the same space as pokemon. Trainers and pokemon can only move one square at a time.

If a trainer believes it has captured a pokemon, if can call a capture() function to tell the space (or server) that it is capturing all the pokemon in the space. The space (or server) verifies that the pokemon is indeed on the space and notifies the pokemon that it has been captured. To perform a capture, the trainer must be in the same space on the board as the pokemon before it can move. If the pokemon has moved before the server verification, the pokemon capture has failed. When all pokemon are captured, the server ends the game.

For those enrolled in CS 5113, there should be no timing delays after initialization. Synchronization should be used through an appropriate choice of mechanism. Students enrolled in CS 4113 may add small timing delays to aid in coordination.

Functions

Below is the minimum list of functionality that the system should provice. Only a skeleton of funcitonality is listed, you may updated function, names and parameter as needed.

Server

Function	Role
Captured()	Tells the pokemon that they are captured.
Moves()	Print each move that is registered; who the move is by and where the move is.
Board()	Print an NxN representation of the current board state.

Trainer

Function	Role
Capture()	Successful if a pokemon was in the space.
CheckBoard()	Examine the board and choose candidate places to move.
Move()	Complete the chosen move.
Pokedex()	Print the set of captured pokemon.
Path()	Print the full path traveled by this trainer.

Pokemon

Function	Role
CheckBoard()	Examine the board and choose candidate places to run.
Move()	Complete a move to a chosen location.
Trainer()	Print the trainer information for the pokemon and information about when and where it was captured.
Path()	Print the full path traveled by this pokemon.

Requirements

You are to use Python, Docker, Docker Compose, and gRPC to complete the project. Each project must be created individually; we treat any instances of academic dishonesty. The project includes several deadlines and we will discuss the specific deadlines for those submissions in separate files.

Submission

.
├── code
│   ├── docker-compose.yml
│   ├── Dockerfile
│   ├── pokemonou.proto
│   ├── node.py  # or other python files
│   └── requirements.txt
├── COLLABORATORS
├── media
│   └── demo.gif
└── readme.md

2 directories, 8 files

Given above is a possible project structure. The collaborators file should contain a comma-separated list describing who you worked with and text description describing the nature of the collaboration. This information could be listed in three fields as in the example is below:

Christan Grant, cgrant@ou.edu, Instructor of CS [4|5]113.
https://docs.docker.com/engine/reference/builder/#env, Stuck at tzdata prompt during build.
https://grpc.github.io/grpc/python/, GRPC Documentation.
https://github.com/grpc/grpc/tree/v1.20.0/examples/python/helloworld, hello-world example.

The readme.md file should contain a walk through of your Python files and other source code you may write including a demo.gif and put it in the readme demonstrating the running pokemonOU game.

Submit all source code to a private github repository named cs4113fa22-proj or cs5113fa22-proj. Submit a link to the private repository to Canvas. Also, you must add @cegme and @jasdehart as collaborators to the repository. Code must accessible by the instructor and TA to receive any credit. The video/annotated .gif should also be uploaded.

This is project may not be done in groups. Any code copying is subject to the university’s academic dishonesty policy. Any websites or discussion should be added to a COLLABORATORS file.

## Deadlines

Below are each of the deadlines for the project. You will get a final grade for the project. You will also be graded for completion of each of the checkpoints.

Architecture Description [10/27]

Protos and interface design complete [11/03]

First version logging [11/17]

Submission Instructions Released [12/01]

Presentation [12/14]

---

Back to CS 5113