In **Question 1**, we explore a taxonomy of in-game actions and try to discover why some actions are more sensitive to delay and consistency, while some are not. Here, we introduce two new notions, precision and deadline, or an action. In Part (a) and (b), you are asked to give two examples, one for high-precision, loose-deadline (HP-LD) action, and the other for low-precision, tight-deadline (LP-TD) action. Most of you got these questions correct. My favorite example for LP-TD: player is on-fire and need to jump into the river.

Next, you are asked to *explain* the relationship between precision and tolerable response time, and between deadline and tolerable response time. Many of you answered that there is no relationship between precision needed for the action and the tolerable response time. In fact, the higher the precision needed, the lower the tolerable response time is. Case in point: have you tried clicking on a few target pixels on screen when your mouse cursor movement is delayed after you move the mouse? It is really annoying. Most of you got the relationship between deadline and tolerable response time correct though (loose deadline means higher tolerable response time).

Finally, in Question 1, you are asked to explain what type of actions is good for short-circuiting, which reduces response time and increases inconsistency. About half got this correct: LP-TD. Since low precision is needed, inconsistency is tolerated, but low response time is good for tight-deadline action.

For **Question 2**, if you understand the question and DDM, the first two parts are giveaways. S_{L} will never overlap with U_{R}, and S_{R} will never overlap with U_{L}. On the other hand, S_{LR} will always overlap with U_{LR}.

Next, you are asked to sketch a recursive algorithm. The idea is basically, to call split() on S and U to partition the input into six partitions. The pairs in S_{LR} will always overlap with U_{LR}. For the rest, we recursively call DDM on the following pairs: S_{L} and (U_{L} union U_{LR}), S_{R} and (U_{R} union U_{LR}), and S_{LR} and (U_{L} union U_{R}). There is no need to consider those that never overlaps. Some of you got partial credits because you only recusrively call DDM on S_{L} and U_{L}, and S_{R} and U_{R}.

Now, for **Question 3**, Part (a) is mostly a give away: delayed ack is implemented in the receiver only; fast retransmission and exponential backoff on the sender only; and redundant data bundle needs to be implemented on both sides (since receiver needs to make sense of the bundled data from the sender). Part (b) is also quite straightforward. If the NIC sleeps for too long, it could cause the connection to idle for more than RTO, and the connections’ congestion window resets. If it sleeps even longer, the TCP connection might time out and three way handshake is needed to reestablish the connection. Either way, the connection restarts from slow-start phase again.

**Question 4** receives several answers that do not use virtual network coordinates and got 0. For the rest, as long as you explain how players can establish its network virtual coordinate (by obtaining a few landmarks from the server, measuring RTT to them, then reporting the RTT or coordinate back to the server) and how the server does matchmaking (by clustering the players using distance computed from the coordinate), you get 15.

Finally, **Question 5** is the one that stumped most of you. The answer can be summarized in two words: frontier region. If two players have no chance of entering each other AOI, there is no need to exchange position update, and this can be achieved through frontier region.

It is disappointing that many of you answered: if two players are not in each other’s AOI, then there is no need to exchange position update. The problem is that, if two nodes do not know the latest position of each other, how do they know that they are in each other’s AOI or not? A similar answer is that two players are very far apart, then they do not have to exchange position update. But did not explain “how far”, nor did the answers explain how can a node know if the other node is far, without know its latest position!

The other popular answer that received a small partial credit is that, if two players (say, A and B) have a common neighbor (C), then they need not exchange position update, since C can tell A and B when A and B enters each others’ AOI. This is correct but incomplete. If A, B, and C are mutually enclosing neighbor of each other, then by this rule, they would not exchange position update so C would not know A and B’s latest positions!

I am, however, quite delighted that a few of you came up with an unexpected answer that is correct: if A is moving away from the last know position of B, it need not update B (and vice versa). The rational is that if A and B are not in each other AOI’s to begin with, then this movement would never cause A and B to enter each other’s AOI.

I hope you had fun answering the paper, which ties up quite a few disparate ideas together, and learn something new in the process. Cheers.

]]>I would like to make all your repo public. If you have any concern about me doing so (e.g., you committed some embarassing code, you included some commercial library/asset), let me know before May 15.

Considering only the academic expectation of CS4344, here are your grades. Most teams that made good decisions about how to deal with network delay and synchronize the game states receive A-/A/A+ range. A few team is lacking in this respect and receives B/B+. A few students received one grade lower than the rest of the teammates, as their contributions are significantly less as reflected in git’s commit log.

024U B 063M A+ 075E A 076N A 103N B- 217A A- 234N A 422A A 441B A 454U A 498A A+ 541L A- 557Y B 656X A- 676R A- 683X B+ 695H B+ 718U B+ 726B A- 734A B+ 742W B+ 747W A- 751U A 758E A- 812X A+ 829B A+ 856J B+ 860W B 909Y A 924M A- 924R A+ 934R A+ 988U B 998R A+]]>

This is an open ended assignment and many different solutions are submitted. The best (and closest to the solution I came up with) is the one by Yang Shun and Hieu (read their report here). Basically, the idea is to find the set of ships that could possibly collide with a rocket, and only send the “fire” commands to these ships. Two other teams have similar solutions. This turned out to be tricky to compute, but with some thoughts, it is doable.

Another popular solution that does not work as well is to use cell-based, distance IM (either a fixed distance or a “cross” ala Problem Set 2). If “turn” or “fire” are sent only when the ship/rocket enters into the AOI, the player will see sudden appearance / teleportation of ships/rockets. Depending on the implementation, this could be either subtle or annoying. Another tricky part is to compute the cell a ship/rocket is in efficiently. If you compute the cell every gameLoop(), it is going to be slow. So you need to predict when a rocket/ship will cross the boundary and update the cell the rocket/ship belongs to only then.

Most of you got the efficiency part right, by considering only rockets and ships in each other’s AOI. But, note that if you recompute the AOI of every rocket and every ship in a loop before checking hasHit(), it does not actually make it more efficient! It would be more efficient only if hasHit() is more expensive to compute than the AOI, which is not the case here.

Several teams tried the multiple server solutions, but none got it perfectly right.

024U 12 063M 16 075E 13 076N 14 103N 12 217A 12 234N 14 422A 13 441B 10 454U 10 498A 16 541L 12 557Y 12 613L 12 656X 13 676R 13 683X 13 695H 13 718U 13 726B 13 734A 15 742W 12 747W 13 751U 12 758E 12 812X 14 829B 14 856J 12 860W 13 909Y 12 924M 12 924R 13 934R 15 988U 12 998R 13]]>

The three projects identified as particularly outstanding by the judges are Elemetal Frenzy, Fighting Arena, and Nutty Ninja X. Here are their trailers!

]]>By now, you should have received an email with comments on your specific assignment. Do let me know if there are any surprises or bug in my marking.

]]>024U 6 063M 11 075E 10 076N 7 103N 7 217A 6 234N 7 422A 10 441B 5 454U 5 498A 11 541L 6 557Y 7 613L 3 656X 10 676R 10 683X 7 695H 7 718U 7 726B 6 734A 7 742W 6 747W 6 751U 8 758E 7 812X 7 829B 7 856J 6 860W 7 909Y 8 924M 8 924R 7 934R 7 988U 6 998R 7]]>

Remember to check out the STePS FAQ and tips for making good posters.

]]>- Date: 29/04/2015 (Wed)
- Time: 9:00 AM
- Venue: SR2