How we made... Borborygmus!

Recently I finished up work on a really fun interactive book project, Borborygmus. It's a beautifully illustrated interactive children's book for desktop and mobile, which introduces Borby - the mischievous little guy in your tummy who keeps everything ticking over, while rumbling loudly and making a load of mess.

This project turned out really nicely, of course primarily as the hand-drawn illustrations were already amazing before I got my hands on them, but also in terms of the fact that we built it in such a way that it works everywhere really nicely and consistently. I've had quite a few people reach out and ask about the underlying tech and approach, so I though I'd outline how we put it together.


The whole project is built using the wonderful Phaser JS games framework, which I've been a fan and user of for a few years now. Phaser really came into it's own while I was working for BBC Children's, and it's really turned into a fantastically mature and well thought-out framework - great API, handles pretty much anything you need it to do, and does a lot of legwork for you in terms of boring tasks like loading, state management, scaling, and a million other things. Phaser also has a huge and really active community around it now too, which is something I feel is just as important as the code itself. There's nothing better than being able to ask someone a question, instead of trawling through docs (although Phaser's docs and resources are tip-top as well, which is great).

Now obviously Phaser is a games framework, and while the Borborygmus book isn't a game as such, it actually still made a lot of sense to use Phaser anyway. We wanted the book to be full screen, work on devices, be richly animated, and all that stuff. We even have particles and physics on some pages for explosions and splatters. So, aside from the fact you don't play it like a game, effectively this still had all the elements and components of a game, making Phaser an obvious choice (and, my days of wanting to re-invent the wheel are long gone too. I just want things to work robustly so I can get on with my day...)

One of the main difficulties with getting the artwork into digital book form was that the pages were supplied by the client as enormously high resolution (print ready) and many-layered artwork files - the whole thing is hand illustrated, and often the beautiful characters are made of huge numbers of composite layers of effects and transparency and things. It ended up being a fair amount of manual work to take this rich artwork and flatten it out for web, while keeping the visual quality high - secretly I'd hoped I could just pop the resolution down and then jam everything in, but of course nothing's ever quite that simple. Overall the effort was more than worth it though.

Another big consideration was the resolution and quality of the assets. Initially I'd planned to take a traditional low/high resolution approach, where richer 2x/3x assets would be served to high res screens, and all that stuff. However I always find that approach time-consuming and a bit clunky sometimes, and so instead I opted to find a happy medium that I could scale appropriately, and be smart about compression. A lot of this decision came from my experience on CBeebies Storytime, where again we opted to find the sweet spot that would work well on many screens, cutting a lot of legwork out.

The scaling worked out well - the book itself is a single centralised scaling element (the book 'outline' around the page), which scales to fit the browser, or pops to full screen if supported. Each spread page exists as a Phaser state, which contains assets that are inserts as child elements of central book object. This means we can do a single scaling calculation on the book, and then resize the pages easily to fit. I guess the book metaphor carries over quite nicely, with the pages being literally placed inside the cover pages of the holder.

(The back/next navigation elements are separate from the Phaser book, and are actually just floating DOM objects over the top of everything that ping events back down)

From there, each page uses a single large background image as a scale reference, which is 1432x723 - the original artwork size scaled down to 72DPI ended up being a fairly appropriate size, so I stuck with it. Page elements (characters, animated elements, particles, whatever) are then positioned absolutely within this holder, so I never had to worry about calculating any odd positions or any of that stuff. There was still some manual jiggling when placing page elements, but overall it worked well.

The single downside to the setup at the moment is that it pulls everything in during a single front load, which is something that in hindsight I should have thought out a bit more maybe, and done a lazy load on individual pages etc. The filesize of the whole thing is maybe a touch on the big side at about 14mb, but the artwork is very rich and there's full sound and narration, so all told it's not too outrageous - ultimately this is a story book, not a bank website, and I think the tradeoff is worth it. The downside with a lazy load is of course that you can bang into loader bars in the middle of the book, which really breaks the flow up - if this was a game and not a story then fine, but I'm hesitant to do this sort of thing when someone's reading.

So yes, that's Borby. If you haven't checked him out yet, give the book a whirl here (and if you have small children, I'd love to hear what they think!)

Borborygmus was written by David Bell, illustrated by Vincent Gallut & Martin Smith.