CS 480/680: GAME ENGINE PROGRAMMING

Transcription

1 CS 480/680: GAME ENGINE PROGRAMMING INPUT AND NETWORKING 2/7/2013 Santiago Ontañón

2 Outline Student Presentations Handling User Input Multiplayer Games Networking Basics Client-Server Architectures Peer-to-Peer Architectures Client-side Prediction Project Discussion

3 Outline Student Presentations Handling User Input Multiplayer Games Networking Basics Client-Server Architectures Peer-to-Peer Architectures Client-side Prediction Project Discussion

4 Student Presentations Sean Bluestein: An Extensible Trigger System for AI Agents, Objects and Quests Kevin Burdick: The 2009 Mario AI Competition Mateusz Stankiewicz: Convincing-Looking Glass for Games Binggang Wo Octree Construction

5 Outline Student Presentations Handling User Input Multiplayer Games Networking Basics Client-Server Architectures Peer-to-Peer Architectures Client-side Prediction Project Discussion

6 Game Engine Architecture Game Specific Game Engine Functionalities Game Engine Resource Management Utility Layer Platform Independence Layer SDKs OS DRIVERS HARDWARE Dependencies

7 Game Engine Architecture Scripting Artificial Intelligence Online Multiplayer Rendering Engine Animation Engine Gameplay Foundations (Game Loop) Physics Audio Subsystem Collisions Profiling & Debugging

8 Handling User Input User Input: Keyboard presses Mouse movements Joystick Touch surfaces Cameras Microphones Remote input (from another computer over the network) Etc. Game Engine should process user input, and react accordingly: Trigger character movements, etc.

9 Trivial Way (Do NOT do this!) boolean cycle() { } If (key_pressed[space] } joystick_button(button1) bouse_button_pressed(button1)) { firebullet();

10 Trivial Way (Do NOT do this!) boolean cycle() { } If (key_pressed[space] } joystick_button(button1) bouse_button_pressed(button1)) { firebullet(); Problem 1: Hard-coding input mapping. If we want to change the fire key to m, we have to look in the code for all instances of this.

11 Trivial Way (Do NOT do this!) boolean cycle() { } If (key_pressed[space] } joystick_button(button1) bouse_button_pressed(button1)) { firebullet(); Problem 2: Hard-coding input devices. What if we want to have a player in a remote computer over the network? What if we want to make our game work on a tablet? Problem 1: Hard-coding input mapping. If we want to change the fire key to m, we have to look in the code for all instances of this.

12 Handling User Input: The Input Map User Input: Game Actions: Move Right? Fire Switch weapon

13 Handling User Input: The Input Map The input map is a table, or module that: Encodes the translation from user input to game actions/events Can be provided by the game engine Typically only used for in-game input (i.e. controlling player character). But it could also be used to handle input for the game menus, GUI, etc. (with a proper design)

14 Handling User Input: The Input Map Input Map example API: Class InputMap { public: void addkeyboardmap(int key, GameAction ga); void addkeyboardcombomap(list<int> keys, GameAction ga); void addkeysequencemap(list<int> keys, GameAction ga); void addmousebuttonmap(int button, GameAction ga); void addjoystickmap(int koystickevent, GameAction ga); etc. } GameInput getinput();

15 Handling User Input: The Input Map Input Map example API: Class InputMap { Class GameAction { Class GameActions { public: int actioncode; List<CharacterActions> controllers; int characterid; void } addkeyboardmap(int key, GameAction } ga); void addkeyboardcombomap(list<int> keys, GameAction ga); void addkeysequencemap(list<int> keys, GameAction ga); void addmousebuttonmap(int button, GameAction The CharacterActions ga); class is void Class addjoystickmap(int CharacterActions { koystickevent, GameAction an abstraction ga); that stores all the bool left, right, jump, crouch; possible actions supported by etc. } your game engine (this example is oversimplistic, you might need a more complex structure), and GameInput getinput(); whether the player triggered that } action or not.

16 Handling User Input: The Input Map Input Map example API: For example, for an analogous Class InputMap { Class GameAction { Class GameActions { control engine (e.g. Nintendo Wii), public: int actioncode; List<CharacterActions> controllers; you might want to include desired int characterid; void } addkeyboardmap(int key, GameAction weapon rotation, } ga); etc. void addkeyboardcombomap(list<int> keys, GameAction ga); void addkeysequencemap(list<int> keys, GameAction ga); void addmousebuttonmap(int button, GameAction The CharacterActions ga); class is void Class addjoystickmap(int CharacterActions { koystickevent, GameAction an abstraction ga); that stores all the bool left, right, jump, crouch; possible actions supported by etc. } your game engine (this example is oversimplistic, you might need a more complex structure), and GameInput getinput(); whether the player triggered that } action or not.

17 Handling User Input: The Input Map Input Map example API: Class InputMap { Class GameAction { Class GameActions { public: int actioncode; List<CharacterActions> controllers; int characterid; void } addkeyboardmap(int key, GameAction } ga); void addkeyboardcombomap(list<int> keys, GameAction ga); void addkeysequencemap(list<int> keys, GameAction ga); void addmousebuttonmap(int button, GameAction ga); void Class addjoystickmap(int CharacterActions { koystickevent, GameAction ga); The GameActions class is just a bool left, right, jump, crouch; list with all the input given to all etc. } the characters in the game (either by local players, AIs, or remote GameInput getinput(); players). }

18 Handling User Input while(!quit) { } I = InputMap.getinput(&quit); G.updateAI(&I); G.updatePhysics(I); G.render(); FPScontrol(); The game loop calls the input handler to translate user input to game actions The AI controls characters also by generating game actions (identical data structure than user input) Physics/animation, etc. do not know if a player is controller by a player, or by an AI.

19 Handling User Input Input Map AI Online Multiplayer Network Game Actions Rest of the game engine

20 Handling User Input Although depending on the multiplayer implementation, your game engine might not need to know the actions executed remotely. Input Map AI Online Multiplayer Network Game Actions Rest of the game engine

21 Outline Student Presentations Handling User Input Multiplayer Games Networking Basics Client-Server Architectures Peer-to-Peer Architectures Client-side Prediction Project Discussion

22 Example Networked Multiplayer Games Multi-User Dungeons Early predecessors of today s MMOs (used a client-server architecture) Unbounded number of players

23 Example Networked Multiplayer Games MUDs have survived, and there are many modern ones:

24 Example Networked Multiplayer Games Bolo (1987) (relatively unknown) Mac-only game, one of the earliest network games ever

25 Example Networked Multiplayer Games DOOM (1993) 4 players over local network (IPX protocol) Peer-to-peer: deterministic game, sharing actions over network (numbered, to detect lost packets) Peers used broadcasts (saturated the network)

26 Example Networked Multiplayer Games Quake (1996)

27 Example Networked Multiplayer Games Quake (1996) Featured permanent servers, where players could meet and play (before Quake, you had to coordinate in the real world on a time to play, and share your IP via phone with friends to play! Client-Server over the internet (not just LAN!) A new problem appeared (unknown till then): latency! QuakeWorld: update to Quake just to address latency. Introduced a key idea called client-side prediction

28 Example Networked Multiplayer Games MMOs, e.g.: RuneScape network of servers

29 Outline Student Presentations Handling User Input Multiplayer Games Networking Basics Client-Server Architectures Peer-to-Peer Architectures Client-side Prediction Project Discussion

30 Networking 101 (for Games) Node: a computer/device in the network IP: Address of a node (e.g ) Packet: a piece of information transferred from one node to another Typically a packet is sent to: (IP, port) IP: address of destination Port: ( ) identifies the service that should respond to this packet Server: a node that offers some services Client: a node that requests a service from a server

31 Networking 101 (for Games) UDP: Most adequate for game Simplest protocol networking. Most games Simply offers a service to deliver a packet from implement one node their own to packetloss protocol on top of UDP. another No control of packet-loss, no persistent connections, etc. Summary: fast but unreliable TCP: Not as common in games, since Most complex protocol it s slower. And its reliability protocol is not designed with Packet-loss control, persistent connections real-time games in mind. Summary: slow but reliable

32 Networking 101 (for Games) UDP: Most adequate for game Simplest protocol networking. Most games Simply offers a service to deliver a packet from implement one node their own to packetloss protocol on top of UDP. another No control of packet-loss, no persistent connections, etc. Summary: fast but unreliable TCP: Not as common in games, since Most complex protocol it s slower. And its reliability It s more complex than this. But the rule of protocol is not designed with Packet-loss thumb control, is: persistent connections real-time games in mind. - Summary: Use UDP slow for real-time but reliable updates - Use TCP for chat windows (Google TCP vs UDP games for more)

33 Sockets Sockets: You can see a socket as a pipe that allows you to send data between two nodes in the network. Once you have a socket open, you can send and receive packts through it. Then can be configured to send using TCP or UDP All network libraries allow you to open/close/send and receive through sockets If you are working on networking for your project, I m assuming you know how sockets work. No time for detailed explanations here.

34 Sockets Different libraries/languages will give you different forms to: Create a socket (TCP or UDP) Server: bind a socket to an address/port for listening to incoming connections Client: establish a connection (to a particular IP/port) Server: accept incoming connections Send data through an open connection Receive data from an open connection Timeline: Server: Client: 1. Create Socket 1. Create Socket 2. Bind 2. Establish 3. Accept 4. Send/receive 3. Send/receive

35 Communication Architectures Peer-to-Peer Client-Server Hybrid Client-Network of Servers

36 Communication Architectures Peer-to-Peer Hybrid Client-Server All instances are clients, who send updates to each other, trying to keep the world simulation in Client-Network sync. of Servers

37 Communication Architectures Peer-to-Peer One instance is special, the server. All clients send Hybrid requests to the server, server maintains the game state, and informs clients of the changes. Client-Server Client-Network of Servers

38 Communication Architectures Peer-to-Peer Hybrid Different game functionalities implemented with different Client-Server architectures, for example: game state using client-server, in-game chat using peer-to-peer. Client-Network of Servers

39 Communication Architectures Each client associated with a server. Network of servers can communicate using a peer-to-peer (or using a client-server, with a Peer-to-Peer master server). Very scalable, but the most complex in terms of communication protocol. Client-Server Hybrid Client-Network of Servers

40 Communication Architectures: Network of Servers Example (MMO) WoW had almost 2000 servers (derived from traffic data) Client Zone 1 server Zone 2 server Zone n server Chat Server Patch Server Master Server Account Server

41 Communication Architectures Peer-to-Peer Client-Server Hybrid Client-Network of Servers

42 Outline Student Presentations Handling User Input Multiplayer Games Networking Basics Client-Server Architectures Peer-to-Peer Architectures Client-side Prediction Project Discussion

43 General Socket Class Your can start by wrapping the socket class given to you in your language in a class like this: Class GameSocket { GameSocket(SOCKET sock, int localip) send(gamepacket data); bool hasdata(); GamePacket receive(); } Class GamePacket { int getbytesize(); char *getdataptr(); } // depending on your game engine

44 General Socket Class Your can start by wrapping the socket class given to you in your language in a class like this: Class GameSocket { GameSocket(SOCKET sock, int localip) send(gamepacket data); bool hasdata(); GamePacket receive(); } Class GamePacket { int getbytesize(); char *encode(); void decode(char *data, int size); } // depending on your game engine This class stores one of the messages that your game will send. It should have at least 2 methods: one to encode the packet into an array of bytes, and the other to decode it from an array of bytes.

45 General Socket Class Your can start by wrapping the socket class given to you in your language in a class like this: Class GameSocket { GameSocket(SOCKET sock, int localip) send(gamepacket data); bool hasdata(); GamePacket receive(); } Class GamePacket { int getbytesize(); char *encode(); void decode(char *data, int size); } // depending on your game engine Your GameSocket class will be an abstract class (that you will exted with a ServerSocket and a ClientSocket class). But this one is handy, to organize the code.

46 Server Socket Classes We will then extend it for the server Class ServerMasterSocket extends GameSocket { ServerMasterSocket (int port); } init(int port); ServerSocket acceptconnection(int &IP); Just creates an instance, but does nothing else. We don t want to open the port right away after creating the socket, since we might just be setting up the data structures. Class ServerSocket extends GameSocket { ServerSocket (SOCKET s); }

47 Server Socket Classes We will then extend it for the server Class ServerMasterSocket extends GameSocket { ServerMasterSocket (int port); } init(int port); ServerSocket acceptconnection(int &IP); This function does all the work of creating the socket: 1) Create the socket 2) Set the options (protocol, etc.) 3) Set the port 4) Start listening Class ServerSocket extends GameSocket { ServerSocket (SOCKET s); }

48 Server Socket Classes We will then extend it for the server Class ServerMasterSocket extends GameSocket { ServerMasterSocket (int port); } init(int port); ServerSocket acceptconnection(int &IP); Class ServerSocket extends GameSocket { ServerSocket (SOCKET s); } When hasdata is true, it means that a client is trying to connect. This function accepts the connection, and returns the ServerSocket that will be used for that connection.

49 Client Socket Classes We will then extend it for the client Class ClientSocket extends GameSocket { ClientSocket (int port); } connect(int IP, int port) The only extra functionality here is to connect to the server socket

50 Overview Client side: Server side: ClientSocket MasterServerSocket Step one is to create the MasterServerSocket, and have it listen for incoming connections.

51 Overview Client side: Server side: ClientSocket Connection Request MasterServerSocket When a client wants to connect, it requests a connection to the MasterServerSocket

52 Overview Client side: Server side: ClientSocket MasterServerSocket ServerSocket When the server accepts the connection, a ServerSocket is created and this is the one that keeps the connection open to the ClientSocket.

53 Overview Client side: Server side: ClientSocket MasterServerSocket GamePacket GamePacket ServerSocket GamePackets can be sent back and forth through this connection.

54 Overview Client side: Server side: ClientSocket MasterServerSocket ClientSocket ServerSocket ServerSocket ServerSocket ClientSocket For each new client, a new ServerSocket is created, but there is only a single MasterServerSocket, that is always open waiting for incoming new clients.

55 Connecting to the Game Loop Client side: Server side: Network Module ClientSocket MasterServerSocket GamePacket GamePacket ServerSocket while(!quit) { I = InputMap.getinput(&quit); G.networkUpdate(&I) G.updateAI(&I); G.updatePhysics(I); G.render(); FPScontrol(); } In the game loop, at each cycle, you call the network module, which would process all the GamePackets received through the socket (you should have an incoming queue, since packets arrive asynchronously). Then update the game state/input/etc. with the info from those packets. It should also send packets to the server with the user input (I).

56 Connecting to the Game Loop Client side: Network Module Server side: Network Module ClientSocket MasterServerSocket GamePacket GamePacket ServerSocket while(!quit) In the server { game loop, at each cycle, you I = call InputMap.getinput(&quit); the network module, which would G.networkUpdate(&I) process all the GamePackets received G.updateAI(&I); through the socket to get the actions the G.updatePhysics(I); players want to execute, it will also send back G.render(); to the clients the most updated game FPScontrol(); state. } while(!quit) { G.networkUpdate(&I) G.updateAI(&I); G.updatePhysics(I); FPScontrol(); }

57 Considerations Depending on the nature of the game, what is sent through in the GamePackets will be different: In a deterministic game: Client/server only need to send actions In general: Clients send actions Server sends game state updates You can send global game state updates, or smaller chunks with individual GameObject updates You can also optimize and only send to each client, updates of the objects that are near the player (the rest, doesn t matter).

58 Outline Student Presentations Handling User Input Multiplayer Games Networking Basics Client-Server Architectures Peer-to-Peer Architectures Client-side Prediction Project Discussion

59 Peer to Peer Architecture All computers are clients and servers Peer 1 side: Peer 2 side: MasterServerSocket MasterServerSocket ServerSocket ServerSocket ClientSocket ClientSocket

60 Considerations All peers send actions and game state updates Need a policy to keep game state consistency Each game object should have an owner (one of the peers). The game state sent by that peer is the one that will stay When new peers connect, or peers disconnect, game object owners should be updated.

61 Outline Student Presentations Handling User Input Multiplayer Games Networking Basics Client-Server Architectures Peer-to-Peer Architectures Client-side Prediction Project Discussion

62 Client-side Prediction Consider a very simple client that simply takes user input, sends it to the server, receives state updates and renders them. User input Perceived delay Process input Render

63 Client-side Prediction Consider a very simple client that simply takes user input, sends it to the server, receives state updates and renders them. User input Perceived delay This can be multiple frames of delay! Process input Render

64 Client-side Prediction Idea: Predict the update that will be received from the server Render the prediction When the update from the server is received, merge any discrepancies Two main problems: Player prediction Non-player prediction

65 Client-side Prediction Player prediction simply simulates the effects of the player actions directly (non-player characters are not predicted) Perceived delay User input Render Process input Merge States Render

66 Client-Side Prediction The client also simulates the game state (physics, collision, etc.) Player Prediction: Effects of the player actions are simulated locally Non-player Prediction: Predict the actions that non-players will execute, and simulate them too (for example, predict that they will keep moving in the same direction as they were in the previous frame).

67 Outline Student Presentations Handling User Input Multiplayer Games Networking Basics Client-Server Architectures Peer-to-Peer Architectures Client-side Prediction Project Discussion

68 Links to Interesting Game Videos Sugar Cube Bittersweet Factory:

69 Remember that next week: Second Project Deliverable: Updated document from Deliverable 1: Address feedback that you got from Deliverable 1 Any potential topic change Small description of how the game loop integrates with your demo/game engine Source code: Do NOT send code as an attachment. Send a URL to your code, or to a code repository (SVN, GIT, etc.) Submission procedure: to (copy both): Santiago Ontañón santi@cs.drexel.edu Stephen Lombardi sal64@drexel.edu Subject: CS Project Deliverable 2 Group #