Selling your stuff

Right back in the early days of Moviestorm, back when it was called Machinemascope (yes, it was spelled like that), and existed only in the minds of Dave and myself, we realised that in order to be successful, we'd need to allow modders to make and distribute content. Not only that, but we'd actually benefit from allowing modders to sell content. The reasoning was quite simple. We cannot possibly make all the content required to make the movie in your head. That would require us to make every costume ever worn, anywhere in the world, at any time in history. Not to mention every costume you've seen in a movie, or in a picture, or in a comic book, or in a game, or in some strange fever dream. And then we'd need to start on props, sets, faces, hairstyles, critters, vehicles and everything else. And you'd want them in a range of styles: some hyper-realistic, some exaggerated and cartoony... basically we'd have to model the entire universe, including the bits that haven't happened yet, as well as a load of universes that don't exist. It's just not going to happen, not even if we had a thousand artists.

Instead, we opted for making the basics, and making our stuff as customisable as possible, and in due course, you guys will make the rest. This, of course, is where the modder's marketplace comes in.

Easy, so we thought. We make a site, you upload stuff, we take people's money on your behalf, we take a cut, and everybody wins. Except it's not that straightforward. This is where everyone jumps up and says, "yes it is, look at XXXX.com". Well, you're probably wrong. Unless you're a lawyer, you probably have no idea how tangled the law is in this regard. In fact, even if you are a specialist international IP/tax/commercial lawyer/accountant, you'll have problems making sense of the legislation. Bear in mind, since we're operating a global business, we're talking about transactions for virtual goods that may involve people and companies from several different jurisdictions. That immediately complicates everything. And just because XXXX.com is doing it doesn't mean it's legal, and we don't want to find ourselves sued or shut down.

Here are a few things we're having to bear in mind.

• You upload a mod. The customer pays us. Who are they buying from? Us or you? That makes an immediate difference. If it's us, then as the vendor, we have a bunch of responsibilities under EU and UK law, and a different bunch of responsibilities under US law (and who knows what under Australian, Brazilian, Chinese or Indian law). If it's you, then we have to make you aware of those. In many ways, resolving this one issue clarifies a lot of the rest of the issues, in that we can then say categorically "it's our problem" or "talk to the modder". However, it's not even clear how the law stands on this, and whether we can easily assign the role of vendor. It's likely that we have to be the vendor, and that we would have to require to to sign a warranty which allows us to come after you if anyone has a go at us. This, of course, then begs the question of what happens if you weren't entitled to sign that warranty (say, you're a minor). And, indeed, what happens when we get sued for squillions but you only have six bucks and a Gnarls Barkley CD to your name.
• Your mod causes Moviestorm (or the user's computer) to crash. How do we deal with the irate customer? Who's going to sort him out? Should we require all mods to go through our QA and be certified? If so, are you prepared to pay for it?
• Your mod isn't what it claims to be, or doesn't work. How does the customer complain, and how does he get his money back? If we've already given you your money, how do we get money back from you?
• Our server goes down and we can't sell anything for a while. So what? Well, if you're doing this as a business, then this is affecting your trade. Can you sue us? Are you expecting a guaranteed level of service?
• Tax - what taxes apply? Applying VAT (or not) is complicated enough, but we need to figure out what we have to report to the tax office. And if you're the vendor, then you may have to charge local taxes, which we don't know about.
• How do we apply special offers to a mixture of our content and yours? If someone has a "buy one get one free" offer, and they get yours free, do you get any money at all? Or are mods excluded from special offers? In fact, is 3rd party content treated completely separately?
• Your mod infringes someone's copyright. How does the rights holder deal with this? How do we avoid being sued? How do we allow you to respond to allegations? Do we have final say?
• Your mod has a different license to ours. Our content is licensed for people to use in commercial productions. You can mash it up with footage from other sources. You, on the other hand, may want yours to be non-commercial. Can you do that? If so, how do we make that clear to the user.
• Your mod contains content that is offensive to some people. What mechanisms do we have in place to address this? Is it up to us to decide what gets sold through our site, and if so, do we have to vet everything before it goes up, or only respond when someone complains? What standards do we need to put in place?
• Your mod contains content that is age-restricted in some countries. How do we ensure we comply with local legislation, and what legislation applies anyway? Do we have to be aware of what restrictions exist everywhere?
• Taking the above to extremes, your mod contains illegal content. (This is the really tricky one.) Does that mean illegal where you are, illegal where we are, illegal where the servers are, or illegal where the user is? How are we supposed to know what's legal? How are you supposed to know? What jurisdictions can you be sued in?

Let's take an example. A few years ago, at a previous company, we made a mobile phone game that contained an image of a Nazi soldier with a swastika on his helmet, and sold it to a major global telecoms company. They distributed it throughout Europe. We then discovered that images of swastikas are banned in Gemany, and we had in fact just broken the law without knowing it. Fortunately, we were able to change the image before we got taken to court in Germany, along with the telecoms company, and we managed to talk them out of what could have been a very nasty breach of warranty. (We had had to state that the content was legal, which, in the UK, it was.)

On a similar note, while watching Burn After Reading, I noted that Americans use the word "spook" to mean a spy, and asked why the British TV series Spooks was renamed MI5 for the US market. I wasn't aware that it was an offensive slang term for a black person in the US.

In other words, there are a whole bunch of issues where you can act in complete good faith, and find yourself in an unexpected and tricky situation. The law's a minefield, and so we're treading carefully through it. Yes, it's frustrating. We'd love to have had the modder's marketplace up and running a year or more ago, but until we get the OK from the lawyers and accountants, we're not prepared to take the risk.

But be assured, we are working on it.

Get used to dissipatement

Sometimes it's the small things that make the difference. Take a look at this:

That's not a clever blend of several different renders. That's pure Moviestorm, generated in a single take from one scene. We now have the ability to make objects disappear (and reappear) during the course of a movie. This is the sort of thing that you might not immediately see a use for. The longer you have it in your arsenal, though, the more useful it begins to appear.

All I've done here is set up two barrels, one on top of the other. The burnt barrel is hidden at the start, with the rusted barrel visible. I use the show/hide functionality on both objects, using the explosion to cover the transition. Silly, yes, but fun and potentially very useful.

This new bit of functionality is already working in our current development code. Hopefully, we'll be able to ship it to you as part of Moviestorm version 1.1.7. As always, our usual get-out-of-jail-free disclaimers apply, but I'm reasonably confident about this one.

Incidentally, version 1.1.7 is shaping up to be a massive release. It's straining at the seams with tasty good stuff. I think it's our most exciting release for a long time.

Moviestorm 1.1.6.2 imminent

We're just in the process of assembling patch release 1.1.6.2. Code's all written, and we're now going through all the usual deployment procedures.

It's not a big release: in fact, it only contains one bug fix, but we decided it was worth while shipping this to you, as it's quite a nasty one.

As reported in the forums, canceling a render causes Moviestorm to crash, potentially leaving a movie unsaved. This was introduced in 1.1.6.1, released on July 10, when we changed how sound worked during rendering (to fix some other problems), and accidentally introduced this bug by failing to move all the necessary logic to the right place.

We'll get this out as soon as we can.

If you want something doing ... give it to Rhys

Software engineering is a weird thing. Even though the code language and libraries are usually well-established, on anything but the smallest of projects you'll find the need to write your own custom components, which you'll then use to construct something useful. Sometimes, you see, before you can get to work on the thing you really want to do, you have to spend some time making the tools that you'll then use to make the thing you really want to make. If you see what I mean. It's as if an archaeologist were required to make his own brush and trowel before he could start excavating, or a fisherman had to build her own rod. So software engineers would have us believe, anyway.

The Moviestorm Modders Workshop is a good example of this. Although it's enabled many of our users to create some fantastic addons for Moviestorm, the primary reason it exists in the first place is because we needed a tool to assemble all our art assets into something that Moviestorm could actually understand. The Modders Workshop is the tool that we use internally to build all of our Content Packs.

We recently managed to drag Dave away from working on his exciting new asset management system for Moviestorm 1.1.7, in order to produce this:



No, not the shed. The little pop-up window in front of it. It's a small addition to the Modders Workshop, but one which makes our life a lot easier. The thumbnails that appear in the Set Workshop Object Browser for each set object are automatically generated when the object is saved in the Modders Workshop. Dave's new tool enables us to pick the rotation, angle and zoom of the object in these thumbnails. That means that we create much better, more logical thumbnails for each object.

Of course, that means we'll have to go through our entire back catalogue of tables, chairs, doors, rugs, mugs, cars, trees ... everything. Every single asset needs a new thumbnail. It's going to be a tedious and time-consuming job. It's not a job I want, I don't mind admitting. What we need is a lackey of some kind. If only there was someone in the office to whom we could give all the boring and mind-numbing jobs that nobody else wants to do .... wait a minute!

Hooray! Rhys is back!

Yes, undeterred by his experience as my personal slave for a week of work experience last May, Rhys has returned for a whole month of work in the QA department. Maintaining the proud tradition we've established for all our interns, he's got the boring job. Today is his last day with us, but you'll be seeing the fruits of his labour in a future release of Moviestorm.

Problems with Moviestorm & nVidia card drivers

Important information for users with nVidia graphics cards - We recommend against upgrading your drivers

During our regular QA testing recently, we've found significant problems when running Moviestorm using a specific set of nVidia graphics drivers: version 190.38. These drivers were released on July 21st 2009 and are the most current nVidia drivers at the time of writing (August 2009).

We strongly recommend against upgrading your drivers to version 190.38.

Problems caused by use of these drivers include:

• Character models deforming and warping during scene playback
• Particle emitters (fireplaces, special effects, etc) not working at all
• Terrain bowl around the set displaying as black

These problems seem to particularly affect graphics cards in the nVidia 8 series, but may also affect 7-series and 9-series cards. Disabling "hardware skinning" in Moviestorm's graphics settings tab can partially, but not completely, alleviate these problems.

We'll try to keep you all updated with any further news (you might want to bookmark this thread) but for the time being, avoid these drivers if you possibly can. If you're looking for previously-released nVidia drivers, nVidia keep an archive of old drivers here.

More information about the 190.38 release on nVidia's forums.

Dis-Tressed

Well, wouldn't ya know it? The hairstyles packs were all ready to roll, and then Ben comes back from holiday, takes one look at them, and finds three issues that need fixing. So after a some soul-searching, discussion, and banging of heads on desks, we decided to hold them for another week and do them properly. The upside to this is that we can also sneak in a few more things that we were reluctantly going to leave out, so it's not all bad.

That's what QA is for, after all.


The thing is, it'll only take a couple of days to fix the problem, but we have a pretty cast-iron rule round here. Never release on Fridays or Mondays. That's a rule born of painful experience. Friday releases almost always mean "c'mon, guys, just get it out of the door and then we can all go home," rapidly followed by "oops, there's a serious problem, and nobody's around to take a look at it for three days." Monday releases almost always mean, "let's shove this out first thing and then chalk up an instant win," rapidly followed by "we did go through the whole release checklist, didn't we? errr...."

Then we get to the corollary of that rule. Don't release on Thursdays unless you're sure it's going to work. Because then when there's a problem, you have to fix it on Friday, which leads to the Friday Release Syndrome, and a good chance you'll rush the fix and get it wrong.

So that's why we try to go for Wednesday releases. We have time to check everything properly at the start of the week, and time to fix it if we screwed something up. Which means that you'll have to wait for next week for the hairstyles.

But we'll tease you a bit in the meantime. We know you love it when we do that. All the screenshots are ready, so we'll post those on the main blog and make you drool. Just a little bit. We wouldn't want you messing up your keyboards.

Pimpin' Conor's Ride

It all started as an innocent prank. Conor left his precious car unattended in the car park and forgot to switch on the CCTV linked to his desktop, and so one lunchtime, we decided to grab ourselves some free advertising space...


In revenge, Conor grabbed a spray can and did a Very Bad Thing to Rhys's shiny new wheels. (Yeah, we know he's only 15 and isn't allowed to drive, but he decided to splash his first week's pay on something spectacular. There's nothing stopping you owning a car at 15. He just has to get someone else to chauffeur it for him. There's a rota in the kitchen for whose turn it is to drive Rhys home each evening. I think we must be overpaying him. Mark and Jules couldn't afford one of these until their second week. But then again, they have kids & mortgages, so maybe it does make sense.)


OK, so that was it, we thought. But no. Rhys just had to go one step too far...

Where do you start?

Occasionally, the company Skype logs reveal an insight into the way the dev team approach problems. Here's an extract from earlier today where they get to grips with an apparently simple and straightforward feature request.

Dave Holloway: Can a movie scene be saved so when it opens, the view is something other than default?

Dave Lloyd: No. Any suggestions for what you want? We did think about opening a movie where you last were - trad Apple HCI rules

Dave Holloway: Yeah, that kind of thing. So where I save, is where it opens again. In the grand scheme this might not be so useful(?) but that's the sort of thing I was looking for in this instance.

Rhys: personally, I prefer opening up in a default location. Makes it feel cleaner. Opening up where you last were seems like a good idea in theory, but I think it would just be better if you think upon loading, "OK, that’s fine, cameras still work, ah yes, editing," because most people don’t save and reload like we do for QA.

Johnnie Ingram: Another possibility is that, when you open a previously-saved movie, you get some sort of pop-up menu asking you to pick an intial View.

Amos Willbond: That would add another step to the process of opening your project... being devil's advocate!

Johnnie Ingram: Yeah, I agree. Not saying it's the right idea! :)

Dave Holloway: Yeah, was about to put what Amos put... nice feature, if it DID go in (and I'm not advocating this as a feature, just for something else) I'd have it as a toggle or something.

Dave Lloyd: Yep - decision point is too early.

Rhys: I think just being put back in a default location tells the brain to re-initialise (I don’t know what the right word would be), which is a good thing, because, for example, in Photoshop, if you close it, it doesn’t re-open with your last project with the filters menu open, it makes a clean slate, just showing you what is happening. If that makes any sense whatsoever

Dave Lloyd: There's a big divide between "where you last were" and "always at the beginning". My current inclination is actually to go straight to the Cutting Room as that is becoming the control hub for the movie as a whole

Johnnie Ingram: cutting room as the hub - yes!

Rhys: perhaps on the Load Movie screen, you could highlight the movie, and on the right of the screen there would be a "Load movie at: Default, last save, SW, CV, DV, CWV, CR, PV" menu, with a checkbox next to it, with Default auto-checked (and you could set your own default).

Dave Lloyd: Too much upfront - it doesn't take long to navigate from anywhere in MS to where you want to go.

Rhys: I guess. But a user-defined default would be handy.

Dave Lloyd: Yeah, we need to do more with the interface settings to customise for preferences.

Amos Willbond: If it's any contribution, all 3D programs remember the position of the non-keyable camera views upon reloading your project.

Dave Lloyd: So, Director's View per scene?

Amos Willbond: Yes, that’s essentially what they do...

It's so often the case that something that seems obvious isn't, and there are several ways of doing it, all of which are right for different reasons. Whichever we go for will have disadvantages. And while we could make everything customizable, that means more for us to code and test, and more for our users to set up. And, in my experience, you can never set it up right anyway. On something like starting view, if I set it to ask me every time, I'd get annoyed that it didn't know where I wanted to be, but if I set it to default to a particular view, I'd get annoyed when it sent me to the wrong one.

My favorite bugbear is whether to pick the set or the characters first. I've used Moviestorm both ways, and they're both wrong at different times. Sometimes you want one, sometimes another. And sometimes I want to pick the music first, or write the script first... sometimes there's no definitively right answer - it's enough to drive a dev team crazy!