Behind the scenes of the oddest party you'll ever try to stop.
Party Pooper came into our lives at the most unexpected moment. The idea for the web-toy was first mentioned in passing over the lunch table, and before we knew it we’d abandoned our sandwiches and gathered in the meeting room.
When we finally launched, it immediately took off on social media and in less than a week there'd been 14,000 attempts to poop the party. It also ignited a fierce contest on Twitter for the lowest time score (current record 18 seconds – can you beat it?) One month and over 110,000 popped balloons later, here’s what we learned.
From a producer’s point of view, keeping in regular contact with the team was key due to the organic nature of the workflow. The whole team had to remain open to different routes as we went along and not get too attached to certain ideas. Regular meetings allowed us to share thoughts and feedback while taking on board people’s advice from their various standpoints, whether creative, technical or process-orientated.
It was also quite a challenge to get team members booked in at the same time throughout the course of production. We try to approach play projects in the same way as client ones, but they do of course take a back seat when client work is requested at the same time. That in itself requires an ongoing process of shifting priorities at a moment’s notice and rescheduling to ensure the work still gets accomplished, without interfering with our client commitments.
It may seem simple at first glance, but behind the scenes of Party Pooper there were a few technical challenges to overcome and new methods to try. We learnt a lot about the Bodymovin plugin, which we’ve started using more and more.
Because of the game mechanic we opted to use Flux Application Architecture. We knew that keeping the state of the game was going to be one of the biggest challenges, and using Flux alongside React proved the perfect toolset for the job. A lot of time was spent setting up a rigid API and events system capable of triggering other animations and states throughout the game.
We decided to make Party Pooper a desktop-only experience simply because, with the amount of simultaneous animation, only a desktop could handle it. With more time we would have potentially tried a stripped-back mobile version too, but having set ourselves particular parameters we needed to stick to them.
Testing was a really interesting part of the process. We had five rounds of tests within the team, allowing us to make sure the story was really clear by the final iteration. It was also important to have a designated product owner who could step in and say which feedback to act upon.
To get five rounds out of the team we focused on three people at a time; each group would see the latest version at the time, which worked really well. It also got the whole team feeling involved, which is always a positive.
Another idea we deliberated over was putting times scores in. We didn’t want to devalue Party Pooper as an experiment by making it too ‘gamified’, but we had such a great response to the scoring system internally that we decided to go ahead with it. The edge of competition, we agreed, would encourage people to play – and keep replaying until their party-pooping skills excelled! We represented the different 'carnage levels' with images like the ones below.
Details like the in-game copywriting were important too. We had to figure out how to tell the story with a user-journey point of view in mind, both from within the game itself and in its promotion. We had a pre- and post-release strategy mapped out in advance on Trello, detailing the assets we’d push out on social media in the run-up, and a corresponding calendar with dates for each drip-feed of Pooper action across Instagram, Twitter, Dribbble and Tumblr. We also had postcards printed to hand out, with a link to the URL.
Paper (the foldy character by the window) and Box were designed quite early on, so we shared Paper’s demise as a cheeky teaser on social media while we were still in the very early throes of building.
On Facebook we decided to create an Event named ‘Party’ to build excitement around the project before announcing what it was. This was a new marketing approach for us and we thought it would be fun; the theme of the web-toy lent itself perfectly to the event format, so we could invite people to ‘attend’. We wanted to keep the project – and the pooper element in particular – a secret for a while, so the description was cryptic and the location initially set as ‘To be revealed’.
We also made the URL party.animade.tv (with no mention of ‘pooper’), and prior to the game’s launch, it redirected people to the Facebook Event. Our attempts to keep things mysterious may have gone a touch too far though, as we discovered when a few followers started thinking there was a real party on the cards!
Upon Party Pooper’s big release we shared the project with our favourite magazines and blogs, and were lucky enough to get featured in Motionographer, Digital Arts and It’s Nice That among others. Party Pooper was awarded Site of the Day on the FWA and received a Special Mention from Awwwards.
We set up a very specific analytics dashboard that enabled us to view everything from how many balloons were popped (at the time of writing, one month after its release, 110,634) to which character got pooped the most (poor old Knife at 17,500, closely followed by Worm at 17,449) – the sneaky Horse got away with a mere 16,065. This is not only fun to track, it helps us get a better understanding of what is working for users.
To date, the game has been played over 25,000 times. That’s quite some party pooping! If you think you can outwit that pesky Horse, give Party Pooper a go now.