Pro / cons of the various kind of MMOs ?

[tolik]

Screw up other people? Sounds like a plan. Golden rule of any succesfull free to play mmos (not social) is "NO CONFLICT = NO MONEY".

[Game Producer]

Hmm, thats not what I take away from it. What I take away is that you should plan for players play styles changing over time. Accept that you are going to have some people who want to screw up the game for others etc.

Of course, if you have an async game where you never have players interact directly, then its moot. But I think the other stuff is worth considering even if ultimately you reject it.

Possibly there's "outdated" ideas and suggestions that doesn't perhaps make sense... but I found out that there was tons of stuff for beginners. First of all, the book gives a pretty good Big Picture about what goes into developing an mmo - it's not just mmo engine. There's tons of things to consider. The book gives some insight also on economy, mentions persistent vs non-persistent stuff. It also helps with "how to do changes in game" (and how people will react to those).

I think it's somewhat a must read for any MMO developer. Of course it's just one source, but right now I don't know a better book on mmo dev (please feel free to suggest) and was somewhat an eye-opener to me.

(It sort of helped with non-mmo game dev as well).

Of course nowadays people talk about "social mmos/games" (whadda hell those are anyway ) and this book isn't directly about that stuff. When the book was written, FB was not in every mom's computer.

Anyway. Nexic of course has much more experience on MMO dev than me so I'll just leave this out as "my 2 cents".

[wazoo]

I just wanted to add "keep going" on this thread!

Great stuff so far!

I'm finally making some breathing room on my plate to tackle a project like this and am still learning how to structure it.

I bow to your deeper brain pools of knowledge.

[zoombapup]

Screw up other people? Sounds like a plan. Golden rule of any succesfull free to play mmos (not social) is "NO CONFLICT = NO MONEY".

Conflict within the confines of the games design (as in planned-for conflict) is fine by me. But griefing where one group of your players simply makes it impossible for the majority to have fun isnt. Which is what I meant.

But I'm more interested in the social space right now design wise, although it feels like most social games arent really (for very good server design reasons) all that social beyond gifting and using the content of a users FB data to scrape some friends to spam with "social" gifts.

I'd actually be happy to NOT have a "hit" game. Hearing about the scaling out of Zynga makes me realize that a smaller game would do fine by me. They were talking about scaling out over 1 million players in a single week. Or around 30 million over the course of 6 months I think it was.

I'd be happy with 100,000 or so over a few months I guess. Rather a smaller loyal playerbase than a huge one. I view it more like the guy who created garfield (i.e. dont create a hit because hits are based on fashion and fashion changes too quickly, rather build something that has core value that people can live with for a long time).

Anyway, made me feel far better about using Flash+php+mysql to develop with. Need to maybe add in memcache in the loop there and consider not scaling table-wise but row-wise (still not quite figure how that works, striping across mysql servers surely causes data loss if one of them fails).

All fun stuff mind you.

[zoombapup]

Oh and while we're at it and for posterity's sake. In terms of backup solutions, it feels like taking a snapshot of the database and sticking it on an EBS (amazon elastic block store) would be viable.

Rob mentioned three monitoring tools also. One was an in-house written thing, another was called Munin and the third was called Nagios or Nagius. Which is a linux monitoring thingy. He also mentioned using business logic as much as server status to monitor the games health (so you might alert someone if currency suddenly starts being generated over a given threshold etc).

What I found weird in his talk, was that they dont use transactions on the database end. He kind of mentioned that the transactions were basically handled at the app (in this case php code) and using memcache as the mutex for the transaction. I guess thats where we get into a lot of detail he couldnt cover in his talk. Stuff like how to ensure that you have a proper commit for things that REALLY need it, like anything the player buys/sells is pretty important. Apparently doing the locking for transactions is just too heavy on the db servers which are the first servers to die (and man I can speak from experience there).

It really is a distributed systems problem, which luckily is what my degree was about. Just need time to really sit and prototype the gameplay side of it.

[wazoo]

Oh and while we're at it and for posterity's sake. In terms of backup solutions, it feels like taking a snapshot of the database and sticking it on an EBS (amazon elastic block store) would be viable.

Rob mentioned three monitoring tools also. One was an in-house written thing, another was called Munin and the third was called Nagios or Nagius. Which is a linux monitoring thingy. He also mentioned using business logic as much as server status to monitor the games health (so you might alert someone if currency suddenly starts being generated over a given threshold

Nagios. I use it at the current "day job".

It's funny / annoying that the bits of detail you REALLY need out of a presentation always seem to be tackled last...thus almost guaranteeing it to be cut short due to time restrictions.

But interesting idea with respect to memcache handling vs. a db lock!

[trinistry]

What I found weird in his talk, was that they dont use transactions on the database end. He kind of mentioned that the transactions were basically handled at the app (in this case php code) and using memcache as the mutex for the transaction.

A common thing to handle these "transactions" are eventhandler, which is basically a php script running in an endless loop which handles all transaction and serialization things. (So kind of a basic php-made gameserver.)

But you might get away without it - for instance a strategy game where you build things that complete after a certain time which will increase or decrease your production, or your neighbours can rob your resources after the time their troops "travelled" towards you (...) would need an eventhandler while a simple character based game, where everything happens right after your click could only use some kind of locking mechanism.

[zoombapup]

Just wanted to say before I forgot, flash builder 4 (aka flex builder) has a "free standard version for unemployed developers". No idea what qualified someone as an unemployed developers, but thought I'd mention it.

I tried using the new flex4->php stuff today. Interesting but its using some pretty hefty zen stuff to use RPC calls via a faked AMF message. Basically NOT the way to do things I think. Mostly you would want to be using get/put operations. I'll have to explore that later.

[Nexic]

zoombapup:
I think you're worrying about scaling a little too much. Having multiple machines handling the same database can get really ugly so once you hit a size that maxes out a single DB machine it's probably best just to start different instances of the game (ie world 1, world 2, or even split by location like US West, Europe etc). That doesn't mean you need to make each game world small though, with DF's current setup we can handle 4000 concurrent players online per server world. That's using EC2's 8-core instance as a DB machine and then using 2-8 small instance webservers that auto switch on/off depending on users online.

Also, my server costs are about 3% of the game's revenue. Really not worth worrying about too much.

[justkevin]

Really interesting thread. I have some comments and questions.

I'm currently working on my own project which is progressing pretty well. It's a top-down 2D game of space exploration. Client is Flash connecting to a Java server using tcp sockets.

Advantages of sockets to java server vs http to php:
Very low response times relative to http. (The game wouldn't be playable with latencies much over a second)
Much more efficient bandwidth utilization.
Low database usage (the java server maintains most state and only serializes "major" game changes).

Disadvantages:
More difficult to implement
Non-http traffic may be blocked by corporate firewalls
Can't just be put up on a shared web account.

Currently, I estimate that a low-end dedicated server could probably support somewhere between 600-1200 concurrent users before topping out the CPU. (It's a very rough estimate because simulated clients aren't real clients.)

Questions:

What do you think the ratio of active players to max concurrent typically is? In other words, if you had 1000 players who are active (play at least once a week) what is the most you would expect to find online at a given time?

[Jack Norton]

I agree that worrying about resources/bandwidth of server is totally useless. Like the people that worry about the buynow page design when they have yet to start making a downloadable.
Even EQ and the BIG multi-million companies just split the world in server/shards or call whatever you want them, so that won't be a problem.
The real problem will be coding the MMO and making it fun

[zoombapup]

In general I'd agree with you guys. But in this case, youre in a situation where if you have even a moderate hit on facebook terms, youre server will be instantly and irrevocably slashdotted. Unless youre design is built to scale out or up from the get-go.

Nexic: 4000 concurrent is good, but I'm not designing a system that allows that kind of play, so I'm aiming for far far higher numbers than that. I'm just trying to make the right decisions and being informed right now. If there are examples of systems that have scaled out when they got a big hit, then I'll follow them.

Its kind of funny, I was writing some flex stuff to use php yesterday and it really was pretty easy, but the "easy" way is so unbelievably bloaty and slow. So doing the simple get/put method is far and away a better choice as Rob mentioned.

I'm a bit rusty with some of this architecture stuff, so its fun to revisit it.

[tolik]

Web MMO games with realtime PvP interactions = mostly Java/other C daemons and either sockets or polling or some hacky persistent connections. Every year complexity of the code will reduce server performance by 25% - e.g. you start with 4k per server and in 3 years will go down to 1k per server thanks to all the cool features
Sharding is OK

Web MMO games with async world interactions
Any scripting language - asp.net, PHP, perl, rarely C daemons for some bottlenecks. Sharding is OK

Social games.
5k concurrent per server, 15k concurrent per single DB node, PHP+memcached+MySQL.
Sharding heavily depends on core game mechanics, mostly NOT OK and exists when async MMO games open their shards for seamless facebook connect integrations and in few other very rare cases.

I agree with zoombapup - I wouldn't develop a game that doesn't scale to 100k concurrent in few weeks. Boutique MMO is the same excuse as making niche indie games - it's an escape from reality and denial of mainstream.

[zoombapup]

I dont think there's anything wrong with boutique MMO to be honest. Its just a different market than I'm designing this for.

Rob in his talk did mention some sharding stuff for MMO's but inherently if you're players are all doing synchronous actions then you are going to hit a barrier to the scale of interactions pretty quickly.

Async play is far easier to see how to scale out. But it does compromise the design some (have to make sure that players have no direction interactions but more indirect ones). Make it feel like theyre interacting by reading from their facebook data etc.

Theyre essentially singleplayer games, with persistant data plus the ability to gift their mates. The gifting is the only real interaction, but you can ration that out so that it doesnt bind up the whole system.

As a distributed systems problem is actually pretty easy, but the reality of actually developing it and keeping it running has lots of stupid little gotcha's doesnt it. These things always do.

[Jack Norton]

Boutique MMO is the same excuse as making niche indie games - it's an escape from reality and denial of mainstream.

OR not everyone has 50-100k or a full team to invest in a big project BTW some niche games make more than "mainstream" casual ones.

Anyway, thanks for the info but it's true that is really complex to make a MMO...

[tolik]

Once again, there's no such term as "casual" in MMO.

[wazoo]

who knows?

maybe Reflexive's new gameplan is to get out of the download market all together and go exclusively social.

Instead of trying to fight for the same crumbs that Amazon is gobbling up, they're just going to new pie.

[Jack Norton]

I found this today:
http://www.ape-project.org
seems interesting (more interesting to me than flash for sure), going to try it

[Nutter2000]

who knows?

maybe Reflexive's new gameplan is to get out of the download market all together and go exclusively social.

Instead of trying to fight for the same crumbs that Amazon is gobbling up, they're just going to new pie.

There is no Reflexive... only Zuul! (...I mean Amazon )

Wrong thread perchance?

[tolik]

Rule #1 - never use some unknown obscure technology. With the same luck you could use http://www.reddwarfserver.org/ or any other lame things out there.

[Nutter2000]

1st Amendment - unless it's your own unknown obscure technology

[Chris Evans]

How did I miss this topic and more importantly why hasn't my game been mentioned yet?

My game, SocioTown is mostly under the radar by the press and I guess even other devs. I won't go into specifics since my users know how to use Google, but we're doing fairly well for ourselves even though we have a relatively small community. We haven't done any meaningful promotion for the past two years while we steadily improve the game, but we've slowly built up a subscription base and steady flow of players that makes us profitable.

I just want to counter the idea that you need 5,000 - 10,000 co-current users to be successful. If you have a low over-head and high ARPU, then you can still do very well with much less.

Unless you have a few 100k, I definitely recommend going niche. You never know you could tap into a hot niche like Nexic did, but even if you don't, you can still do well by properly serving and satisfying a small loyal audience if you have the right revenue model in place.

If you don't think you can pull in a huge volume of users, go with subscriptions. Generally in business, acquiring the user is the most expensive part. But once you have them, you can generate revenue from them at the fraction of the cost. If you do purely micro-transactions, you either have to constantly keep getting new customers or constantly feeding them new content/items for them to purchase. But with a subscription model, it's much easier to harness your existing customers. For example, you don't always need to generate new content to keep a subscriber happy. You can do special or community events to keep them involved or run random contests/competitions. Give other little incentives to keep the player active so they don't lose their status. Also, some players just won't cancel their subscription unless you give them a negative reason to do so.

You can crunch the numbers yourself, just having subscribers in the low thousands can have you making more money than most of the games on the casual portal top ten lists (at least the developer's cut).

Developing an MMO is tough, but not impossible. It takes time and you probably won't be developing another full game for a long time. But you can control your own destiny. Most of the people on this forum don't even know my game exists, but I'm one of the few indies doing very well despite the whole casual industry imploding and the iPhone/Flash markets getting over-saturated.

So don't easily dismiss boutique, social MMOs or whatever you want to call them.

[electronicStar]

Nowadays, if you use Flash, there is a plethora of APIs that can take care of registrations, badges and microtransactions for you: mochi, heyzap, gamersafe, kongregate, etc...
I suppose it makes it easier to devellop a barebones MMO in these condition (the difficult part being the whole multiplayer crap).
PRO and CON being that players aren't tied to only your game.
Even if you want to do Facebook stuff there are many APIs available for free to tap into facebook.
It can be worth it if you want to start up fast.

[synapse]

Gonna have to jump in with Nexic and tolik on this one.

I made our first FB game, a hardcore PvP game. It took two weeks while learning PHP and MySQL. I did all the code+db stuff. It was terrible, but it worked, and it got the ball rolling.
-> it does NOT take a full team and $100k to make an online game.

It reached only 3k DAU but it gave us a launching point for our next game, which ended up reaching 10k DAU within 2 months of starting to learn web programming. Already at that point, it was a profitable, sustainable business with 2 people and one art contractor. We've since grown a bunch with the following advice:

-Do not go with subscriptions-only. Some people are willing to spend a ton more than you can imagine, so don't limit it from them with a best-guess subscription price. I have seen much, much better results from virtual goods.

-PHP/MySQL to start with. Easy, free, and definitely powerful even without animations. Move to Flash when you have a foundation of users and experience. Don't use any fancy BS that requires downloading plugins, because you'll lose 95+% of your userbase that way.

-This is a bit contrarian - Do not worry about scaling for your first game. There's a ton to think about, and if you get any of the core stuff wrong, you won't ever get enough users to scale.

-Research popular game mechanics and try to incorporate at least one or two of them. Innovation is fine, but users are much more comfortable when it starts off somewhat familiar.

-Fast dev cycles. Don't make the perfect, ambitious game, and then test it to death. Get something out in 2 weeks, and update it with user feedback. User behavior is the best indicator of how fun and addicting your game is. Online games are a service, not a finished product.

-Analytics. You have omniscience of your users actions. Use it to figure out what parts of your game suck, and make it better.

-Mainstream is great, but niche can be very profitable too. If you want $10-50 million, make a cutesy, accessible game. If you want $1-5million, make a niche game.

[tolik]

Can't agree more with synapse. You must focus on basic metrics to understand what is actually happening - measure your retention, user experience funnel (where do they leave?), your virality (use kontagent), etc.

[Jack Norton]

Thanks for every contribution. Lol this might even become a stick post, considering how many casual devs are shifting towards MMO/social games recently!
I think is definitely possible to make an online game alone (using contractor for art). synapse suggestions are really good IMHO, many people start building up a team and investing lot of money thinking to make the next yoville/farmville and end up with having wasted 2 years with much less income than a superniche zombie MMO done alone

I want to warn other "normal offline devs" like me, doing online coding is TOTALLY different, not just harder but a different thing and you really must love it. Indeed I've decided that while I could probably code a online game I prefer to spend time doing the game design and less boring tasks, so I'll just hire someone to code instead

[Spiegel]

First of all, great thread, lots of great information even for people (like me) that are just curious about this sort of business models.

-PHP/MySQL to start with. Easy, free, and definitely powerful even without animations. Move to Flash when you have a foundation of users and experience. Don't use any fancy BS that requires downloading plugins, because you'll lose 95+% of your userbase that way.

Quick question about the client (hope not too offtopic), downloads are a negative thing but...

What about java? What is your opinion (or the anyone else's opinion) on using Java for an applet or JNLP download ?
ThreeRings uses this as their clients, is it worse than flash for avoiding the 95+% userbase loss?

[Nutter2000]

In my opinion, it's going to depend on the client base you're targeting.

If your players are more used to downloading and configuring their computers to play games, then I don't believe you would necessarily see a 95%+ user loss.
In fact, what I suspect is that you would initially see less "tire kickers" (that is people who will play for free but wouldn't ever pay), and more actual paying customers.

On the other hand, for a very casual game (e.g. *Ville) you would expect to see people wanting a very accessible game therefore something that will just work in their browser, i.e. flash.

You should also remember that PuzzlePirates (ThreeRings) predates Facebook by 5 years (PP was released 2003, FB: 2008).
At the time, most mmo's were downloadable, and so people were more used to that.
I'm not saying you couldn't do it these days, but ThreeRings have kept a lot of momentum going since then so they can afford to keep with Java

[synapse]

First of all, great thread, lots of great information even for people (like me) that are just curious about this sort of business models.


Quick question about the client (hope not too offtopic), downloads are a negative thing but...

What about java? What is your opinion (or the anyone else's opinion) on using Java for an applet or JNLP download ?
ThreeRings uses this as their clients, is it worse than flash for avoiding the 95+% userbase loss?

It's definitely takes more steps to start a Java game than to play a flash game. It's a dealbreaker for a lot of people, especially people who just want a 5-10 minute experience. There's nothing wrong with 'tire kickers', because even people who play your game for free can become addicted. Addicts become evangelists, and evangelists bring more users.

Just as an example of how fickle a lot of users are, our browser game initially had 4 pages before you actually started the game, involving a combination of story and character customization. Each page saw about a 30-50% drop off, meaning we ended up losing about 80-85% of the users that started to play the game, just because they weren't hooked enough to click a button on a webpage! Imagine if they had to download a JNLP app, possibly wrestle with having to configure and update Java. Flash, on the other hand, has a huge reach and games only take ~5 seconds to load (with no user interaction).

The real question is - what are the benefits to using Java? If the only answers you have are things like 'faster execution', 'easier code' or 'better libraries' - you're not thinking about the user first.

[puggy]

I want to warn other "normal offline devs" like me, doing online coding is TOTALLY different, not just harder but a different thing and you really must love it. Indeed I've decided that while I could probably code a online game I prefer to spend time doing the game design and less boring tasks, so I'll just hire someone to code instead

The real trick with network code is to make one that you can basically forget about. Starpeace has RDO (remote delphi objects), no point googling it, it was made for starpeace. What makes this effective is that it allows the use of functions from client to server seemlessly to the coder. This way you don't have to work on network code each time you want to send or retrieve data, just 2 functions, one on the client, one on the server.

Ok at first it might be slightly harder and longer to actually code this, but in the long run you'll save a lot of time and effort and as it's not specfic functions can be reused in other projects. The downside is that your going to have some extra data to send but it's not a huge amount.

Of course the most infuriating thing about network coding is you need to be coding the server and client at the same time and testing that new code at the same time. If you have 2 computers to spare it's probably best to use them at the same time, side by side or else you'll go nut's trying to keep things in check.