Results tagged “veure”

Atomic Updates with DBIx::Class

As we're building Tau Station, a narrative sci-fi MMORPG written in Perl, we've encountered any of a number of challenges, not the least of which is that this is a very "write-heavy" application. Further, because it's a universe where people interact, there's often no clear isolation between what you can change and what I can change. Thus, there's a lot of writing to the database and often to the same data!

By now you've probably heard of the Object-Relational Impedance Mismatch, which is just a fancy way of saying "collections of objects and databases aren't the same thing."

One problem which is particularly difficult is handling "syndicate credits". Syndicates ("guilds" in other MMORPGs) can tax their members and every time a member gets credits deposited in their bank account, a certain percentage goes to the syndicate. So let's say two syndicate members each earn 100 credits at the same time, paying 10% tax to their syndicates. It can look like this:

  • Process #1: Read how many credits a given syndicate has.
  • Process #2: Read how many credits a syndicate has.
  • Process #1: Set syndicate credits = credits + 10
  • Process #2: Set syndicate credits = credits + 10

Logically, the syndicate should end up with an extra 20 credits. But if you do a naïve:

$syndicate->update({ credits => $credits + $tax });

... you can easily wind up with 10 credits because the "Process #2" read the total credits before "Process #1" wrote them out. Fortunately, there's an easy fix to this.

Tau Station is now live!

It's been a few years in the making, but Tau Station is now live!

It's a free-to-play post-apocalyptic interstellar MMORPG that runs in a browser, tablet, or mobile. The backend is written in Perl.

Join Tau Station and let's show the world the awesome things you can do with Perl! (And hey, spend money if you can; I need to keep the lights on) :)

We follow WCAG 2.0 AA standards for accessibility (blind and mobility impaired people can play).

Tau Station is now live

Metric Time in Tau Station

If you've been following our progress with Tau Station, you know we're creating a science fiction universe in Perl for people to enjoy. As of this writing, the time in Tau Station is 194.10/51:647 GCT.

"GCT" stands for "Galactic Coordinated Time" and that's a variant of metric time. As a software developer, I wish we had that in the real world, but alas, we don't.

The GCT time listed above is roughly 194 years and 10 days after the "Catastrophe" (an apocalyptic event that effectively serves as our "epoch"). There are 100 days in a year, 100 "segments" in a day (14.4 minutes each) and 1000 units in a segment (.864 seconds each).

I love the fact that figuring out the display time for GCT is this simple:

my $days = sprintf "%9.5f" => $seconds_since_catastrophe / $second_in_a_day;
$days =~ m{^(?<year>\d+)(?<day>\d\d)\.(?<segment>\d\d)(?<unit>\d\d\d)}a;
my $gct = "$+{year}.$+{day}/$+{segment}:$+{unit} GCT";

Due to imprecision in normal dates, we don't get an exact round-trip conversion between regular DateTime objects and GCT, but so far we've not found them more than a second off.

Figuring out durations (D0.00/12.500) is similarly simple:

my $days = sprintf "%9.5f" => $duration_in_seconds / 86400;
$days =~ m{^(?<years>\d+)(?<days>\d\d)\.(?<segments>\d\d)(?<units>\d\d\d)}a;
my $duration => "D$+{years}.$+{days}/$+{segments}:$+{units}";

Of course, since that means we often need to know the total number of seconds, we have this nasty bit of code to figure that out:

sub period (%args) {
    my $seconds = delete $args{seconds} // 0;
    $seconds += ( delete $args{minutes}  // 0 ) * 60;
    $seconds += ( delete $args{hours}    // 0 ) * 3600;
    $seconds += ( delete $args{days}     // 0 ) * 86400;

    # solar year
    $seconds += ( delete $args{years}    // 0 ) * 31_556_925.97474;
    $seconds += ( delete $args{units}    // 0 ) * .864;
    $seconds += ( delete $args{segments} // 0 ) * 864;
    if ( keys %args ) {
        my $unknown = join ', ' => sort keys %args;
        croak("Unknown keys to Veure::Util::Time::period: $unknown");
    }
    return round($seconds);
}

Metric time is lovely and easy. Regular time sucks.

I really wanted to write a DBIx::Class inflator to use GCT objects instead of DateTime objects, but found too many assumptions about the use of DateTime in the DBIx::Class code, so we scrapped that bit. Darn shame.

Seeing the SQL in DBIx::Class

There's no question that DBIx::Class is the dominant ORM in Perl. That's because it's fast, it's flexible, and sane. Well, mostly sane, until you need some introspection (if anyone knows a better way to do this, I'm all ears!):

sub _get_json_columns ( $self, $schema_class ) {
    state $json_columns_for = {};
    unless ( exists $json_columns_for->{$schema_class} ) {
        my $columns = $self->schema->resultset($schema_class)
          ->result_source->columns_info;
        $json_columns_for->{$schema_class}
          = [ grep { 'json' eq $columns->{$_}{data_type} } keys %$columns ];
    }
    return $json_columns_for->{$schema_class};
}

But what's terribly frustrating to many devs is getting DBIx::Class to show the queries it's executing, along with the bind parameters (one without the other is often useless).

Tau Station Updates

I haven't blogged lately because of ridiculous amounts of work on the Tau Station MMORPG (the game formerly known as Veure and written almost entirely in Perl). I had reluctantly stopped my last contract with ZipRecruiter because of surgery (long story, but not life-threatening) and then experiencing the joy of physiotherapy. Near the end of physio, we decided as a company to make a serious push on Tau Station and bring it to alpha. Here's an update.

wallpaper mockup of Tau Station art

Announcing Veure at The Perl Conference

I'm back from Romania and had a lovely time at YAPC::EU, er, The European Perl Conference, er, or this:

I unveiled that suggested logo at my opening keynote only to discover that many Perl devs had no idea what I was talking about. My sense of humor is shouting "get off my lawn."

However, I gave a lightning talk announcing Veure, including the game's name and blog! Veure is officially known as Tau Station and sign up for our newsletter to find out more, including keeping up with the alpha. Or just read our blog to see what's happening with it (but you really want to sign up for that newsletter).

Many thanks to Evozon for hosting a great conference!

Veure's Database

I recently wrote about Veure's test suite and today I'll write a bit about how we manage our database. Sadly, this will be a long post because it's a complicated problem and there's a lot to discuss.

When I first started Veure, I used SQLite to prototype, but it's so incredibly limited that I quickly switched to Postgres. It's been a critically important decision, but I want to take a moment to explain why.

All software effectively has four "phases" which amount to:

  1. Initialization
  2. Input
  3. Calculation
  4. Output

Note that we could rewrite the above as:

  1. Initialization of data
  2. Input of data
  3. Calculation of data
  4. Output of data

Notice a pattern?

Yeah, I thought so. There are all sorts of areas where we could get things wrong in software, but the further down the stack(s) you go, the more care you need to take because the more damaging bugs can be. Data storage is often pretty low in your stack and you don't want to get this wrong. So what happens?

Why I try to avoid Perl's punctuation variables

Over on Perlmonks I wrote that you should probably use this:

say join '', @array[2,4];

Instead of this:

local $" = '';
say "@array[2,4]";

And my reasoning being:

Why is that better? Because nobody knows what $" is, but everyone knows what join() is. Always write your software to be as readable as possible :)

I received a couple of upset replies along the lines of "Perl devs should be allowed to write Perl!" While I generally agree with that sentiment -- I had no problem with the array slice, for example -- I think the replies came, in part, because I had answered too quickly. I clarified what I meant, but I thought I should explain it here, too, because too many people reach for those punctuation variables.

Veure's Test Suite

We're still hacking away on the Veure MMORPG and things are moving forward nicely, but I thought some folks would like to hear more about our development process. This post is about our test suite. I'd love to hear how it compares to yours.

Here's the full output:

$ prove -l t
t/001sanity.t ... ok   
t/perlcritic.t .. ok     
t/sqitch.t ...... ok     
t/tcm.t ......... ok       
All tests successful.
Files=4, Tests=740, 654 wallclock secs ( 1.57 usr  0.20 sys + 742.40 cusr 15.79 csys = 759.96 CPU)
Result: PASS

Let's break that down so you can see what we've set up. You'll note that what we've built strongly follows my Zen of Application Test Suites recommendations.

The Ovidian Update

Haven't posted anything for a while, but I'm not dead, just busy. Here's a quick recap of things that I think people might find of interest.

Send In The Clones (click for larger version)

First and foremost, I'm going to be in Brussels, Belgium, next weekend for FOSDEM. If you can make it, check out the Perl track. I'll be speaking about why people are finding Perl 6 so exciting. In particular, ever since the Christmas release, there's been a fair amount of chatter about Perl 6 and I've been paying a lot of attention to people who are looking at it for the first time, without a lot of preconceived notions. The reactions often range from "wow, that's cool", to "oh my goodness, I want that!" What's even more interesting is that they're not focusing on a particular feature (which would be scary as it would pigeonhole Perl 6 as a "niche" language). Instead, plenty of people getting excited about different things which scratch their particular programming fetishes: grammars, gradual typing, concurrency, and so on. It's fun to watch.

But there's more ...

The Veure MMORPG Saga Continues

I'm doing heater runs in Taungoo Station when someone tells me about a problem in Nouveau Limoges, another station in the Sol System. I mosey on down to the port, hop in Serenity, my corvette class spaceship (with some "quiet" modifications), and launch. Serenity's an older ship and she higher maintenance than I would like, but she keeps flying and that's good enough for me.

A little over 7 segments later (a long, boring flight), I arrive at Nouveau Limoges. And that's when the trouble kicks in. You see, I'm a Consortium citizen, but Nouveau Limoges is a Gaul station and I forgot to renew my visa. Immigration computers notice my status and I get auto-deported back to the station I came from: except I am still on Serenity and she doesn't have enough anti-matter reserves to make the flight back. An HTTP redirect loop ensues and ...

I found that bug hilarious and it will be fun to resolve. Sadly, it probably won't be me who fixes it, even though I want to dig in.

Improved DBIx::Class usage with arbitrary SQL

A few months ago I write about using arbitrary SQL to generate DBIx::Class resultsets. These DBIx::Class::Report resultsets are read-only, but I found that I needed to add additional methods to each result and now I can. This makes the software much more flexible.

Testing your sqitch changes

When you work on larger projects, you'll often find that database changes are hard. Multiple developers, working on the same project, changing the same tables, can be difficult. Database migration tools often (but not always), come with one or more standard flaws:

  • Reliance on migration numbers (in other words, two or more developers commit migration number 6 and get a conflict)
  • Reliance on an ORM, such as DBIx::Class (sucks for the Python devs)
  • Reliance on something other than the Data Definition Language, or DDL (sucks when your custom tool can't represent the stored procedure you want to define)

There are plenty of other ways database migration tools fail, but the best standard tool I've worked with so far is sqitch. Its documentation needs some work, including more explanations of how to deal with common failure modes, but it avoids the above problems and provides you with a rich set of tools to make database migrations easier for large teams.

However, its common failure modes include:

  1. Creating a "revert" change that doesn't revert.
  2. "verify" scripts that work now but don't work in the future (for example, when MySQL is changed to "strict" mode)
  3. Hard-to-comprehend error messages about changes not appearing in the plan (usually a merge conflict that can be solved with reverting some changes and re-deploying)

There's work being done on some of these issues, but the first two can be mitigated with a simple test script I wrote.

Veure: Artists and Narrative Designers

This has been a busy week with Veure. As usual, my daily routine is:

  • Wake up
  • Hack a couple of hours on Veure
  • Work for $client
  • Have dinner
  • Optionally hack more on Veure

Hack, in this case, does not simply mean "write code." There are many other things involved, including research, research, and more research. And legal stuff. And writing. And hiring.

Yes, hiring. For example, we think we've found a great artist. If it works out, we can replace my crappy concept art of a space station:

New ships can be done, new background graphics, and so on. In fact, this could turn into a full-time job for him if Veure is successful. But that's not all we're hiring.

Veure: Arbitrary Mission Actions

This little baby makes me very happy:

That is a screenshot from the completion of a level 1 mission "Find Amaidoo's E-slate." The code was painful to integrate, but it makes things like the above simple to do.

Beta Features for Veure

There was positive response to my last entry about Veure, both on the post and in private email, so I'll keep posting.

Currently, we're pushing forward hard to try to get to the alpha release and get playtesters (let me know if you want in on it). Major things we need to finish to get there:

  • More missions and jobs (repeatable missions for lower rewards)
  • Auction Houses
  • Elite-style trading
  • More NPCs
  • More game balancing
  • Some legal stuff (expensive and time-consuming)

There's more we need, but those are the "big" items we need to finish. The content generation is some of the most time-consuming. Plus, I need to do a lot of work to make the mission system manageable for someone who isn't me. Right now it's complex (to put it mildly) and I'm adding a new feature to make it more flexible but which also increases complexity. If we can't have rich, compelling, missions, much of the game falls flat.

How I write custom quests for Veure

Note: If MMORPGs are of interest to you, please read through this and answer the simple questions at the end.

I'm still diligently hacking away at Veure. About a year ago I wrote that I had 17% of the alpha tasks done. Given that I've added a number of alpha tasks (and pushed some back to beta), I'm relatively pleased that as of this writing, I have 81% of the alpha tasks finished, with over 90% of the commits by me. It's daunting single-handedly writing an MMORPG, but we've a developer who's been working on it and will be returning to it in June, so that's going to help. We're also looking at hiring a narrative designer to flesh out content. Writing a game is hard, but filling it with content? Hoo boy! It's the difference between outlining a novel and writing it (well, not exactly, but cut me some slack, eh?).

And that brings me to content. Much of $secret_mmorpg_name (legal stuff, sorry) will be impacted by missions, but what are missions?

Wanna Getta Drink (in Veure)?

So, it turns out that working full time on a great contract, overseeing employees/contractors on other contracts, trying to build an MMORPG, working through legal issues associated with said MMORPG, preparing conference talks, and trying to be a good husband and father is a wee bit time-consuming. That's why I probably didn't answer your email or write a blog post in the past month.

So to let those interested in Veure know that it's not dead: we have bars! (Amongst many other things). Read on!

Building a Thin Controller

I haven't updated about Veure in a while and though this post isn't really about Veure, per se, I'll use some code from it to illustrate a "thin controller."

There's a lot of confusion about the thin controller/fat model advice which gets passed around. In fact, I've seen some developers get upset about the idea, claiming that it's the model which should be as thin as possible. I'll explain what's really going on and give some real-world examples, using code from Veure.

Using Role as Partial Classes

For Veure, my text MMORPG, I found myself worrying about the Character class turning into a god object. At over 2,300 lines, 105 methods, and growing, it was getting hard to keep track of everything. I want my code to be clean and easy to follow. As a result, when new behavior arose, I started thinking of other places to put behavior, and wound up with abominations like this:

if ( $missions->has_misssion_for( $character, $npc ) ) {
    ...
}

If you're not familiar with the terminology, NPC stands for "non player character" and, as you might guess, they're implemented via the same class as player characters. So what does the above code do? Does it mean that your character has a mission for an NPC? Does it mean that an NPC has a mission for your character? Does it mean that your missions have a mission for ... wait, what does that even mean? The last one, though, is the natural reading of the above.

All because I was trying to limit the size of the Character class.

But wait, this is an MMORPG. Your character drives everything. Your character moves. Your character goes on missions. Your character has to interact with their inventory. Your character has to do all sorts of things and artificially shoving those things into different classes just to avoid the "god object" makes for unclear code like the above. However, shoving all of that behavior into the Character class means it's getting huge and unreadable.

Until now.

2  

About Ovid

user-pic Freelance Perl/Testing/Agile consultant and trainer. See http://www.allaroundtheworld.fr/ for our services. If you have a problem with Perl, we will solve it for you. And don't forget to buy my book! http://www.amazon.com/Beginning-Perl-Curtis-Poe/dp/1118013840/