Building/hosting a web-based MMO

[Samwise]

I'm probably going to regret asking this here, but what the fuck.

So I'm looking at making a web-based MMO as a sort of hobby project.  Not planning to make money with it, so I'm not interested in spending lots of money on it.  I have a bit of web dev experience and am not scared of new technologies, but given the choice of wasting lots of time fucking around with someone else's broken shit and wasting lots of time reinventing wheels, I'll take the wheels.

My current leaning is to write the whole thing in Java with GWT, and host it on AWS with SimpleDB as the database.  If all that stuff works (and works well together), I think it'd meet my needs very nicely; AWS seems to have really nice pricing, and it seems like GWT would let me do lots of fun stuff with the interface without having to become a Javascript whiz.  On the other hand, I have no experience actually coding with GWT, and I'm a little worried that if I code my app around the AWS stuff then I'd have a hard time moving it to another environment (which may or may not ever be an issue).  Does anyone have any horror stories they'd like to share?

My second option would be writing something from the ground up that doesn't depend on anything more than LAMP, which has the benefit of being solidly in my comfort zone and being so generic that I'd have a lot of hosting options.  On the other hand, I might be making things more difficult on myself than I have to, and I'd probably end up with a relatively ugly Urban Dead-esque interface.

Okay, commence shilling for your favorite web technologies. 

[Trippy]

Oh god not GWT. Debugging that crap is truly a nightmare -- the JavaScript it outputs is in effect obfuscated.

SimpleDB isn't such a good idea either since that ties you to Amazon AWS. Plus you may need to do queries more complicated than that key/value store can easily handle. Why not just use MySQL?

[Samwise]

The main attraction of SimpleDB would be not having to worry about setting up a MySQL server in my EC2 environment or whatever and then having one more thing that I'm on the hook for figuring out and maintaining.  I think the other issues are pretty easy to mitigate -- my app's not likely to be using the db for anything other than a simple data store anyway, and it'd be easy to take abstraction precautions to make porting after the fact easy if that were a big concern.  I think.

What sorts of issues have you had with GWT?  From my limited understanding of it, the JS is essentially compiled code (hence obfuscated), but if it works right you never have to look at it.  Does it often not work right?

[Trippy]

The main attraction of SimpleDB would be not having to worry about setting up a MySQL server in my EC2 environment or whatever and then having one more thing that I'm on the hook for figuring out and maintaining.

MySQL is trivial to setup on a Linux system with a decent package manager, e.g. on Debian/Ubuntu:

sudo apt-get install mysql-server mysql-client

What sorts of issues have you had with GWT?  From my limited understanding of it, the JS is essentially compiled code (hence obfuscated), but if it works right you never have to look at it.  Does it often not work right?

I've only worked with GWT in the context of adding functionality and fixing problems (or trying to) with somebody else's code. I already knew/know JavaScript so working through GWT was a pain in the ass. E.g. we ran into an issue with something not working right on Safari/Webkit that we could never figure out because the output JS code is virtually mpossible to work with.

[Typhon]

I fucking hate GWT for developing a straight-up web app.  JSF 2 is much more straight-forward for creating a basic web app.

That said, GWT's event driven model will probably be more suitable for what you are trying to do, where everything is events (and listeners to events) anyway.

You can turn on pretty javascript which makes it somewhat easier to debug.

[Samwise]

E.g. we ran into an issue with something not working right on Safari/Webkit that we could never figure out because the output JS code is virtually mpossible to work with.

See, that's precisely what GWT is supposed to prevent you from having to do.  I.e. fiddle with Javascript to fix stupid browser compatibility bugs.  The sense that I'm getting is that it's all lies.

So given that I don't have much interest in messing with any of that shit at all, the best option for me might be to just use straight up HTML forms, which have the benefit of working everywhere.  Correct?

[Trippy]

Depends on how you want your UI to work.

[naum]

I would dump the Java/GWT scheme , or even traditional Apache LAMP stack and go with Node.js -- Javascript server along with socket.io.

Real-time data chunks in/out instead of the page/response paradigm.

[Samwise]

Depends on how you want your UI to work.

If I were using GWT I'd probably be aiming at something vaguely similar to The West, with different floating windows to manage different gameplay tasks and live updates in response to server events.  But I'm pretty sure I could also make something functional with plain old HTML and reloading the entire page to reflect changes in game state.  (See Urban Dead.)  As long as the core game works and the interface isn't a giant pain in the ass I don't care that much how shiny it is.

I would dump the Java/GWT scheme , or even traditional Apache LAMP stack and go with Node.js -- Javascript server along with socket.io.

Real-time data chunks in/out instead of the page/response paradigm.

Um, what does that get me?

[naum]

Depends on how you want your UI to work.

If I were using GWT I'd probably be aiming at something vaguely similar to The West, with different floating windows to manage different gameplay tasks and live updates in response to server events.  But I'm pretty sure I could also make something functional with plain old HTML and reloading the entire page to reflect changes in game state.  (See Urban Dead.)  As long as the core game works and the interface isn't a giant pain in the ass I don't care that much how shiny it is.

I would dump the Java/GWT scheme , or even traditional Apache LAMP stack and go with Node.js -- Javascript server along with socket.io.

Real-time data chunks in/out instead of the page/response paradigm.

Um, what does that get me?

Eliminates the suckiness of Java, replaces it with the power of a functional, higher order language, commonizes client/server libraries…

Better performance without non-essential pieces of the server stack, a framework more suited to socket level IO between client and server, written in a higher level language, using pre-built libraries or simply adding your own…

[Samwise]

Eliminates the suckiness of Java, replaces it with the power of a functional, higher order language, commonizes client/server libraries…

Better performance without non-essential pieces of the server stack, a framework more suited to socket level IO between client and server, written in a higher level language, using pre-built libraries or simply adding your own…

Is it going to make it easier to create a shiny UI?  If not, it really has nothing to do with replacing GWT, at least for my purposes.

Given that this is a small hobby project I don't think performance is going to be a huge concern.  If it ever got successful enough to be an issue I'd probably want to do a rewrite anyway.

[Trippy]

I would dump the Java/GWT scheme , or even traditional Apache LAMP stack and go with Node.js -- Javascript server along with socket.io.

Real-time data chunks in/out instead of the page/response paradigm.

Um, what does that get me?

Nothing. But you would be working with the latest server-side fad

[Tarami]

No, node.js is not what you're looking for. It has nothing to do with UI... it doesn't really have anything to do with anything you asked, but it's the "hotness" this week and will solve all your problems. Even the bad reception on your TV.

/snark

I would recommend using old-fashioned HTML and sprucing it up with jQuery and jQuery UI. It gets you 90% of the way (convenient floaty dialogs, ajax and so on,) removes virtually every cross-browser pain that comes from Javascript and is intuitive to learn and use. If you already know a bit of JS, you can improve your code and UI without having to learn an entire framework. You can just pick up bits here and there as you go.

For backend, use whatever you're comfortable with. I don't think any specific platform is going to make specifically game creation that much easier.

I guess my point is this: if your goal is to make a game and not just wank around with technology, use things you already know or aren't too much out of your way. It's kind of redundant to say, but there's time for productivity and there's time for experimentation and in my experience they rarely mix great (especially in a self-motivated project.)

Yes, I'm a such a bore.

[Samwise]

I guess my point is this: if your goal is to make a game and not just wank around with technology, use things you already know or aren't too much out of your way. It's kind of redundant to say, but there's time for productivity and there's time for experimentation and in my experience they rarely mix great (especially in a self-motivated project.)

No, I'm right there with you.  Hence wanting to ascertain whether any new bit of tech I pick up is actually going to save me time on making something.

I have very minimal JS experience and what I've done with it I've found painful (mostly just ugly little bits of AJAX copied and pasted from tutorials to implement "click here to expand" stuff on wiki pages).  How much am I going to like/hate jQuery?

[Trippy]

jQuery is nice and it will make a lot of UI stuff a lot easier (with jQuery UI mentioned above) but it is still JavaScript. If you don't like working with it that's still going to be a pain point.

[Tarami]

Well, as an example, this is jQuery asyncronously loading the response from a page with some querystring parameters into a DIV id'ed "myDiv" every 5 secs (like an updating status window:)

Code:

var myTimer = setInterval(function() { 
    $('#myDiv').load('/mypage.php', { id: 15, junk: 'abc' }); 
}, 5000);

Trippy is right, though - JS is JS. My experience is however that it's better to be relatively close to barebone JS because the frameworks are really, really leaky and not at all existing in harmony with the DOM. GWT, ZK and their ilk treat JS/HTML as problems and try to solve them using more HTML and more JS. It's, quite frankly, going so-so.

Edit:
Syntax error...

[Samwise]

Hm.  Seems like it might be worth playing around with.

[Lantyssa]

I use mostly php/html with javascript to handle events.  Really depends what kind of responses from the server you need though.

[Margalis]

Just learn Javascript. It isn't hard, and you're going to have to know it to really make anything anyway.

[Viin]

How about Flash/Flex? They are pretty friendly and powerful, but won't work on the iPhone!

[Krakrok]

http://www.slideshare.net/amittmahajan/rapidly-building-farmville-how-we-built-and-scaled-a-1-facebook-game-in-5-weeks

Flash <-> Apache/Nginx <-> PHP <-> MemCache <-> MySQL

To scale:
Flash <-> HAProxy <-> Apache/Nginx <-> MemCache <-> MySQL and a CDN to offload static content.

Nginx is suppose to take less RAM than Apache. For any AJAX all you really need is jQuery. Flash compiles to Android and iPhone (theoretically) with little to no changes. The reason you use PHP is that most APIs (like payment processors, offer walls, stats packages, auth APIs, etc.) all support native PHP libraries. And I'm a ASP.NET person.

Hosting services like Slicehost let you roll your own cloud using the above software.


Player.IO looks like it has a pretty cool solution too though:
http://playerio.com/

[Tarami]

I'll just leave this here...

http://www.xtranormal.com/watch/6995033/mongo-db-is-web-scale

[Xanthippe]

I hope you're making a zombie game.

[Samwise]

I hope you're making a zombie game.

Confirmed.    Once my "design doc" is a little more fleshed out and I'm in a particularly masochistic mood I'll share a link to it.

Player.IO definitely looks worth checking out...

[Ironwood]

I'm genuinely interested in this and wish to subscribe to your newsletter.

[Samwise]

Player.IO looks like it provides a pretty good framework for making "instanced" multiplayer web games, but isn't really built for a persistent world sort of thing.  Which is a shame because the integration with Facebook and payment systems would have been handy.

[Krakrok]

Their BigDB doesn't work for that? Seems like what you would need to do it would be a Server client which connects to their stuff and performs server side actions on the data.


You can probably mix and much which features you want to use out of the API.

MochiMedia has a payment solution too (and a developer fund aka free money):
http://www.mochimedia.com/developers/coins.html


I don't use any of them because I don't like having to rely that much on a third party for the database.

[Samwise]

Their BigDB doesn't work for that? Seems like what you would need to do it would be a Server client which connects to their stuff and performs server side actions on the data.

It'd be doable, but I wouldn't really be using their framework.  Basically I'd build a "single player" game that used their database to share data with a bunch of other "single player" game instances.  Which means I couldn't use their built in chat stuff, for example.  And I'd also be concerned that since their database is meant for infrequent and lightweight tasks like saving high scores, it's not going to hold up well if I need to poll it constantly to get information about the game world.

[Salamok]

Here are my votes:

No on nginx: It is probably a better option than apache if for serving static files but for something more dynamic like a game it isn't worth the extra pain to set up and configure.  

No on node.js: node.js is geared towards developing web services which could be useful in some sort of distributed approach but that doesn't sound like the approach you are going to take.

No on Java: Wrapping things in 50 layers of abstraction might be good for re-usability and maintenance but it generally doesn't lend itself to snappy response times or quick development.  Also for a 1 man crew a KISS imperative approach is going to be the way most likely to get you to a playable state quickly.

Yes on either jQuery/jQuery UI or Flash: This really is a major fork in the road and you will most likely want to use one or the other but not both.  Going with flash means learning actionscript and climbing into bed with adobe but you wont have to learn very much else as almost the entire thing can be done inside flash.  Personally I think jQuery/jQuery UI is a more flexible and desirable skill set for web development in general though, jQuery eliminates many of the browser compatibility issues and makes AJAX extremely simple, plus the UI library has tons of cool snazzy effects.  If this were any other web project but a game i'd toss Flash out on its ass.

Yes on MySQL:  MySQL is free, easy to set up, easy to use, well documented and stable.  There are better choices out there for a professionally developed MMO but you aren't building WoW and MySQL will do what you need it to do.

Yes on the LAMP stack:  If you are already comfy here then there isn't any reason to look elsewhere. If you go the Flash route you won't be doing much of the actual game here anyhow.

edit: If you do go with the LAMP stack I can't recommend using linode enough, for $20 a month you get a pretty nice VPS.  If you are not paranoid about security and are fine with rolling out on someone else's scripted install their stack scripts are nice.  If you are paranoid or do want to do it all yourself the linode library has some of the best step by step guides I have run across.   Also since it is a VPS and not a shared host you can easily go with LEMP, LEPP, LAPP, etc... variations, you lose cpanel but it is a crutch you are most likely better off w/o anyhow.

[tazelbain]

Maybe I am reading this wrong but it seems you can go flash without Adobe.  http://flixel.org/

[Salamok]

Maybe I am reading this wrong but it seems you can go flash without Adobe.  http://flixel.org/

You are still dependent on their player, there are alternatives to that but they are ones that 99.9999% of your users have never heard of, much less have installed.

[Samwise]

Yeah, I've pretty much settled on LAMP / JQuery, and some kind of cheap LAMP-ready VPS once I get it to the point of putting it out on the interweb.  Big benefit of doing everything generic-like on the server side is that I can do most of my development locally rather than having to code around some cloud-based thing, and not have to worry about finding hosting until I actually have something playable.

Reckon my next step is to brush up on MySQL, as my experience with it so far has been limited to tweaking existing systems rather than coming up with a  schema and figuring out how to handle concurrency and all that.

[Soln]

any updates?  curious how that set up was working (MySQL+LAMP+JQUERY)

[Samwise]

Haven't actually written anything yet, but I am half-assedly poking through documentation.  If anyone has any favorite online tutorials for MySQL I should look at, that'd be swell.  I'm particularly interested in learning about row-level locking semantics, handling/avoiding deadlocks, that kind of thing.

[WindupAtheist]

So what's your theme/concept for this?