I want to make a similar browser online multiplayer game like "Dueling Network" (link below) but for a different TCG.

What technologies you believe they used to create it?

Could anyone kindly refer to any good resources/books to start from, so that eventally (not soon) I myself can create something very similar to the game mentioned above, perhaps a little more simpler.

Assuming Flash and AS3 are involved, and I have 0 knowledge of them. Only have been exposed to VB, C#, and most web programming languages.

Dueling Network NSFW: loud music


closed as off-topic by MichaelHouse Jan 22 '14 at 17:20

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions that are about "which tech to use" are outside the scope of the site. For more information, see this meta post" – MichaelHouse
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    \$\begingroup\$ You could always use C# with Silverlight \$\endgroup\$ – Ray Dey Aug 14 '11 at 0:57

Apache Server, Flash, PHP, Javascript, and a few other things.

Source: http://builtwith.com/duelingnetwork.com

This may not be 100% accurate, but it at least lets you tell what technology that front page is reporting.


I may not be able to answer the direct question of what technologies this specific game uses, but the more general question of what technologies are ideal.

For an MMO-WEB style game Flash (AS3) is an extremely useful client interface for the game. Flash is cross browser and cross platform compatible, and has access to a high level socket layer (used for network communications).

AS3 has two kinds of sockets: The Socket and the XMLSocket. Now most people make the very faulty assumption that XMLSockets are easier to use, when in reality they are identical except one is meant to parse only XML data (from things like feeds, or web page data), which isn't very useful for games. The regular plain Socket is what you should spend time learning. Unfortunately there are very few tutorials around the web, as Socket programming is still quite young in Flash, but still very useful.

The basic idea from the Flash (Client) side of things is:

Create Socket Object -> Give It Server IP/Port To Connect To -> Attempt Connection -> Create Listener For Incoming Data -> Wait For All Data On Line -> Use Data -> Send Data -> Listen For Incoming...

Now as for the Server side, DO NOT USE FLASH. Flash may be very useful as a Client, but as a Server it's pretty much useless. You need a language that supports threading, I'm currently using C# as my Server backend so that's the only I can recommend (but it is by no means the only or best option). C# provides easy use of threads and has a similar Socket system.

The Server is FAR more complicated than the Client, as you must manage every connection asynchronously (at the same time), and worry about things like bad data, attacks, disconnects, flooding, overloading, timeouts, lost packets, and a seemingly endless list of trivialities.

You also have to manage all user data, lobby handling, game handling for which I personally use mySQL. It looks super complicated on the surface, but it's pretty much a beefy excel (please no flames for the slack comparison). It's quite easy to make a simple database to store usernames/passwords, or game information, and if you use raw access from C# it's also quite zippy.

So in a nutshell, you don't need a book. Go look for information on simple socket interfaces in AS3 and C# (or a language of your choice, but I recommend C#). Learn about threading and why it's used, there are plenty of great tutorials. Then learn about how games transfer data to and from the server, and why they do the things they do. But before you do all of this make sure you have a STRONG working knowledge of both Flash, AS3 and C#. You should be able to create the game to be made networked in full, start to finish - then only after it is complete add networking last.


Not the answer you're looking for? Browse other questions tagged or ask your own question.