Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: THEend8_
CS157B Embedded Static & Dynamic SQL
This coursework is individual. While discussion among students about the coursework is encouraged each student should have a unique submission and be able to explain their code. If plagarism is suspected students will receive zero for the coursework. There are two options for the coursework.
Option 1:
The goal of this option is to add some functionality to handle networking and consistency issues in existing multiplayer games. You may select the game and language of your choice but please include the source of your game in your submission.
Please feel free to share sources on the forum if you find something you think other students may find useful.
The additional functionality which should be added to the are as follows:
Introduce an artificial network delay to simulate some of the challenges which take place in networked games. This should vary over time to simulate real network conditions. Static network delay will be given partial marks.
Implement bucket sychronization so that all clients have the same frame rate so the game can be considered “fair”
Implement interest management so that a large map exists on the primary copy of the game while information on objects which are sent to secondary copies should only contain information relavent to that client
Implement dead reckoning so that players continue to update in the event that network problems cause delays in updates received about player position
Implement smooth corrections so that players move towards the correct position after drops in network communication to prevent jerky animation
Introduce some form of cheat which allows one client to perform a game action that cannot be done by other clients. This can take multiple forms. One example would be to increase the movement speed of one player
Introduce some checking on the server side which allows the cheating to be detected. This cheating detection should be general rather than specific to how you implemented the cheat. E.g. If you implement a move cheat you should check for unrealistic movements in player position rather than looking for a specific function call.
The deliverable is concerned with the design of the game. You are expected to upload one zip file containing all the source files for your coursework by 10am the 20th of April. You are also expected to upload a 5-10 minutes video of your code running and explain the features you implemented. This could be demonstrated in the application e.g. showing only some of the game sprites for Interest Management or via the code e.g. explaining the code that creates an artificial delay. Please note that the submission of a demonstration video is mandatory and failure to submit will result in zero marks. Both the code and video are required for the project.
The marks for this option are as follows:
Artificial Network Delay (4 marks)
Bucket Sychronization (6 marks)
Interest Management (6 marks)
Dead Reckoning (6 marks)
Smooth Corrections (6 marks)
Cheating (4 marks)
Cheating Detection (4 Marks)
Code Style and Readability (4 marks)
(total 40 marks)
Option 2:
The goal of this option is to expand the work you have done in lab 1 and 2 to create a system which will allow the distributed processing of matrix calculations. The system should have the following features:
A REST interface that allows matricies to be uploaded as files. The files can be any format but I would recommend using the space character to seperate elements and new lines to seperate rows for simplicity. The component should be able to accept matricies of arbitrary size but you can assume they are square matricies whose dimensions are powers of 2 so you can use the divide and conquer approach utilized in lab 1. If a matrix is not this size the REST interface should throw an error. The REST interface should also have functionality to trigger the matrix multiplication and present the results. The gRPC client code should be integrated into the REST interface to call the addBlock and multBlock functions on the gRPC server. Partial marks will be awarded for matrix multiplication which does not allow matricies of an arbitrary size.
A gRPC server which provides access to the addBlock and multBlock functions. These functions should be able to accept any square matrix whose dimensions are powers of 2.
There should be multiple instantiations of the gRPC server. You should have at least eight gRPC servers threads. There are two ways to go about this. You could use a large instance with 8 cores e.g. a e2-standard-8 and configure the gRPC threading model to access each of these cores or you could have 8 small instances e.g. e2-micro and configure the gRPC client to spread the load among these servers. I would recommend the later. Please note that you should have sufficient credit for the module to implement the proposed system if you manage it correctly e.g. stop instances if you are not using them. Managing your credit is part of the challenge so requests for additional credit will not be entertained. The performance improvement via scaling is not quite linear (Adding needs to be done after multiplication) but you should see a signficant performance improvement as you add more gRPC servers.
Frequently large scale workloads use the notion of a deadline to determine how many servers should be assigned to a workload. Your system should have a deadline based scaling function. A footprinting function should be implemented to determine the time required for multiplying one block and this should be used to determine the minimal number of servers required to achieve the deadline. You can ignore the adding time for this component (this may lead to a workload exceeded the deadline which is fine).