|
dchandler has asked for the wisdom of the Perl Monks concerning the following question:
I have a friend across the country who I'd love to play texas holdem with. I am pretty sure that I can write this program for a single computer. Such that if the players didnt mind everyone seeing everyone else's cards, the game would work fine. Clearly, for purposes of gambling this is beyond useless.
I'd love if I could create a webpage that allows my friends to signin (with passwords). We'd all then sit down and play the game such that community cards are revealed to all of us, but that our private cards are sent only to each respective player. The program would also need to know when to accept information (about betting, raising, folding, etc.) from each player and when to then move on to accept information from each other player. I'd also like to be able to tally up amount of money in pot and for each person at all times.
My main question is this... I am *very* new to perl. I think I can figure out the mechanisms of the game, but don't know if it is possible to accept and display input to and from different users simultaneously on a website. Is this very difficult to implement? Where might I look, or what books should I find to learn how to do such things? Does anyone know of any sourcecode for other interactive website games that might give me ideas?
thanks alot,
dana
P.S. When I create this program, I will totally be making it available to everyone! |
Re: Making an Interactive Game on a website (Texas Hold'em)
by gumpu (Friar) on Aug 14, 2004 at 07:18 UTC
|
Instead of using a webserver you can also consider writing your own little client-server system. This might be easier
to start with, and a nice way to learn about it.
All players get a client program that communicates via a socket to a sever program. Sockets are pretty easy to program (for examples see the perl cook book). The server program keeps track of the score and the cards. The client program displays everything (you could use PerlTk for that) and accepts the moves and bets.
The advantage of writing it yourself is that you can make it
as interactive as you like as you control the communication protocol.
A drawback would be that your friend have to install Perl too... but then again that is not a real drawback but rather a chance to learn a very enjoyable language.
| [reply] |
|
|
And: If you want to get a server up and running quickly, have a look at Netserver::Generic. It'd leave you lots of time to play with the client code.
| [reply] |
Re: Making an Interactive Game on a website (Texas Hold'em)
by Zaxo (Archbishop) on Aug 14, 2004 at 07:24 UTC
|
| [reply] |
Re: Making an Interactive Game on a website (Texas Hold'em)
by neilh (Pilgrim) on Aug 14, 2004 at 07:13 UTC
|
G'day,
There are a variety of tutorial heres, and elsewhere on how to build Perl based websites.
On Perl Monks -
CGI/Network Tutorial.
At CPAN
CGI.pm
Books -
For a list of Books have a look at Perl Monks Reviews
I look forward to seeing your product.
Neil
| [reply] |
Re: Making an Interactive Game on a website (Texas Hold'em)
by zentara (Archbishop) on Aug 14, 2004 at 13:32 UTC
|
I'm in the process of working on such a game, one that can be played over a lan or the internet. I will be posting it here after a bit more testing. It is a scrabble-type game that can support up to 4 players. I will attempt a poker variant next using the same framework.Now to get to your question. I originally wanted to do it via CGI, but you run into one big problem...CGI is a stateless protocol, so you will have to store all the sessions in a database of some sort, send out alot of hidden fields to maintain state of the users, and deal with the fact that you will need to force an update to all the users, that may require javascript ? Otherwise, the players won't know when the other players have played, unless they click an "update" button. So that is your big problem with using CGI. Now I just decided that using TCP sockets was an easier way to go. You make a perl server listening on some port, and have your clients connect to it. I'm using Tk for the clients. The benefits of using TCP are: it maintains state, the server can send out data to the clients for updates, automatically; and it also allows for a little real-time chat between players. So consider TCP for realtime games, it actually is easier than CGI, (once you learn a bit about sockets, and some Tk for the clients)
I'm not really a human, but I play one on earth.
flash japh
| [reply] |
Re: Making an Interactive Game on a website (Texas Hold'em)
by mattr (Curate) on Aug 14, 2004 at 16:21 UTC
|
There is a key question about architecture, will it be a CGI program that is called up every time a move is made, or will you have an always running application, which might be good for a game but is much harder to write. I think a plain CGI program will be best for you.
But you might want to check out OpenThought too which I haven't tried although it has always seemed neat, in that a running perl cgi application can push data to a user's homepage through javascript quickly, so users don't have to wait for a whole page to reload.
Also more advanced, but if you want more of a client application instead of a web page, check out WxPerl which is a Perl interface to the cross-platform GUI toolkit WxWidgets. But you can do pictures, sound, and javascript animation with ordinary web pages so wxperl is probably not what you need now.
It certainly is possible to accept and display input to different users at the same time, but your application needs a way to always know the state of the game. This requires some kind of persistence mechanism. You could write the information to a text file but then you would have to write code (or get a module) to deal with several people trying to access it at once. More likely you would be using a database, or maybe a "tied hash" (a data structure that is automatically saved to disk when it is changed). Or you cuold just use a hash that is stored in a (IPC) shared memory cache. These storage modules will be accessed every time someone does something to change the state of the game (i.e. makes a move).
In Perl if you are very new to it, the keywords are "TIMTOWTDI" (There Is More Than One Way To Do It), and "laziness" which is seen as a virtue. In this case, laziness means find useful modules from the CPAN (they can be automatically installed for you too) which you know already work, so you can focus more on the presentation and game logic.
If you use a database in Perl you usually use the DBI module (see search.cpan.org) in which case you might like Class::DBI, which simplifies it with an object interface. But the plain DBI module provides ways to grab a whole table or row into a perl data structure (a hash or array).
Finally as for logging in users, a simple CGI parameter is enough for you to store the name of the user probably, but a system that would be a little harder to cheat on would probably use something like the module CGI::Session (or I use Application::CGI::Session I think) to create a session for each user in the database when they log in. This is more than you want to get into now.
Wny not start really small and simple, and then grow from there? You are sure to learn a lot! | [reply] |
|
|
