By that I mean, can you work in out with trial and error as you go along or are there tried and tested methods for doing this.

I mean you have a central server that deals with all requests and passes them on accordingly. Is this going to be a lot more difficult than I think it is.

Can you give me an idea/links or what kind of problems you are going to run into.

In other words how much different will this be than say a standard multiplayer game.

It depends on how seriously you take the "Massive" part of MMO. Typically, it means that there can be lots of concurrent players. I don't think you'll arrive at an implementation that can really handle the kind of numbers that MMOs aspire to by "hacking", you have to have a design.

However, if by "MMO" you mean a large open world RPG game, without necessarily needing tens of thousands of concurrent players, then yes you can probably hack something together that could support on the order of hundreds of players, depending on how complex the rest of the game is, etc.

Most of the challenges come from when you intend to exceed the capabilities of a single server to run the entire game, it gets a lot more complex at that point.

This depends completely on skill, scope, and time.

The best way to develop an MMO in today's market (as an indie) would be target 100~ or so concurrent users, and scale up if your needs actually reuire more than that (Which they won't, honestly).

The best way to develop an MMO in today's market (as an indie) would be target 100~ or so concurrent users, and scale up if your needs actually reuire more than that (Which they won't, honestly).

This is rather non-advice.

"Scale up" is a nice term but you display an alarming lack of appreciation for what it actually means. There isn't some knob or switch you twiddle to "scale up" a network architecture. It isn't as if there's a constant NUM_MAX_CONNECTIONS in the code that you just crank up to 1 million.

An architecture that can scale to 100 players is going to look radically different from an architecture that can reach 1000, or 10000, or 100000. There's even a name for this phenomenon: a popular threshold is "C10K" (referring to 10,000 concurrent users).

My point is that if you build a game to handle 100 players and then suddenly become wildly successful and need to handle 1000, you're probably rewriting most of the game at that point. Literally.

The best way to develop an MMO in today's market (as an indie) would be target 100~ or so concurrent users, and scale up if your needs actually reuire more than that (Which they won't, honestly).

This is rather non-advice.

"Scale up" is a nice term but you display an alarming lack of appreciation for what it actually means. There isn't some knob or switch you twiddle to "scale up" a network architecture. It isn't as if there's a constant NUM_MAX_CONNECTIONS in the code that you just crank up to 1 million.

An architecture that can scale to 100 players is going to look radically different from an architecture that can reach 1000, or 10000, or 100000. There's even a name for this phenomenon: a popular threshold is "C10K" (referring to 10,000 concurrent users).

My point is that if you build a game to handle 100 players and then suddenly become wildly successful and need to handle 1000, you're probably rewriting most of the game at that point. Literally.

This I know is a good reply, I questioned the 'scale up' myself in the same way as you did. No offense meant to conq however. I am still in early stages of learning about this.

The best way to develop an MMO in today's market (as an indie) would be target 100~ or so concurrent users, and scale up if your needs actually reuire more than that (Which they won't, honestly).

This is rather non-advice.

"Scale up" is a nice term but you display an alarming lack of appreciation for what it actually means. There isn't some knob or switch you twiddle to "scale up" a network architecture. It isn't as if there's a constant NUM_MAX_CONNECTIONS in the code that you just crank up to 1 million.

An architecture that can scale to 100 players is going to look radically different from an architecture that can reach 1000, or 10000, or 100000. There's even a name for this phenomenon: a popular threshold is "C10K" (referring to 10,000 concurrent users).

My point is that if you build a game to handle 100 players and then suddenly become wildly successful and need to handle 1000, you're probably rewriting most of the game at that point. Literally.

The proper wording should have been "re-write for" in my post.

My point was that trying to hack together an MMO wouldn't be worth the time, as "MMO's" which have more than 100~ concurrent users are pretty rare in the indie scene.

I'd still contend it's a much better choice to simply not expect/worry about dealing with massive numbers of players until it seems like you might actually reach that point.

Yes, you can: http://www.enchantedage.com/pymmo
Is it a good idea? Depends on your actual needs and the amount of money at stake.

You can hack together the networking code of an mmo by trial and error, by the "infinite monkeys with typewriters producing Shakespeare" theory. However, while you make mistakes these will cost you users and by the time you are perfect with your approach there may be no users left and a badly burned reputation. For a free or open source project this might be acceptable and you will have near infinite "monkeys" (developers - no offence intended!) but in a commercial environment you must be pretty close to correct and perfect first time... Or risk bankruptcy and failure of your business.

these will cost you users

If you have a slow influx of users that you can test with (say, by paying $50/month for Google ads or whatever,) then that may be acceptable.
Once you find that some users actually like the game, you figure out how to reach more of those kinds of users, and turn up the efforts.
It's very hard to predict what will be important, and how close you are to "good enough," without actually measuring on real users.