Welcome to the Monastery, I'm not sure if you will find a guru here but you can get the very best help if you are willing to put in some work yourself. A good place to start would be the Tutorials section of the Monastery where I would direct you to How (Not) To Ask A Question and How to RTFM. Then you might want to skim through the offerings in the "Getting Started with Perl" section- your programming experience will dictate how deep you need to read. Finally if your application is going to be CGI based then you will want to look at the CGI resources I recommended recently or you might like to take Ovid's CGI Course. Have fun and good luck!
-- Do not seek to follow in the footsteps of the wise. Seek what they sought. -Basho
| [reply] |
We're here to help, but we prefer to answer specific questions or fixing specific problems. It's best when you provide us with a minimal piece of code where the problem occurs. It can help to provide sample inputs, and the expected output for those outputs.
By the way, the answer to next first post may very well begin with "Start by using use strict; and use warnings;". Save yourself trouble and use these, and understand and fix the errors these give rather than turning them off. The earlier you start using them, the better.
Another tip is to use CGI. Don't reinvent the wheel.
| [reply] [d/l] [select] |
I don't know the game "Food Fight", but whether that project is feasible doesn't depend on which language you implement it (assuming sane languages like Perl, PHP, C++, Java, and not INTERCAL or sendmail.cf).
I'd first decide whether I'd do it as an applet (which would limit the number of languages you can use), or as a pure browser game. The latter brings some restrictions. Or rather, one restriction with consequences. The restriction is that all communications goes over HTTP, which is essentially a state-less, connection-less protocol. Cookies have been bolted on top of HTTP to get some form of states, and there's keep-alive and HTTP push to get partially around the connectionlessness as well, but it's awkward.
I'd first design how to do the communication between the clients (players) and the server. What state do you need to keep? How does a client register? What do you do with unresponsive clients? And I'd write it in a language I feel comfortable with. | [reply] |