CSE 381 Advanced Game Programming

1. CSE 381Advanced Game Programming Sockets

2. Programming with TCP • Transmission Control Protocol • Has layers of error checking • Guaranteed Packet Delivery • All or error • Makes it easier to deal with • No worries for packet loss, packet splitting, packet corruption • Just keep an eye out for socket exceptions

3. Programming with UDP • User Datagram Protocol • No guaranteed delivery. You don't know: • when your packet will get to its destination • If it even made it there • If your data was split into multiple piecees • What's good about it? • lightweight

4. ACKs • TCP waits for ACKs from receiver • What's an ACK? • Acknowledgement • TCP Application can wait for ACKs before sending more. Why? • prevent wasting bandwidth • Alternative: nonblocking socket

5. Nonblocking Socket • TCP Socket setting • Doesn't wait for ACK after each send • Allows you to stuff data in pipe as fast as you want • Operates asynchronously • As opposed to a blocking socket • easier to program, less useful for game programming

6. Internet Addresses • All computes with TCP/IP have unique IP Address • some through their own network which provides access point (LAN) • i.e. unique to sub-net • IPv4 32 bits • IPv6 128 bits • big enough so every living human may have their own 5 x 1028 addresses

7. IPv4 Address Representations • It's just a 32-bit number • Decimal: • 3486000987 • Not easy for humans to remember • Hex: • 0xCFC8275B • not much better • Dotted Decimal Format: • 207.200.39.91 • now just remember 4 numbers

8. Sockets Libraries • Handle low-level network communications. Ex: • Berkeley Sockets • WinSock

9. Sockets API • Provide: • Initialization and shutdown • Utility functions • Domain Name Service (DNS) functions • Creating Sockets and Setting Socket Options • Connecting client sockets to a server • Server functions • Reading and writing from sockets

10. Sockets Init & Shutdown • Must startup library before using any other functions int WSAStartup(WORD wVersionRequested, LPWSADATA lpWSAData) Ex: WORD wVersionRequested = MAKEWORD(0, 2); WSADATA wsaData; int err = WSAStartup(wVersionRequested, &wsaData); • When you're done, deregister the application: int WSACleanup(void)

11. Utility Functions • Help with conversions • Ex: unsigned long inet_addr(const char* cp) • converts string IP (i.e. “127.0.0.1”) to num htonl, ntohl, htons, ntohs • used to convert endian-ness of numbers between host machine order and network order • Ex: • Intel is little-endian • Internet standard is big-endian

12. DNS Functions • Help with locating hosts • Ex: struct hostent* FAR gethostbyname( const char* name) • gets host info, like IP address, by host name struct hostent* FAR gethostbyaddr( const char* addr, int len, int type) • gets host info, like host name, by IP address

13. DNS Example • Let's print the IP Address of microsoft const char *host = "ftp.microsoft.com"; struct hostent *pHostEnt = gethostbyname(host); if (pHostEnt == NULL) fprintf(stderr, "No such host"); else { struct sockaddr_in addr; memcpy(&addr.sin_addr, pHostEnt->h_addr, pHostEnt->h_length); printf("Address of %s is 0x%08x\n", host, ntohl(addr.sin_addr.s_addr)); } Address of ftp.microsoft.com is 0xcf2e858c

14. Creating Sockets • To create a socket: SOCKET socket(int address_family, int socket_type, int protocol) • Some families: • PF_INET (Ipv4), PF_INET6, PF_DECnet, PF_APPLE-TALK, PF_ATM • Socket types: • SOCK_STREAM, SOCK_DGRAM, SOCK_RAW • Protocols • IPPROTO_TCP, IPPROTO_UDP

15. Changing Socket Settings • To change a socket: int setsockopt(SOCKET socket, int level, int optionName, const char* optionValue, int optLen) • Like what settings? Ex: • disabling internal buffering (trade bandwidth for speed) • To specify socket as blocking/nonblocking: int ioctlsocket(SOCKET s, long command, u_long* argumentPointer)

16. Ex: Making a nonblocking Socket • May only be called on a “live” socket • a client connected to a server • a server listening for clients // 1 = unblocking, 0 = blocking unsigned long val = 1; ioctlsocket(m_sock, FIONBIO, &val);

17. But what are we going to connect to? • A server waiting on a port for connections • On server side specify where to listen: int bind(SOCKET s, const struct sockaddr* name, int namelen) Then listen: int listen(Socket s, int backlog) And when a client requests a connection, accept it: SOCKET accept(SOCKET listenSock, const struct sockaddr* name, int namelen)

18. What if a client knocks on the door? • When a client requests a connection, accept it: SOCKET accept(SOCKET listenSock, const struct sockaddr* name, int namelen) Later, we can make sure the client is still there: int select(int nfds, fd_set* readfds, fd_set* writefds, fd_set* exceptfds, const struct timeval* timeout))

19. So how does the client request a connection? • Connect to listening server via connect: int connect(SOCKET s, const struct sockaddr* name, int namelen)

20. Socket Reading & Writing • To send and receive bytes: int send( SOCKET s, const char* buffer, • int length, int flags) • int recv( SOCKET s, char* buffer, • int length, int flags) The send side is pushing bytes into the pipe The recv side is pulling them out

21. So what do we do with sockets? • Common multithreaded approach: • Server Side: • dedicate a thread to listen for each client • Client Side: • dedicate a thread to listen for server • wire sockets into event system

22. Client Sockets & Events • Translate network data into events • recv packets • interpret packets • fire local events to update game state • Translate events into network packets • requires common event system contexts • Implement translation through streaming system • i.e. employ STL's istrstream & ostrstream

23. The Event System • Requires contexts, meaning abstractions of different types of events • Event System obligations: • for sending: • translate events into contexts to send • employ stream/sockets system to build and send packets • for receiving (after packet translated into context) • wire contexts into actions (methods)

24. What’s an MMO? • MMO: Massively Multiplayer Online • MMOG: Massively Multiplayer Online Game • MMOPW: Massively Multiplayer Online Persistent World • MMORTS: Massively Multiplayer Real Time Strategy Game • MMORPG: Massively Multiplayer Role-Playing Game • Everquest, Tactica online, Final Fantasy XI, etc. • Descendants of MUDs (Multi-User Dungeons) • 1979, Roy Trubshaw and Richard Bartle

25. Types of MMOs • MMORPG • immersive worlds • replace your own life with that of your own avatar • typically each player controls a single unit • MMORTS • strategy & quick thinking more important • typically each player controls dozens of units • units may be visible, though far away • thousands of units may be visible at a time • more data transferring required than MMORPGs • have not yet caught on

26. Source: http://www.mmogchart.com/

27. Source: http://www.mmogchart.com/

28. Source: http://www.mmogchart.com/

29. MMORPG Demographics • Typical MMORPG player: • Male • 13 – 34 years old • Median late 20s/early 30s • ½ are heavy users, playing more than 18 hours/week • tend to play one game at a time • many still stay after maxing out game – why? • Most important feature to players? • character customization • Problems severe enough to make players consider leaving game? • not enough new content, bugs, latency, cheating

30. MMO Costs • Everquest uses thousands of clustered server boxes working together in a redundant network • a server box may contain multiple CPUs • each server can handle 200-300 players • additional redundancies necessary as well • Continually tweak balance to avoid “dead servers” • Other costs of course: • networking hardware • trained personnel • air conditioning • MMOs are a very expensive market to enter • As games get more popular, they get much more expensive to maintain • small companies commonly sell growing games to larger companies

31. Updating Data Revisited • Unique data challenges: • thousands of players share the same contiguous virtual space • huge, expansive world • in many cases, user created • each player needs to receive information about their immediate surroundings • updating all the information (in excess of 50KB/sec) around each of the players’ units all the time may be impractical • Bottom line: only update what needs updating

32. Additional Processing Problems • Huge computational demands for AI • both for players and for the computer adversaries needed to act against these players • typical virtual worlds might include millions of AI units • Huge computational demands for path-finding • large maps needed to house thousands of players are problematic for standard path-finding techniques • Data consistency • across multiple servers • all connected clients • can get very complex

33. World Segmentation • To save on data transferring • Divide the world into small square regions • each region must be bigger than the highest line of site radius • don’t worry about info that can’t be seen • for each region, keep track of: • all the elements in the region • all the players who should receive information about that region • players viewing the region

34. Crossing Regions • World segmentation on the server before and after unit A in D4 crosses to E4. • The gray areas are regions marked as viewed for the player who owns units A. • Units that belong to other players are marked as b (viewed), x (not viewed).

35. Alternative: Selective Continuous Updating • World segmentation on the server before and after unit A in D4 crosses to E4 • The light gray areas are regions marked as viewed for the player who owns units A • Light gray are CU (Continuously Updated) • Dark gray are PUR (prediction used)

36. Approach for Maintaining Data for (each region of map R) do { for (each connected player P viewing region R) do for (each element E in region R) Create message updating element E’s state } for (each connected player P) do { Compress all messages to player P Send messages to player P } • This gets complicated for RTS when a player’s units may be scattered over multiple regions

37. MMO Architecture • Client/Server dominates • implementation requires scalability, reliability, and speed • also requires measures to enforce subscriptions and prevent cheating • Plus a database. For what? • world info (ever changing) • game state • player/character info

38. MMORPG Communications Example • Ex: a player wants to strike an enemy with a sword • Player sends an action message to the game server • communicates that player wants to "strike" an enemy • at this point, the player cannot send further messages until this message - including ALL of the packets that comprise it - is received by the server, processed by the game engine, and an update message sent back to the player • the moment a player's PC initiates an action, the PC is locked up until the above scenario plays out • Server receives message in queue with messages sent from hundreds, or thousands, of other players • The server’s game engine deciphers the action message and calculates the necessary information to determine the outcome of the action "strike with sword." • the engine will consider many factors, including the statistics of the player and the enemy, the properties of the sword, etc. • The game engine determines the outcome and communicates this event to the player, along with all potentially affected players • The player and his or her fellows will now experience the action as it is displayed on their computer screens

39. More Saving on Data Transfer • Only update game state data that has changed • Only update position if it changes and the velocity changes • each client can use dead reckoning reliably otherwise

40. Additional Issues to Consider • Game Lobbies • Subscriptions • Virtual Economies • Cheating • Farming

41. Game Lobbies & Subscriptions • Client/Server of course • Middleware opportunity • uniform expectation for all games • players don’t come back for more because of the lobby • Ex: Gamespy • can support hundreds of thousands of players searching for games • enable chat & voice • tournaments, ladders, etc. • automatic game patching • etc.

42. Virtual Economies • More an more games encourage trade • Some even use currency • Ex: Second Life • Creates a game within a game • Can help build communities • Player accounts have additional security concerns in such games • government regulation seems inevitable on some level • virtual taxes?

43. Cheating • Can ruin a gaming experience • Comes in so many forms, sometimes there is no programming solution to prevent it • when action is taken outside the virtual world • Game performance vs. Cheating prevention • Pure Client/Server vs. Hybrid • Encryption vs. Plaintext

44. Categories of Cheating • Exploiting Misplaced Trust • tampering with client side code • ex: map hack • Collusion • common in card games • Abusing the Game Procedure • I’m losing so I’m quitting or slowing down • Abusing Virtual Assets • not paying for acquired assets, using farms • Exploiting Machine Intelligence • using Deep Blue on Yahoo chess

45. Categories of Cheating (2) • Modifying Client Infrastructure • changing a graphics driver to ones advantage • ex: to see through walls, “wall hack” • Denying Service to Peer Players • flood an opponent’s network connection • Timing Cheating • Delay moves until opponents moves are known, “look ahead hack” • “suppress correct cheat”, purposely drop update messages at the right time • Compromising Passwords • roam around looking for newbies • tell them you are the administrator and need their password • hope they are 12 years old and dumb

46. Categories of Cheating (3) • Exploiting Lack of Secrecy • sniffing unencrypted data • Exploiting Lack of Authentication • setting up a bogus game server • re-authenticate idle players – issues at Internet cafes • Exploiting a Bug or Loophole • farming • gameplay for some vs. cheating for others • Compromising Game Servers • hack a server, screw everything up • Related to Internal Misuse. • evil employees

47. Farming • A player kills monsters in the game for the money and items that the monster drops • Players who farm usually: • camp an area • kill monsters as they spawn • collect the loot • sell the items to others • Sweatshop farming in: • China, Mexico, and others • see http://www.1up.com/do/feature?cId=3141815 • Other MMO terms: • loot whore • twink • zerging

48. What else? • MMOFPS • not many so far • Ex: • World War II Online (2001) • PlanetSide (2003) • Control Monger (2005) • Huxley (2006) • Lord of the Rings Online: Shadows of Angmar • http://lotro.turbine.com/ • Want a job at Turbine Games in Westwood, MA? • http://www.cytiva.com/cejobs/templateTurbine.asp

49. References • A Systematic Classification of Cheating in Online Games by Jeff Yan and Brian Randell • Addressing Cheating in Distributed MMOGs by Patric Kabus, Wesley Terpstra, Mariano Cilia, Alejandro Buchmann • Alternate Reality: The history of massively multiplayer online games. by Steven L. Kent • http://archive.gamespy.com/amdmmog/week1/ • Analysis of Factors Affecting Players’ Performance and Perception in Multiplayer Games by Matthias Dick, Oliver Wellnitz, Lars Wolf • From sweatshops to stateside corporations, some people are profiting off of MMO gold.by James Lee • http://www.1up.com/do/feature?cId=3141815

50. More References • High Latency Multiplayer Gaming by Edward Hannay • John Carmack’s Blog • http://www.armadilloaerospace.com/n.x/johnc • Massively Multiplayer Game Development 2 by Gideon Amir and Ramon Axelrod • MMO Demographics, Trends Explored in Survey • http://www.gamasutra.com/php-bin/news_index.php?story=6582 • Networking Multiplayer Games by Sugih Jamin • http://ai.eecs.umich.edu/soar/Classes/494/talks/lecture-15.pdf