Distributed Computing Systems

1. Distributed Computing Systems Project 4 – Dragonfly Wings Extending the Dragonfly Game Engine with Networking Due date: Friday, May 2nd, 11:59pm

2. Synopsis • Goals • Understand implications of distributing shared, virtual world on multiple computers • Realize implementation of distributed system • Acquire familiarity with networking for game engine • Gain experience using fundamental networking code • Objectives • Implement distribution of state in virtual world • Extend single player game to two player, networked game with client-server architecture • Design and implemented network functionality for game engine • Implement networking (TCP/IP) socket code from scratch • Extend Dragonfly with network support • Create two player, 2d game using engine

3. Outline • Overview • Project • Game engine • Dragonfly extensions • Network Manager • Network Events • Hints • Experiments • Hand In • Grading

4. Dragonfly Overview • Text-based game engine • Primarily to teach about game engine development • But full-featured (graphics animation, collisions, input/output)  can make real games! • Does not provide networking support • (That’s the goal of this project!) (High-level architecture slide next)

5. Dragonfly Overview GAME CODE Saucer: hit() Hero: kbd() Star: onEvent() TextMessage: step() DRAGONFLY DrawCharacter InsertObject LoadSprite GetKey MoveObject SendEvent COMPUTER PLATFORM Allocate memory Clear display File open/close Get keystroke

6. Tutorial Overview • Good overview of Dragonfly through tutorial • Setup development environment for building • Work through tutorial making a game • Get used to Dragonfly • 2D (text-based graphics) game engine • From game programmer’s perspective • In this project, you both game programmer (Saucer Shoot 2) and engine programmer (networking) • Learn enough about game to extend to two-player version

7. What is a “Text-based” Game?

8. Why Text-based Graphics? • Conceptually easy • (x,y) location, all cells • Platform independent (mostly) • Curses (NCurses) ported nearly everywhere • All modern terminal windows support • e.g., Linux/Mac shell • e.g., Windows command prompt • Reduce temptation to spend time on art • “Programmer art” is ok!

9. Text-based Graphics Sprites • Animations stored in Sprite file • Read in by engine before use • Sprite file with fixed format • Note, must be exact (spaces) • Included sprites (sprites.zip) all work with tutorial • Note, if doing your own may need to “deubug” art • If doesn’t load, see “dragonfly.log” for messages • Dragonfly does 30 updates/second ( can potentially change frame each update) • Use Object setSpriteSlowDown() if slower

10. Tutorial • Saucer Shoot • Online: http://dragonfly.wpi.edu/tutorial/ • Work through start to finish • “Cook-book” like, but with some explanations • Need Sprite package (sprites.zip) • Also available is source code if stuck (gameX.zip) • Internal understanding not necessarily needed • That is a whole other class! • Basic external understanding expected • Needed when extending Saucer Shoot game

11. A 10,000-Foot View of Game Code • Startup Game Engine • Initialize graphics, input devices, file logging • Populate World with Objects • Player object (Hero), Enemies (Saucers), Decorations (Stars) • Run Game • Move objects, get input, send events to objects (e.g., collisions), draw screen (objects draw themselves) • Game engine does most of this work! • Shutdown

12. Core Attributes of Engine in Tutorial • Startup • Managers – how invoked • Objects – these need to by synchronized across platforms! • Made once (Hero, Stars) • Made many times (Saucers, Bullets, Explosions) • Events • Built-in: Keyboard, Collision • Custom: Nuke • Not explicit, but also • Debugging (own code) • Reading (and using) logfiles

13. Platforms • Engine can be developed on common desktop development environments • Unix, including Linux and FreeBSD • Windows, including Windows XP, Windows 7 and Windows 8 • With Cygwin (Unix-like environment) • MacOS

14. Development Environment Tools and Libraries Environment Make (and makedepend) Editor (e.g., emacs or vi) Debugger (e.g., gdb or ddd) • C++ compiler • Standard C++ libraries • NCursesdevelopment libraries • Terminal window Note: Eclipse can be used for all environment options, but will still need tools and libraries installed

15. Dragonfly Documentation http://dragonfly.wpi.edu/documentation/

16. Outline • Overview (done) • Project • Game engine • Dragonfly extensions (next) • Network Manager • Network Events • Hints • Experiments • Hand In • Grading

17. Dragonfly Classes Utility Events Managers Objects Scene graph Add Manager Add Event

18. Managers class Manager { private: boolis_started; // True when started successfully. public: Manager(); virtual ~Manager(); // Startup Manager. // Return 0 if ok, else negative number. virtual intstartUp(); // Shutdown Manager. virtual void shutDown(); // Return true when startUp() was executed ok, else false. boolisStarted(); // Send event to all interested objects. // Return count of number of events sent. intonEvent(Event *p_event); // Indicate interest in event. // Return 0 if ok, else -1. // (Note, doesn't check to see if Object is already registered.) intregisterInterest(Object *p_o, string event_type); // Indicate no more interest in event. // Return 0 if ok, else -1. intunregisterInterest(Object *p_o, string event_type); }; • Notes: • Base class • Other managers inherit • virtual ensures derived calls

19. Managers: C++ Singletons • Idea - compiler won’t allow creation (so have only 1) MySingleton s; • Instead: MySingleton &s= MySingleton::getInstance(); • Guarantees only 1 copy of MySingleton will exist  Use for Network Manager class Singleton { private: Singleton(); Singleton(Singletonconst&copy); Singleton&(Singleton const&assign); public: static Singleton &getInstance();. }; // Return the one and only instance of the class. Singleton &Singleton::getInstance() { // A static variable persists after method ends. static Singleton single; return single; };

20. Network Manager (1 of 2) class NetworkManager : public Manager { private: NetworkManager(); // Private since a singleton. NetworkManager(NetworkManagerconst&); // Don't allow copy. void operator=(NetworkManagerconst&); // Don't allow assignment. intsock; // Connected network socket. public: // Get the one and only instance of the NetworkManager. static NetworkManager &getInstance(); // Start up NetworkManager. intstartUp(); // Shut down NetworkManager. void shutDown(); // Accept only network events. // Returns false for other engine events. boolisValid(string event_type); // Block, waiting to accept network connection. intaccept(string port=DRAGONFLY_PORT); …

21. Network Manager (2 of 2) … // Make network connection. // Return 0 if success, else -1. intconnect(string host, string port = DRAGONFLY_PORT); // Close network connection. // Return 0 if success, else -1. intclose(); // Send buffer to connected network. // Return 0 if success, else -1. intsend(void *buffer, intbytes); // Receive from connected network (no more than bytes). // Return number of bytes received, else -1 if error. intreceive(void *buffer, intbytes); // Check if network data. // Return amount of data (0 if no data), -1 if not connected or error. intisData(); // Return true if network connected, else false. boolisConnected(); // Return socket. intgetSocket(); };

22. Dragonfly Events • Built-in events derive from base class • Game programmer can define others • e.g., “nuke” • Use for network event (EventNetwork)

23. #include <string> #define UNDEFINED_EVENT"__undefined__" using std::string; class Event { private: string event_type; // Holds event type. public: // Create base event. Event(); // Destructor. virtual ~Event(); // Set event type. void setType(string new_type); // Get event type. string getType(); }; Event.h

24. EventNetwork.h #include "Event.h" #define NETWORK_EVENT"__network__" class EventNetwork: public Event { private: intbytes;// Number of bytes available public: // Default constructor. EventNetwork(); // Create object with initial bytes. EventNetwork(intinitial_bytes); // Set number of bytes available. void setBytes(intnew_bytes); // Get number of bytes available. intgetBytes(); };

25. Using Events • Objects register with appropriate Manager • Engine knows about built-in events • All user-defined events go to World Manager • Note: won’t really know about network events • Need to explicitly register with Network Manager • When event occurs, call appropriate Manager’s onEvent()method • Pass in event. E.g., NetworkManager &network_manager = NetworkManager::getInstance(); EventNetwork en; network_manager.onEvent(&en);

26. Client and Host Objects • Host object (derived from Object) runs on server • Client object (derived from Object) runs on client • Host game started first, whereupon Host (using the NetworkManager) readies computer for connection • Client (also using NetworkManager) starts after and connects to Host • Each game step, Host checks all game objects to see which ones are new (their Object id's are modified) • Synchronized via NetworkManager • Client receives object data over network, updating Objects • Host receives keystrokes sent by Client, generating network events to game objects (e.g., the Client Hero) to handle

27. Extending Tutorial Game – Saucer Shoot 2 (1 of 3) • Need core gameplay only (e.g., hunting Saucers) • No GameStart and GameOver • Nukes also optional • Once connected, can go right to gameplay • Once Hero dies, can exit • Note: additional features (e.g., GameStart) for Miscellaneous points (below) • Add additional code (and sprites, if needed) • Networking from independent computers (a distributed system) • Two-player (one can play “on server”)

28. Extending Tutorial Game – Saucer Shoot 2 (2 of 3) • Possible functionality • Simultaneous Heroes (same side, opposite sides) • Second player controls Saucer(s) • Your own clever idea! • Many decisions for multiplayer game • How player actions are transmitted to the server • How inconsistencies between client and server game states are resolved • What Objects are synchronized and how often • Key aspect – how to “send” an Object from one computer to another

29. Extending Tutorial Game – Saucer Shoot 2 (3 of 3)

30. Serializing (Marshalling) Objects // Object class methods to support serialization // Serialize Object attributes to single string. // e.g., "id:110,is_active:true, ... // Only modified attributes are serialized (unless all is true). // Clear modified[] array. virtual string serialize(bool all = false); // Deserialize string to become Object attributes. // Return 0 if no errors, else -1. virtual intdeserialize(string s); // Return true if attribute modified since last serialize. boolisModified(enumObjectAttribute attribute); • Derived classes (e.g., game objects) need to (de)serialize own attributes. • (See helper functions next slide) • Call parent methods

31. Utility Functions // Convert integer to string, returning string. stringtoString(inti); // Convert float to string, returning string. stringtoString(float f); // Convert character to string, returning string. stringtoString(char c); // Convert boolean to string, returning string. stringtoString(bool b); // Match key:value pair in string in str, returning value. // If str is empty, use previously parsed string str. // Return empty string if no match. string match(stringstr, string find);

32. Synchronizing Objects (1 of 2) • Only synchronize important objects and events (e.g., Hero destruction vs. Stars moving)

33. Synchronizing Objects (2 of 2) • Have Configuration for game (host | client) • Can keep same codebase for Hero, Bullet, Points… • Generally, only Host creates/destroys • Except for Explosion • Generally, Host and Client move and animate • Except for Client Hero (see below) • Client Player input • Could update ship and synchronize • But if not allowed, need to “roll back” state • Instead, send keystrokes to server • Let server move all Objects and send to client

34. Messages // Suggested Format: // + Header (HEADER_SIZE): // + size is one int. // + message type is another int. // + if NEW then next int is object type, // + else UPDATE and next int is object id. // Rest is serialized Object data (string). // Note, if Object hasn't been modified, nothing to send. // Return 1 if sent, 0 if not sent, -1 if error. #define HEADER_SIZE3 * sizeof(int) // Types of messages from Host to Client enumMessageType { ADD_OBJECT, UPDATE_OBJECT, DELETE_OBJECT, }; • Suggested message structure • Client can “peek” at data, not pulling from socket until size bytes available • At least one message complete • After pulling message, can check type and take appropriate actions

35. Outline • Overview (done) • Project • Game engine • Dragonfly extensions (done) • Network Manager • Network Events • Hints (next) • Experiments • Hand In • Grading

36. Dragonfly Question-Answer http://alpheus.wpi.edu:8080/osqa/

37. The LogManager - Functionality • Manages output to log file • Upon startup  open file • Upon shutdown  close file • Attributes • Need file handle • What else? • Method for general-purpose messages via writeLog() • E.g., “Player is moving” • E.g., “Player is moving to (x,y)” with x and y passed in • Could include time - game or wall clock (optional)

38. Using the LogManager(1 of 2) // Get singleton instance of LogManager. LogManager &log_manager = LogManager::getInstance(); // Example call with 1 arg. log_manager.writeLog( “NetworkManager::connect(): Socket is open"); // Example call with 2 args. log_manager.writeLog( “NetworkManager::receive(): read %d bytes”,bytes); // Call with 3 args. log_manager.writeLog( “Hero::kbd(): Hero is at is position (%d, %d)", x, y);

39. Using the LogManager (2 of 2) • Tip #2! • When calling writeLog()include information: • Class name • Method name • // Sample logfile output: • 07:53:30 Log Manager started • 07:53:31 GraphicsManager::startUp(): Current window set • 07:53:31 GraphicsManager::startUp(): max X is 80, max Y is 24

40. Once-only Header Files • "Redeclaration of class ClassName...“? • When header included first time, all is normal • Defines FILE_FOO_SEEN • When header included second time, FILE_FOO_SEEN defined • Conditional is then false • So, preprocessor skips entire contents  compiler will not see it twice // File foo.h #ifndefFILE_FOO_SEEN #define FILE_FOO_SEEN // The entire foo file appears next. class Foo{ … }; #endif// !FILE_FOO_SEEN

41. Protocols and Sockets • TCP – stream oriented, may have part of a message • Check that header arrives, header has message size, then check that full message arrives • UDP – frame boundaries (e.g., message) preserved, but message may be lost • If matters (could ignore), use sequence numbers to detect • Non-blocking via MSG_DONTWAIT for recv() • ioctl(sock, FIONREAD, &bytes) to get byte count

42. Dragonfly Book The book Dragonfly - Program a Game Engine from Scratch guides programmers through the implementation of a full-featured, 2d, text-based game engine. • If interested: • Order for cost (see me) • Borrow from IMGD student

43. Outline • Overview (done) • Project • Game engine • Dragonfly extensions (done) • Network Manager • Network Events • Hints (done) • Experiments (next) • Hand In • Grading

44. Experiments (1 of 3) • When done (networking and Saucer Shoot 2) • Measure: 1) network data rate from server to client 2) network data rate from client to server 3) in-game round trip time • Consider in-game aspects • Data rate over time (e.g., game beginning, middle, end) • Gameplay during measurements • Number of Objects in game (e.g., more saucers as time progresses) • Player actions (e.g., frantic moving and shooting)

45. Experiments (2 of 3) • Network data rates • Instrumenting code to write data out to logfile each packet sent/received • Analysis on packet sizes, packet rates and bitrates • At least one graph of network bitrate (e.g., Kb/s) over time • In-game round trip time • Timing when player inputs a key until action on screen • Logfilemessages placed at right points in client code • Analysis on average, min and max • System call gettimeofday()for system time • Multiple measurements

46. Experiments (3 of 3) • Design - describe experiments • a) how instrumented/measured • b) number of runs • c) system conditions • d) any other relevant details • Results - depict results clearly • Tables and/or graphs • Statistical analysis where appropriate • Analysis - interpret results • What the results mean • e.g., scalability to more players? • playability over networks? • Any subjective analysis

47. Outline • Overview (done) • Project • Game engine • Dragonfly extensions (done) • Network Manager • Network Events • Hints (done) • Experiments (done) • Hand In (next) • Grading

48. Hand In (1 of 2) • Source code package • All code necessary to build your engine modification (well-structured, commented) • Any other support files, including .h files. • A Makefile • You do NOT need to turn in any Dragonfly headers or libraries • Game code for Saucer Shoot 2: • All code necessary to build your game (well-structured, commented) • Sprites (including all “default” sprites) • A Makefile • README file explaining: • Platform • Files • Code structure • How to compile • How to run • Anything else needed to understand (and grade) your game

49. Hand In (2 of 2) • When ready, upload (WinSCP) to ccc.wpi.edu mkdirlastname-proj4 cp* lastname-proj4 tar czvfproj4-lastname.tgz lastname-proj4 • Submit your assignment (proj4-lastname.tgz): /cs/bin/turnin submit cs4513 project4 proj4-lastname.tgz • Verify /cs/bin/turnin verify cs4513 project4 • Turnin help at • http://www.cs.wpi.edu/Resources/turnin.html • Due at mid-night (11:59pm)

50. Grading • Networking Support 25% • Socket-based code • Integrated with Dragonfly as Manager • Saucer Shoot 2 50% • Networking • Distributed Object synchronization • Enhanced gameplay for 2nd player • Experiments 20% • Design, Results, Analysis • Miscellaneous 5% • Flexibility in grading • “Extra” points can apply to any section