Download, check - the tweaked version from roboticus, actually. Play, check (after fixing the two variables reported by '-w'.) Feel all old-school, check. :) Very cool for a first effort, indeed!

In addition to the one-off positioning problem reported, the collision detector doesn't work during placement; I was able to place all my ships one on top of another (I think I heard the computer sobbing in frustration after shooting up half the board without a single hit.)

From the coding end... yeah, gotta say: it's a mess. :) If I had to maintain such a thing, I would *much* rather have had it handed to me without any namespace declaration - all globals - than something like this.

Also, it seems that somewhere along the way, you were taught that Thou Shalt Use Subroutines No Matter What. Actually, subroutines are used for specific reasons: modularization, for example, is a good one, and useful for creating short, easily readable "main" blocks, and for having "user functions" that you can call multiple times. But your main block isn't a readable, obvious description of program flow - it's just a series of calls to blocks of code, with no visible structure to it. To figure out what is happening in your program, you need to dive into the code itself... which sorta blows the whole idea out of the water. (Ahem. Pardon the metaphor, but I'm a sailor with 25 years of experience behind me, so I have certain privileges.)

Another reasonable use for subroutines (I was going to say "subs"...) might be for keeping a sort of a small, private "working area" - that is, making it easy for yourself to see the entire scope of what you're working on, and creating a series of "black boxes" that take input, return output, and don't collide with each other because their content is effectively isolated (I know, I'm starting to preach OO here...) Not what's happening here, though.

Please note that the above isn't really related to Perl specifically - it would apply no matter what language you were using. The problem I'm talking about isn't related so much to the functioning of the program as to the way that you "communicate" with your fellow programmers - anyone who comes along to read or maintain your code - which is what so much of the various programming patterns, etc. are all about. Yep, there are better ways of approaching the problems you're trying to solve - but they're not complex ones, and improving that is a different matter entirely. But when you write a program, please remember that you're not *just* solving those problems - you're also "writing to an audience", and _that_ communication needs to be as clear and explicit as possible.

[ Oh, dear. I think I accidentally hit my 'rant' button. <click> OK, it's off now; everybody's safe. Whew. :) ]

No matter what, though - thanks for the fun experience!!! It's definitely been a Blast From The Past.

-- 
I hate storms, but calms undermine my spirits.
 -- Bernard Moitessier, "The Long Way"