One thing that I find Perl to be lacking is a “wow” factor. Something so easy and awesome that within 5 minutes you’re sold on it. I was reminded of these after starting a side project with Ruby on Rails and Heroku.
This is my 3rd foray into Rails. I briefly worked on the initial version of OrgSync in 2007 with Rails 1.2. I came back to do a small website (since switched to WordPress) in 2009 using Rails 2.3. Now I’m back on the train in 2011 with 3.0.7. Every time I’ve ventured in I’ve come out deeply impressed and this time it is even more so because of Heroku. I went from never having read anything about it to having an app up and running in hours. And a lot of that time was spent just browsing their documentation. I could have done it in 15 minutes. The pain of Rails hosting I experienced in the past is simply gone. And it is free to get started. Everything about the process is designed to minimize the amount of friction a new user experiences, all the way from creating a Rails app, creating some scaffolds, and installing it on Heroku.
Maybe Stackato or DotCloud can provide some “wow” for Perl. Until then I’m pretty stoked to be riding the Rails again.
After much gnashing of teeth, I got Games::Tetravex working earlier this week. This a Perl implementation of tetravex using SDL and MooseX::Declare. As my first foray into both SDL and Moose, as well as the first game programming I have done since college, I thought it would be useful to lay out my impressions.
I’m pretty ignorant when it comes to graphics libraries. I did a little bit of game design in college in Java, but nothing with any depth. My crowning achievement was a half-working, four player, networked pong that I wrote in a two night code flurry. Then we got our grade and I never looked at the code again. With such little experience my first task was locating some tutorials. Luckily, I stumbled on SDL_Manual which, while not great, gave me enough of a primer to get started.
As far as actually using SDL for Games::Tetravex, it was pretty easy. It required me to start thinking in terms of (x, y) coordinates again, but, armed with some scrap paper, I was able plot out most of my canvas fairly quickly. It’s by no means pretty, but it does the job. I was quite happy with the SDLx::App and SDLx::Controller wrapper modules, as these made writing the actual game loop a piece cake. It becomes as simple as creating the app, registering some event callbacks, and calling run. Very nice.
To me, Moose is what gives Perl a future. Without a full featured OO framework it will be difficult to attract young developers to the language and Moose delivers the goods. My usage in this project is primitive, but I still came away with a good impression. I started the project as just one big script until I got a handle on what exactly I wanted to do. At that point I started refactoring using MooseX::Declare and was very pleased with the final result. In truth, the use of MooseX::Declare was complete overkill for a project of this size, but I figured I might as well jump into the deep end of the pool and see what happens.
It wasn’t all fun though. The big issue is the stack traces MooseX::Declare returns whenever you have some sort of parse error. They’re awful. Very rarely did they give any information about where the parse failed. I had to resort to commenting out large blocks of code until the program would run again. That was the only pain point I ran into, but it was a doozy. I’m sure there is useful information buried in there, but a stack trace of over a hundred lines with no useful summary is a problem.
There is still a lot left to do. The big one is that you can only play a 3×3 grid. After that it needs a lot of spit and polish, such as
better piece swapping animations
and a bunch more I’m forgetting right now. We’ll see how much I actually get to before my eye starts wandering to some new piece of shiny I want to learn.