Peter Liepa on Boulderdash and Agility

One of the most unexpected pleasures from this project so far, and importantly one I could not have foreseen prior to it (theme of the project so far), is the amazing series of emails I’ve had with Peter Liepa, the creator of Boulderdash.

Peter has been incredibly generous with his time and also his enthusiasm to talk about his work but what has been revelatory has been that we both share the same philosophy for Agile development methods.

“Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.” – Wikipedia,

As an undergraduate back in *cough* 1992, I remember feeling exhausted both mentally and physically, lugging around a copy of the massive Pressman tome on Software Engineering: A Practitioner’s Approach . It was filled with dry accounts of metrics, methodologies and process all interesting in their own way and useful for certain types of projects but there was a bigger problem that was not being addressed (I’m sure it has now!) This was 1992 and the world wide web was starting to rapidly infiltrate into the world via NCSA’s mosaic and it was changing, every day, probably every second somewhere.

I was captivated. I could open a terminal, fire up vi ( and update my little web application that blocked rude websites from children (for schools 😉 and within minutes, everyone else could see my new and improved version. Then using email, users could send me message straight away telling me they liked the new version (or not!). Instant feedback, iterative development, structured releases and no long winded word documents. This felt an intuitive way to develop. Add in structured releases, source control and some QA and this is more or less Agile development.

Here’s my latest conversation with Peter:

I’m finding that my current research and hypothesis is quite biased toward my own experiences of software development and that I’ve always had leanings to use methodologies and formal processes to help the development cycle. It seems games development, even now, doesn’t have quite the same approach with the design and development process being more fluid, almost to not interrupt the creative aspect is that the case?

“Methodologies and processes are a good thing, but not much use unless they anticipate that the very act of development will cause things to change. Agile methodology handles that very well, and shifts the emphasis from a detailed long term plan to being able to ship something that works every day. Because there is true value in being able to use the software from Day 1, and every day after that. This guy puts it well:, if you have the time to watch.”

Do you remember how you got the original idea for Boulder dash and how different was the released product from it?

“The project started off as somebody else’s clone of an existing arcade game that involved tunnelling through earth. I very quickly decided that was a non-starter, so I just rebooted by implementing some simple rocks/dirt/gravity/digging physics and playing with the parameters until I got something fun. The game evolved by ‘monetizing’ the physics into tasks and points, and then by endless polishing the look, feel, sound and gameplay. So, there was never really an original idea for Boulder Dash, as much as mucking around until something felt like fun. And then a lot of work, and even more in the wastepaper basket.

Out of curiosity I looked up three other games involving rocks and digging. They are “The Pit”, “Mr. Do”, and “Dig Dug”, all written in 1982 (which was a year or two before Boulder Dash). All are described in Wikepedia and there are clips on Youtube. It was fortunate that the clone I started off with was so lame I abandoned it, otherwise I may have set out to duplicate one of these. However, I didn’t have access to any at the time, or that’s what I may have done. Well, not really, because I’m not very good at sticking to upfront specs or exactly cloning other people’s work.”

Leave a Reply