In 1982, Laskys (UK) was one of the most popular high street electrical retailers. They were also one of the few national chains where you could see a selection of microcomputers on display and, in Cardiff at least, happily fiddle around with them without getting shooed away – a rare thing if you were a 9 year old computer nerd!
Here’s the draft chapter stubs for the project
- Gaming – hasn’t it always been social?
- Classic games as blueprints for building tight game play (Liepa, Jarvis, Minter, Takahashi)
- Social networks and their infrastructure
- The game industry: a publishing primer on choosing the right model to release your game
- Marketing: why you need to market early and often
- Design for a social game and choosing the right design for you
- Server Design, Scalability and Persistent worlds
- Game Production and managing the process
- Conclusion, did it work?
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, http://en.wikipedia.org/wiki/Agile_software_development
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 (http://en.wikipedia.org/wiki/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: http://unspace.ca/innovation/speak, 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.”
Great little article on level design on Gamasutra
[Gamasutra is presenting an in-depth excerpt from IGF nominated Dyson/Eufloria co-creator Rudolf Kremers’ new book Level Design: Concept, Theory, and Practice, which was recently released by AK Peters. This extract, just part of the book’s seventh chapter, looks at wish fulfilment and escapism occasioned by some of the best video game level designs.]
If somebody holding carrots beats you with a stick it would be very satisfying if you were to wrestle the stick away from your tormentor and make him give you all the carrots…
Quick update: I’ve just swapped a few emails with Katamari’s legendary designer Keita Takahashi who’s in the UK as part of a project to create a childrens’ playground. He’s giving a talk next week and has amazingly invited me and this crazy project along. At the talk will also be the legendary designer, Martin Hollis, who was the designer of Goldeneye on the N64. I absolutely can’t wait. I imagine they are not quite as excited as me but then again, they’ve not met me and my crazy project yet.
Before I have a talk with Keita I’ll have another bash at trying to deconstruct the character design and see how much his vision for them altered as the project progressed. Maybe I’ll be suprised and find out the whole thing was meticulously planned and used CMM or Prince 2 to manage the project. I seriously doubt it 🙂
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.
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 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:
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.”
Just a quick hack to sketch out a couple of topics before I dash out to get a large slide for our garden.