next »

[Sinister.Frankly]

I'd like to make this thread to gather information together for making browser based games.  I'm fairly new to game development, and I'm trying to make a simple single-player Rougelike game.  I'm wondering if it's possible to program for the browser without using php/actionscript, and rely on dhtml and primarily ajax style server interaction.
Is this a good idea, or is it too slow?  Where is a good place to get started with this kind of programing?
Thoughts, opinions welcome!

Google yields:
http://www.google.ca/search?hl=en&q=browser+based+games+dhtml&btnG=Search&meta=
http://dave.caretcake.com/writing/dhtml_games.rhtml
http://jayisgames.com/archives/2009/03/puzzle_dungeon.php
http://jayisgames.com/tag/dhtml

[Overkill]

Firstly, you should introduce yourself.

From personal experience, using DHTML and AJAX can be done, but your game had better rely on doing stuff locally as much as possible. This is because the server can't send any information the client didn't ask for first, meaning that you end up with some horrible polling situations which can overload your server if you check too often.

That said, for a Roguelike it could be okay. Just make sure all your rules and processing are done client-side, and only ask the server when you need a new floor generated.

Also, animations and effects are a pain, unless you're willing to cope with using .GIFs.

Oh, and doing server-side stuff pretty much means you need some sort of server scripting. Most people use plain PHP (even though it's ugly, broken, and inconsistent, it's extremely easy to learn). Also good frameworks: CakePHP (needs PHP), mod_python, Django (needs Python support of some kind). I guess some people might be shouting Ruby on Rails, personally I've never used that so I can't comment.

If you need something more interactive or shiny, use Flex already.

[Sinister.Frankly]

Overkill : Thanks for all of your feedback.  I've been thinking about RUBY for a while, as some cite it as a stepping stone to C, in the long run.  Haven't checked out flex properly, thanks for heads up.  When you mention problems animating, is the problem jsut in the amount of code that needs to be run?

As for introductions, I'm really shy + socially awkward.  I wasn't sure if I should add to the stickied post, general forum or where. I can't even find the file type restrictions for avatars u_u;

[Aquin]

Is Javascript allowed into this?  If so, look at the Chrome Experiments website.

If it's not allowed...uh... hmm.  The most I ever did with just PHP was a character generator + role-playing device for use with my friends over Skype.

I guess it wouldn't be a stretch to include imagery, text-based descriptions, and a text-parser.  So you can at least make a MUD-type game with images.

[Overkill]

Overkill : Thanks for all of your feedback.  I've been thinking about RUBY for a while, as some cite it as a stepping stone to C, in the long run.  Haven't checked out flex properly, thanks for heads up.  When you mention problems animating, is the problem jsut in the amount of code that needs to be run?

Well, there's a fair amount of code needed, but that's less it. It's just that you'll either need looping gif images, or keep an image for each individual frame of animation. It can be done, just either requires a fair more of bandwidth. Also, browsers can get some wacky out-of-sync problems, esepcially if you're putting animated gif images on tiles. They'll all be starting at a different time. And with the separate frames thing, you're making the game a lot slower to load.

As for introductions, I'm really shy + socially awkward.  I wasn't sure if I should add to the stickied post, general forum or where. I can't even find the file type restrictions for avatars u_u;

Hey, don't be afraid. This a friendly place, and getting over shyness is a good thing. Just post in the stickied thread and tell us about yourself!

Also the avatars are resricted to the standard internet formats, I think. So JPEG, GIF, and PNG. I dunno about size limits, but I'm assuming like 100x100's a sane limit for most people.

[nihilocrat]

If you just use text in a fixed-width font, I'm pretty sure you could write a purely javascript roguelike without need to interface with anything fancy after putting together a simple curses-like interface.

[Snakey]

This is because the server can't send any information the client didn't ask for first, meaning that you end up with some horrible polling situations which can overload your server if you check too often.

Well, this isn't 100% true. You can actually send data from the server to the client without using polling and so forth. It's called Cometd, or reverse AJAX. However, there are a lot of costs in using this technology as you often need to use virtual server hosting, which can be a lot more expensive than standard web hosting.

[bateleur]

Is Javascript allowed into this?

That's the 'J' in AJAX!

Incidentally, anyone who's comfortable with Javascript should definitely consider using Actionscript, since they're basically the same language.

You can actually send data from the server to the client without using polling and so forth. It's called Cometd, or reverse AJAX. However, there are a lot of costs in using this technology as you often need to use virtual server hosting, which can be a lot more expensive than standard web hosting.

Another potential downside to this approach is that the server achieves this by keeping the HTTP connection open. If your game has a lot of players this can get quite rough on the server. Also I suspect (although I haven't tested this) that the server would be unable to detect disconnections as it could with sockets.

[Aquin]

I was a bit confused, because he didn't want PHP or Actionscript, but he was looking for an 'AJAX-style' server.

I have to admit, maybe I don't understand what he wants. 

notpr0n is a great example of a browser game that isn't that fancy.

[Snakey]

Another potential downside to this approach is that the server achieves this by keeping the HTTP connection open. If your game has a lot of players this can get quite rough on the server. Also I suspect (although I haven't tested this) that the server would be unable to detect disconnections as it could with sockets.

This is also why I said that there are a lot of hidden costs, and why you'd most likely need a virtual server host. The primary reason is mostly because you need to run a custom server such as Jetty, TomCat or a modified Apache. The secondary reason is because you want the machine to just handle your site and no one elses. Comet is able to detect when a user disconnects, and this is easily proved by the common chat examples that come with most Comet implementations.