Interviews with Peter Liepa with regard to game development

New game releases, new tools, website updates, ...

Moderator: Admin

Post Reply
User avatar
Posts: 24
Joined: Sun Apr 05, 2009 1:40 am
Location: Moscow, Russia

Interviews with Peter Liepa with regard to game development

Post by Klaxer »


So where the hell does charm come from? At what point does the block of code you’ve loaded into memory and its instruction pointer start to become charming? Unsurprisingly, when it’s written by someone with a sense of humour, which is what makes these games stand out.

By the way, the best way to think about how that block of code becomes characterful is to think of it like a flip book that you probably made when you were small (or not, as I still do them for my daughter). You know, you take a bunch of pages (like the bottom corner of your maths exercise book) and draw a character on page 1. Then for every successive page you draw the character in a slightly different position. When you flip them all together at a constant speed you get your own movie.

Like this one:

One of the earliest examples of “character” animation I can think of is the main character Rockford that appears in Peter Liepa’s Boulderdash. Rockford, when he is left idle gets bored. This is what the BCDFF document says on it (

A: “When Rockford is not moving, he faces forward (out of the screen towards the player). Rockford gets bored; he taps his foot and blinks his eyes. Blinking and tapping are independent of each other; in the C64 implementation, the upper and lower halves of his body are controlled separately.

Animation sequences are eight frames long, and each frame is displayed for two ticks, so it takes 16 ticks (about 0.27 seconds) to complete each animation sequence. At the beginning of each new animation sequence (ie every 0.27 seconds), if Rockford is not currently moving, it is decided whether Rockford will be idle, blink, tap his foot, or blink and tap his foot. There is a 25% (1/4) chance he will blink each animation sequence, and a 6.25% (1/16) chance that he will stop tapping (if he is currently tapping) or start tapping if he isn’t.”

My first question to Peter is to ask where this idea came from, as it totally elevated an already high quality game but also the precision that he used in order to breathe life into his character doesn’t seem random. Did he have a strong sense of giving him personality from the start or was it more serendipitous stemming from something pragmatic like giving the player a visual cue to get a move on (as Boulderdash is a timer based mechanic?).




It’s starting to become clear that over analysis could be a bad thing and that the design of a game is a lot more loose than I thought. As suspected early on into the process, this is largely a hangover from working in an industry where we have process and methodologies for everything. That’s not to say the games industry does not, especially in the larger studios, but it’s becoming obvious that the design and development phase is a more loose playground for creativity and too much formality might result in “analysis paralysis”. In fact, Lee’s already written a great comment on my need to be able to formally evaluate ideas post earlier on this week and I’ll address that next.
This morning Peter Liepa replied to my questions about Rockford’s character design, I was particularly interested in how he came to inject personality into him and if that was a deliberate design choice, based around a particular game mechanic. Peter’s reply, in line with Lee’s earlier comments, points out that the process is more creative and experimental than I first realised. Thinking about it, it has to be really. Damn those years shackled to the Capability Maturity Model (CMM

Q: Peter, I’m curious about how you came to give Rockford the foot tapping and blinking characteristic when he’s idle. Did you have a strong sense of giving him personality from the start or was it more serendipitous stemming from something pragmatic like giving the player a visual cue to get a move on (as Boulderdash is a timer based mechanic?)

A: "The answer is somewhere in between, I think. I don’t think I thought of Rockford in terms of personality. In fact, he was just a static symbol during early development, and he never had a name until after the publishers gave him one."

Q: Well that’s that blown out of the water. After all these years, I find out that it’s the damn publisher that gave my beloved bunch of bits his name. Damn their marketing prowess!

A: "On the other hand, I worked hard applying my limited animation ability to creating a believable character and movement given the small number of pixels available. I probably had a number of poses in my animation editor, along with variations of the character."

Q: This is more like it! Alchemy!

A: "I’m guessing that I have been comparing, say, eye size and position between variations when I realized that I could make the character blink. Once I realized that having Rockford blink while idle gave him extra life and presence, I probably experimented with tapping.

But that’s a guess. I don’t think I set out to give him independence, but once circumstances suggested it, I went with it. And I don’t think that I was exactly prompting the player to get a move on – it was more that the game was quite quiet if Rockford wasn’t moving, and I was pleased with the extra depth it gave the character."

So pretty much all of my assumptions were wrong. Brilliant. Actually it is brilliant, it should stop me early on into this process assuming too much. Perhaps it’s more simple, that only the overall project needs a formal plan with deliverables to test and release and what happens in between is a mix of creativity, experimentation, experience and previous influences. A manager’s nightmare I’m sure!


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:

Q: 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?

A: "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."

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

A: "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."


If I compiled a list of my favourite games before I started this project Boulderdash would appear at zero. That’s a pretty dire programming joke but it’s absolutely true. No game has ever entranced me to the same degree. I still have the cassette of my Atari 800 version, actually the copy even has the cassette inlay drawn by my 12 year old self (it’s on the bookshelf behind me, I’ll dig it out). Its design simplicity is eternal but more importantly it is Fun. The frequency at which Boulderdash clones and updates appear, most recently on the DS as Boulderdash Rocks!, are proof of its endearing appeal.


[my awesome cover art, aged 12 & 3/4]

So it’s with a twinge of sadness that this is probably the last big part of talking with Peter Liepa about Boulderdash. I want to thank Peter for the astonishing amount of time and patience he’s shown me and the project. It might be obvious by now that I’m not an experienced interviewer (hard to believe I know) and his tolerance of my ‘style’ has not only been pivotal in me starting to understand the differences in game development but hugely inspiring. Plus I got to find out some exciting news, Peter’s working on a new puzzle game but that’s as much as I can tell you at the moment. Okay, enough with the schoolboy mawkishness already.

Back to the plot…loading…


Peter, if games are all about a “feeling” of enjoyment and fun then would it seem reasonable then to assume that you must have a sizeable iterative process loop of “play/testing/refining” your game model in order to arrive at something enjoyable? Probably the majority of your development? That is, beyond a rough spec/idea for the physical constraints of the world, the rest of the specification is written as a result of development and not the other way around?

A: "That sounds about right. Frankly, it’s not as if I had an official ”process”. I was just a guy working at the metaphorical “kitchen table” trying to create a game. I had much bigger things to worry about than process. In fact, my experience to date had been that process wasn’t much use unless you were working with a larger team. And I am by nature an improviser."

Q: So perhaps it would run along the lines of “my first goal is to have something that does y in a weeks time and then as a result of play testing y I actually now know that my model also needs x to support and precede y to help make more sense of its function” and this might not have been visible through spending a month writing a formal specification for it, as it’s almost impossible to feel fun through a written description, in the same way that reading a play will be nothing like the experience of going to the theatre to see it.

A: "Sounds like a good plan. Obviously you want to think things out as far as you can in advance, but recognize that there are diminishing returns for that. There are lots of things that you don’t know yet, and value (as a navigational aid) will reveal itself as you go along."

Q: As my project will also result in the agile development of a social/Mobile game, I wonder if you had thoughts on how Boulderdash would evolve if you were developing it today with the influence of Facebook and Twitter? (I guess an impossible question really, as it Boulderdash exists as a product of it’s time really) Beyond something like social hi-score tables did you ever conceive of it being multiplayer for example? Have you ever had any desire to revisit it – or games in general?

A: "I have a vague recollection that I may have thought of multi-player Boulder Dash at one time, but as you point out it was a product of its time. It did just fine as a one player game.

Funny you should ask about revisiting games. From 1994 until early 2009 I worked at Alias, the company that created Maya and was acquired by Autodesk. Since leaving that company, I’ve had the mental bandwidth to return to some of my “roots” in mathematical visualisation, generative art and gaming. One of the projects I’ve been working on lately is a web version of my game Brain Jam, which was released as freeware in early 90′s and enjoyed some cultish popularity. It was written back then as a learning exercise for C++ and Windows, and is being rewritten now as a way of learning web technologies.

It’s on the backburner right now, due to a contracting project, but we might be able to talk more about its process when I resume."

Q: I guess I’m coming to the end of my questions too (sadly!), so perhaps it’s fitting then to ask about the end of the development of Boulderdash. How much time was spent on “polish” in regard to the whole development time (actually, how long was it, start to finish?) The game has always struck me as something of a labour of love as it’s so beautiful to see and hear. A good example for me is the way that the cave structure is first revealed to the player, as it flips each border tile to show dirt/boulder/firefly/diamond etc and scrolls to Rockford who finally ”arrives” in the cave slightly later and gives a genuine sense of transition.

That sense of scrolling encourages the user to explore, eagerly searching out those diamonds. Were these things that were added after the core mechanic was working, i.e. design ideas that came as a result of polishing? When did you decide it was time to stop – or did the publisher decide for you? What was your overall experience of the development and publishing relationship?

A: "Boulder Dash took about 6 months to develop. That would have been 2 hours of what looked like “real work” every day, along with 22 hours of what may have looked like time wasting but was probably integral to the process. Somebody once mentioned to me that you can get an awful lot done in life with a mere hour or two a day of genuine productivity, so I guess there is hope for those of us who can’t work like machines.

As for polish, the mechanics of the game showed up within the first three days of the project. You could argue that after that everything was polish. I think that all good or great works of art need to be labours of love, because otherwise those with artistic temperament wouldn’t stick around to give them all the polish and finish they need to go out into the world. If an idea is worth spending six months on, it’s probably reasonably good.

So the effects that you describe – the revealing of the cave, the scrolling, were all part of polish and presentation. The original
game had smaller tiles that all fit on one screen. To make them more vivid, the tiles had to be bigger. And once they were bigger, the game no longer fit on the screen, so scrolling was introduced.

I can’t really remember how it was that I decided the game was complete. Something about works of art not being finished, only abandoned. By the time I found a publisher, I only had a few sample caves. It was easy enough to design enough caves for the whole game, once we decided what was enough. But they specifically asked for a ”granny cave”, which was their term for a cave that anybody, including your grandmother, could get through. And they also wanted ”intermissions”, which seemed to be popular in games at the time as rewards.

So I just added some smaller puzzle caves after every four of the main caves. I think both suggestions, especially the granny cave, enhanced the game."

Q: Lastly, I loved reading your blog entry ( ... ash-theme/) that had the music transcribed using a flash application. How important to you was the music and soundfx? The soundfx is terrifically atmospheric and has a distinctive echoey and metallic effect (that could be my memory playing tricks on me) Did you design the soundfx?

A: "I designed the music and soundfx. They were as important to me as any other part of the game in terms of adding richness to the experience. I had some background in both music and waveform/sound synthesis, so they were a fairly natural thing for me to do, although the sound chips in those days were pretty basic. My philosophy with music is that you take the instrument you’ve got – whether that’s a rubber band or a grand piano – and build the music around that. So I was trying to leverage the available sound chips to making sounds that suited them."

[Transmission ends]

Post Reply