Every decision you make can affect networking. ...

Shit! networking is the end of the world! Run for your lives!!!
Sorry... I couldn't hold myself. Anyway, that's sad, bud good to know, thanks.

Retrofitting network play into an existing game can range from "very easy" to "requires a full rewrite". Don't take it too lightly.

WebGL availability is hit-and-miss on mobile devices. HTML5 is also hit and miss, some devices perform reasonably well (getting 10+ frames per second) and others perform at the seconds-per-frame rate, or they just crash. Mobile devices are different from desktop computers, most notably JavaScript performance is typically 20 to 30 times worse than the desktop environment, and memory is tight; once you get into 20 MB or 30 MB of data (such as many graphics) the web page is likely to die.[/font][/background]

Wow, that's really bad about the fps. If this is true there is no way making and HTML5 game at all...You mean the realy old mobile devices? Or that includes the medium value ones released in the past 3 years? I need to search for more info about that...

Check out WebGLStats for some numbers. They say for devices they track that 7% of Android smart phones support WebGL, 5% of tablets. Other stats trackers have different but similar numbers.

HTML is designed for documents, not for apps.

Depending on what you are doing, what device you are on, and how your app is coded you might get pretty good numbers. I've seen a Nexus 7 from last summer get into the 30 FPS range for a WebGL game, but a 1.5 GHz quad-core is far above the average device in the wild.

We kept a bunch of "typical" phones around the office for several games, and using the default browser almost all of them immediately crashed when we were doing our first round of simple HTML5 games, which is why we are still sticking to apps. We discovered (somewhat surprisingly) most in our demographic were just using the stock browsers.

Now it is certainly possible that your demographic is different.

It is possible that everyone who browses to your site on mobile might be on Android devices. And that they all have Opera Mobile installed, or you might limit yourself to a portion of WebGL that is implemented on Chrome Mobile or Firefox Mobile. And all of those people might be running on new, high-end devices, all purchased within the last year.

As for Apple, iOS7 doesn't support WebGL yet, and considering Apple's stance on running iApps that didn't pay the app store tax, well, don't count on it any time soon. It took four years of their customers screaming at them before Apple permitted Flash-anything, and even then, well, if you have an iPhone you know it's current state. Don't expect to build your game in full-featured Flash and have Apple mobile customers enjoy it.

Maybe I misunderstand the concept of an MMO. For me It was an online game that support players playing in the same ambient simultaneously. Didn't know it had so much to do with the "massive" part. (but makes sense to have something to do... right? ._.) How many players playing at the same time there has to be to be considered an MMO?

There have been online games for ages. Text-based multiplayer online games date back to the early 1970s.

The term "MMO" came about when people needed to differentiate smaller-scale online games with large scale undertakings. It depends on who you ask, but the cutoff line tends to be around 100,000 active users at the minimum. Below that you can usually use fairly small-scale infrastructure. Simultaneous online users is different than MAU or DAU, and games that require only matchmaking and partial mesh P2P node helpers need far less infrastructure than fully-hosted worlds. A simple world needs less infrastructure than a complex world. One well-written server can easily handle 5,000 simultaneous users for a simple game, which might equate to 30,000 'active' users. You might need two or three dedicated machines for a larger user base. One very popular title I worked on (not an MMO) had weekend peaks around 150K simultaneous players and only needed two racks of (heavy duty and seriously taxed) server machines, one in the US and a second in Europe.

The transition from "large online game" to "MMO" is usually not about the exact number of players. The process means branching out from a few boxes at a single site or at a colo site, transitioning to a system of hundreds or thousands of machines at multiple sites around the globe. If a handful of people on 24/7 on call support are maintaining your servers, that is not an MMO.

GameMaker could be a viable option, yes. LibGDX is another good cross-platform system that plays well on iOS, Android, Web, and PC.

As for the online servers, the confusion between "persistent worlds" and "MMO" is something new to the last few years of game players. There are three basic tiers:
* A few players connect for a session, play a game, and are done. Worlds can persist or not, matches can be random or not. "Online game."

* Hundreds of people playing together at once, infrastructure is a very small number of servers. Various names: graphical MUD, web games, occasionally "massive online", online games, etc.

* Typically millions of players (although many hundred thousand players can also fit). Infrastructure is generally multiple data centers around the globe. "MMO".

The small online games are relatively easy to build and nearly free to maintain. Players can often host a server directly on the same machine they play the game. This style often includes the 10-minute game sessions of FPS and some simpler RTS games. They can be persistent worlds; MUDs were the first example of online games in the 1970s and they were persistent. Minecraft servers fit comfortably fit in the first category. You can get away with minimal network planning on some designs, others require significant effort. This is the type that the network forum has examples of a fully-functional online game server in a few hours.

The medium and large scale online games are harder to build and usually have a larger team set up for server development. Servers usually require multiple programming disciplines to create, and usually the game clients have multiple network-centric developers. Servers are generally plural and are designed to be dedicated machines. Expect to pay tens of thousands per month for servers, staff, and bandwidth. These can include all types of games, from the 10-minute sessions to global lobbies and matchmaking to very large dedicated worlds with small numbers of players. These require significant effort and planning for network infrastructure.

Then MMO. MMOs are huge. EVERYTHING is designed around networking. Gameplay is designed completely around networking. Animations are designed around keeping things mostly in sync on networks. Data management is designed around getting necessary information across the network while limiting information to prevent cheating over the network. Expect to pay several hundred thousand or into the millions for monthly server maintenance and bandwidth. If one day of development goes by and somebody didn't think about networking at all, that person probably should be kicked off the team. Questions about latency and bandwidth should be part of nearly every meeting.

Within the small class you can turn a small chat system into a simple space shooter or a simple persistent world or a simple social game fairly easily. I've built and shipped games on devices from the DS to the X360 and PS3 that relied on this kind of very simple message passing. If your engine provides central hubs where all events and data are processed it might only take a few weeks for an experienced network programmer to add a networking component. If your engine has scattered processing where everything updates itself, adding networking can mean major changes to everything.

If you have a system designed to support several thousand concurrent users you can morph it into a different but similar-scale system with a bit of work. Transitioning from a moderate sized RPG to a different RPG is much easier than transitioning from RPG to RTS.

If you have a MMO and want to make a similar MMO, the client and server rework can be extensive. If you are moving from an RPG to a similar RPG you might end up with anything from a small number of scripting differences to a huge number of component differences, in the ten to fifty work-year range. If you are switching between styles, say from an MMORPG to an MMOFPS, be prepared to spend several hundred work-years in the transition. It may sound like a lot, but considering the game probably would require thousands of work-years to complete the cost is relatively cheap.

From what you described, you probably fit in the first category. Again, make a few single-machine games first, but when you have done that it is pretty natural to experiment with the first category of online games. I would start by adding a simple and reliable chat to your single-player game, then add components one feature at a time. It is as simple as adding a side-channel to the chat system where the relevant details are shared.

Does libGDX run on browsers without plugins?

I saw on their "features" page that it runs on browsers via Google Chrome Frame. Then I went to know what is this Google Chrome Frame and I found out that it has been discontinued. So it won't run anymore on browsers?

Other than that looks very interesting.

There is also the option of making java Applets. But then the user will need JVM. This plugin does not come along with most browsers right?