I'm writing a multiplayer 2D online game, where game servers are hosted by the players. I want to show players a list of the currently hosted game servers.
How would I do that? I know how to let players host servers. But how would I then get a server list? Should I use a database? Is there an easier way?
In order to get a server list, you will need a central matchmaking server to which all game-servers connect and announce that they are online and to which all game-clients connect to obtain the list of currently online servers.
How many servers are you going to have? For comparison, I remember that during the high-times of the original Counter Strike, the WON matchmaking servers listed tens of thousands of gameservers. And that was Counter Strike, the most played multiplayer-FPS of all times. So how many people will you convince to host servers for your game?
When you only want to list the servers which are online right now, a database would be unnecessary. When you have a thousand gameservers and each one with just a few kByte of information, that's still just a few MByte of RAM. That's not nearly enough data to justify a database and enough to be handled by the cheapest VM instances you can rent.
Losing the data in case of a server reboot isn't a problem either, because you will want your game-servers to reannounce themselves to the matchmaking server every few minutes anyway to make sure that they are still online. So it won't take long after a reboot until your server list is complete again.
A database might be interesting when you would like to collect some usage statistics about your servers and clients and later want to data-mine this information. But that's a different topic.
But while storage space likely won't be an issue, there is another aspect which might get a bit more of a concern and that's bandwidth. I don't know how many clients and servers you expect, how often your clients will request the server list and how much data they receive each time. But you should know and be able to make a rough estimation how much traffic this will consume daily and check what server-hosing which allows that kind of volume will cost you.
When your budget is low and you want your technology to be scalable, you could save a lot of resources by using the Distributed Hash Table algorithm. This technology is used by peer-to-peer filesharing networks like BitTorrent or tools like TOR to reduce the dependence on a central server. In this system, the global server list isn't hosted on one server, it is distributed over many servers. You can use your game-servers or even your game-clients for this purpose. However, you will still need to host at least one server with a known IP as an entry-point into the network. But the load on this server will be a lot lower than on a central matchmaking server.
For simple matchmaking only, you can create an ASP.Net or PHP website that the players login to (via your game app) and push a notification when they create a server. The problem is securing the server to make sure only your players are accessing critical services like advertising a host or requesting the available host list.
There are also services like Kongregate that have an API you can integrate with your app to get matchmaking services, in addition to achievements, leader boards, and other features.
If you run your own matchmaking service, you would probably want some sort of shared data storage that all the user sessions can access in memory... databases tend to be too slow for the quickly changing list of available servers if your game gets any sort of popularity... how you do this shared cache depends heavily on the web server technology you decide to use. Both PHP and ASP.Net have ways to deal with this so long as you only have a single server handling the matchmaking. If you get to the point where you need a web farm to handle your player load, you are pretty much stuck with a database.
