After an extended absence (due to a combination of few ideas of things to write for them, shortages of time, and platform-specific challenges), I'm back into the DIC52 with an entry for the HTML5 challenge, Traspel Lite. This is a simple one-page spellcasting game, pitting the player against a series of foes of increasing difficulty.

Cross-posted from dream.in.code:

That's a big question which goes straight to the heart of Perl and plays a big role in why Perl is such a love-it-or-hate-it language.

For this week, I've written up an Ars Magica die roller. Ars Magica's dice conventions are unique, using three different types of rolls, all of which are based on ten-sided dice:

• Simple Roll: This is just your basic d10 roll with 0 read as 10.
• Quality Roll: In a quality roll, 2-10 are read normally, but a roll of 1 means to re-roll, doubling the result. Further rolls of 1 will repeatedly double the final result, allowing for arbitrarily high rolls. For example, rolling 1-1-1-7 is read as 56 (7, doubled three times).
• Stress Roll: Stress rolls are basically like quality rolls, but with the potential for very bad results as well as very good. A stress die is rolled just like a quality die, except that, if the initial roll is a 0, the total of the roll is 0, regardless of any modifiers, and the die is rerolled to determine whether you have botched your attempted action. Under poor circumstances, additional botch dice may be called for. If any botch die comes up 0, something bad has happened in addition to having failed. If multiple botch dice are rolled and more than one 0 is rolled, each 0 makes the result even worse.

This week is something of a gimme for me, given that I've already done app development against the Twitter API. For the sake of something simple and accessible, I opted to revise my earlier Iron Man post on Monitoring Hashtags with Perl and Net::Twitter to make use of Twitter::TagGrep and call that my DIC 52 Weeks of Code entry for this week:

Call it loose coupling, application of encapsulation, avoiding god objects, plugin-based architecture, or whatever else, but I don't like having objects which carry out the functions of another class's objects. I believe that each class should contain the full measure of its functionality, so that adding it to a project is as simple as use MyClass; without requiring modification of any existing code for the new class to do its thing. (Existing code will often need to be modified to tell it to use the new class, of course, but that's not what I'm talking about here.)

Unfortunately, KiokuDB::Tutorial's example of using Search::GIN hardcodes knowledge of how the Person class should be indexed into the database ->connect call. I'm sure this was just done for the sake of showing the simplest possible example, but here's how I set things up so that my ->connects don't have to change when a new class or index is added.

My second trip to #kiokudb came about when I got to the point of wanting to edit my objects through a web interface, which called for identifying the object I was editing. While Kioku was assigning unique IDs to each object which would be perfect for the purpose, the objects themselves didn't have access to their IDs and so couldn't provide them to my templates for insertion in the pages. Starting from my root node and walking the object graph every time seemed unreasonable and

$dir->store($obj);
$obj->id($dir->object_to_id($conf));
$dir->store($obj);

As mentioned in my last post here, I've recently started in on a free-time project to teach myself some of the more-currently-popular modules that I haven't been using. So far, that means Moose and KiokuDB. Moose has been coming along pretty readily so far (I'm not entirely sure whether that's because of MooseX::Declare or in spite of it), but KiokuDB has had me scratching my head quite a bit and sent me off to IRC twice for help.

In the last couple weeks, I've seen Perl questions on at least two separate forums which revolved around the connection between .pm files and Perl packages. Really, though, this connection is quite easy to understand if you just remember one thing:

It doesn't exist.