specialmoves: "The Osbournes"

July 30, 2002
by the specialmoves staff

The Osbournes Site

A lot of people have been asking us about The Osbournes site, how we made it and why we chose Macromedia Shockwave over Macromedia Flash.

As usual there were many factors that informed our decision, so it may be helpful to start with some background.

MTV approached us wanting to do something 'really cool' to support the transmission of The Osbournes in the UK. The show was massive in America and MTV believed that it could be as popular over here. They wanted a site that would stand up next to the TV show, and be something that would be just as impressive and original as the TV show was.

They wanted to present the content that appeared on the US website, but in a much more interesting way, not just as brochure-ware. It had to be truly interactive not merely presentational so the user actually got involved with the content and hopefully enjoyed playing with it.

It would have been a shame to sanitise The Osbournes for the web. We all wanted to keep it funny, keep it full of swearing, keep the characters looking like they do and show off the house the best we could.

It really was the best brief a company like ours could get. They wanted a world where you could interact with the Osbourne family and liked things like Habbo Hotel, The Sims and Little Computer People but that was about it. We had pretty much complete freedom to come up with what the characters would do and how they would interact.

So why Shockwave?

The biggest factor was development time. It took 4 weeks from our first meeting to putting the first version up live. This just wouldn't have been possible using Flash. It's not that we don't know Flash; just that Director is much more suited to the level of programming and multimedia development required.

Another major factor was execution speed. We ended up with over 5,000 lines of code, doing everything from A* path finding, dynamic loading of the content, and running what we call the interaction engine.

The interaction engine is a fully object-based system that controls all the characters, objects in the rooms and how they interact with each other. It even has its own scripting language (called OzzyScript). Each event that can happen has a own script -- and there are over 170 of them, all held in text fields. This would have very slow and clunky in Flash. On a slow machine we would soon start to get those nasty "A script is causing this movie to run slowly" messages.

Graphics Production Process

We knew this project was going to be very graphics-intensive so we had to make the production process as smooth as possible. The graphics were created with a variety of tools. The rooms and the objects in them were modelled in discreet 3D Studio Max (v4) and exported out using electric rain's swift3D plugin to give us the correct perspective view. These graphics were then re-coloured in Flash and cut up in Adobe Photoshop. The Photoshop files were then imported into Director using MediaLab's PhotoCaster so we could split the alpha channels from the Photoshop layers. We converted the graphics to 16-bit images with 4-bit alpha masks to reduce file-size. We did look at going down further to 8-bit, but this seemed excessive and the trade-off between file-size and quality seemed about right at 16-bit.

The characters were drawn and animated on paper, scanned, traced and coloured in Adobe Illustrator. The coloured frames were then imported into Flash and optimised. The Flash files were then imported into Director. This seems like a long-winded process but it was the best way to get the characters looking great and keep their file size as small as possible.

Click on the image to see it at full size (1149 x 679 pixels)

Most of the interface graphics were designed in Flash to keep a consistent style, but when importing into Director we always checked to see if they were best imported as flash or bitmap. There was a constant trade-off between file-size and execution speed, with too many flash sprites on the screen, things would have rapidly slowed down.

Interaction Engine

When we started to plan out the programming tasks for the site, things fell into a few broad categories:

Isometric engine.
A* Path Finding.
Interface.
Animations.
Character Interactions.

Within the first few days, the Isometric view, some interface elements and the A* were working well and we had a box-man demo running, but how we were going to do the character interactions and animations was still a bit unclear so we had to stop coding and think things through properly.

We had decided on an object structure initially and went over this again to make sure it was sound for all the possibilities we were thinking about. Luckily it was and we thought about all the things the character would have to do: speak, walk to grid positions around the room, face particular directions, call other characters over, wait for them to arrive etc.

We split up the interactions into different types but it soon became clear that some kind of mini scripting language would be able to cope with everything. At first this seemed a bit of a daunting task, especially with a tight schedule, but after a few days experimenting it was obviously the right way to go.

Each script has an owner and a series of properties dictating when it can be run e.g. which room, then a list of commands characters must do.

Here's a simple example script:

#OZZYSCRIPT
DISPLAYNAME:Example
OWNER:OZZY
ROOM:#ANY
TYPE:GENERAL
PRIORITY:#LOW
=================================
1:OZZY:MOVETO:[7,7]:WAITUNTILDONE
2:OZZY:SAY:ROCK AND ROLL!!
3:OZZY:CALL:JACK
4:ALL:WAITFOR:3
5:JACK:SAY:Hello Dad

In this script, Ozzy moves to grid position [7,7]. When he gets there he says "ROCK AND ROLL!!" and calls Jack over immediately. Both Ozzy and Jack wait for Jack to arrive and when he does, Jack says "Hello Dad"

Getting all this working was tricky for a number of reasons. Firstly we needed each character to run its commands in parallel so they could do things independently of each other. Secondly, what would happen if parts of the script couldn't complete? What if grid square [7,7] was blocked or Jack couldn't reach Ozzy?

Detecting and resolving commands that couldn't run turned out to be a considerable task and meant re-organising a fair bit of the OzzyScript code for phase 2 of the site's launch. This cleaned up a lot of bugs and we started to introduce a lot more commands. We ended up with about 40 commands ranging from simply hiding/showing objects to navigating from one room in the house to another.

Scripts ranged from 5 to 70 lines and enabled us to setup all the simple reactions and complex interactions we needed.

Working Practices

The project ran really smoothly internally despite being a tremendous amount of work to do in such a short space of time. It took just over two months to complete the whole site including a screensaver version, which seems incredible now.

We spent much more time than usual planning out the way we were going to approach the programming and graphic production tasks. This seemed counter-intuitive at the time but it was exactly the right thing to do. It saved us from many blind alleys later on.

We also enforced a no-late-working rule: we knew that no matter how talented and committed the people working on the project were working until the small hours for weeks on end just would not deliver the quality level we wanted. We've actually found we have become more productive by reducing the maximum hours we allowed people to work on the site.

The Finished Site

We're really happy with it on many levels. On a technical level there is some really advanced stuff going on and it's designed so we can easily repurpose it for a variety of other projects from scripted animations to full on games. The graphics all look great, we really wanted to move away from the pixel based isometric stuff that everyone else has been doing and I think we've done that. Everything is anti-aliased so it was a struggle to keep the performance up and the file size down but I think we've got a good balance.

Overall it's the best bit of work specialmoves have ever done and has been a great site to work on.

The Team

Darrell Wilkins
Director and interaction designer

Darrell is responsible for the strategy and planning within specialmoves. Making sure that everything is in place for the rest of the team to get on with what they do best. He is also responsible for ensuring that all of specialmoves’ output meets the high standards for quality and usability. In 1997, Darrell won a prodigious D&AD (Design and Art Direction) Silver Pencil for outstanding Internet design whilst still at university.

Darrell was the project manager for The Osbournes and kept everyone else in check. He helped with the conceptual design of the site, wrote the A* path finding algorithm and some of the interface control code.

Pascal Auberson
Director and interaction designer

Pascal leads up the programming team. He is extremely talented and is comfortable coding in many different languages. He has a great understanding of Internet-based technologies. Pascal is also working with artist Michael Atavar on a 3D interactive installation to be exhibited later this year.

Pascal was the main programming lead on The Osbournes. Most of the 5000 lines of code was his work. He was also responsible for a lot of the movie construction work.

See Pascal's Developer Profile.

James Norwood
Director and interaction designer

James's main area of expertise is graphic design and styling. He has an amazing ability to create fresh clean styles even when working under strict branding guidelines. James’s designs are always original and aesthetically pleasing. He has also lectured on interactive design at Plymouth University.

James was the graphic design lead on The Osbournes. He designed all the rooms, the interfaces, slaved over the animations and generally made everything look great.

Oscar Wright
Animator

Oscar is a traditional paper-based animator by trade. He drew all the characters and animated them. If it moved, Oscar drew it.

Stephanie Richards
Interaction designer

Step did much of the graphics production work, scanning, tracing, cutting up and putting together. She also did many many hours of testing and bug finding.

Iain Lob
Interaction designer

Iain did graphic production work on The Osbournes. He did lots of tracing, and scanning, as well as Fash animation work.

specialmoves: the history

specialmoves was formed in 1999 and has grown consistently since then. The three owner/directors are : Darrell Wilkins, Pascal Auberson, and James Norwood. The trio met while studying interactive design at university, after a period of working within the industry they decided to set up specialmoves.

Since its conception, specialmoves has won most of its contracts based on its high production standards. The majority of projects are repeat business. specialmoves the people

specialmoves’ people share between them a wide-ranging skill set, that when combined, results in highly original creative solutions. The core team have studied interactive design to degree level, and have been part of both large and small production teams on many high profile websites and CD-ROMs.

For specialmoves, creativity is key and it only employs talented, educated people with a high level of competence in their particular field and an excellent understanding of how all the constituent parts work together.

specialmoves has created integrated websites, web based applications, online advertising and interactive promotional content. Clients include : MTV, Volkswagen, Universal, Independiente, Guardian Unlimited, Vodafone, Sony, Compaq, Pfizer and AltaVista.

¬†