New High Score! Leaderboards in the Cloud

Editor's Notes

• #2: 1
• #7: Transmission Control Protocol / Internet Protocol (TCP/IP) | Open Systems Interconnection (OSI) The thing with TCP/IP is that it is distinct from the OSI model ("the layers"). OSI is just a model of the separation of concerns. There are sometimes not clear boundaries between the layers. They simply serve as a guideline to how your networking functionality should be divided. Now, onto the layers. Suppose you are trying to communicate with Alice and Bob, who are next door neighbors living on each side of your house, using a three cans and three wires. (One can is connected to both other cans.) The cans and the wires are the physical layer. They allow you to transmit raw sound (raw bits). The problem with this is that you don't know who you are sending to. You want to somehow address either Alice or Bob. So, before you say your actual message, you say the street address (MAC address) of the guy you want to talk to, and they both listen to this address and determines whether the message is for them. Now, you have to have good faith that Bob will not eavesdrop on your message to Alice. This is the job of the data-link layer. Let's say Alice's parents are rich, and they own the entire block. They move around houses every day, and you don't know where she is at any given moment. How will your message reach her? Remember, she listens only for the street address where she is currently at. So, you guys get together and assign each of you a number (IP address) that identifies you no matter where you go. And, you decide to post in the local newspaper (DHCP service) the physical location of each of you, every day. That way, you can look up Alice and Bob’s physical addresses when you need to, and will be able to send them messages. This is the network layer. What if you want to talk to multiple people in Alice’s household? What if she has a hot older sister, Charlotte, whom you have a crush on? How will you let Alice know that a message is for Charlotte, instead of Alice? Simple, before your actual message, but after you say the street address, you say “This message is for Charlotte.” But names are complicated, so we assign a number (port number) to each person (process) in the household that wants to communicate. This is the transport layer. (TCP and UDP sits on this layer.) Furthermore, sometimes the wire is bad and there’s a lot of background noise outside so you can’t be sure that the other person got your message. What do you do? Simple: have the other person acknowledge every message you send, say, “I got it.” (This is what TCP does but not UDP.) Remember, all of these messages are still prefaced by “This message is for ___” and the street address of the recipient. How will Alice know when the conversation is over? What if she wants to go eat and doesn’t want to pay close attention to the wire? Just say “Goodbye” at the end of your string of messages. This is the session layer. (This layer isn’t very well-defined, and is often combined with the transport layer.) Perhaps now you want to talk to David, Bob’s uncle. He doesn’t speak a word of English and only speaks Russian. What can you do? Get a translator! The translator listens to your message, translates it into Russian, and says the message in Russian to David. When David wants to talk to you, he talks to the translator, and the translator translates his Russian message into English, and then relays the message back to you. This is the presentation layer. Suppose, on top of all of that, you want to play a game of chess. Chess has well-defined, standardized notation of the moves. So you can simply say “knight to F3” and the other person will understand that you want to move your Knight to the square labeled F3. Imagine, that you have a chess board that speaks the move in the standardized notation every time you make a move, and every time it hears a move, it moves the mentioned piece to the correct location. Now, you can play chess, over two cans and a wire, with everyone that has a similar chess board, even with David, who has a board that only operates in Russian. This is the application layer.
• #10: Separation of concerns = network traffic does not slow down GUI display. We can deploy it, make it redundant, fault-tolerant, and all the good stuff. You don't have to worry about the fluff of managing a VM. We do all that for you in the Azure side, and you just worry about the application and that service providing the functionality. You can just isolate it, get it ready, and deploy it into a cloud service, and it's running! No need to upgrade and patch your operating systems for security holes. Cloud services take care of all that behind the scenes. It's essentially running in a small application-isolated box. You just update your code.
• #11: A "Get" is a postcard. You're supposed to use it to request a document. There's no space on the postcard to send me a document, although you can squeeze a couple of lines into the end of the room and name field. A "Post" is an envelope. It's supposed to be used to send me a new document for me to store, but you can really put anything in the envelope. A "Put" is another envelope. You give me a document, and I'm supposed to replace a document I have with the one you gave me. A "Delete" is a postcard telling me to throw out a document. REST takes as its premise the idea that there are really only four sorts of things you might want to do: Create, Read, Edit, or Delete things. I have a mail room somewhere with a separate slot for each "thing". You send a letter with a name and room specified, and it really goes to a slot in this room, where someone takes and processes the request. If you want to Create something, you send a Post with the thing you want to create enclosed; if you want to Read something, you send a Get; if you want to Edit something, you send a Put with the thing enclosed; if you want to Delete something, send a Delete postcard. That's it – there's nothing extra to work out. All you need to know is what "things" I have, which is fairly easy for me to communicate.
• #12: Let’s give this Mobile Service a name. For example, I could to use “testleaderboard,” which means that the start of the REST API endpoint for this service would be https://testleaderboard.azure-mobile.net.
• #13: After choosing a name and selecting a database, we will have to enter in the database credentials. Under the database dropdown, you will have a few different options: use and existing one, create a new one or create a new database server.
• #14: Once you have your database selected, your Mobile Service will be created. You should be able to see it in list with its creation progress being reported back to you. Once it is created, select it from the list. We now need to think about the data that we want to store and access. We can create a table to store the data and add whatever columns we think we may need. For this example, I am going to create a table called ”highscore” and add in a few columns
• #15: We need to name this table and set its permissions for the various CRUD operations. For this example, I am just going to allow insert, update, delete and read to happen with an application key. We will need to find the application key as we will need to use that with every api call that we make. Don’t worry about the application key quite yet, we’ll get to that in just a bit.  Let’s add a few columns to the table first.
• #16: To add a new column, select the “Add Column” button from the bottom navigation. I am adding two columns : one called “user_name” with data type of String, and another called “score” with data type of Number.
• #17: Select “Add Column” from the bottom navigation and add a column called “user_name” with data type string, and a second column called “score” with a data type of Number. We now have a table called “highscore” for our Mobile Service and we added two columns called “user_name” and “score” to the already existing columns in the table. Now we need to only do a few more things before we can start using this service. First, let’s go get our application key.
• #18: Select “Manage Keys” from the bottom navigation. We will need to record the application key. Copy the top application key and record it for later use.
• #24: Unity3D Leaderboard in the cloud using Bitrave Azure plugin https://www.youtube.com/watch?v=KGEabheqcRA Microsoft Azure Back End for Gaming https://mva.microsoft.com/en-US/training-courses/microsoft-azure-back-end-for-gaming-10548?l=RU7KQp97_1504984382 Play Together! Leaderboards with Windows Azure and Multiplayer with Wi-Fi Direct https://channel9.msdn.com/events/Build/2013/3-051 How To Create A Global Leaderboard For Unity 3D Using Azure Mobile Services https://channel9.msdn.com/events/MVP-Virtual-Conference/MVP-Virtual-Conference-Americas-2015/Dev2-How-To-Create-GL-Unity-3D-Azure-Mobile-Services
• #25: http://thebitchwhocodes.com/2014/02/24/using-azure-mobile-services-to-create-a-game-leaderboard-in-minutes/ REST API: https://www.reddit.com/r/explainlikeimfive/comments/1fevr4/eli5_representational_state_transfer_rest_or/ TCP/IP: https://www.reddit.com/r/explainlikeimfive/comments/mk75a/can_anyone_please_explain_tcpip_and_its_layers_to/
• #26: https://www.visualstudio.com/en-us/products/visual-studio-community-vs.aspx