Recently someone posted about an online job:

Did u know I'm actively hiring experienced web developers to work remotely? https://t.co/krb5gep8V7 #rails #nodejs #angularjs #plsRT

— Obie (@obie) November 4, 2014

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

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.

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.

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.

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.

Yes, it's another post about Veure (whose actual name we might finally have chosen, but that's another story), the MMORPG that I've been writing.

There are 117 stars in a 20 light year radius around Sol. There are 544 space stations and currently there are 3,080 rooms in those stations (and that number is growing). That means there's a lot of area, but how do I fill that area? There's a lot of work still left to be done, but I took a quick stab at implementing a procedural mission generator as described in this paper. Surprisingly, the core of the code only took about an hour to write.

Did you know you can write a view in DBIx::Class? The DBIx::Class::ResultSource::View module makes this very easy and it's helped me solve a very thorny problem in Veure: how do I efficiently make sure that email sent from Alpha Centauri to Epsilon Eridani doesn't show up instantly in your inbox?

Often we hear people talk about making your programming more "data-driven". When you can convert procedural code to a data structure (generally with a small procedural driver), instead of replicating procedural code, you just add another entry to your data structure. This is great with dispatch tables, repetitive chunks of code and state machines. However, there is a hidden benefit of it which will not only make you a better programmer, but it will make later maintenance programmers fail to notice a common flaw that your code lacks. They'll curse you if you have the flaw, but if you don't have it, they'll find that data-driven sections of your code are so easy to work with that they won't even think about it.

On my personal blog I wrote about Veure, an MMORPG that I'm writing in Perl. I followed that up with a post about the roadmap to an invite-only alpha. It's a lot of work, but my company has now decided to commit to it and figure out how to finance the work. This browser game is huge in intended scope, but fortunately, Perl has given me the power to get much of it done quickly. In fact, according to my private Veure github repo, I now have 17% of the ALPHA tasks done. That's up from 0% when I posted the roadmap a little over a week ago. In short, progress is fast.

Currently I'm working on character combat and that's where custom DBIx::Class resultsets have made my life easier.

Some of you may remember me talking quite a bit about Veure a few years ago when I was living in Amsterdam. I never discussed on the Web what it was about.

Now it's time to fess up, but I've posted the story of Veure to my personal blog instead of blogs.perl.org because it's not really about Perl (and blogs.perl.org kinda struggles with images). Veure was/is a Perl-based MMORPG. It's not done, but I included a few screenshots.