hplus0603

Moderators
  • Content count

    11931
  • Joined

  • Last visited

  • Days Won

    2

hplus0603 last won the day on June 20

hplus0603 had the most liked content!

Community Reputation

11347 Excellent

2 Followers

About hplus0603

  • Rank
    Moderator - Multiplayer and Network Programming

Personal Information

  • Interests
    DevOps
    Programming

Social

  • Twitter
    jwatte
  • Github
    jwatte
  1. A "socket" is the software API that most programs use to talk to the tubes; it's not the tubes themselves. "Sockets" is to networking what "openGL" or "Direct3D" is to 3D graphics. The tubes are to networking what the graphics card is to 3D graphics. Yes! The "number of doors" analogy is fine. There are in fact a number of addresses that stack on top of each other. The various numbers are: What network protocol are you using? This is almost always "4" for IPv4, or "6" for IPv6. Unless you're a crazy person running Banyan Vines or AppleTalk or Novell Netware on your pre-historic DOS re-enactment computer, or something, that is. This number tells routers how to interpret the next set of addresses. What IP address is the target host? This tells routers how to forward the packet to get to the other end of the tubes. IP addresses might be like streets. What IP protocol is used for the packet? This is things like "ICMP" (for ping, etc) "TCP" (for web browsing and downloads and remote shell) "UDP" (for IP phones and action games etc) and so forth. Protocol numbers may be like house numbers on a street full of apartment buildings. For TCP, what TCP port is being used. For UDP, what UDP port is being used. For other protocols, other protocol-specific sub-addresses. The important bit here: A UDP port is different from the TCP port of the same number -- just because you live behind door 80 in the TCP building, doesn't mean you have anything to do with whomever lives behind door 80 in the UDP building! For game protocols, games will often add game-specific sub-addresses here, such as "player 3" or "small gray rock object #7123761." There is no standard for this; each game is different. There is a distinction between the "host" (who gets to set the game rules, kick other players, etc) and "server" (which computer do everyone else send packets to.) This matters when the game company in question runs the servers, but still allow players to host. For example, custom matches in Overwatch. However, in most player-hosted games, the "host" and the "server" are one and the same. There are multiple systems involved. Yes, most of the time, especially for games with < 30 players, one of the consoles is the "server." Separately, there is a big back-end that does things like scoreboards and matchmaking and friends lists and so forth. The console game developer develops the code that actually runs the game server; the platform provider (Microsoft, Sony, ...) provides the back-end that does matchmaking, score-boarding, banning of bad accounts, and so forth. MMOs are different; the consoles don't run those servers, the game developers do; typically they develop servers that they then host in approved/provided data centers that are tied into the console platform network. Even some non-MMO games use developer-provided servers, to cut out the chance of having to migrate servers when players rage-quit. I know Gears of War did this, for example. Either the game suppots player-hosted servers, and tell you "please connect to my server!," or someone reverse-engineers the server-side protocol, and run their own server somewhere on the internet (and, again, say "please connect to my server"!) The problems with player-hosted servers have almost nothing to do with PC capability. It has more to do with network problems -- home networks are not well suited to low-latency upload which is what servers need. When your sister starts torrenting the latest Linux distribution, all other players in your game would suddenly get a bad connection. When you rage quit (sorry, when "your console crashes,") all other players in the game either get kicked, or some disruptive server migration event takes effect. This is a bad user experience. Thus, large games that can guarantee a revenue stream, will likely want to host their own servers, to make sure the gaming experience is smooth. Separately, for player-hosted servers, because the hardware is under the control of a particular player, that player could conceivably hack/cheat the game, by modifying the server software, and/or modifying the network packets that flow to/from the server. Because the hardware is under control of the player, there is nothing that a developer can do to deter a sufficiently advanced/determined hacker, and once a hacker has developed a script, less advanced cheaters can easily re-use that script. This, as well as the quality of the experience, is often one of the main reasons why developer-hosted servers will probably never go away.
  2. Experience with Photon Engine?

    There are successful games running on Photon, so clearly it's a "good enough" solution. I know people who used it for real-time multi-player, with Unity, and it worked for them. If you're not using Unity, I don't think that's a good option, though. However, if what you need is turn-based, batch-oriented, web services, then by all means use Node.js. Photon starts showing value when you actually need interactive real-time games. Farmville or Hearthstone? Node, not Photon. Overwatch or World of Warcraft? Photon might work better than Node. And, in the end, if you build an entire infrastructure around your game, you'll probably want a web application server anyway, so typically you'll end up having both anyway.
  3. User login system for mobile.

    What kind of attack do you think SRP protects against, that you need protection against? Do you not trust the ISPs on the way between the client and the server, AND you don't trust the TLS certificate chain of trust? Pretty much the only case where SRP would be better than password-over-TLS is where you believe there exists a man in the middle that has managed to insert a trusted root certificate into the clients' root store. Which is totally possible when we're talking about state actors, but ... it's unlikely the NSA is all that interested in your game :-) I'm not saying it's a bad idea to use a well tested library and protocol. Just curious why you choose to worry about those kinds of attacks.
  4. My point is that there is also a separate piece of state for multiplayer RPGs! It is in fact not the same. Specifically, the NPC may have state, and the player may have state, but there is also state in the relation between player and NPC that is different between each player and the same NPC. In a single-player RPG, you'll almost always just tack this state onto the NPC themselves, but that doesn't work for multiplayer RPGs. So, the pieces are: Client can see NPCs and the world, because you've arranged for the world entities and changes to them to be streamed to the clients for rendering. NPCs have some general properties known to clients, such as what they look like, where they are, and what kind of interactions they may accept (giving things, talking, etc.) Client chooses to make an interaction with NPC; this is all client-side, based on information client has. Let's say the interaction is "say 'hello'" Client sends interaction to server: "client X does interaction say,hello to NPC Y" Server receives interaction, and verifies that client is near NPC Y and such. Server retrieves the state (or creates new state if this is the first time) for the relation between this particular player and this particular NPC (<-- this is the different bit!) Server forwards the interaction event to the NPC handler. (Depending on how you write the script, you may need NPC state, player state, world state, player/NPC relation state, and data from the specific interaction event) NPC script runs whatever logic it wants, which may generate world-visible events, may send chat to the player-only, may modify inventories, and so forth. Server saves the outcome of the interaction as modifications to player, NPC, and player/NPC relation objects. Server sends outcomes of interaction back to player. This may be an explicit response message, but more likely, the client just sees the effects because of the side effects from running the NPC interaction script -- "an item was added to your inventory by Y" and "Y says 'here you go'" and "door object 22 opens" that the client knows how to render no matter how those actions were initiated. (See step 1 !) Each of these bullets need support from the game engine, and while you could get 1, 2, 4, and 10 out of a typical multiplayer library (anything from Photon to Unreal Engine to whatever) you will generally have to build 3 and 5-9 specific to your game.
  5. This is the event handler you would write for the NPC on the server. Presumably, the client already sees NPCs in their vincinity on their clients, and can interact with them, which would send these kinds of interaction events to the server. The server would then run sanity checks ("can player see NPC, is the distance not too large, is there no locked door in between, is NPC alive, is player alive, ...") and forward the event to the NPC in question. Building the infrastructure that actually allows these kinds of events to be forwarded with the correct context, is one piece that sets an online RPG apart from most other kinds of games; there are more fiddly bits of state here than in "I put this bullet into the world and woe unto anyone in its path!"
  6. Yes, games get pirated! And to some extent, this is not great. And if you can lock down your app, there is some gain to be had there, assuming that your game is well known enough that it will have lots of players, and important enough that the players who crack software will actually bother with it. Another option is to use the piracy as a marketing mechanism. If you update the app every month, with new encryption keys and new content not available in the previous month, then you can use the pirate copies as marketing. When your server tells the app is 3 months old or older, pop up a dialog saying "get the latest version from iTunes to unlock new cool content!" Hackers that hack the app might not find this dialog, and because the time isn't yet that old, the app won't show it until it's spread already. Will server-side keys plus encrypted files stop a casual hacker? Yes, likely. Will your game be annoying to players if it has no way of being played when in the basement or traveling between coverage areas? Absolutely! Which of these is the bigger problem? Only you can decide for sure. Mostly, though, piracy hurts small game makers, not because the small games are pirated, but because the big games are pirated. If a game playing pirate can play the big games for free, or play the small games for free, they'll more likely play the big games. If the option is playing the big game for free, or paying a small price for the small game, then the small game can't compete. For users who don't pirate, the equation is instead "play big game for lots of money, or play small game for little money," at which point the equation starts working for the small game developer. Finally, I will leave you with what I think is the best story about piracy management, out of the release of Game Dev Tycoon.
  7. Keeping your iOS application un-cracked is really Apple's problem, not yours. Keeping users from rooting their devices is Apple's problem, not yours. The question is: If you could somehow make the game not work when on the pirate app stores, do you think people would instead pay for your game in the iTunes store, or would they just play another game on the pirate store instead? Similarly, if they REALLY want to play your game, is the price in the app store really going to be a problem for them? I think you're trying to "solve" something which isn't actually a problem for your profitability or marketing. And if that "solution" means that regular, paying players get worse service (say, the app doesn't work when they're not connected to mobile data/WiFi) then you're actually hurting your own chances. Note that users capturing the screen will be able to share the screen caps quite easily, so it's not just "users who paid for the card" that see it; it's the entire internet. A much more useful strategy than locking things down, would be to put the name of your game in the lower-left corner of all screens, in an unobtrusive way, so that anyone who sees a shared screen, can see the name of your game. If it were me, I would spend approximately zero time on solving the rooting/cheating problem, and spending all of my time on making sure the game is worth paying for, and then spending time on figuring out how to tell the world that the game exists and is worth paying for. It will likely have a much higher return on time invested than anti-hacking mechanisms.
  8. Typically, you'll run all world updates in a single thread, so that you don't need to implement locking. It's very uncommon for a full world/zone to be so complex as to overwhelm a single core, unless you also do physics simulation, which may need a multi-threaded implementation. There is one difference to single player games! In a single-player game, you will have two entities that matter: The player, and the NPC. If the player says something to anger the NPC, the NPC may change its own state to "angry," start to attack, and so forth; this state can easily be kept on the NPC. In a multi-player game, there are actually three things that matter: Each player, each NPC, and each relation between specific players and specific NPCs. This separate player/NPC relation is actually a different "thing," and you'd probably do best to keep it separate in the game, although you'd want to store these states keyed on the player in your database. So, the scripting callback from the player talking to the NPC might contain five arguments: def onInteraction(self, world, playerInteraction, playerRelation, player): if player.faction != self.faction: self.tell(player, "You are not my kind!") elif playerRelation.state == None: self.sendDialog(player, self.initialDialogTree) elif playerRelation.state == ON_FETCH_QUEST: if (playerInteraction.action == OFFER_ITEM and playerInteraction.item == SMALL_GRAY_ROCK): self.tell(player, "This is great! Here is your reward!") player.addInventory(FLAMING_SWORD_OF_FIRE, 1, self) player.removeInventory(SMALL_GRAY_ROCK, 1, self) elif ...
  9. Client-side culling of distant entities

    A belt-and-suspenders approach would also have the server tell the client "you should now have area 458 but if you don't, let me know and I'll be happy to send it." You'd likely want to not just trust the client blindly when it says "I don't have area 458" but instead verify that that area is actually within view of the client, else clients could request areas far away for whatever gameplay cheating reasons that gameplay cheaters can come up with. Thus, the request the other way would go "I'd like area 458" and the server would either say "here is area 458" or it'll say "you're not close enough to area 458."
  10. What is the attack you actually want to protect against? For example, you could pre install all cards, but make the client "dumb" and just send selections to the server, and then only show/animate based on instructions from the server. This would prevent against players "seeing the wrong thing" until players figure out how to write a fake server. Regarding encrypting the assets against "ripping," know that tools exist to slurp textures and vertices out of the graphics card. Because the card needs to render to screen, that data need to ultimately be in decrypted form. Pays can also use screen video recorders to record the animations and enjoy them whenever they want. If you want to encrypt files on disk, there is nothing bad about that per session, but it won't stop a determined attacker. That being said, your actual problem will be getting people to find out about your game, and then care about your game, and then care enough to give you money. Asset ripping seems like a first world problem by comparison -- almost like free advertising... Anyway, define the attack you want to defend against, define the capabilities of the attacker, and may be able to come up with a solution, but the attack "sufficiently motivated users can copy your art when they see it on the screen" is not something you can realistically defend against without hosting your have only in carefully controlled secure facilities.
  11. SpatialOS single shard MMO

    The other thing containers do, is deliver a "complete working piece of software" in a single download. All the libraries and data files and whatnot needed by the software in the container, is typically included inside the container image itself. Thus, containers are also a convenient way of delivering pre-configured software for various tasks, even if those tasks aren't inherently scalable. Instead, what you get then is the convenience of "download a thing, click run, and it will (hopefully) Just Work (tm)" Thus, "it uses containers" tells us pretty much nothing about the innards of the system, but it does tell us that it's probably easy to download something and start it up, and it's probably easy to start up many copies of it. Whether those copies will efficiently form some kind of larger cluster, is totally up to the implementation of the software on the inside.
  12. SpatialOS single shard MMO

    Docker is largely a cheaper way of running "virtual machines" of software in isolation from other software. It makes building the "machine images" (containers) straightforward, and has a number of orchestration methods to put containers on physical hardware. The draw-back, compared to VMWare or Xen or whatever, is that all the containers have to run on the same kernel, and that kernel needs to support containers in turn. You can run web servers in containers. You can run game servers in containers. You can run memory caches in containers. You can run proxies in containers. You can even run desktop software in containers (if you forward the appropriate desktop.) You can also run databases in containers, although the I/O virtualization ends up making that so slow that nobody really does that for real. The fact that something "uses containers" or even "is built on containers" doesn't really tell us much at all about what it does, other than that it presumably has some way of breaking up work into smaller, hopefully scaleable, units.
  13. You should look up the "priority queue" data structure, which is generally implemented as a heap. This means that insertion is O(log N) and extraction of the next event to run is O(1) Even if the queue is just a big ol' vector, insertion will be O(log N) for searching (binary search) and O(N) for the memcopy to make space for the event in the vector; turns out memcopy is very very fast compared to chasing pointers so that O(N) is unlikely to dominate. Compared to scanning all players and other entities for all possible events every simulation tick, this will be a lot more efficient.
  14. Most game engines will have a priority queue of timed events. Thus, you won't check all the things that could happen, "have you happened yet?" Instead, you'd insert a record in the event queue saying "call this object function at this game time." The game loop will then, in each simulation tick, advance time, then run all the event records that have a time less than or equal to the new game time. That way, when the player dies, you simply insert a record saying "disconnect this player after 7.3 seconds" and it will happen at the right time. This mechanism is often used for other things, too, such as the expiration time of buff spells, expiration of invites, and so forth.
  15. User login system for mobile.

    There are two kinds of tokens: 1) A long, random, string, which you use as a primary key on the server to look up user ID, expiration date, and so forth. A good way to generate this is to generate 32 bytes of random data (using /dev/urandom, or CryptGenRandom) and then encoding as base64 or base85, so that it consists of entirely printable ASCII characters. 2) A token that consists of some "real" data and a signature. For example, the token could be "version:userid:generatedtime:signature" where "signature" is computed as HMAC(version:userid:generatedtime, secret-key) and only your servers know the secret-key. Your servers can then verify this token by looking at the generated time, making sure it's in range, and then verifying the signature. The signature is likely using SHA256 and encoded similar to how you'd encode the long random string in the other case. You'd use "version" to be able to add more data in a compatible way later, or to update the private secret every so often if you fear it leaking out. The benefit of 2) is that it doesn't require a database lookup to generate or validate. The benefit of 1) is that it's simpler, and there's no private secret to share on your servers (and that someone could steal.) These tokens are very similar to session cookies, stored by web sites when you log in. Web browsers used to store cookies in plain files on the user's hard disk. I think that with "browser sync," the mechanism is a little more involved these days, but in principle, if someone can already infect your computer to the point where they can read your files, you can't protect against them anyway, so encrypting on the local machine is probably not necessary.