riuthamus

You could use a separate seed for placing resources, so you send the normal terrain seed, and then send the visible resources individually (not by sending the seed)

That is a very interesting concept... separate them out and never share that seed with the client. Send resources to the client as they get near the chunk... very interesting indeed.

So, to give you some background.

I have a game that we are making. ( the core elements of the game are already in place and we were working from a Single player perspective only ) Unfortunately, we found that to get the multiplayer to work properly we would need to redesign most or all of the information. We have completed that process of handling how the server sends information to the client the question is now "What data to send the to client? and how often?"

We have a very massive world that is created with a perlin noise algorithm. The map is created in 16x16x255 regions know as "chunks". We want to figure out the best possible method for sending this information from the server to the client application. We would like to avoid the pitfalls that minecraft had with loading chunks outside of the players immediate zone, or having chunks missing all together for an extended period of time. What, if any, methods can we use?

Things of interest:

• We dont want to spam the client with redundant regions
• We want to prioritize regions closer to the client so they load first
• We want to limit how much information is sent and optimize that with the premise that the player cant and doesnt need to see everything.
• Possible use of super regions ( regions grouped together that have not been modified since last seen )
• Storing the data, once sent, best possible option for storing it.

We have tried a few methods but wanted to see what people thought was the best route. Also, i am not sure if this post belongs here, it tech falls under game development as well as Networking/Multiplayer. If this needs to be moved please do so as we have no problem with that.

Or you could look at a whole different approach - use steam (even though they will take a cut), you can develop your dedicated servers that the public will be able to host to verify each player is a valid steam client with a copy of the game (You should be able to do this, if not my bad. I havn't played around with the steamworks API main due to the problem being I havnt released a game on steam yet).

I thought of doing that as well...

I would agree with hplus. Just make the game first. You can develop the game with efficiency and reliability in mind but, once you release the game you can then expand (improve hardware) as the game grows. 10,000 connections per second wont happen overnight.

I think you guys are missing the point. I have a game.... the point now is to work on the connections to enter the game. I wouldnt be coming here and asking these things if I did not have a game already in place. I am looking for ideas on how best to tackle the situation not advice on where to start the game development; while I appreciate the concern, it is more or less pointless to attempt to try and tell me "dont bother with this till much later". I am bothering with it since it is where we are going next. As for 10,000 requests... i have no clue what is or is not a bit amount. I have come to this section looking for knowledge... If this is the improper practice I am sorry for my misunderstanding.

Wouldn't it be an even huger waste of time to spend time writing support for a game that nobody wants to play? Or spending time optimizing something which won't actually turn out to be a bottleneck in the end?

It would be, assuming I had nothing... an assumption that is very much unfounded.

But that doesn't mean that login servers are a bottleneck at all. A login server needs to verify user name/password, generate a signed ticket with some lifetime, and write an entry into a log file. You can do thousands of that per second on a single virtual instance, and if you have a thousand users per second logging in, you're bigger than any indie game company I know of (except possibly for Steam.)

This is good information to have, something that I did not know and something that is important to realize. Scope is the whole point of this and if the scope I was looking at is too grand than I can certainly scale that back a bit. This is constructive information, much more than the "dont bother with this for now" comments.

I think Minecraft is a phenomenal success and I would have been very proud have I created it. Sure it can be better, but 99.9% of all projects are actually failures. Usually, the problem is that developers spend way too much time building things that don't matter *yet* instead of making sure they figure out what the successful game will look like. Building robust infrastructure as you need it is much easier than building a compelling experience that users want to pay for.

That being said: If you can spend six hours instead of two hours on some task, and the difference is that with the six hours, you solve a problem right, and with two hours, it will fail when you have a hundred users, then spend the six hours. Just don't spend six days if you can unblock the "fun finding" with two hours of work.

I never said that minecraft wasnt a success, i said I do not want to fail on the aspect of not being able to login, as they have had that issue on several occasions. The point of this thread is not for me to get advice on what I should be working on. The point of the thread is to get advice on how best to handle a login server. I am not the main coder of my game and because of this I have all the time in the world to waste on asking these questions and learning. Without knowing my development process and my development team such advice seems unfounded and more or less a waste of all of our time. If you have something of value to add to the post please let me know so I can learn and start to do some research. Otherwise, I would very much appreciate the comments about "not a valid use of time" to cease. Part of the development process of any project is research and development.... to get there you have to know how things work and how they are built. That is what I am doing with this thread... finding out the information with the help of people who are, much like yourselves, experienced. Walking through the jungle can be a very dangerous path... but if you have a tour guide they can show you the things you need to know to get through and focus on what you are looking for.

Thus, the creation of this post. Finding those people who know much more about a thing that I have barley scratched the surface on. Again I will stress that I have all the time in the world to be doing this so please indulge me with your comments on how best to approach this, otherwise dont post about how I should or shouldnt handle my time.

If you want to understand load generation, set up a user database in Redis or something. Spin up an Apache or nginx or Node or something. Write a little PHP script or JavaScript or whatever, where all it does is:

0) decode the user name (email?) and password from the request
1) look up the user record based on the user name / email in Redis
2) hash the provided password with a salt
3) compare the password hash with the hash in the user record
4) if mismatch, return error
5) if match, create a ticket consisting of (username:expirytime:hash(username:expirytime:serversecret)) and return success

Now, your client can present the ticket to any server, and it can verify that the user is who he/she says he/she is by simply verifying the hash (all servers should be configured with the same server secret.)

Now, use "ab" or a similar load testing program, running on another machine or two, to generate load for this service, and see how far it goes.

Note that, if average session time is 1 hour, and average login request service time is 10 ms, then you can serve 360,000 simultaneous online users from a single login server, and I'd be quite surprised if the login mechanism described above couldn't be made to run much faster than that.

And, if you're using a simple key/value store for user records, and a simple signed-ticket service for login/authentication, then you can scale horizontally with very little effort -- use consistent hashing for the storage instances, and any HTTP load balancer for the front end. This is a solved problem, and as long as you have a reasonable path towards the scalability you need, you don't actually need to develop and test it until you actually need it. Time is the most precious resource we have, and using it to address the biggest risk first is, IMO, the best use of it.

This is exactly what I like to read as it is informative and supports the idea you wish to express. Informative and it shares your point of.... its not needed right now in a way that seems less hostile. Thank you for this information as it will certainly help in me finding the path I am searching for.

You are wasting your time, first write a game that demands 10,000 requests per second, and then you will be able to hire a whole team of hplus types to solve all your problems

Read the above wall of text. Post is pointless and I have no need to hire teams of hplus's. The point of this forum ( as far as I understood it ) was for would be game developers to help one another grow and develop. I am not asking for direct answers or for people to do the work for me, what I did ask is how people would do it or what ideas they might have when dealing with such a request. Information like that can lead me to the answers I am really looking for and save me wasted time of wading through thousands of hours of bullshit that has no relevance to what I am looking for.

Again, thank you for the help hplus, your most recent post was very helpful.

I think you're starting in the wrong end. First, you have to make sure that you have a game that's fun, and that people care about. Then, you need to make sure that you know how to add capacity once you have a success. Then, you need to start promoting your game. As your user base grows, you should add capacity to stay at least a few weeks ahead of the curve.

While i respect your choice to have an opinion i do not agree with it. If i muddle around without planning for such things and when the time comes I have to rework most of my stuff because I was simply throwing things out there, it would be a huge waste of time. Part of what makes the game fun ( as per what I want to do ) is having 100+ players in a server fighting and going at it. To ensure that happens I need to make an authentication server that doesnt bug out like minecraft does. Players cant access servers with their accounts if the primary authentication system is down because it doesnt handle stuff correctly. Why waste time in later development when I can do so now? That said, i wouldnt spend 500 hours working on a flawless system if the need was not there. Im simply trying to process out what is the best practice for making an authentication server. Not sure your comment supports or helps with that.

And, if you really worry about this, then develop on a public cloud where you can easily provision hardware you need -- Amazon ECC, Linode, Rackspace, Heroku, or similar. That way, you can start with a micro instance that contains both database and application server and cache (good enough for 10 users per second,) and then grow to a bigger instance once you have users, and then split to multiple instances once you're successful, and only pay for what you use/need.

I do own a Linode server already. I have a media temple one, as well as 4 other dedicated servers that can host up to 25 game servers on them each. I have plenty of resources at my disposal ( thanks to my gaming community ). Again, my major point of this post was to detail out the best possible practice for creating such a process. Should the login/authentication server be held on a different machine than the web server? how would you make them interact with one another since it all needs to be linked? Those types of things. I apologize if I did not detail myself better in my original post; thus causing all of this confusion.

I am curious if this is worth the effort:

• Purchase a webserver ( small for beginning tests )
• Create code that allows the tracking of server stress
• Create code that tracks unique hits
• Create code that tracks client requests
• Create code that when button pressed will launch and authentication request to the server
• Release the site to many other sites to help test the stress level and load stability of the server

The goal of this would be to estimate the load a web server could handle and withstand. This would also give us an idea of how much of a server we would need based off of the reporting information it has. If our game is successful we could have upwards to 10,000 requests a second. Anyway, thoughts on how we could do this better? or things we should attempt to capture?

Well, i did not think this would get so many comments and suggestions! I am overjoyed!

1) The overview map would not be zoomable. You would only be able to view, pan left and right, top and bottom. The idea is to give them a more world based view of what is going on. We have already created he minimap ( radar type thing ) that lets you see where you are and displays wavepoints and such. We want to make this overview map a tool for seeing borders of regions ( owned land of other nations/countries ) and a way to track where you are in the world compared to other players.

2) Our game is 100% multiplayer. There is no single player, the Singleplayer option is just a multiplayer server with a server player count of 1! So loading screens will not exist except for when entering a server. Everything else must be done on the fly and in real time.

3) We are using dx11, and C#. The actual code itself is rather strong... i just am not sure of the best process for creating the overall look and theme I want. I will start out with the ocrtree and see where we can go from there. All of your suggestions are very much appreciated and I will let you know if we make any headway with this process. Thanks again

I dont know, seems doable. In 2000's NWN ( a great game, but horribly coded for mass multilayer ) was easily hosting 250 players on the big servers. This loaded all areas into memory and was doing some silly things. For an indie developer not using any of the newest technologies you should easily be able to handle 100 players on a single server. Minecraft ( which currently has shit for netcode ) can host up to 75+ with a decently sized world ( 5gb ) and have little to no lag unless you are doing some seriously massive world changes. That said, with the right code I am almost certain you could triple that.

As for games like TF2, they were not designed for bigger numbers and thus they are limited. It is not because they are not capapble, they just didnt want a game that would work with anything past the current cap. I run, and have hosted for 4 years, one of the top tf2 servers and we have been hosting it at 32 players ever since the crack came out to do that. We asked them for more player slots on several occasions as our server could have easily handled 64 players, but they said it would break the concept of the game... and I can see how it would. We had to make several changes to the core systems in order to allow it to work for the 32 player setup.

Anyway, all in all i think what you are trying to do is possible.

Just to update, in case anybody wanted to see where this went.

For the OP, we found that perlin worked the best

Simplex and perlin noise are pretty much indistinguishable - the one is a further development of the other.

Unless, of course, you learned about perlin noise here, which is wrong (it actually describes 'Value Noise', combined with 'Fractal Brownian Motion').

I never said they were or were not... i simply said what we went with. We have not touched terrain generation in months since we have been focused on character creation, items, crafting, spells, so when we get back to it I will most certainly take a look at the Simplex process. I can tell you, that the main point of my post was that having an in game generation setup was much more helpful than closing, recompiling, and doing it all over again. *shrugs* that is how it has worked for us.... perhaps that wont for you, or anybody else. Simply sharing my thoughts friend!

I actually like the idea of the 3d one... so thanks for posting it!

For the OP, we found that perlin worked the best, I would play with it, see if you can create an in game render system that will let you modify values and click GENERATE, this is what we did and it let us find the best results quick.

Yeah, def. I will have him post it as soon as he gets up. Or pm you with it, you have been most helpful quiSHAD, if you ever need some art let me know.

Well... i convinced him to make a slider system so we could control the settings... and.... we came up with the following:



Now this looks rather good so far, but there are certain lighting scenarios where that blur just goes ape shit again. This new control system we setup really helps.... curious if we could do, On the fly editing of it... hm....

Anyway, we also fixed the auto exposure setting, once we get some shadows in ( another issue ) we are going to be in business!

We are having a problem with our point lights not working. Our current setup is a deferred rendering for lighting. Now somebody can correct me if I am wrong but this is how we are doing it:

• We render stuff and our colors are recorded on a color RT
• Normals on another RT
• Depth on another RT ( our depth is logarithmic )

When we render the point lights they need to read the depth RT so they can use the depth to calculate the world position of the pixel and then we can do the lighting calculations.

Our problem is we have no way of reversing that logarithmic depth at this point... any clues on how we could go about doing this? Or maybe there is a better way to handle the scenario all together. Thanks for your help in advance.

Yes that is correct. As far as I understand the sampling helps to get a smoother result but I did not go through the whole C++ code of the DirectXSDK sample so I could be wrong but it gives me a better result. Oh and the "+1" to vSample is a project specific color correction constant so you can ignore it.

Why not sample once, save yourself the loop and x9?

EDIT: Did some work to get this:



Wanted some advice about what you thought the silhouette looked like. Do you think this would be an interesting creature to control? Any suggestions are welcome.