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.

Understanding Behavior Driven Development

I think I'm on the verge of drinking the Cucumber flavored Kool-Aid, which is odd because I've never done Behavior Driven Development (BDD) before. If you've followed my blogs over the years, you know that I am happy to investigate new trends, but at the same time I'm deeply, deeply suspicious of them. BDD has been one of those "fads" that I've been suspicious of, but I think I've changed my mind. What follows is why.

Sometimes Agile Can Hurt Your Company

I've been rather quiet lately because I'm busy, busy, busy. Part of this is contract work for a company (amongst other things, I've been doing building sqitch setup for them), and part of this is new research into Agile. Today I wrote a quick blog post explaining one of my pet peeves about Agile: people say it's not a silver bullet, but they don't say why. I briefly explain when you should and should not use Agile.

Quacks who write software make us all look bad

By now I'm sure that many of you have read about the research which claims that people aren't smart enough for Democracy to flourish. This was big news and made the rounds (including here on Reddit). The main researchers listed were Dunning and Kruger and I don't think anyone disputes their credentials.

Except that this is a science article, not a link to the actual research. In particular, I was intrigued by this by a reference to a software simulation validating their results. That piqued my curiosity.

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/