I thought it'd be handy or interesting for people if we posted up all the documentation we used during the creation of Woodlouse.

There are piles of people out there that want to get into games, and - whilst there's never been a better time than now, what with a growing indie movement, great tools, and fantastic distribution opportunities - it's harder than it looks.

Woodlouse is, basically, a list. It's quite a posh list, but it's a list nonetheless.

Given that it's 'just a list', you might be surprised at all the time, effort, thought, and hard work that went into making it.

Woodlouse was made by a two-person team. Me, based in London, and Jake, based in the US. Because we couldn't get together very easily, and because Woodlouse is actually really simple, writing documents was a good way for us to go. In larger projects, I'm really not a fan of what we call 'Game Design Documents' – they're big, difficult to read, and too static. Game development, as 'a thing' needs to be fluid and iterative.

That said, I knew from the outset what Woodlouse was going to look like. It's simple enough to specify exactly how the whole thing hangs together, how it all interacts, and so on. So creating a set of definitive design documentation for Woodlouse was an okay way to go.

This is the biggie – the initial document that lays out the entire design of Woodlouse. It's designed to be a one-stop shop for the whole project for anyone involved with it (which was just one other person, but hey). It's designed to be the sort of document that you can hand to someone, wait a while, and get back exactly what you had in mind.

Which is pretty much what happened, really.

If you're trying to get into making games, you might be surprised with the level of detail the Product Specification goes into. If anything, though, there's not quite enough there. As designers, we can always define / describe things a little better.

Click here to download the Product Specification.

The Visual Specification is a kind of visual equivalent of the Product Specification. Whilst the Product Specification is detailed and thorough, it's true what they say: a picture paints a thousand words. The Visual Spec gives an easy-to-understand overview of how Woodlouse hangs together.

Once you've read the Product Spec and the Visual Spec, you should have a pretty clear picture of exact what development effort is required to make Woodlouse.

Click here to download the Visual Specification.

The last document I prepared for the start of development was a clickable mockup. It's the 'interaction design' equivalent of the Visual Specification. It mightn't look as Woodlouse is supposed to look like, but its structure is right. The idea here is that it gives other developers an idea of how all the different bits of Woodlouse relate to each other – which pages lead to which other pages, how things relate and react, and so on.

The file itself is a clickable mockup. If you're viewing on Preview on a Mac, go into the 'View' menu and click single page. Now click stuff, and you'll navigate round the mockup.

If you're on a PC… sorry. Not a clue.

If you're wondering what that blue arrow is, it represents a swipe down on the UI. It's how the 'hidden' UI is revealed.

Click here to download the Clickable Mockup.

Part of being a good gamesmaker is to be reactive and flexible.

I hadn't been descriptive enough or precise enough with the in-app purchase specifications in the initial Product Specification. Jake needed more detail, so I rattled off the IAP Specification. It goes into the level of detail needed for implementation of the stuff in the Woodlouse Store.

Click here to download IAP Specifications.

We always knew that the transitions were going to be a difficult thing to get from my head into Jake's. I'm an interaction designer, not a visual one, so I couldn't mock up animations for him.

The Visual Transition Specification is my attempt at fleshing the transitions out into the level of detail needed for implementation.

Click here to download the Visual Transition Specification.

Finally, Jake pointed out that my design for the Score UI was, well, a bit rubbish.

I came up with another one that's less bad. Still not perfect, but better than it was before.

Click here to download the Alternative Score UI.