#but between this and his reactions to losses in days multiplayer i think that just can’t be true

[firestorm09890]

“Dear Diary”. Zexion’s Mystery Gear. “A weapon that draws forth its wielder’s personality.” Sleek and cold and gray exterior, decorated only by the symbol of the Organization. A tool with access to more information than a normal book can grant, and capable of holding more secrets than a normal book could store. But then, open it up- the wallpaper is an eyesearing red, so vivid in shade that it leaves afterimages. Something you wouldn't be able to see when the laptop was closed unless you used it for violence.

Mystery Gear weapons are designed for being overanalyzed as symbols. This thing represents Zexion. What’s the red wallpaper imply then, huh? Mr. “Intellectual with no room for feelings”?

[blubberquark]

Things To Think About Before You Implement Online Multiplayer

Sometimes people ask “how do I make an online multiplayer game?“ and then somebody answers “you don’t, you haven’t even made a game as simple Tetris yet“, and somebody else answers: “I never made an online game, but you should use TCP/IP. Here’s a link to the socket documentation.”

That’s just terrible. Sockets are low-level and tricky to get right.

Or maybe somebody links that poor sod to this YouTube video about how modern 3D shooter games do netcode. That’s also bad, but slightly less so. Game netcode is complicated, but not every game needs real-time shooting action.

Maybe you use Unity3D, and you just use the standard Unity networking tools that let a player host a game and automagically synchronise the state of game objects between all players. I think they changed that recently. Maybe the Unity3D multiplayer features are not at all what you need. Maybe you are in luck and you need something much simpler.

If you’re an experienced programmer, you already know how much of a hassle low-level networking can be, or you’re a beginner and would rather use a readymade networking layer for your engine. How do you evaluate which system is right for your game?

Sometimes a game can be easily made into an online multiplayer game, except for one or two features. It can help if you think about how game mechanics are interacting with online multiplayer while you design the game. If you design your game from the ground up to be easy to adapt to online multiplayer, you will have an easier time later. Multiplayer is like AI in that regard. Rather than making your AI smarter, you can also make your game world easier for simple algorithms to navigate.

This post will not teach you how to make multiplayer games. That is very much on purpose. It’s more general than that. This post is meant to make you think about what kind of multiplayer system your game needs. If you understand that, you can look at tutorials, protocols, libraries for networking, or prefab high-level multiplayer systems, and evaluate whether these are a good fit for your game.

Time Scale, Turn Structure

Real-Time: All players are in the game at the same time, seeing and interacting with each other. Waiting/standing around thinking might mean losing the initiative. Examples: Quake, StarCraft.

Turn-Based: Whichever way the turn order is decided - alternating players, active time battle, simultaneously, alternating units a la Worms - players have time to think their turn through, and don’t need to have fast reaction times. Players need for their opponents to finish their turns, but there can be a turn timer or a chess clock/byoyomi. Example: Advance Wars, Hearthstone.

Turn-Based (Play By E-Mail): This is like turn-based, except players don’t actually wait their turn inside the game. Instead they get an e-mail notification that their opponent made a move, have a couple of days to make their move, start the game, make their move, close the game, and wait for another e-mail. Example: Chess 2: the Sequel, Laser Squad Nemesis, Frozen Cortex.

Slow Real-Time: The game happens in real-time, but there is no real bad consequence for taking hours to perform an action. When you attack another player, it takes a day or so for the army to arrive. When you build a house, construction takes two hours. Many actions are instantaneous, but have half-hour cool-downs. You cannot really lose. It’s long-term and low-stakes in the short term. Examples: BattleNations, OGame, Pokemon Go.

If you’re doing real-time multiplayer, you might have to use UDP or a UDP-based networking system like ENet. If you’re making a turn-based game, you can get away with TCP, and if you’re making a slow or play-by-email game, you will be more concerned with saving game state to a database than with optimising network latency, so you can use a high-level RPC library on top of TCP or even a REST API on top of HTTPS.

This stuff is really important to figure out early: If your game is slow real-time, you probably need a database, but you don’t need any client-side prediction. It’s fine if some actions, like building a house in a city-building game, take half a second. You can hide the delay pretty easily. And when the actions by other players arrive ten seconds late and out of order, it doesn’t matter either. If you make an online city-builder game for the iPad, you don’t need the lag-reducing tricks used in Halo, but you will need to worry about saving the cities somewhere when users log off.

But imagine a one-second lag in a tennis game, or imagine your game nice and responsive, but then you hit the ball from your perspective only, and not in the view of the other player! In that case, you need something that’s both fast and accurate.

See also:

https://gafferongames.com/post/what_every_programmer_needs_to_know_about_game_networking/

Players vs World Size

Small World: The level is small, and over one play session, you will see the whole level and encounter all the other players. Examples: GangBeasts, Quake, raid dungeons in World of WarCraft.

Large World, Few or Independent Players: The world is big, and you are unlikely to encounter most players in a play session. Maybe most players are not even online. You interact only with a fraction of the world at any time. Examples: MineCraft, World of WarCraft (PvE).

Large World, Many Interacting Players: Examples: Fortnite, Destiny

In a small world, you can send everything other players do, and everything that happens everywhere to all other players.

In a large world, you can compartmentalise, or just send to each player the part of the world that he or she needs to see. Or you can have players cache the world locally. Maybe the map is static, so it can be stored locally, and maybe inventory items or crate contents can be handled server-side. Maybe mob AI runs locally if only one player interacts with a mob.

If many players interact with mobs and each other, state needs to be shared and synchronised, or actions must be handled server-side, which necessitates a round-trip. Destroying a block in Minecraft usually necessitates a round-trip, a confirmation from the server, and if you have high ping or packet loss it takes a noticeable while for the block to actually disappear. Chunks are saved or loaded from disk on the server, but also sent from the server to the client. It’s not necessary for the server to send the game state (players, mobs, items, blocks) for the whole world to all clients.

Pokemon Go has a large world, but players only interact inside arenas.

In Tetris 99, there are 99 players interacting in real time, but if somebody sends his lines half a second later, it’s not a big deal. There is a lot of state to share, but the players are mostly independent from one another.

Perspective

Shared View: All players have the same camera perspective. Example: Super Smash Bros

Fog of War: Players have the same camera perspective, but do not look at and cannot see the same things. Example: StarCraft

Different Perspectives: Players are looking from a first- or third-person perspective. Example: Quake

If all players share the same perspective, then discrepancies become very noticeable. In a shooter with different perspectives, it matters whether the shot hits from the perspective of the player who shot it. In a fighting game, everybody sees the same perspective, so a discrepancy in player positions can cause the game to look like a punch connects in the perspective of one player, while it doesn’t connect in the perspective of the other. In a game with one-hit K.O (Samurai Gun, TowerFall), such discrepancies are game-breaking.

In real-time strategy games, consistency is even more important. A single unit or a small initial tactical advantage can turn into a large material advantage quickly. You can often trade-off high lag for better consistency, and then hide the input lag behind the UI. Clicks should register in the UI immediately, even if it takes a while for the commands to be processed over the network. Usually, the game state between the players is 100% consistent, and the fog of war is calculated only locally.

In turn-based games, you never have to trade off input lag against consistency. First-person shooter netcode is necessarily very different from fighting game netcode or real-time strategy netcode.

Games like Halo or Fortnite can look different for different players and they won’t notice. A game like StarCraft must never look different for both players. It should look the same for both players, and the same as it will later look in the replay.

A game like Skullgirls will be unplayable with the slightest amount of lag. A game like Hearthstone can have a responsive UI, and just send things with a bit of lag, and it’s fine. You can’t interact with your opponent’s cards when it’s not your turn anyway.

If the game has a shared perspective, but players don’t interact directly, like in BrowserQuest, you don’t need to keep the state completely synchronised.

Connection Problems

Bandwidth: How many bits can go through the connection per second? 

Packet Loss: What fraction of packets arrives at the destination unharmed?

Latency: How long does it take for one packet to arrive?

Even high-bandwidth connections to the Internet can have high latency and packet loss, especially mobile and wireless. If you make a game, think about all three, and test how your game runs under suboptimal conditions! If the game becomes unplayable with a connection that is slow, low-bandwidth, or unreliable, consider checking and warning the player before entering a game!

High packet loss will probably lower both your bandwidth and your latency. If a player has a low ping most of the time, but lost packets introduce round-trips and lag spikes, then you need to work around that somehow.

You could send the updated player state to the server with every packet, and the updated game state to the player. This way, if one packet gets lost, and the server gets the next one, it will just take the newest state and apply that. If the older packet then arrives later anyway, it would just be discarded. You need to number your packets for this to work, but it’s easy enough to implement. But if you decide to use this method, players could hack their game client and just jump around on the map!

What do you do if there is a spike in lag, and then everything is fine again?

How do you detect that your game is running behind? If you use TCP for networking, packet loss means the packet is re-sent, and you will have to wait until the data arrives.

If you use plain UDP, you will have to deal with packet loss yourself. Both approaches have drawbacks.

What to Send

Input Data: Raw keyboard events, gamepad button presses, mouse movements, and joystick positions are sent to the server. The server decodes the input.

Abstract Actions: Commands like “(deal 5HP damage to player #7), (tell unit #5 attack F1)“

Differences: Send only the things that changed. This might necessitate a naming scheme to refer to game objects that changed and game objects that stay the same. For example: “(create Sprite #101 at (500, 0)), (update Sprite #3 position=(321, 10)), (destroy Sprite #1)“

Whole Game State: This can make sense if the whole game state is small anyway.

Maybe your server will send different data to the client than vice versa: The client could send abstract actions to the server, while the server sends back the whole game state.

This ties into the next point: If you send abstract actions to the clients, they need to apply them client-side. If you send input data to the server, the server can use it to compute the next game state, and send the game state back to the clients, or the server can bundle and relay client inputs to other clients.

If your game is something like two-payer Tetris, or Tetris 99, it might be simpler to occasionally send the state of the whole arena, instead of the movements of the falling pieces.

Simulation

Server-Side Only: The game runs on the server, and the clients don’t run code that implements the game mechanics, only things like UI, input, and rendering. Frequent round-trips might cause lag. Usually used in MUDs.

Server-Side (with Client-Side Prediction): The game runs on the server, but also on the clients. The clients simulate the game mechanics based on local game state, but the server has the final say. The clients calcualte the game state based on local inputs in order to reduce lag, but when the server data conflicts with the locally calculated game state, the server-side game state wins out. This minimises input lag, but might cause inconsistent game states. Players who lag behind have a disadvantage. Usually used in modern shooter games with cloud servers.

Client-Side (Peer-To-Peer): The game runs on every client, and every client keeps the game state of its own player. Inconsistencies happen, but game code is executed on each player’s client based on that client’s view of the world. This is susceptible to cheating. Used to be common in shooter games, and is still used in retro shooter games like Cube/Sauerbraten.

Client-Side (Lockstep): The game runs on every client, and every client has exactly the same game state at all times. If one client lags behind, the game slows down for everyone else, or that client drops out and has to re-synchronise its game state. The game state is too large to be sent over the network frequently, so only (abstract) player inputs are sent over the network. The game engine must run completely deterministically for this to work, or at least the gameplay mechanics. Things like animation and particle effects may have some nondeterminism. This method is used in real-time strategy games with lots of units, if it would take too much bandwidth to send the position of every unit during every frame.

This is not an either-or thing. Often some important but less frequently updated aspects of a game could be handled completely server-side, like quests, inventory, and player stats (especially currency and experience points), while movement and combat have client-side prediction. Some MMO games use Peer-To-Peer communication in certain areas and between friends, but server-side simulation in others.

Some games use client-side game simulation running in lockstep, but still relay all data through a central server. This way, the server can synchronise the inputs and ensure that input data data is received by all clients at the same time - if one client receives a click even one frame late, the simulations wouldn’t be running in lockstep any more!

When you are running multiple simulations in lockstep, or even doing normal client-side prediction with high-precision numeric calculations, you need to take special care to ensure that the floating point calculations on different processors and operating systems are numerically stable and deterministically reach the same results.

If you are using different floating point maths for graphics on different clients, maybe a difference in rounding results in a texel being one pixel to the left, or in different patterns of z-fighting. But if you have different floating point behaviour in gameplay code, small rounding errors can add up quickly. You can avoid such errors by always using integers internally, always using exact decimals or fractions, or by using a server-authoritative architecture with robust conflict resolution. In this case, you can have either side use whatever floating point type is fastest, but you need to send the server state to the client frequently, and provide a conflict detection or resolution method in case the client diverges too far.

If you have some things, like inventory and experience on the server, you have to think about where to draw the line. If a mob drops an item, does that happen on the client or on the server? If a player picks up an item, or uses an item from the inventory, that needs to happen on the server, or to be confirmed by the server.

Related links:

https://gafferongames.com/post/networked_physics_2004/

https://www.forrestthewoods.com/blog/synchronous_rts_engines_and_a_tale_of_desyncs/

https://www.forrestthewoods.com/blog/synchronous_rts_engines_2_sync_harder/

Metagame/Save State

Persistent State: When the players log off, the state is kept, or saved on the server, to be loaded again in the next play session. (as opposed to ephemeral state: When the game ends, ephemeral data is discarded)

Replays: Players can save and re-watch game replays.

Ladder: The server maintains win/loss stats and skill estimates for players.

Lobby, Server Browser: There is a UI to choose a server, start a game, and find or talk to players before the actual game starts.

This is not important to implement right away, but worth keeping in mind.

If your game world is living on the server, and the server is running all the time, you need to use some kind of ACID database to store the game state, or a method to regularly save savegames on the server, in case somebody in the data centre trips over the cable, or, far more likely, your server code crashes. You probably don’t need to save everything, but again, probably things like currency, XP, inventory and quest state are important, mob positions, health, mana and animation state less so.

You might want to have a “lobby“ client that lets you browse and connect to servers, chat with other players, and look up ladder statistics. Sometimes the “lobby“ client doesn’t load the full game engine, but is a regular desktop program built using a normal GUI toolkit, that lets you configure the game and find other players, before the actual game engine is started. SpringLobby is such a “lobby client“.

If your game engine is deterministic, you can just store actions or input data, and if you feed that into the engine again at the right times you have a working replay system. Otherwise you need to think about how replay would work, and what to save in a replay file.

It is especially important to keep such metagame features in mind because if you simplify your game design or deliberately cut some corners in your game design, implementing server-side persistence becomes much easier.

If your game is play-by-email, or has a significant ladder/social component, you need some server-side persistence, to store player profiles, replays of finished games, win/loss statistics, or game states of unfinished games.

It might make sense to have a lobby client while you’re developing an online game, even when you will later want to have everything in one process, one GUI toolkit, and one engine: When you’re using PyGame, you could have one TkInter program that connects to the server browser and chat system, which then launches another process that uses PyGame and no Tk.

There are advanced topics, like detecting de-synchronisation, host migration and streaming game state to late joiners, that you probably won’t need to worry about in your first game. What you need to do is to think about what kind of game you are making, and what kind of networking your game would need.

Would it be a big deal if two players see different things? How badly will lag affect gameplay? Can lag be hidden by starting actions locally before the server confirmed then? What must be computed on the server, and what can be done on the clients?

Then, and only then, can you decide to just use whatever networking comes with your game engine.

[mtg-weekly-recap]

MTG Weekly Tumblr Recap

Tibalt | Original art by @sedelerystick​

Welcome to another edition! So many things to look at this week, including a look at the spoilers for Amonkhet, as well as Cats under Wraps, and some reactions to this weeks Magic Story, Trust. But let’s not put the Cartouche before the horse, and get started on the bounty that is this issue of the Magic the Gathering Weekly Tumblr Recap

1. To the Victor go the Spoilers

Cartouche Blend | Reconstructed by @hopelessly-vorthosian, Original MtG art by Kieran Yanner

This week, we got glimpses of Amonkhet’s local deities, and they’re posed to make waves. Like the gods of Theros, these gods require you to meet a certain condition before they can fight for you. It seems that all 5 will have different conditions, which will interact with their activated abilities. Hazoret feels right at home with Madness cards from Shadows Over Innistrad, and Amonkhet’s own “Discard matters” theme.  Kefnet strikes me as a shoo-in for a control build. not only does it give you an end-of-turn mana sink, but late game, only costs 3 if you miss your land drop. Expect to see these on game day, I think!

Recently, we saw the Planeswalker deck cards, sans text, but now here they are, in their untouched, uncensored, lean, mean ab-flexin’ glory! Gideon, Martial Paragon is lackluster, feeling like a toned-down version of his Battle For Zendikar printing, which has been a mainstay in Standard since he was printed. Liliana, on the other hand, is EDH ready, just begging to be slotted into an Atraxa deck. Her +2 can make short work of smaller creatures, or gun down larger threats every other turn, much to the ire of Voltron players. Her ultimate is nothing to scoff at, especially in a multiplayer game where she’s spent several turns putting creatures underground. 

Liliana, Death’s Majesty looks amazing to me, being able to wipe the board 3 turns after she comes down, all while protecting herself in the meantime. Alternatively, she has a home in battlecruiser decks, promising to raise the two titans left in standard, or any of the Gearhulks from Kaladesh. Gideon of the Trials also has the goods to shake up standard, being a three mana Platinum Angel that can protect itself. The great thing is, the emblem even works with any other Gideon, including his Battle for Zendikar printing, or Martial Paragon. Expect to see this, alongside his Oath at an LGS near you!

These two creatures are posed to be my favorite in the set. Scribe of the Mindful seems lackluster at first glance, but serves as a potent threat. With it, and Keftnet in play, your opponent is forced into a dilemma. Either walk right into an answer, such as a Fatal Push with revolt on, or give you the free card draw. With so many uses, I look forward to playing with the Scribe. Soul-Scar Mage fills me with an incredible urge to build UR Prowess again. It was an archetype I enjoyed deeply during EMN standard, but lost its chutzpa for me with the release of Kaladesh, and more importantly, the loss of Elusive Spellfist. Soul-Scar mage could be the aggressive, field-controlling presence the archetype needs to return!

-- Nick @nick-dowdle-jeskai-judicator​

2. This  Week’s Magic Story Review

Trust, by James Wyatt

Untitled | Original MtG art by Tyler Jacobesen

When writing a recap for the Magic Story, I think it’s important to consider beforehand what you want to focus on and what to leave out. For example, are we writing this for those who have read the story or for those who haven’t? The answer, of course, is both. You should cover the essential aspects of what happened so that those who haven’t read it can catch up and understand, but at the same time additional thoughts should be added, or those who have read it will find this to be nothing other than a boring summary. So, with this in mind, let’s get right to it!

This week’s Magic Story, Trust, follows the Gatewatch as they arrive in Naktamun, and their first experiences there. Thanks to Jace’s sublime improv abilities (and despite Chandra’s vocal ignorance regarding the customs of Naktamun), the group is able to lie its way into convincing Vizier Temmet that they’re returning from a mission for Bolas, and secure a place to stay as base for its operations. There are two main takeaways I would like to underline from this story. Firstly, we see a warrior taken away by viziers of Bontu as consequence for declaring  “The trials are a lie! The gods lie! The hours are a lie! Free yourselves!” and “The return will bring only devastation and ruin!” This is interesting: this woman somehow found out the truth, or at least part of it, hiding behind the trials of Amonkhet. This begs a few questions: how did she find out? Have other Amonkhetians discovered the truth over the years? And does she know something that we, as an audience, do not? Sooner or later, we will hopefully find out.

Renewed Faith | Original art by Wesley Burt

Now, onto the second major issue: Gideon. Ohh boy. As I mentioned in last week’s installment, Gideon’s admiration of the gods (stemming from his backstory) can and will cause friction between him and the rest of the Gatewatch. The feeling of utter devotion that Oketra instills in him in this story is powerful and difficult to explain (props to James Wyatt for conveying it so effectively), and has resonated with many who have felt a similar religious abandonment in their life: take @talinthas​ post on this, for example\. As a non-believer, I have a hard time relating to this feeling, but I do not underestimate its power. And it is clear that Gideon is torn between the Gatewatch’s mission and his feelings towards Oketra. All you have to do to see that is read these two passages: Firstly:

"Do you hear her?" Chandra said. "She's a freedom fighter!"

"We're not on Kaladesh anymore," Gideon said gently.”

and secondly,

"And what if your precious cat-god is the one lying?" "She's not." "So much for asking questions. Seems you already know the truth." "I don't know about the woman, or the trials, or the hours. But there is no deception in Oketra.”

There is no doubt, in Gideon’s mind, that Oketra is on the right side of the things. The gods’ true nature and intentions are still a mystery, both to the Gatewatch and to us, but the fact that they are the supreme authority on Bolas’s plane should make us suspicious, at the very least. Next week we will hopefully resume from the cliffhanger of Gideon meeting Oketra alone and see how exactly this will unfold.

As Cruel Reality shows us, Gideon will eventually have to face the true face of Naktamun. But what will happen between now and then? And how will this affect his relation with the divine? I look forward to finding out alongside you all.

--- Diego, @magus-of-the-color-pie

3. Just Cos...play

Nicol Bolas Armor | @dominian-dracologist​ After some exciting progress reports, it’s finally ready!

Akroma | @jdcosplay

--- Compiled by Liam, @coincidencetheories​

4. Shot through the Fan-Art

All Long, Evil Villains Have Equally Long, Evil Cats | Original art by @frigidloki

Spoiler season descended upon us like angry Jackal God, and as the new art is unveiled, new inspiration sparks within Magic Tumblr’s best and brightest. @diorevoredo is enamored with the concept of cat mummies, while @misteryada celebrated the opening of a fresh pack of chalk with a six foot announcement board drawing of our beloved Goddess, Oketra. Speaking of the Gods @theblogeternities imagined a world where Elspeth, spurred by the devotion of those who share her story, ascends to Theroan Godhood. Also, see the same user’s melding of the Amonkhet and Theroan Pantheon’s key art If you’re less for the gods, and more for the monsters, @steveraffle​ has immortalized the Eldrazi Titans in Stained Glass  --- Liam, @coincidencetheories

5. Tunnel Vision

Tunnel Vision| Original Art by Danny Orizio

This week, we’re looking to highlight some YouTube videos!

Commander Clash - MTGGoldfish:  A third series begins with a brand new cast member, Twitch’s Mrs Mulligan, Jennifer Long!  Deck Tech #1 - Board State: Recap contributor @delver-of-seacrest​ is starting a YouTube channel, Board State, and in this premiere video, he’s going through the Temur variant of the Modern Delver. Is it worth it: Mind vs Might - Tolarian Community College: The Prof takes a look at Magic’s most out-of-it’s-time duel deck release in recent memory, and asks if it is indeed worth the MSRP. and what else might be of relevance... oh yes Amonkhet Trailer (English) - Wizards of the Coast: I’ll just leave this here. --- Liam, @coincidencetheories

...and finally: Magic: the Travelling Binder project

It started with an idea by @zoe-of-the-veil, to send someone a magic card for them to receive, enjoy, love and then autograph and pass along to another magic player, with new cards being added once a card is full of signatures, hopefully building to an amazing collection winging it’s way around the world. Adapting and developing the idea, @commandtower-solring-go is preparing to host the Magic Binder of Travelling Cards, hoping to turn the tables on Wizards, and instead of sending cards to WotC for them to sign, participants would chose a pet card, sign it themselves and send it to @commandtower-solring-go. The cards would then be collated and arranged in a binder, to be sent to Head Office in Renton, as a gesture of appreciation for the game we all love. We understand that this is still going head, so check out the post for more!

Thank you again for reading this week’s issue of the MTG Weekly Tumblr Recap. Hope to see you next week!

Interested in contributing to the Recap? Want to keep track of notable posts and trends throughout the MTG community on a given week? Or write a short blurb on a specific topic? Do you just want to make us aware of one specific topic or post? Please PM our main editor @the-burnished-hart or any of our staff writers!