Thursday, 19 March 2009

Moviestorm 1.1.5 delayed

On Tuesday, we told you:
Moviestorm 1.1.5 is now going through its final checks, and, assuming we find no last-minute nasties, should be released in the next couple of days.
Well, guess what? We found last-minute nasties. Big, nasty ones. Like a little bug where rendering a movie is liable to crash your PC. Which it didn't do on Monday, but something we fixed since then seems to have broken everything in a big, big, and very nasty way. And sadly, that's not the only one. So there's no way we can release it as it is.

I'd love to tell you that it'll be fixed next week, but as we told you last week, engineering supremo and Chief Architect of the Virtual Universe Dave Lloyd is going to be in San Francisco, and this one looks like this is going to take his oh-so-special skills to sort out. So the plain truth is that, barring a miracle, 1.1.5 almost certainly won't be out for a couple more weeks. And that means the Criminals pack won't be out either, because it needs the new features in 1.1.5 or it won't work.

We're still hopin' for a miracle...

So, well, I know the current dictum is "never apologise", but, umm, sorry.

But hey - at least we know the guys in QA are doing their jobs!

Tuesday, 17 March 2009

Case swap

It's the classic move from Hustle. One person puts a case down, another picks it up and walks off with it. New animations and assets from the upcoming Criminals pack.

Moviestorm 1.1.5 nearly ready


Wednesday, 11 March 2009

Moviestorm performance

I've recently been examining performance, so maybe it'll help to have an understanding of why Moviestorm is the way it is.

MS is render-bound at the moment. It spends more time drawing than computing other stuff. I'd kind of expect this. I think one of the big differences between MS and a game is that a game can fine-tune the resources it needs for a level offline. For example, it knows ahead of time all the textures it will ever need, and can optimally pack them into texture pages that minimise the transfer of bulk pixel data between system memory and the GPU. In MS, we can't do this because a user can have any number of different objects in any scene potentially containing their own textures. Or as another example, shaders in MS need to be compiled on-the-fly depending on what the precise lighting and material characteristics of the set are, whereas a game can simply pre-compile them all and load them up en masse. So because MS is an "open" system that can't make assumptions about the data that'll be thrown at it, there is a compromise in performance (conversely, games perform fast because they severely restrict the things that can be changed).

I don't think we're bound by poly count. We could probably raise or lower them by some moderate percentage and not see better frame rates. We submit vertices to the GPU through the DMA channels that OpenGL provides us and my impression is that we pack around 10,000 verts into a buffer that could contain 16,000. Coalescing the buffers won't necessarily result in a 60% speed gain because of the need to pack and unpack the streams. Besides I think it's good to have headroom for future expansion - something games are usually less concerned about.

That said, we're well aware of the things we can do to boost performance. On the CPU side we need to get our skeletons working smoothly. We started off using the CAL3D animation package, and I have to say that it has features that both sap performance and make it awkward to work with. Given time and/or an infinite number of helper monkeys I think these things would be done in a jiffy; whilst we're on the hunt for them primates, we're always looking to improve things. Just this week I have implemented a number of speeds-ups in the skeleton code, for example. We're also thinking very hard indeed about how to resolve some of the lumpiness in MS's performance whilst managing the potentially vast open data sets of AddOns.

On the GPU side, that's a bit harder. We need to run a performance anaylser on what the video cards are doing, and that's a specialist skill. Finding someone who can do that professionally has proven to be either tricky (in reality there are few with the skills) or prohibitively expensive. We'd love to get the help of the hardware vendors, but in reality we're probably a little on the small side for them to take notice as of yet. As we grow, I expect that to change. And when it does, chances are we'll be able to quadruple the body counts and perform much more sophisticated lighting calculations, and all the things that games are doing now (though it's worth stressing that not all cards will support such prettiness and we have to keep all our customers happy). In the meantime, it's fair to say that MS performs comparably with competitors such as Antics, which didn't even have lighting and shadows till way late in the game, which was shader-less (their faux shaders simply controlled the OpenGL fixed-function pipeline) and so couldn't do things such as depth-of-field, particle volume renderers, normal maps, depth sprites, and some of the things potentially coming (no promises mind!) such as skylight absorbtion, bloom, and maybe even the deferred rendering technology seen in games such as Killzone.

MS is a rapidly evolving piece of software. We've not been afraid to tear down large chunks of legacy code and replace it with leaner, meaner, prettier - or more robust - variants. This will continue as long as there's breath in us! Though at some point, we're sure things will stabilise a bit, and at that time - bearing in mind the advice of Mr Computer Science himself, Professor Donald Knuth's, advice "never optimise early" - we can start tuning the performance. It's worth saying though that a software engineer typically has a number of criteria the application should satisfy. For example:

* Performance (measured in frame rate)
* Responsiveness (does it do what I want when I want?)
* Stability (how well it performs over a spectrum of hardware)
* Robustness (how often serious problems occur)
* Scalability (how far can it be pushed)
* Extensibility (closed, or degree of openness)
* Security (can it be maliciously hacked?)
* Ease of use

These criteria are generally not independent, and different priorities will be put on them depending on the type of application as we realise they can't all be satisfied simultaneously. Games tend to emphasise the first two, whereas MS has a different set of weightings, and (say) an internet browser will differ to both. I think we've done pretty well thus far, and though of course I'd like to see more bigger faster prettier right here right now, the reality is that we have to wait a while. We're not like a game - we don't release and then forget (admittedly now game developers may release patches to fix their over-hurried engineering hacks and blunders); we promise continual, regular delivery, and improvement with every version. Not bad for a free app, eh?

Tuesday, 10 March 2009

SF in SF

If you're going to GDC09 in San Francisco (March 23-27), the Game Developer's Conference, keep an eye out for Dave, who'll be wandering the halls, searching for interesting people to share a beer with and chat about anything and everything.

Meanwhile, Johnnie and Matt get to go to the annual OCR AS/A Level Media Studies conference in London on March 20, where they will be presenting Moviestorm. You can find out more here and book a place here.

Which means we'll get home in time for a nice cup of tea and a biscuit, while Dave has to spend hours on a plane and hanging around in airports. Oh, the glamour of international travel!

Monday, 9 March 2009

Moviestorm 1.1.5 in test

We've just sent Moviestorm version 1.1.5 over to the QA team, so that Synnah and Dick Swayze can break it before they leave. All being well, it should be ready to ship in a couple of weeks.

Most of this build is fixes to the modders' workshop, and a few minor changes necessary to support the next couple of content packs. When those are nailed down, we can finally get the criminals into QA, and hopefully you'll get them soon as well.

We'll let you know as soon as we get a firm release date.

Wednesday, 4 March 2009

Big Brother IS watching you

Here at Moviestorm Towers, we're always striving for greater realism. And as we stroll innocently through the streets of Cambridge, minding our own business, we can't help noticing the way our benevolent rulers and retail environment owners have placed cameras everywhere to keep us safe from the foul miscreants who would destroy our civilisation. It makes us happy to know that our every action is being watched and recorded so that we can prove our innocence should we need to, and it makes us feel good to know that we are doing our bit to help our heroic law enforcement officials in their fight against terrorrorororrism. And we know you feel the same way too.

So here you go. Security cameras. Moving, blinking, and remembering everything you do, just like the real thing. So no more excuses of "I didn't touch anything, it just crashed." We can see your keyboard, so we know you hit the magic CTRL-ALT-7 combination that causes everything to go slow.* And we can see what you're doing while you wait for your movies to render.

They'll be part of the Criminals pack. Which will be out... altogether now... when it's ready!

*Oh come on, don't tell me you actually tried it, did you? You did? Mwahaha!

Monday, 2 March 2009

I'm bad, I'm bad, you know it, I'm bad

Now that the Streets bundle has, erm, hit the streets, the next pack going into test* is Criminals, who compliment the kindly, friendly, law-abiding policemen in the Law and Order pack. We've shown you a few sneak peeks before, but today, we've got a first look at the new faces.

Now, as everyone knows, bad guys are always disfigured (except when they're suave British villains played by Alan Rickman), so we've introduced some new morphs. Which means you can give your perps broken noses and the like. Cos then everyone will know they're bad.

*When it's ready. Did you really need to ask?