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!