Multiplayer Game Question
 

I have written a multiplayer game which can be played over the internet. The game runs in a stand alone application, not in a web page. I would like to allow people to play each other for money, eg, 2 people in a game, they both put $$££ down and the winner takes all.

My question is, is this really possible when using a stand alone application, as opposed to a browser embeded applet, since I see the following security problems:

* The player would subit their moneytary/credit details on my website via PayPal (or whoever). But then I need to transfer the credit details from the webserver to the games server, (and then also possibly from the games server to the client). My problem with doing this is shorely it would not be secure! Basically it would rely on the security of my own TCP/IP code!

Would it be possible to securely manage credit from a website to client machine?

Apologies in advance if I'm asking a stupid question, but I'm not entirely sure how these sort of things work.

You're right to be concerned about security, because used incorrectly, encryption can be just a false sense of security. That said, there are many encryption libraries around you can use, so whilst you have to be careful, it's certainly not impossible.

However, it's unlikely you could do this with Paypal, at least not via your application, as I doubt they'd like you sitting in the middle of a secure financial transaction, privy to all the financial details the user enters. The only way I could think of doing it would be to provide a website where users could money to your account, and then you automatically give it to the winner.

However, your users would have to trust you with their money, and you couldn't have a client-to-client multiplayer game, since there would be too much chance people would cheat. It would have to be a client-server-client architecture, with the clients being thin enough that altering their code wouldn't allow them to cheat. Of course for this, you'd also need a dedicated server to run it off.

Thats for the reply Arevos thats really helpful.

You say users would have to trust me with their money, are there not (in the UK) any 'regulatory bodies' which set out technical rules that you have to comply with if your going to handle other peoples money over the internet? After searching google it seams the only rules are things like you must state your company name and address etc.

There are a few applications which handle moneytary transactions online and then provide the 'credit' in an application, SecondLife is one example.

I think to take this project to the next level I may need some help. Maybe I'll post in the job offers section soon, with a link to download the game and test it, then see if anyone has any interest in sharing the project with me.

i think credits would be the way to go. setup a third party or bank to handle all of the transactions and then they could supply the client with credits equal to their deposited amount. with the winner of the game receiving credits you'd still have to worry about cheating, but at least it could take the financial burden off of you.

To take my project to the next level I need the help of an experienced programmer.

My game, its a 2D Pool game, the first version is finished. It uses OpenGL/DirectSound/WinSock2 programmed in c++ with MFC using VS2005. Basically when you start the application you enter the 'games lobby' (connect to the server, which I host), then you can start a game with anyone else in the 'games lobby'.

What I would like to do is allow players to play each other for money. There is one other pool/billiards application (not broswer applet) out there that does just this (its at www.8ballclub.com). So I know its possible.

What needs to be done: the website and the secure passing of financial info from a webserver to the games server, and all the other missellanous stuff which goes with this.

I need an experienced programmer to help with (and lead the way, since I dont know exactly what has to be done) this uncompleted part of the project. If the project succeedded financially we would share the income.

I live in England so I'm looking for someone who lives here also.

If anyone has the skills/ability and interest then send me a PM (or post in the thread), and I can send you the Pool application which you can test out.

They probably use a merchant account, but getting one can be tricky and expensive. Firms like Paypal and Worldpay act as middlemen, processing credit cards and storing money in return for a percentage. The difference between a service like Paypal and a merchant account, is that Paypal requires users to enter their credit card details through the Paypal website, whilst a merchant account allows one to construct their own credit card handling system.

You could have some sort of credit system, as has already been mentioned, where users buy a set of credits which can be later be reimbursed for cash. However, you might want to check up on local gambling (probably not an issue in England) and money laundering laws. The law may require you to keep certain records, though I suspect that if you use a middleman like Paypal or Worldpay, they'll keep all the records required by law, so that might be okay.

It's worth mentioning that your clients will have to be pretty thin. The physics, positioning of the balls and score will all have to be handled by the server, and range checking on the velocity of the cue is a must.

Yes I agree the client will have to be thin, I don't see a problem with that. Of course the physics could not be solely handled by the server over TCP since it would not be quick enough to run in 'real time' at the client end. But how it would work is, the server could keep track of the motion itself, and at the end of each players turn the server would check with the client that they both agree on the final position, just check for 'synchronisation errors' after each turn.

Just checking :)

Your implementation sounds perfect, by the way. I don't see you having many problems stemming from the networking aspect of the game.