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.

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.

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 ...

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.

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.

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.

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.

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.

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.

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?

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!