Results tagged “veure”

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.

Stop Putting AUTO_INCREMENT IDs in URLs

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 weworkremotely.com/ (though I suspect it's not something they're worried about).

  1 2 3  

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/