   multiplayer turn based browser game
  Hello all,I'm looking into making (as the subject mentions) a multiplayer turn based game that is played through a browser.  I'm getting conflicting advice when searching about this, and a lot of google searches just throw back a bunch of game pages.Anyway, I'm wondering what a good architecture would be for this setup.  It will kind of be like an RPG where you have whatever data stored about your character - items, level, stats, etc.  The main gameplay will revolve around fighting npcs or other people in final fantasy type turn based combat.  I want to design this with the multiplayer aspect in mind from the ground up.I feel like, with what I want, I'm being led towards coding the game as a java applet, mainly because of the "browser based" requirement.  I'm comfortable switching to other languages if they make more sense.  I could also look into flash, but I know very little about that thus far.  I expect there would be a lot of database calls going on and I'm not sure how flash handles that, and I know nothing about how supportive flash is of multiplayer.  I'm also looking into silverlight as a possible option.From what I'm reading, I think that it would make sense to host a lobby, and have the users actually host the games/matches.  Does that sound like it makes sense for what I'm doing?Long story short - can anyone give me some guidance on what would be the best way to approach this project?  I realize there's not always a "right" answer to these types of questions... but I'd really appreciate any ideas people have about what the might be the right direction.  Thanks!   
  Since you are not coding an Action Game, if possible just use plain HTML and PHP. If you really need an Advanced Front-end then go with Flash.   ;  Well it's going to be multiplayer so I think I will need client side stuff to be running, and I want to have a somewhat developed GUI that will be smooth and easy to navigate.  I will look into the option of flash some more, and would appreciate any advice that others have to offer.   ;  Flash has built-in facility to send and receive XML messages with the server, through the browser-offered request mechanism also made available to &#106avascript. You can easily send and receive nul-terminated strings, too, but XML can get pre-parsed for you into an object-like DOM for easy handling. Java has XML parsers, and sockets; you can do the same kinds of things easily, it just requires a bit more hands-on work.If you're a programmer, then starting with nearly nothing graphically might make more sense to you, and Java would be the right way to go. If you're more of an artist or designer, then learning Flash and working with what it offers you might be more your style.By either route, you still need a game model, a server, and a message architecture, in approximately that order. You need to clearly define how your game will behave, and what states the user and their character(s) can be in. For instance, assuming you are aiming for a Final Fantasy-esque overworld, as well as combat area...States- Unavailable: party is logged off or AFK.- Overworld: player moves party around the map, can interact with shops, NPC parties, player parties, objects. Variety of interactions depends on target and location; friendly zones don't allow attacking, wilderness makes combat with NPCs automatic, etc.- Engaged: two interacting parties are visible on overworld, but not interactable with by other parties. Meanwhile, those two parties are engaging in combat.Data Model- Party; has member characters, an item pool all members can access, and has a location in the overworld if logged on. Also has a current state.- Character; has various statistics used in combat and minigames.- Engagement; created when two parties enter combat. Keeps a data structure of turn order, current turn, etc.If timing is at all relevant to combat (ie you get only 20 seconds to commit to an action on your turn), then you need a clock synchronized between client and host; see http://www.gamedev.net/reference/programming/features/clocksync/You need to make client and server somewhat robust to failure; a client must always be able to yield to what the server claims to be true, and the server must be able to occasionally resolve conflicting pieces of information between different clients' states in a fair manner.Hope this helps as a starting point.   ;  Hey, thanks a lot, yes that's a lot of help.  I've been spending some time thinking on it now.  I've realized that the scope is pretty big for just starting with this stuff (games, not programming), so I've decided to try to divide and conquer.  I believe the most difficult part of the application for me (and maybe the most important) will be setting up and handling fights between 2+ live players.  I want this to be part of the foundation of the game, and want to build it with that in mind from the start.I'm just kind of thinking of ways I can do this, as I'm having trouble finding any tutorials on multiple clients interacting with each other through the same server (plenty of stuff on a server handling multiple clients at a time, obviously).  Anyway, I'm thinking that I want to have some sort of lobby area where people could see who else is on, and invite them to a match.  I'm thinking the initiator will open a socket to the server (new thread), and then tell the server to initiate a connection with the other player.  That way, they could both easily be contained in the same thread.  I'm thinking that I could have a listener on the client side that maybe they could flag on and off when they want to be available for matches, running on a thread that they initiate when they start the game.  Is there some way I could join the socket/thread that they originally opened with the thread the initiator created?The goal here would be to have a thread that controls the 2 (or more) sockets/threads pertaining to the players in the match.  Once everyone has agreed to join, this server thread would accept their actions for the turn, do the computations to check the results and then return the new state of the game for the next turn.Does this sound possible?  Will doing these computations on the server side overburden it?  Is there a better way to handle this information (store it somewhere else, communicate in a different way, run the computations somewhere else)?Thanks again, for all the help thus far.   