Thanks for posting the game. Honestly, I've never had the patience to work through one of those slider games. But it's fun to see the game presented in Perl.
I did want to contribute a few suggestions that might both improve the game as well as your code overall. You'll find that to implement my suggestions probably means a complete rewrite. But if you take a few of these suggestions with you to your next project you'll end up with cleaner, more robust, easier to handle code.
- use strict; If it doesn't execute under strictures you should dig into understanding why. Strict will force you to declare your variables before you use them. It will force other WISE practices as well, and you'll find that development time and bug tracking will become much easier. 'strict' is your friend.
- Pay attention to warnings. The code isn't done until you've squished every last one. You clear the screen by scrolling 100 '\n' (newlines). But that masks the fact that just starting the program up gives you about ten warnings. Some of them are significant.
- Use an array of arrays (a two-dimensional array) instead of $a1, $a2, $b1, $c3, etc. It's cleaner, easier to maintain, easier to grow, better all around, less kludgy, and less confusing. It's simply the better way of handling a two-dimensional entity. Since this particular program uses rows A through C, and columns 1 through 3, you might consider a hash of arrays (keys being A through C, for the rows, and columns being 0 through 2 internally). See perldoc perllol and perldoc perlref for info.
- Input parsing should be more robust. Entering 1a should be just as good as entering a1. Why not? And 1A should be acceptible too.
- Your validity checking isn't working properly. Somehow undefs are still slipping through, and causing warnings to be generated right in the middle of the printing of the grid, thus distorting and wrecking the grid. If a user enters an empty cell, you could use the "if (defined....){" construct to check against that possibility. And if a user enters a cell that is immobile (blocked by other tiles) that shouldn't cause the program to spit out a warning right in the middle of the grid.
- Don't use seven or eight print statements in a row when a HERE document would be more efficient, cleaner to write, easier to read in the source code, etc. I understand that you wanted to use printf. But there's still probably a better way, using HERE docs than having six or eight printf's in a row.
- Pass arguments into your subroutines, and return values from them. Don't let your subs rely on global variables. Subs should rely on what they find in their own local namespace. If you think of a subroutine as a black box that does a particular job, you don't want it to do its job based on all sorts of unnamed things going on in the world. One good way of writing obfuscated code is to let your subs deal entirely with global variables rather than passing data in through the more traditional parameter list method. See perldoc perlsub. Also see perldoc perlref to understand passing hashes, arrays of arrays, and other more complex datastructures into subs.
- Rather than use nine nested if/elsif statements to probe a hash, use the hash itself as the "switch" handler. Give the hash subroutines as values. Or use one of the other cleaner 'switch' idioms described in perldoc perlsyn.
- Declare your variables (strict will force you to do this). Declare the variables that subs use internally, within the sub. Always try to limit scope to where it is applicable.
There are probably other things to discuss, but these are the ones that jumped out at me first. Again, I'm not trying to criticize your code. I think it's a fun implementation of a well known game. I just offer these tips so that you might have an easier time of making a more robust program next time around. I'm no expert myself. But as someone who was at the level of your code not too long ago, I just wanted to help point you in the right direction in tackling the learning curve.
Keep up the good work. As long as we're all learning all of our efforts are worthwhile. Keep having fun with it.
Dave
"If I had my life to do over again, I'd be a plumber." -- Albert Einstein
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.