Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

485 Neutral

About antosdaniel

  • Rank
  1. antosdaniel

    Future proof scoreboard server design pattern

    For errors I would stick to google's best practices (for some reason it does not automatically scroll to #error, so go to "Top-Level Reserved Property Names" -> "error" or "Reserved Property Names in the error object" for more details on each field).   Personally, for API version I would go with url versioning instead of headers. It is easier to setup on backend (if you want to support old API calls) and is more transparent for API users (devs). Here you can find more opinions about it.         Are you sure about status field? Isn't HTTP code enough? Like 201 is success or 400 for failure? (I am talking about good practices here, both will work, I just can not find any reason for adding this)
  2. antosdaniel

    Future proof scoreboard server design pattern

      Use POST and GET, whatever fits best. GET is most often used for retrieval when POST is for create/update. Both are fine.     I am not sure if Amazon is best place to start, there are cheaper options. Although I heard that they have first year for free (if you do not go above cheapest solution).     How application will know this secret? If client application knows secret then so can a cheater. What if same client reports hundreds of wins with different match ID?     That would kill your game.     I do not know how it looks on amazon but on different web hosting providers you can add domain so it should be possible. I do not have much experience here so I may be wrong.
  3. antosdaniel

    Future proof scoreboard server design pattern

    So you generally need to write an API for your backend. I am sure you can find many good sources on that, these look good (I just glanced over them, there is PHP section). In short, your game makes normal request to your site like www.yoursite.com/leaderboard to get top players on leaderboard or POST request to www.yoursite.com/matches to register for a match. Doing it this way you provide very light server application which should scale well.   For maintenance break just return HTTP 503 response code when he sends any request. You can also make client sends GET /status request every minute.   Your biggest problem will probably be cheating. How will you know who won a match? If you relay on player reporting his victory it may go badly - someone can send thousands of victory reports in seconds. My only idea right now is to limit reports per hour. If your standard match lasts 15 minutes it is very unlikely that someone will win more than 5 times per hour so you can limit that. You could also always wait for 2 reports - if winner reports that he won match with ID 120, and looser reports that he was defeated in match with ID 120 then you can give him points. If someone has more than 90% win ratio and way to many games you can also mark it as  suspicious behavior which you can reports to yourself and check it manually to avoid banning dedicated players. Maybe someone will have better idea.   What do you mean by ISP change? Do you want to host it on your computer or are you going to change hosts frequently (and why)? As long as you purchase domain and all the requests are made to this domain (which should point to your application) it will be fine. Client always sends GET request to www.your-awesome-site.com/status. If you change your hosting you just change IP to which your domain points to.
  4. antosdaniel

    Destructible terrain

    Yes, it seems like they are using Voxel Farm I made some more research and there are games which use that but they focus on building instead of combat and destruction. Voxel Farm's blog does not go into details about networking nor collision.         Shouldn't I? It is an MMO and I am interested how do they handle voxel generated world on the server side.         What do you mean by that? From video it seems like you can destroy a mountain or dig your way under the castle.         In video player digs tunnel under castle. It is possible that they allow only for height modification (it is hard to say from footage). Seems like a good way to go about it   I know title is "Destructible terrain" but they allow to destroy anything - if there is a wall in your way, no problem, cast some spells and create hole in it to let your troops pass. I thought that they use single collision detection method for everything but after your responses I suppose they may use different system for every "object type". For example, terrain may only use its height but structures are handled as mesh which is rebuild after few fireballs. Did I get it right?
  5. antosdaniel

    Destructible terrain

    Today I found interesting concept of destructible terrain in Crowfall. They say that they want to use "tiny blocks" to build (from video player can also build) or destroy anything. How do you think they want to do it (or maybe they already did)?   For me it looks like quite difficult task. Not only building/destroying but collision. Collision detection between many small blocks and player seems nuts. They probably could rebuild voxels to planes for collision check but I am not sure how efficient it would be - creating simple geometric figures every time player destroys something may get overwhelming in some kind of "castle defense".   PS. Do you think they are being over-ambitious? They have (a lot) more experience than I do but it seems really massive for not that big of a studio. Good luck to them anyway
  6. antosdaniel

    Handling multiple maps

    I would solve path finding on client. Client sends points to which he WANT to move, when server manages collision detection while moving player towards these points. If you have master server NAT should not be a problem (I only read about it - try NAT introduction). Player connects to server, when he wants to join realm then your server can inform realm about new server and player about new (or existing) realm. This gives direct connection between players (and probably solves NAT).   For bandwidth I would send only informations which other player can see on screen. If you want to share everything then you can send rest in batches later.
  7. antosdaniel

    Reliable UDP messages

    "fire & forget" seems the best option for fast paced games, but even then there are messages which should be reliable - player connect/disconnect, player A headshot'ed player B, combat log or chat.   1) Is sending these messages "reliable way" best option? Syncing seems like wasting bandwidth. When data (eg. combat log) grows we will have to sync only newest part of data, which gives another layer of complexity and there is still possibility of loosing some data with bad connection quality.   2) Is sending messages in different delivery methods supported by most networking libraries? What I mean by that - are there any problems when sending 5 unreliable messages followed by 1 reliable? I am currently using lidgren but if someone has used other libraries I would gladly learn about them too.
  8. antosdaniel

    how to protect mysql strings?

    If you store connection details on the client, you can not protect it.   You should create server in between. Client ask server hosted by you, server has connection details and decides if data can be saved/loaded to database.
  9. antosdaniel

    How unreliable is UDP?

    I am not looking for any *real* answer, I was just curious after reading the article I posted. Additionally, it is good to know under how "bad" connection I should test multiplayer games.   I am very satisfied with answers by the way, thanks :)
  10. antosdaniel

    How unreliable is UDP?

    Thanks for responses, they are useful, but I am more interested in statistics. They will vary from connection to connection, but average % says more than "frequent", "good", "bad".   What is time span for good and bad connection out-of-order? What I mean by this is how much later does this packet arrive? Is it something within 2 * ping or can it arrive 10 seconds later?
  11. Recently I read this. Does anyone know how these numbers look for heavier traffic (well, games)? Is packet loss so irrelevant (in terms of %)?
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!