Can anyone tell me what I need in order to create a multiplayer web-based game.

I've already got a player vs computer version of the game done and I'd like to make it so that it can be played by 2-6 players accross the web.

Currently it's in C#.

Any thoughts on this would be appreciated.

Thanks

Well, the first place I would start is the basic framework of the online part. Figure out the database tables, and then make a login, and register. If you would like to purchase one, contact me and I can get you a working ASP login and registration with SHA-256 encryption already made.

If you have never worked with ASP before, I would look at Visual Basic Script tutorials as a start, although having a backround in C does help.


If you need anything, feel free to contact me.

You know I got all excited that someone had replied to my thread. I really thought that there'd be something of use here for me to get moving on my game, but really, I see that you've posted this one post as an advertisement for your services. And worse than that, you didn't even offer me what I needed, you offered me something I didn't ask for. And then you took a moment to think that I've never programmed in ASP before.

Let me take a moment to remind you that I have my game, it's done in C#. I've got a working login and registration page that is also done in C#.

I'm looking to take it to the next level. I want my currently player vs computer game to become a web based multiplayer game (2-6 players). I'm looking for someone to help me head in that direction.

I am sorry for misreading the OP. What exactly is your game, and what exactly do you want to do? Do you want it to be turn based, or use Cron Jobs to update?

my game is a card game, and i'd like to make it into a multi player turn based real time game

Moving to the new C# forum per request.

Is your game browser-based (in HTML/Javascript), or is it a client application that will therefore need to communicate with other clients across the internet? The approach would be very different depending on which.

(ROFLMAO at your comments to cobrastrike, I was thinking pretty much the same thing when I read his "advice" ...)

--serializer

The game is browser based, it's html/c# however, I want two people, on two different computers in any location to be able to play against each other, which essentially means (in my head) that the ability to communicate across the internet is a necessity.

Does that make sense?

Obviously for any internet multiplayer game, some form of net communication is necessary; however for a client application-based game, the mode of communication is different. Since your game is already browser-based, it is already communicating with a server, and each other player will also be communicating with that server; therefore your main task is getting the server to manage the game state, i.e. the interactions between the players and the game rules.

You also have the secondary task of adapting your user interface. Currently (and here I am entirely in the realms of guesswork since I have no detailed knowledge of your game) the interface will involve the user clicking on a card to select their move (possibly having first set bidding options, etc.); at this point the server will work out the computer player's response, and return an updating page showing the user what has taken place. Stop me if I'm wrong?

You'll definitely need some sort of AJAX system so the page will be regularly updated, so the user can constantly see the progress of the game, i.e. what the other players are doing. The web server will also need to manage the game; this will take some sort of persistent storage, for example a database, so that one player's session knows what's going on in another player's.

Does this all make sense so far? How much of this is already implemented?

--serializer

they way you wrote out your response makes me feel as though you think i'm a student trying to get a solution to my homework, so let me just preface this by saying that the player vs computer part was for my senior project. I've since graduated and would like to take it to a higher level. I'd show you what I've got except I just canceled hosting due to lack of response to the conversion of this game from player vs computer to player vs player.

So primary task, let's start there, getting the server to manage the game state, what do you suggest?

Not what I was thinking... Must be my writing style. From your level of activity in the forum I'd guess you were professional/experienced in a number of areas; I was trying to probe what things you might have already thought about or know about, rather than jumping straight in with advice that might not be any use.

On to the task at hand: Game State management. The essential problem for the web game scenario is that web pages are Stateless. Rather, we can only handle the current state of the application at the time of a HTTP request, usually accompanied by GET/POST data which provides our application an update of the user's state. Between such requests, the application's entire state is stored away in Session.

The complication is that we have multiple clients in this scenario, each talking to the server at unpredictable times. Basically, each player's game (as a client-server interaction) needs to be thought of as an independantly running application, even though they all run from the same scripts. Server-side, each one's Session stores an ID which references game state information stored in a Games table. This table will need an ActivePlayer field to indicate whose turn it is.

If the current Session's PlayerID is the same as ActivePlayer, and they've submitted a move with this request, update the game state and submit a response, also updating the value of ActivePlayer to the next one in sequence. (If there are any computer players immediately next, their moves should be made, and ActivePlayer passes to the next human.)

If the current player is NOT the ActivePlayer, simply return an update on the state of play, so that user can see what's going on.

You'll also need a GamePlayers table to indicate which players are currently participating in which games.

You'll need another table - perhaps CommandQueue - if you want players to be able to send commands to the game whilst they're not the ActivePlayer (the situation we need to avoid would be two processes both trying to update the game state at the same time, so some form of command stack allowing them to share information would be needed).

You also need to consider timeouts, for a user either
a) disconnecting (and remember they could have just had a flaky connection for a short while)
dawdling (possibly some sort of kick system could appear when a user has waited tool long)

I could go into more detail on some of this, but that's about all I can think of up to here.

--serializer

hey guys when you finish the game, inform me cuz i would like to be a test your work.