short-session - Leapfroglog

What should a casual MMOG feel like?

I’m finding myself in the starting phases of designing a casual MMOG (or virtual world, if you prefer that term). When I say design, I mean determining the structure and behaviour of the world — interaction design, in other words.

It’s an interesting challenge (and a significant change from designing mobile games, to say the least). I can’t think of a class of games that has the potential for more emergent phenomena, both social and economic. This is truly a second order design challenge.

Of course, the same old player needs still hold true, and tools and techniques such as scenarios and storyboards are just as useful here as in any other project. But the need for an iterative, test driven design and development process becomes hugely apparent once you start to think about all the effects you simply cannot design directly.

You might think I’m involved with a WoW- or SL-like endeavour. On the contrary! The aim of the project is to bring some of the unique pleasures of a virtual world to a mass (adult) audience.¹ That means making the experience more casual, more short-session.

Our players will still want to feel related and socialise, but on their own terms. They’ll still want to feel autonomous and explore, but in short bursts of activity. They’ll still want to feel competent and achieve, but without having to make too huge an effort…

There’s plenty of movement in the space of casual, short-session MMOG’s. Some have dubbed them PMOGs — Passively Multiplayer Online Games — and focus on making them open systems that interact with daily life. I’m trying to imagine what — as a closed system — a casual MMO should feel like, what its aesthetics (PDF) need to be. What, in other words, would WoW or SL have turned out to be if Miyamoto-san had designed it?

Plus some other more unique goals, that I won’t talk about just yet. [↩]

My GDC Mobile 2008 proposal: accepted!

It doesn’t say so on the site yet, but I am on the program for next year’s GDC Mobile.¹ Yesterday I got the email that my talk — titled Designing a Casual Social Gaming Experience for Generation C — has been accepted. To be honest I was quite surprised. I work in the blurry overlap of the interaction design and game design fields, have no actual game titles under my belt and proposed a weird subject to boot. Who in their right mind would invite me to speak? Of course I am also really excited about this. GDC is the professional event for the games industry so I’m honored to be part of it.²

My talk will be closely related to the things I’ve been working on for Playyoo. I’ll discuss how short-session mobile games and a web based meta-game can interconnect to create a social game experience that allows different levels of player engagement. I’ll look at the ways you can align your game design with the expectations of Generation C: customization & personalization, recombination and connectedness. I might post the extended abstract sometime in the future, for now I’m just wondering: Who else is going to GDC? What would you like to see me discuss?

Update: The conference site has been updated, here’s the description of my session.

Don’t be scared by the big Orc in the header of their site. [↩]
Now I just need to figure out whether traveling to the US twice in one month is a feasible undertaking. [↩]

Pollinator — a casual game prototype made with Mobile Processing

Last sunday I sat down and coded a prototype of a casual game in Mobile Processing. I got the idea for it the evening before: You’re a bee who needs to collect as much honey as possible in his hive while at the same time keeping a flower-bed blooming by pollinating… Play it and let me know what your high score is in the comments!

Thinking and making

I’ve been looking for an excuse to get some experience with Processing (particularly the variant suitable for developing mobile stuff) for a while. I also felt I needed to get back into the making part of the field I’ve been thinking about so much lately: Game Design. I agree with Saffer, Webb and others — making is an important part of the design practice, it cannot be replaced by lots of thinking. The things learnt from engaging with the actual stuff things are made of (which in the case of digital games is code) aren’t gained in any other way and very valuable.

Get the game

I’ve uploaded the first version of the game here. You can play it in the emulator in your browser or if your phone runs Java midlets, download the file and play it like you’re supposed to: While out and about. The source code is provided as well, if you feel like looking at it.¹

How to play

You’re the yellow oval. The orange triangle in the top left corner is your hive. Green squares are grass, brown squares are seeds, red squares are flowers and pink squares are pollinated flowers. The field is updated in columns from left to right (indicated by the yellow marker in the bottom). A seed will turn into a flower (in rare cases a pollinated flower). A flower will die, a pollinated flower will die and spread seeds to grass around it. Move your bee with the directional keys, use the centre key to grab nectar from a flower. You can cary a maximum of 100 nectar. Drop your nectar off at the hive (again using the centre key) to up your score. When you first grab nectar from a pollinated flower and subsequently from a normal flower, the latter is pollinated. Try to keep the flower-bed in bloom while at the same time racking up a high-score!

You’ll get 10 nectar from a flower (in bloom or not). Pollinating a flower costs 5 nectar. If you try to take nectar more than once from the same flower, you’ll loose 10 nectar.²

Improvements

Stuff not in here that I might put into a next version (whenever I get around to it):

Animation — I need to get my feet wet with some scripted animation. Thing is I’ve always sucked at this. For now it’s all tile-based stuff.
Better feedback — For instance show the points you earn near the bee and the hive. I think that’ll make the game a lot easier to understand and therefore more fun.
Menus, pause, game over — It’s a prototype, so you get dumped into the action right away. (The game starts on the first key you press.) And there’s no actual game over message, the field just turns green and you’re left to wonder what to do.
Balance — I’m not sure if the game like it stands is balanced right, I will need to play it a lot to figure that out. Also there’s probably a dominant strategy that’ll let you rack up points easily.

The aim was to create a relatively casual game experience that will almost allow you to zone out while playing. I think it is far too twitchy now, so perhaps I really should sit down and do a second version sometime soon.

Mobile Processing

I enjoy working with Mobile Processing. I like the way it allows you to program in a very naive way but if you like structure things in a more sophisticated fashion. It really does allow you to sketch in code, which is exactly what I need. The emphasis on just code also prevents me from fiddling around with animations, graphics and so on (like I would in Flash for instance.) Perhaps the only thing that would be nice is an editor that is a bit more full-featured.³ Perhaps I should grab an external editor next time?

Feedback

If you played the game and liked it (or thought it was too hard, boring or whatever) I’d love to get your feedback in the comments. Anyone else out there prototyping games in Processing? Or using it to teach game design? I’d be very interested to hear about it.

Not that it’s particularly good, I’m an amateur coder at best. [↩]
I’m not sure this is the right kind of negative reinforcement. [↩]
The automatic code formatting refused to work for me, requiring me to spend a bit too much effort on formatting by hand. [↩]

Snacking on casual games

Following up on an earlier post about short-session games here are some comments on a recent Gamasutra article by Ian Bogost (it’ll be in the link post for tomorrow). It’s titled ‘Casual As In Sex, Not Casual As In Friday’ and in it Bogost argues there is quite a bit of unexplored space in the casual games domain.

In the article, Bogost points out that casual games are usually seen as easy to learn but hard to master, like Go. They are commonly cheap (or at least cheaper than typical console and PC titles) and easy to get. Finally, control of the game is often simple and limited to few inputs. (Bogost recommends only using the mouse on the PC, I wonder what he’d recommend on a mobile…one button?)

Bogost points out that a typical casual game-play session might be short, but that the overall model of casual gaming (both the distribution and the game mechanics) actually encourage repeated play over a long period of time whereby a player achieves an increasingly higher level of mastery of the game (which arguably is the antithesis of casualness.)

What we rarely see are games that are explicitly created to be played once and never revisited. Bogost mentions September 12th and Zidane Head-Butt as prototypes for these types of casual games.

This is all very interesting to me because in a current project I have been discussing this notion of snack-sized games quite a lot. I am convinced there is a market for games that are consumed once and are then discarded, but there are some challenges to overcome. Bogost mentions these as well: They need to be ridiculously simple to access, as cheap as possible (ideally free) and instantly learnable.

One point Bogost doesn’t raise is: Who will feel compelled to create these games? Because game creation always involves some effort, typical game developers might not see much profit in releasing their games into the wild for free. What’s in it for them? I think the key there is the democratization of game creation. Giving ordinary users fun tools to create these short-session, snack-sized, casual-as-in-sex games as a form of personal expression.