class: center, middle # Creación de Videojuegos ### Networked Games --- class: center, middle # Networking --- # Why Networking? - Players enjoy interacting with other players - Killers like messing with people - Achievers like having leaderboards and showing off their achievements - Socializers like interacting with other people - AI is not (yet?) perfect --- # Networking Requirements - Fast: Should not adversely affect gameplay - Reliable: (Small) connection problems should not ruin the game - Fair: No player is preferred/affected by other player's connection problems - Secure: Players can't cheat --- # Peer-to-Peer Games - In the olden days, games would simply connect all players with each other - Every player runs the game on their machine - When someone moves, the move is sent to all players and their copy of the game state performs it - How can we synchronize the moves, so that all players have the same game state? --- # Lockstep Networking - Let's assume our game has "turns" - When it is a player's turn, they send the action they perform to everyone else - Players synchronize game states using turn order - Note: Real-time games can use this, too, by using "very short turns" (e.g. 10ms) --- # Lockstep Networking: Limitations - The game needs to be deterministic - Connection problems produce noticeable wait times - Worse, *any* player's connection problems affect *every* player - Also, what if the players do not agree on the game state (perhaps because someone is cheating)? --- # Client-Server Games - Instead of letting every player keep track of the game state themselves, let's use a central server - The server is the authority on the correctness of the game state, the clients only display it - When a player wants to perform an action, a request is sent to the server, and the action is only performed if the player is allowed to do so --- # Client-Server Games: Challenges - The server needs to respond to client requests quickly - However, there can still be a delay between the request and the answer - Clients should (ideally) not know anything the player should not know - What if there are network delays? --- class: tiny # A word from John Carmack "While I can remember and justify all of my decisions about networking from DOOM through Quake, the bottom line is that I was working with the wrong basic assumptions for doing a good internet game. My original design was targeted at < 200ms connection latencies. People that have a digital connection to the internet through a good provider get a pretty good game experience. Unfortunately, 99% of the world gets on with a slip or ppp connection over a modem, often through a crappy overcrowded ISP. This gives 300+ ms latencies, minimum. Client. User's modem. ISP's modem. Server. ISP's modem. User's modem. Client. God, that sucks. Ok, I made a bad call. I have a T1 to my house, so I just wasn't familiar with PPP life. I'm addressing it now." --- # Client-Side Prediction - In the original model, if you press a button, you have to wait for the server to answer to actually move - But the client could know/expect/*predict* that the button press will cause movement - Then, when the server confirms the coordinates, the client synchronizes with that information - Problem: The client tells the server about updates "in the past" --- class: small # Dead-Reckoning - Remember Newton's first law? Objects in motion will stay in motion (unless a force acts on them) - The client can assume that for non-player objects - When the server sends another update, the client reconciles the actual information with their prediction - For example: If a character is moving forward, the client can keep moving them forward until the server tells them otherwise - The client can also use the game mechanics to predict changes in movement (e.g. through collision) --- class: small # Example: With 100ms delay - t = 0: Player 1 sees player 2 in crosshair and presses "fire" button, client sends the "shoot" action to the server; client 1 predicts that player 2 was hit and killed - t = 1s: The server receives the "shoot" action from player 1, but player 2 is no longer in the crosshair - t = 2s: Client 1 gets response from server; Player 1 missed the shot, and player 2 isn't dead after all - Player 1 feels bad, because they "definitely" hit player 2 --- # Lag Reduction - The server keeps track of past game states - When a player performs an action, the server applies it to the game state at the appropriate time in the past - This means the server must also re-apply other players' actions that happen afterwards - Advantage: Most of the time, a player's action will have the effect they see on their screen --- class: small # Example: With 100ms delay - t = 0: Player 1 sees player 2 in crosshair and presses "fire" button, client sends the "shoot" action to the server; client 1 predicts that player 2 was hit and killed - t = 1s: The server receives the "shoot" action from player 1 *with the timestamp information*, and applies it to the game state at t = 0, resulting in a new game state in which player 2 is dead - t = 2s: Client 1 gets response from server, they hit player 2 and killed them --- class: small # But what about player 2? - t = 0: Player 2 is visible to player 1 - t = 1s: Player 2 is behind a wall - t = 2s: Client 2 gets a message from the server telling them that player 2 died (at t=0) - Player 2 feels bad because they were hit "while they were behind a wall" --- class: small # Trade-off - This system is actually fair: Both players have the same chances - However, it favors active behavior, because a player's own actions are reflected in the game state more readily than actions that are performed *on* the player - In many cases, especially in shooters, players are running towards or away from their enemies - Often the delay is also not large enough for players to actually notice, since they also need some time to process what is happening to them - Keeping track of historical states is expensive for many players --- # Trust the Client? - As we discussed earlier: The client can not be trusted - How about Hybrid Hit Detection (such as in Battlefield 3)? - The *client* says when they hit someone - The server performs a plausibility test --- # Cheating - The server is the authority on the game state - However, to be able to predict movement, the client needs to know the positions of other players - By extracting information from the binary game state, cheat programs can "see" enemies through walls - Other cheating methods include disabling or manipulating the z-Buffer to draw hidden enemies --- # Anti-Cheating measures There is no method that is 100% effective against all forms of cheating, but a few things that are done are: - Scan game binaries for modifications - Look for known cheat software that is running - Run game in a sandbox that can't be tampered with - Check for graphics card driver modifications/settings --- class: center, middle # Player Analytics --- # Why Player Analytics? - Games are expensive to make - Players often abandon games quickly - We want to know what players *do* in our games to keep them engaged - Related: We also want to make money --- # Player Analytics - We can collect data while players play the game - This data can then be analyzed to answer questions/confirm hypotheses - The answers to these questions can then inform game design - Typically, you want the players to keep playing your game, and use all your content - Or you might want to know *what kind* of content you should make more of --- # Player Retention <img src="/CI-2700/assets/img/android_retention.png" width="100%"/> --- # Player Retention - Good first impression/new player experience - Good challenge curve/flow - Delayed rewards (daily log-in bonus, loot chest with a key coming later, etc.) - Give player a personalization/progression choice - Social features, invite and team play rewards (see also: player acquisition) --- class: small # Madden NFL - Madden NFL is a game where you play American football - Researchers (in collaboration with EA) analyzed game log data - They built a statistical model to predict how many games a player would play - Using this model, they identified features which result in higher player retention - Game design can focus on improving these features --- # Madden NFL: Features <img src="/CI-2700/assets/img/nflfeatures.png" width="100%"/> --- # Player Modeling - You can personalize content, or just focus on more common types of players - How do you determine "types" of players? - Your game can track player actions and report back! - Especially in open world games, determining what players spend their time on is beneficial to focus future development or guide players to underexplored areas --- # Player Profiles - On the other hand, you also want to know *who* plays your games - Geographic region, age range, maybe personal details, personality - Why? So you can target ads - Play patterns are also important: time of day, session length, number of games per week --- # Player Profiles: How do you get this data? - IP Geolocation tells you the region - Provide a birthday bonus to incentivize players to tell you their birthday - Connect to facebook to get personal details - Statistical models: Play style and personality have been shown to be related --- # Machine Learning for Player Analytics - Some machine learning techniques can be used to analyze collected data - For example, if we want to know which "types" of players exist, we can use clustering - If we want to *predict* what the player is likely to do, we can use supervised learning (e.g. a neural network) - We can also learn a player's preferences (e.g. which weapon they are likely to favor) --- # How to use this information in Game Play - Marketing is nice and important, but can we use this for actual mechanics? - Of course! - Say a large portion of your players typically play from 7-10pm - Put large in-game events at 8pm - You can cater the type of event to the typical player population --- # How to use this information in Game Play - If you know your players are going to favor a certain kind of weapon, you can focus on making more of these weapons in the future - You can even use the learned models *during* development of future versions to predict where players might go more - Player types can inform the kind of content you should focus on --- # Game Play Statistics - So you have your game and you collect data - Then you analyze what content which players are consuming and when - But you already invested all this time and effort? - Let's look at an example --- # Project Gotham Racing 4 <img src="/CI-2700/assets/img/pgr4.jpg" width="100%"/> --- class: small # Project Gotham Racing 4 - Single player *and* multi player - 10 different game modes: career, arcade, network race, tournaments, time attack, etc. - 29 "event types": street race, elimination, cat and mouse, etc. - 134 cars with 7 different ratings (easy to hard to control) - 9 cities with a total of 121 race tracks - Development cost: "a fortune" (per Business Director Brian Woodhouse) --- class: small # Project Gotham Racing 4: Analysis - 4 researchers (including one from the publisher) analyzed 3.1 million game logs - Overall, 30-40% of the content was used in less than 1% of games - Game modes: Network tournaments were used in less than 0.1% of games - 12 of the 29 event types were used in less than 1% of games - 50 cars were used in less than 0.25% of races - 47 race tracks were used in less than 0.5% of races *each* (13% together) --- class: small # Project Gotham Racing 4: What to do? - First observation: More is not always better - The data can be used when developing a successor - But there would also have been a better way to develop *this* game: * Release a small/core version of the game with less content * Add content *where it is needed* * You will spend less money overall, even though you provide "free content updates" - Claim: An analysis like this might cost $50-$100k, but will save $0.5-$2 million --- # Player Acquisition - Marketing! - For now, let's talk about *mechanics* that encourage player acquisition - Once you have players, you want them to invite their friends - The power of social connections --- class: small # Player Acquisition - Say you have a game in which you tend to *your* farm - You can make money that allows you to buy more things for your farm - Some (fancy) things you can only buy with real money, though - Unless your friend (who also plays the game) "gives" them to you (*they* don't have to pay) - Of course you also *have to* tend to your crops (or they die) - But a friend can help you out on your farm --- # Player Acquisition: Other tactics - Get a bonus for posting a status on facebook that allows your friends to perform some in-game action - Make content harder to beat alone - There is a fine line between designing mechanics for player acquisition and (overly) aggressive marketing - The actual game play should still be enjoyable --- # But we don't have any game yet! - Many of the analytics options are only available to the developers - But there are APIs to extract replays for many games - You can run analytics on these replays to find out what players do in *other* games to learn their preference - This can inform design decisions for your own game --- class: center, middle # Unity Analytics --- class: small # Unity Analytics - Unity has built-in support for data collection - To enable analytics, open the Services window under Windows -> General -> Services and switch Analytics to "On" - By default it will collect: * New installs * Daily/Monthly active users * Sessions (total/per user) * Time spent * Users by geographic region, OS, life cycle - There are many other standard events you can use, or create custom ones - Also integrates with monetization options --- class: small # Unity Analytics: Funnels - There are many ways to analyze the collected data - One of the more common ones: Funnels - You measure the progress through some linear progression (e.g. the tutorial) - The "funnel" will show you how far players make it through the progression, i.e. where you lose players ```C# AnalyticsEvent.LevelStart(thisScene.name, thisScene.buildIndex); ``` --- # Unity Analytics: Funnels <img src="/CI-2700/assets/img/funnels.png" width="90%"/> --- # Unity Analytics: Heatmaps - You may also be interested *where* in your game things happen - Where do players go often, where do they die - There is a Heatmap extension for Unity analytics, where you send analytics events with a location - Requires Unity Pro :( --- # Unity Analytics: Heatmaps <img src="/CI-2700/assets/img/heatmap.png" width="90%"/> --- class: small # The EU General Data Protection Regulation - Remember getting emails from every website telling you that they collect personally identifiable information? - That's because of the EU GDPR - Use the Unity Analytics Data Privacy Plug-in - This plug-in includes a button you can place in your game for players to opt out of data collection (and see which data was already collected) - Make sure, *you* don't send personally identifiable information in your analytics events --- # The Flip Side <iframe width="560" height="315" src="https://www.youtube.com/embed/nqGcXOksFGg" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> --- class: tiny # References * [What Every Programmer Needs To Know About Game Networking](https://gafferongames.com/post/what_every_programmer_needs_to_know_about_game_networking/) * [1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond](http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php) * [Client-Server Game Architecture](http://www.gabrielgambetta.com/client-server-game-architecture.html) * [Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization](https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization#Lag_Compensation) * [The pitfalls of verifying floating-point computations](https://hal.archives-ouvertes.fr/file/index/docid/281429/filename/floating-point-article.pdf) * [Hybrid Hit Detection in BF3](https://www.reddit.com/r/battlefield3/comments/n2oiy/we_need_someone_to_create_a_guide_for_the_new/c35xc2m/) * [Valve AntiCheat mistakenly bans 12000 players](https://www.rockpapershotgun.com/2010/07/26/valve-anti-cheat-software-goes-a-bit-glados/) * [Networking in Unity](https://docs.unity3d.com/Manual/UNetOverview.html) --- class: tiny # References - [Player Retention](https://medium.com/roblox-developer/player-retention-a-first-look-at-how-to-get-players-coming-back-to-your-game-9ae68826f466) - [Data-Driven Game Development](https://www.loggly.com/blog/data-driven-game-development-analytics/) - [Data Analytics for Game Development (NIER Track)](https://games.soe.ucsc.edu/sites/default/files/p940-hullett_0.pdf) - [Jim Whitehead on Analytics](https://slideplayer.com/slide/5354512/) - [Raph Koster on Social Mechanics](https://www.gdcvault.com/play/1014555/Social-Mechanics-for-Social-Games) - [Unity Analytics](https://blogs.unity3d.com/es/2016/05/03/analytics-the-player-lifecycle/)