1. Lessons learned from a multiplayer RTS development Based on: http://www.gamecareerguide.com/feat ures/20010322/terrano_01.htm - accessed on 17th December 2009 http://www.gamecareerguide.com/feat ures/20010322/terrano_01.htm

2. The article The article is linked from my webpage It is from 2001 and concerns Age of Empires 2, Age of Kings 2 and Age of Empires 3 – There is stuff about modems in there It is an extraordinarily interesting read Particularly note the synchronized simulation

3. Design Goals The design of the multiplayer system started with a series of goals: – “Sweeping epic historical battles with a great variety of units – Support for 8 players in multiplayer – Insure a smooth simulation over LAN, modem-to-modem, and the Internet – Target platform of: 16MB Pentium 90 with a 28.8 modem – The communications system had to work with existing engine – Target consistent frame rate of 15fps on the minimum machine config”

4. Genie Engine Originally the game ran on the Genie Engine: – Single threaded – 2D – Sprites in 256 colours Post optimization performance (roughly) – 30% Rendering – 30% AI and pathing – 30% Running the simulation & maintenance

5. Genie Engine Performance Performance varied greatly As much as 200 msec / frame, depending on what the player was doing – How many items on screen? – Was the user just watching? – What was on the terrain? – What was the AI trying to do?

6. Genie Engine – distributing data What sort of information would we need to distribute per unit? – X and Y coordinates – Orientation – Status – Action – Damage Even just that set would have restricted them to a maximum of 250 active units in the game

7. Solution Simultaneous simulation – Each machine in the game runs the game in a synchronized fashion – Each machine “synchronizes its watch” – Then commands are replicated around the network – Note: commands, not information about units So long as every game starts at the same point and executes the same commands …

8. Network Limitations Latency swings of 20 – 1000 msec (remember, this is 2001) Ensuring that every machine executes every command (bear in mind that receipt of “other” players’ commands will be subject to this latency) would be tricky Solution is to run the simulation two commands behind

9. “Communications Turns” Commands issued on turn 1000 would execute on turn 1002 and commands issued on turn 1001 would execute on turn 1003 Diagram is from the Gamasutra article (op cit)

10. Speed Control The game can only execute as fast as the slowest PC On each turn, each PC sends information about how long the last executed turn took – latency – execution time The designated host would take these messages and work out turn rate to all “clients”

11. Protocol UDP was used for communications Remember, UDP does not guarantee delivery Each packet sent included sequence information – If messages were received out of order, recipient would send a re-send request – If acknowledgement was overdue, the sender re- sends (ie assumes the message was dropped unless it hears otherwise)

12. Security benefits The synchronized nature of the simulation meant that it was difficult to cheat – Any client that is different (eg if someone has added extra food in their client) is tagged as out- of-sync and the game stops.

13. Problems with the approach Suppose a unit is slightly out of alignment – In your simulation he chucks a spear, kills the deer and takes home some food – In mine, he misses the deer and takes home none Even if you have a checksum on the amount of food and that reveals a discrepancy, that is not the cause of the bug, just its symptom

14. Lessons learned 1.Know your user – The article says some interesting things about user perception of latency So long as the latency is steady it is fine up to about 500msec – It is better to be consistent and slow than to be fast most of the time but slow at others – Measure user behaviour How often does your user issue commands? Design the system to cope with peak issuing times (3- 4 commands during battles)

15. Lessons learned 1.Know your user (continued) – Watch out for pathological behaviours At times of excitement users would issue the same command multiple times The developers introduced a filter so that identical commands were not sent over the network multiple times

16. Lessons learned 2.Metering is king – Meter your communications system The developers put in metering to see how the network was behaving Furthermore, they trained their testers on interpreting the metering information

17. Lessons Learned 3.Educate the developers – The team used a system of communication turns – A command issued on turn 500 would be executed on 502. – Programmers had to get used to this concept. – Programmers also had to remember (eg) to re- seed the pseudo-random number generator to ensure that all simulations remained in synch

18. Lessons learned 4.Be careful of third party tools – There is always a danger that they will not operate as you expect them to – Be prepared for testing Simulation applications Stress testing – You have to build these things yourself!

19. Lessons learned 5.Unexpected benefits – The approach they took to simulation made it very easy to do game recording – This was critical for debugging of course – It also turned out to be an extremely popular gameplay feature: Players could replay battles Players could save their performances Players could analyze strategy

20. Task The article on which this lecture is based is from 2001. – Does modern, improved connectivity mean that we don’t need to do this sort of thing anymore? – How does a modern RTS do it?