Results tagged “veure”

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.


Recently someone posted about an online job:

Well, that looks interesting, except that what interested me wasn't the job, it was the information the ID tells us about (though I suspect it's not something they're worried about).

Veure Update: Missions

Just a quick update for those who are following the progress of Veure. Here's the current character stats page.

That's just a hint of some of what's new.

Legal Issues in Game Software Creation

Note: I am not a lawyer and the following should not be considered legal advice. Double-check everything and hire a lawyer.

As I continue to work on Veure, I have the added fun of less time spent working on it while I try to understand the legal problems. If you're going to create and publish your own game, you'll invariably hit legal issues. What's worse, you might discuss them publicly and some bright spark will vaguely remember an online article, dumbed down for mass consumption, regarding a complicated libel lawsuit for the print industry and swear up and down that it applies to you. They won't supply a link.

In fact, software games seem to have some peculiar legal issues all their own, compounded by the fact that they're often indie games created by hyper-intelligent, well-read individuals who either don't think of legal issues or assume they already understand them. On the off chance that they're right about a given issue, there's also one tiny detail they often overlook.

Veure Update

Just in case you're curious, I'm still hacking on Veure, though the last month has kept me busy on a bunch of other things (our daughter just started school, so that's a big one!)

I've been building so much of the infrastructure that you might be surprised to realize that I've only just gotten around to being able to equip weapons and armor:

My last entry gives some hints on how this works.

The other developer has been working on the cockpit view. If you travel from system to system in your own ship, the experience should be different than if you take public shuttles. I haven't actually seen his work yet, so no screenshot on that one.

Update: OK, I have some of the initial screenshots for the cockpit work. They look great, but not sharing until some things are settled.

Creating an MMORPG in Perl

Question: do you want to hear more about my attempts to create an MMORPG in Perl, even if posts are not Perl-related? Also, are you interested in helping me develop its ideas further?

As many of you know, I'm trying to create an MMORPG running on Perl. It's codenamed veure. Though I've written about it a few times here, I've not written much because many of the entries are about game design and not strictly about Perl. As a result, I've tried to avoid spamming this blog. That being said, people constantly say "stop talking about how great Perl is and build great things with it!" So I'm trying to build something great with Perl, but as most experienced programmers know, it's not so much the programming language as the business rules which are important.

And damn, business rules in an MMORPG are hard.


About Ovid

user-pic Freelance Perl/Testing/Agile consultant and trainer. See for our services. If you have a problem with Perl, we will solve it for you. And don't forget to buy my book!