I apologize if this has been answered in bits and pieces in different threads, but a brief look in this forum hasn't answered my question. I would like to write a game similar to Magic Online. In the game, players should be able to chat in rooms, chat with each other, join clans/leagues, enter rooms where they can challenge other players to a match, and enter rooms where they can sign up for tournaments. I would also like to eventually have auction capability for in-game items, similar to World of Warcraft. Game play itself will be very similar to Magic (turn based). My first question is the following: what technology should I use? Ideally I would like to get the networking part up and running as fast as possible. Initially, I think allowing up to a couple of hundred players should be sufficient for beta testing. Would using Python/Twisted be a good starting point? Should I write a server in C#? In the unlikely that the game turns out to be commercially viable, I think writing a full-blown C/C++ IO completion port server will be necessary and that can be done at that point. Also, is there a better choice between TCP and UDP? The messages between server and client will never be very large. I was also thinking of sending the messages in XML format in order to increase ease of use and facilitate later porting to other platforms - would that be a huge waste of bandwith? For the client, I was thinking of writing it in C#. Is there a better choice for rapid development? For the database I was going to use PostgreSQL. I would love to use SQLite, but that's probably not realistic for a decent sized project. I'd rather not use MySQL as I don't want to deal with license issues. I was told BerkeleyDB is very fast, but isn't a traditional SQL database and I have other things to learn for this project. Last question: what order should I implement everything in? My thinking was to start with chat, then inventory management/trading/auctioning (could do this last instead), then game play, then tournaments for last. About myself: my formal education was in applied math, and am self-taught in programming. I know C++ fairly well, and have picked up many languages/technologies over the years professionally and when working on personal projects (VBA - I know, not a real language :-) - C#, perl, Python, SQL, HTML/CSS/&#106avascript, Flash/Flex). I plan on hosting the server at home. I appreciate your taking the time to read this. Thanks, Marc.

First off, I think you're a bit over-concerned about per-server performance. Fundamentally, an online trading card game doesn't have a lot of shared state. You should be able to scale out very well by adding servers and load-balancing. I don't think you'll need to worry about a full-blown C++ IO completion ports solution. Use whatever technology you are most productive in. I know of at least one web-based trading card game (using Java applets).

I would say that using XML as a message-passing format is a waste unless you do not control both the client and the service. Even if that is the case, JSON is probably a better choice. If you do control both, then binary serialization is probably better, although the best choice is to use built-in serializers, unless you're finding you need to optimize for size. Frankly, a trading card game isn't likely to be very bandwidth heavy, so you should probably lean more towards reliability and ease of development in your message format.

As far as the database goes, I'd stay away from Berkeley DB. Its good at what it does: extremely fast, simple, local storage. However, you're probably going to want an actual relational database, and trying to turn Berkeley DB into one of those is going to be a lot of work and negate any gains you'd get from that technology. I don't have a lot of input into which RDMS you use, but I'd recommend that you write a data abstraction layer to accommodate schema/database changes.

Thanks for your reply.

Quote: Original post by Rycross
First off, I think you're a bit over-concerned about per-server performance. Fundamentally, an online trading card game doesn't have a lot of shared state. You should be able to scale out very well by adding servers and load-balancing. I don't think you'll need to worry about a full-blown C++ IO completion ports solution. Use whatever technology you are most productive in. I know of at least one web-based trading card game (using Java applets).

I would say that using XML as a message-passing format is a waste unless you do not control both the client and the service. Even if that is the case, JSON is probably a better choice. If you do control both, then binary serialization is probably better, although the best choice is to use built-in serializers, unless you're finding you need to optimize for size. Frankly, a trading card game isn't likely to be very bandwidth heavy, so you should probably lean more towards reliability and ease of development in your message format.

As far as the database goes, I'd stay away from Berkeley DB. Its good at what it does: extremely fast, simple, local storage. However, you're probably going to want an actual relational database, and trying to turn Berkeley DB into one of those is going to be a lot of work and negate any gains you'd get from that technology. I don't have a lot of input into which RDMS you use, but I'd recommend that you write a data abstraction layer to accommodate schema/database changes.

I haven't really had much experience with networking. How does load balancing work? When a player wants to log in, they contacts a "gate" server, and that server then assigns the player to a server that actually handles the connection for that player? Do you have any idea how many players a server with a quad core CPU could handle? I just want to find out so I don't go off on the wrong path from the get-go.

Since, as you said, TCG's don't use much bandwith, I was thinking using XML would be OK. The main reason that I wanted to use XML is to make it easier to develop clients cross-platform. I would love to create a framework that allows players who use a PC, Xbox, PS3 or iPhone to play against each other. However, realistically, the protocol shouldn't really matter I guess - smaller is better.

Quote: Original post by hplus0603
Start out with a web development framework, like ASP.NET or PHP, and build the app inside a web browser using &#106avascript and AJAX/AJAJ (I prefer JSON to XML).

My initial inclination was to write a perl CGI script, hosted on an Apache server. I just thought that such a server would slow down very quickly with any reasonable number of players online at the same time.

What about writing a Flash application for the client? It would have the benefit of easily accommodating visual effects down the line.

Thanks,
Marc.

Write server in Python, host it on AppEngine. BigTable is an oddity, but nothing drastic.

Write client in JQuery, using Ajax to talk to server.

It's about as easy as it gets, and without much of deployment hassle.

Quote: I would love to create a framework that allows players who use a PC, Xbox, PS3 or iPhone to play against each other

The above covers anything with non-archaic web browser and internet access.

Quote: Original post by hplus0603
On any modern machine, I'm pretty sure you can do at least 2,000 simultaneous online users with a perl CGI module. I'm basing this on utilization of the perl-based "perlbal" soft reverse proxy. Exactly where the limit goes is of course dependent on how expensive you make your application.

"load balancing" for bigger sites is generally done with hardware load balancer boxes, like your Nokia, Cisco or Foundry hardware. These will detect incoming connections, and pick the "least loaded" of your web servers, and do reverse NAT from the source IP to the target server. That mapping will generally persist for a while, to keep sessions in cache and whatnot.

2K simultaneous users with a perl CGI module seems like a lot more than I would have guessed. I am assuming that some portion of users will be chatting, while the actual game messages will be small, something like a series of IDs (for the player, the action, the source, the target), the server will determine the state of the game based on the actions that the players take (managing player resources and checking win conditions etc.).

It seems like load balancing is something I will have to worry about only once there will be a very strong possibility of commercial viability.