Implementation of a Peer-to-Peer Multiplayer Game with ... - DVS

More documents

Recommendations

Info

API IntroductionThis section briefly introduces the Irrlicht C++ API. As this is only an overview, it is recommendedto refer to the complete API 4 for detailed descriptions. The Irrlicht API classes are assigned to severalnamespaces. All parts of Irrlicht are in the top level namespace irr which has the sub-namespacesirr::core, irr::gui, irr::io, irr::scene and irr::video. In the following, there will be no referencesto the namespaces of the particular classes; again, refer to the complete documentation for anydetails.The core class of the Irrlicht API is IrrlichtDevice. Each application using Irrlicht usually creates oneinstance of that class. Instances are created using the function createDevice. createDevice has severaloptional parameters of which the most important allow specifying the 3D device type (i.e., whether touse software rendering, Direct3D, OpenGL or none), window size and color depth. An IrrlichtDeviceobject holds a video driver (IVideoDriver) and a scene manager (ISceneManager) object.The ISceneManager object represents the virtual scene that is to be rendered. A scene containsany number of scene nodes (ISceneNode). Subclasses of ISceneNode implement the various scenenode specializations, e.g., meshes, animated meshes, terrain, text, light sources and cameras. A newscene node is added using one of many corresponding ISceneManager methods of which most arenamed add...SceneNode. For instance, ISceneManager::addMeshSceneNode adds a mesh scene nodefrom a mesh (IMesh) that can easily be loaded from a file using ISceneManager::getMesh. Differentkinds of animations (e.g., movements, rotations or delayed deletes) can be realized by assigningISceneNodeAnimators to scene nodes.To be able to render the scene, it is necessary to have a camera scene node. Such is added usingaddCameraSceneNode or one of the two specialized versions addCameraSceneNodeFPS and addCamera-SceneNodeMaya which already support basic user control.IVideoDriver is used to control anything related to the screen. For rendering the scene, you first haveto call IVideoDriver::beginScene, then ISceneManager::drawAll and finally IVideoDriver::endScenewhich results in the presentation of the rendered image on the screen. Besides drawing the whole scene,it is also possible to perform direct 2D or 3D drawing to the video driver object between the beginSceneand endScene calls. Loading textures is also done via the video driver.For processing 3D geometry, Irrlicht provides an extensive library of optimized geometric functions.One important exemplary structure is the (3D) vector. The vector3d class (T is the element datatype, ususally float or double) provides various methods including simple addition, multiplication,length and distance, but also some angle computation.User input is passed to the application through the IEventReceiver interface. An application implementsthat interface and registers itself using IrrlichtDevice::setEventReceiver. There are differentevent categories: GUI events (e.g., a button is clicked), joystick events, key input events, log events,mouse input events, and user events. So for example processing mouse events allows the application toreact on mouse input.Finally, Irrlicht provides a simple GUI environment for creating dialogs etc. The predefined controlsinclude buttons, check boxes, lists, combo boxes and scroll bars. The GUI API also includes 2D imageand text rendering functionality.2.5.2 CUSPCUSP (Channel-based Unidirectional Stream Protocol) [33] is a transport protocol initially developed forBubbleStorm but available for any application. BubbleStorm originally used TCP as its transport protocolbut TCP has soon shown to be too far from optimal for BubbleStorm. Firstly, BubbleStorm requires amessage passing protocol. But unlike plain UDP, messages have to be delivered reliably, and UDP does4 http://irrlicht.sourceforge.net/docu/32 2.5 Implementation-relevant Technologies
not support in-order delivery. TCP does not provide prioritization, and the head of line blocking problem[29] makes it impossible to acceptably implement priorized messages. Once data is queued for transmitin TCP, data with higher priority cannot pass the older data in the buffer. Thus, big messages with a lowpriority may block high priority data.There are two other transport protocols that tend to be more suitable for BubbleStorm: SCTP [31]and SST [13]. Both support multiple streams, allowing for parallel transmission of data. But SCTP onlyallows for a fixed number of streams that has to be selected when creating the connection. SST hasseveral shortcomings (e.g., a broken windowing) that make it unusable for BubbleStorm.CUSP has unidirectional streams which is efficient for realizing the packet-oriented behavior. A streamcan be created, a message sent and shut down, resulting in only one packet. Thus, streams do notproduce any packet overhead. Connections are encrypted by default. Applications do not need to takecare of encryption; optional user authentication is a simple task. Finally, CUSP supports mobile IP andNAT traversal (with help of the application) of which the latter has become a very important feature ofpeer-to-peer applications in general.One of the reasons for using CUSP in this work even without BubbleStorm is simply the need fortesting the protocol. At the time of writing, the CUSP implementation is still very new and needs forevaluation by applications using it. But that is not the most important reason. CUSP is very suitable forimplementing peer-to-peer games, mostly because its prioritization and NAT traversal capabilities. Thespecific benefit for a peer-to-peer game is the stream concept which allows for both a reliable transportlike TCP and a low latency packet-oriented behavior like UDP. By having feedback about buffer states,the application gains the potential of precisely controlling its traffic, and it may remove selected data(e.g., packets with outdated information) from the buffers by resetting streams.Functional OverviewBetween each pair of hosts that communicate using CUSP, there is one channel. A channel is the ‘physical’link between the hosts. Encryption and congestion control is located at the channel layer. Channel managementis not the application programmer’s duty. Once a handle to a remote host has been obtained,the application may create any number of streams. Similar to TCP, an application listens for incomingstreams at certain service IDs. Service IDs correspond to port numbers in TCP and UDP. But as CUSP isbased on UDP, each CUSP instance binds to exactly one UDP port through which all services are realized.As mentioned before, streams are unidirectional. Applications can only create outgoing streams (to a remoteservice) and receive incoming streams (after listening for a certain service). Each outgoing streamhas a priority based on which data is sent; the queued data of the stream with the highest priority issent until the stream’s queue is empty or data has been queued for a stream with a higher priority. Eachstream has its own flow control.API IntroductionThe following provides an overview of the CUSP API. Part of this work is the implementation of C++bindings for the transport protocol which itself is written in Standard ML. As this work only uses theC++ API, the section does not cover the original Standard ML API. But besides language-related conceptualdifferences, both APIs are very similar. Also, this section is simplified and reduced to the corefunctionality and thus does not cover the full API including all (helper/handler) functions necessary foran implementation. Refer to the CUSP documentation 5 for more detailsEndPoint An EndPoint is the local connection point for the transport protocol. Any application usingCUSP usually creates one instance of EndPoint which is provided with a UDP port to bind to.5 http://www.dvs.tu-darmstadt.de/research/cusp/2 Related Work 33
Page 1 and 2: Implementation of aPeer-to-Peer Mul
Page 3: AbstractMassively multiplayer onlin
Page 7 and 8: Contents1 Introduction 71.1 Planet
Page 9 and 10: 1 IntroductionIn the recent years,
Page 11 and 12: Figure 1.2: Screenshot of the origi
Page 13: Avatar is the virtual representatio
Page 16 and 17: scenarios with millions of users, t
Page 18 and 19: ArchitectureCensus operates in epoc
Page 20 and 21: administrative data. For short gami
Page 22 and 23: 2.3.2 HydraHydra [5] is a peer-to-p
Page 24 and 25: DHT’s key space. A comparison of
Page 26 and 27: the sender). Interest sets limit th
Page 28 and 29: EvaluationVON is evaluated in a sim
Page 30 and 31: 2.4.1 Low-Latency Information Disse
Page 32 and 33: 2.4.3 Object Synchronization and Ga
Page 36 and 37: The EndPoint class provides two mai
Page 39 and 40: 3 ConceptThis work’s implementati
Page 41 and 42: A solution could be using a mix of
Page 43 and 44: closing connections immediately is
Page 45: game instance. startNode() takes a
Page 48 and 49: Figure 4.1: Game Component Dependen
Page 50 and 51: Figure 4.2: In-game status message
Page 52 and 53: lock other tasks, resulting in a fa
Page 54 and 55: AvatarAn abstract representation of
Page 56 and 57: Figure 4.4: The network engine’s
Page 58 and 59: Figure 4.6: AI motion prediction wi
Page 60 and 61: MessageTable 4.1: Message types use
Page 62 and 63: Table 4.2: Message types used by th
Page 64 and 65: }// init gamegame ->init(device , t
Page 66 and 67: Irrlicht for Linux requires a few a
Page 68 and 69: ExamplesRunning the program without
Page 70 and 71: 4.6.2 Implementation ConcernsUnlike
Page 72 and 73: eset callback may be called synchro
Page 74 and 75: Table 5.1: Client-server traffic de
Page 76 and 77: 700006000050000Traffic (bytes/s)400
Page 78 and 79: 1000000900000800000700000Traffic (b
Page 80 and 81: Table 5.3: Computation time and mem
Page 82 and 83: Table 5.4: Computation time and mem
Page 85 and 86:
6 ConclusionThe core task of this w
Page 87:
New game features and improvements
Page 90 and 91:
AIprintf("Init AI...\n");ctx ->ai->
Page 93 and 94:
Bibliography[1] E. J. Berglund and
Page 95:
[32] Ion Stoica, Robert Morris, Dav
show all

Implementation of a Peer-to-Peer Multiplayer Game with ... - DVS

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?