[09:33:23] Julian Gold says: http://news.bbc.co.uk/1/hi/technology/6225286.stm
[09:34:13] Julian Gold says: (Pretentious, moi?)
[09:46:04] Chris Ollis says: you could argue that yes it was a "fine piece of art" being a creatively constructed medium designed to make people think and react emotionally. But it doesn't stop it being wrong. When will the human race stop doing things without questioning if it should?!
We had a very similar game almost made while I was at Codies called "Drive by", I refused to work on it. It eventually got canned.
[09:58:05] tom kelly says: one of the advantages of educating people should be to be able to avoid censorship
[10:13:44] Julian Gold says: it would probably be a good thing to start educating people then (wait)
[10:13:59] Julian Gold says: (oh the satire!_
[10:14:07] tom kelly says: lol
[10:14:09] Chris Ollis says: But if everyone was educated then no one would buy these games!
[10:17:40] david j bailey says: have a look at the titles on sale in WH Smith on the /book/ shelves. Pure filth, evil, sadistic, violence, sex, etc. We do not censor books, why do we censor images?
[10:18:27] tom kelly says: because 4 year olds don't know the word biestiality and it'd be nice to keep it that way
[10:18:37] david j bailey says: nor does the OED ....
[10:18:39] Julian Gold says: they are different media: books require mental image construction whereas pictures don't - they therefore exercise different parts of the brain
[10:19:43] Julian Gold says: (that's not an a priori argument for censorship; merely a conditioner for the rationale that they should be considered separately)
[10:20:38] Matt Kelland says: The book/film censorship argument has been raging for about a century - as has the fine art/photography argument. It boils down to "books & fine art are for the literati, so they can handle nudity etc, films & photographs are for the hoi polloi who need to be protected."
[10:22:20] Julian Gold says: the problem with that is that there are more "hoi polloi" than "literati" and therefore we'd expect a greater number of extreme behaviours at the ends of the bell curve
[10:23:08] Julian Gold says: IOW in no way does it address the issue "what psychological effects do media have on us and is there a motivation for addressing it at policy level?"
[10:25:27] Julian Gold says: I always wonder: what would happen IF tomorrow a study categorically demonstrated that (say) video games were harmful beyond all reasonable doubt? Would we accept it, or try to rationalise it away? It's characteristic of humans to treat evidence that supports their own predilections more favourably than that against. This is the problem with self-regulation.
[10:27:09] Ben Sanders says: studies dont demonstrate things beyond all reasonable doubt
[10:27:27] tom kelly says: i think that was the point
[10:27:28] Julian Gold says: you're missing the 'IF'
[10:27:32] Ben Sanders says: and people dont stop smoking just cause it is harmfull (well, some do, but...)
[10:27:38] Chris Ollis says: and you can prove anything with the right facts ;)
[10:27:42] tom kelly says: it's a question of risk perception - we see less risk in situations we control.
[10:30:02] Julian Gold says: studies are based upon probabilistic methodologies. "Beyond reasonable doubt" could simply be that the hypothesis sits in the 95% confidence interval
[10:32:48] Matt Kelland says: New Sci a couple of weeks ago reported on some very in-depth studies which all suggest that watching violent TV does have an effect on kids. More importantly, though, they continued with a further set of studies that showed how different groups of people react to such studies - basically, we simply do not want to accept those findings.
[10:34:11] Matt Kelland says: Advertisers are quite happy to accept that showing their products on TV does influence people to buy them, and showing their products in a negative light may prejudice people against them; but they're not prepared to accept that viewing other forms of content has an equivalent effect. Humans are very good at rationalising contradictions.
[10:34:39] Ben Sanders says: doing stufies that result in an obvious conclusion are not going to affect people who were ignoring the obvious conclusion anyway
[10:35:01] Julian Gold says: which is precisely the motivation for censorship
[10:35:41] Matt Kelland says: No - the motivation for censorship is to ensure conformity to social norms.
[10:36:27] Julian Gold says: well maybe: but IMHO it's a better motivation for censorship (which generally I do not support)
[10:36:44] tom kelly says: scary media is scary. we are hard wired as social animals to protect those we see as vulnerable from scary stuff. problem is - as arrogant monkeys we all see many others as inferior and vulnerable.
[10:56:43] tom kelly says: does anyone mind if paste the last hour of the chat to the company blog?
Thursday, 21 June 2007
Moviestorm private beta closes
Whew. It all feels rather different in the Moviestorm mansion today. It's not just that we've opened all the windows and let some fresh air in. There's an indefinable change in the atmosphere as we move into the fourth stage of development, slightly subdued, with an undercurrent of anticipation, and everyone intently hunched over their keyboards dotting i's, crossing t's, or huddled in corners niggling away at little details, and checking off tiny but vital tasks against a huge "to do" list.
Once upon a time, what feels like many, many years ago, Moviestorm was just a germ of an idea, with two of us bashing out bits of tech demos to experiment with different ways of making machinima, and raise the money to make a real go of it.
Then, in November 2005, we hired a few staff, made ourselves into a real company, and started building the damn thing for real, and got Moviestorm (or Machinimascope, as we called it back then) to the point where we had the bare bones of a new type of movie-making tool.
Last Christmas, we moved into stage three, and started getting real users involved, even though Moviestorm was nowhere near finished, and, to be quite honest, wasn't even really ready to go out the door. We jumped from six people to twelve full-time staff plus a load of freelancers, got ourselves an office, and went from having just a few bits of test artwork we'd produced in-house to commissioning loads of art from studios in India and the Ukraine. It's been a really intense six months, and Moviestorm has changed completely in that time: we've developed features we didn't think were important, because our beta testers said they wanted them; we've dropped features we liked because our beta testers said they didn't need or didn't like them; we've completely redesigned the user interface; we now have literally thousands of new characters, models and animations; and so on. On top of that, we've built a community Web site, a place to host movies, and an online distribution and update system. And last, but absolutely by no means least, we now have a fantastic community of 700+ users from all round the world, who have provided us in equal measure with tough love and praise, and who have created some really surprising test movies which have pushed Moviestorm into some unexpected directions. We've taken input from professional film-makers, from complete novices, from experienced machinimators, from kids, from housewives - well, from absolutely anybody we possibly could. Moviestorm's still not finished, of course. In all likelihood it never will be. There's so much we want to do with it, and new ideas are presenting themselves every single day. But it's now feeling like we have a proper movie-making tool at last.
So now it's time to kick things up a gear again and move into the fourth stage. We're currently wrapping everything up for our imminent public beta release, at which time anyone in the world will be able to come along and grab themselves a copy of Moviestorm. That's going to present us with a whole new set of challenges. We need to make sure we're ready to respond to the needs, queries, demands, and problems of a much larger user group, which means providing new infrastructure, new in-house processes and systems, and understanding that we're dealing with a slightly different type of user. It won't go 100% smoothly, of course. It never does. But at least we should be prepared to deal with whatever spanners get thrown in the works.
We've now closed the private beta program, so we're not taking on any new users for the time being. But we will be open again very shortly - and we're all waiting to see what happens!
Once upon a time, what feels like many, many years ago, Moviestorm was just a germ of an idea, with two of us bashing out bits of tech demos to experiment with different ways of making machinima, and raise the money to make a real go of it.
Then, in November 2005, we hired a few staff, made ourselves into a real company, and started building the damn thing for real, and got Moviestorm (or Machinimascope, as we called it back then) to the point where we had the bare bones of a new type of movie-making tool.
Last Christmas, we moved into stage three, and started getting real users involved, even though Moviestorm was nowhere near finished, and, to be quite honest, wasn't even really ready to go out the door. We jumped from six people to twelve full-time staff plus a load of freelancers, got ourselves an office, and went from having just a few bits of test artwork we'd produced in-house to commissioning loads of art from studios in India and the Ukraine. It's been a really intense six months, and Moviestorm has changed completely in that time: we've developed features we didn't think were important, because our beta testers said they wanted them; we've dropped features we liked because our beta testers said they didn't need or didn't like them; we've completely redesigned the user interface; we now have literally thousands of new characters, models and animations; and so on. On top of that, we've built a community Web site, a place to host movies, and an online distribution and update system. And last, but absolutely by no means least, we now have a fantastic community of 700+ users from all round the world, who have provided us in equal measure with tough love and praise, and who have created some really surprising test movies which have pushed Moviestorm into some unexpected directions. We've taken input from professional film-makers, from complete novices, from experienced machinimators, from kids, from housewives - well, from absolutely anybody we possibly could. Moviestorm's still not finished, of course. In all likelihood it never will be. There's so much we want to do with it, and new ideas are presenting themselves every single day. But it's now feeling like we have a proper movie-making tool at last.
So now it's time to kick things up a gear again and move into the fourth stage. We're currently wrapping everything up for our imminent public beta release, at which time anyone in the world will be able to come along and grab themselves a copy of Moviestorm. That's going to present us with a whole new set of challenges. We need to make sure we're ready to respond to the needs, queries, demands, and problems of a much larger user group, which means providing new infrastructure, new in-house processes and systems, and understanding that we're dealing with a slightly different type of user. It won't go 100% smoothly, of course. It never does. But at least we should be prepared to deal with whatever spanners get thrown in the works.
We've now closed the private beta program, so we're not taking on any new users for the time being. But we will be open again very shortly - and we're all waiting to see what happens!
Thursday, 14 June 2007
Testing on a shortfuze
There wasn't much activity on the blog, so I'm borrowing for a little while it to add some development details of how we're building 'storm.
Standard software development calls for a large suite of test cases as you're programming. The idea is that you write the tests for whatever you're going to build, then build it and check it passes the tests. The many benefits of this technique include:
The problem lies in the fact that it is very difficult to unit test a mostly visual medium. Does the character look right? Is she triangulated nicely? Do the buttons line up? What happens when you move the mouse slightly while clicking a button, do the characters shatter when you drag the window around the desktop?.
Standard agile practice would have us adding a unit test for each instance, there are techniques that we can use for this - the java.awt.Robot takes you so far - you can automagically move the mouse to a location and click, or check the colour at a location. But it becomes very fragile - if a button moves location or the artists change the skin tone you "red line" on the tests. Keeping in the green takes an intolerable quantity of time, compared to eye-balling the output as you go.
What are we doing at the moment? We've got a really really fast turn around between the programmers (~minutes) - "you forgot to add that jar to the build paths". Then there's a quick turn around between the QA guys and the programmers (~hours) - "I can't save my movie". We've got a slightly longer turn (~days) around between the QA guys and the in house machinimators (product users) - "My video file has more artefacts than it did". And we've got ~weeks between QA and our cutting edge beta testers - "you can't save the movie when you try to open door #23 on a tuesday". Each layer removes some of the problems and the most annoying problems are flattened first.
It's not a textbook operation, but with a small team it works surprisingly well.
Standard software development calls for a large suite of test cases as you're programming. The idea is that you write the tests for whatever you're going to build, then build it and check it passes the tests. The many benefits of this technique include:
- If someone else plays with your code they have more of an idea as to what the outcome should be.
- When something just won't work, running all the tests can highlight where the issues lie.
- you can automate tests so people get annoying emails if the code the checked in doesn't pass all the tests.
- It forces developers really understand what you're doing before you start coding.
The problem lies in the fact that it is very difficult to unit test a mostly visual medium. Does the character look right? Is she triangulated nicely? Do the buttons line up? What happens when you move the mouse slightly while clicking a button, do the characters shatter when you drag the window around the desktop?.
Standard agile practice would have us adding a unit test for each instance, there are techniques that we can use for this - the java.awt.Robot takes you so far - you can automagically move the mouse to a location and click, or check the colour at a location. But it becomes very fragile - if a button moves location or the artists change the skin tone you "red line" on the tests. Keeping in the green takes an intolerable quantity of time, compared to eye-balling the output as you go.
What are we doing at the moment? We've got a really really fast turn around between the programmers (~minutes) - "you forgot to add that jar to the build paths". Then there's a quick turn around between the QA guys and the programmers (~hours) - "I can't save my movie". We've got a slightly longer turn (~days) around between the QA guys and the in house machinimators (product users) - "My video file has more artefacts than it did". And we've got ~weeks between QA and our cutting edge beta testers - "you can't save the movie when you try to open door #23 on a tuesday". Each layer removes some of the problems and the most annoying problems are flattened first.
It's not a textbook operation, but with a small team it works surprisingly well.
Subscribe to:
Posts (Atom)