Tag: design

Pollinator — a casual game prototype made with Mobile Processing

I wrote a game about a bee and flowers today

Last sun­day I sat down and cod­ed a pro­to­type of a casu­al game in Mobile Pro­cess­ing. I got the idea for it the evening before: You’re a bee who needs to col­lect as much hon­ey as pos­si­ble in his hive while at the same time keep­ing a flower-bed bloom­ing by pol­li­nat­ing… Play it and let me know what your high score is in the comments!

Thinking and making

I’ve been look­ing for an excuse to get some expe­ri­ence with Pro­cess­ing (par­tic­u­lar­ly the vari­ant suit­able for devel­op­ing mobile stuff) for a while. I also felt I need­ed to get back into the mak­ing part of the field I’ve been think­ing about so much late­ly: Game Design. I agree with Saf­fer, Webb and oth­ers — mak­ing is an impor­tant part of the design prac­tice, it can­not be replaced by lots of think­ing. The things learnt from engag­ing with the actu­al stuff things are made of (which in the case of dig­i­tal games is code) aren’t gained in any oth­er way and very valuable.

Get the game

I’ve uploaded the first ver­sion of the game here. You can play it in the emu­la­tor in your brows­er or if your phone runs Java midlets, down­load the file and play it like you’re sup­posed to: While out and about. The source code is pro­vid­ed as well, if you feel like look­ing at it.1

Pollinator 0.1

How to play

You’re the yel­low oval. The orange tri­an­gle in the top left cor­ner is your hive. Green squares are grass, brown squares are seeds, red squares are flow­ers and pink squares are pol­li­nat­ed flow­ers. The field is updat­ed in columns from left to right (indi­cat­ed by the yel­low mark­er in the bot­tom). A seed will turn into a flower (in rare cas­es a pol­li­nat­ed flower). A flower will die, a pol­li­nat­ed flower will die and spread seeds to grass around it. Move your bee with the direc­tion­al keys, use the cen­tre key to grab nec­tar from a flower. You can cary a max­i­mum of 100 nec­tar. Drop your nec­tar off at the hive (again using the cen­tre key) to up your score. When you first grab nec­tar from a pol­li­nat­ed flower and sub­se­quent­ly from a nor­mal flower, the lat­ter is pol­li­nat­ed. Try to keep the flower-bed in bloom while at the same time rack­ing up a high-score!

You’ll get 10 nec­tar from a flower (in bloom or not). Pol­li­nat­ing a flower costs 5 nec­tar. If you try to take nec­tar more than once from the same flower, you’ll loose 10 nec­tar.2

Improvements

Stuff not in here that I might put into a next ver­sion (when­ev­er I get around to it):

  • Ani­ma­tion — I need to get my feet wet with some script­ed ani­ma­tion. Thing is I’ve always sucked at this. For now it’s all tile-based stuff.
  • Bet­ter feed­back — For instance show the points you earn near the bee and the hive. I think that’ll make the game a lot eas­i­er to under­stand and there­fore more fun.
  • Menus, pause, game over — It’s a pro­to­type, so you get dumped into the action right away. (The game starts on the first key you press.) And there’s no actu­al game over mes­sage, the field just turns green and you’re left to won­der what to do.
  • Bal­ance — I’m not sure if the game like it stands is bal­anced right, I will need to play it a lot to fig­ure that out. Also there’s prob­a­bly a dom­i­nant strat­e­gy that’ll let you rack up points easily.

The aim was to cre­ate a rel­a­tive­ly casu­al game expe­ri­ence that will almost allow you to zone out while play­ing. I think it is far too twitchy now, so per­haps I real­ly should sit down and do a sec­ond ver­sion some­time soon.

Mobile Processing

I enjoy work­ing with Mobile Pro­cess­ing. I like the way it allows you to pro­gram in a very naive way but if you like struc­ture things in a more sophis­ti­cat­ed fash­ion. It real­ly does allow you to sketch in code, which is exact­ly what I need. The empha­sis on just code also pre­vents me from fid­dling around with ani­ma­tions, graph­ics and so on (like I would in Flash for instance.) Per­haps the only thing that would be nice is an edi­tor that is a bit more full-fea­tured.3 Per­haps I should grab an exter­nal edi­tor next time?

Feedback

If you played the game and liked it (or thought it was too hard, bor­ing or what­ev­er) I’d love to get your feed­back in the com­ments. Any­one else out there pro­to­typ­ing games in Pro­cess­ing? Or using it to teach game design? I’d be very inter­est­ed to hear about it.

  1. Not that it’s par­tic­u­lar­ly good, I’m an ama­teur coder at best. [↩]
  2. I’m not sure this is the right kind of neg­a­tive rein­force­ment. [↩]
  3. The auto­mat­ic code for­mat­ting refused to work for me, requir­ing me to spend a bit too much effort on for­mat­ting by hand. [↩]

Learning about emergence from games

A game of Go

I’m still try­ing to get a grip on why I think games are such a good ref­er­ence point for IAs and IxDs. I’ll try to take anoth­er stab at it in this post. Pre­vi­ous­ly I wrote about how games might be a good way to ‘sell’ algo­rith­mic archi­tec­tures to your client. Even if you’re not active­ly push­ing your clients to adopt ideas such as on-the-fly cre­ation of site nav­i­ga­tion, soon­er or lat­er I’m con­vinced you’ll find your­self con­front­ed with a project where you’re not asked to devel­op a defin­i­tive infor­ma­tion archi­tec­ture. Instead you’ll be charged with the task to come up with mech­a­nisms to gen­er­ate these pro­ce­du­ral­ly. When this is this case, you’re tru­ly fac­ing a sec­ond-order design prob­lem. How can games help here? 

One of the defin­ing char­ac­ter­is­tics of games are their com­plex­i­ty. A few years ago Ben Cer­ve­ny gave a bril­liant talk on play (MP3) at Reboot 7.0 and men­tioned this specif­i­cal­ly — that much of the plea­sure derived from game-play is the result of the play­er com­ing to terms with com­plex pat­terns. This com­plex­i­ty is some­thing dif­fer­ent from pure ran­dom­ness and most cer­tain­ly dif­fer­ent from a ‘mere’ state machine. In oth­er words, games show emergence.

There are many exam­ples of emer­gent sys­tems. The Game of Life springs to mind. This sys­tem isn’t real­ly a game but shows a remark­able rich­ness in pat­terns, despite (or maybe because of) the fact that it is based on a set of decep­tive­ly sim­ple rules (which appar­ent­ly took its cre­ator, John Con­way, over 2 years to per­fect!) The thing is though, The Game of Life is not interactive. 

A won­der­ful exam­ple of a com­plex emer­gent sys­tem that is inter­ac­tive is the real game Go. It has a set of very sim­ple rules, but play­ing it well takes a huge amount of prac­tice. The joy of play­ing Go for me (an absolute begin­ner) is large­ly due to dis­cov­er­ing the many dif­fer­ent per­mu­ta­tions play can go through. 

So get­ting back to my ear­li­er remark: If you’re con­vinced you’ll need to get a bet­ter han­dle on solv­ing the sec­ond-order design prob­lems pre­sent­ed by the design of com­plex emer­gent sys­tems, games are an excel­lent place to start learn­ing. They are emer­gent first and inter­ac­tive sec­ond, the per­fect twin to the web envi­ron­ments we’ll be shap­ing in the future.

UX designers should get into everyware

I’ve been read­ing Adam Greenfield’s Every­ware on and off and one of the things that it has me won­der­ing the most late­ly is: are UX pro­fes­sion­als mak­ing the move to design for ubiq­ui­tous computing?

There’re sev­er­al places in the book where he explic­it­ly men­tions UX in rela­tion to every­ware. Let’s have a look at the ones I man­aged to retrieve using the book’s trusty index…

On page 14 Green­field writes that with the emer­gence of ubi­comp at the dawn of the new mil­len­ni­um, the user expe­ri­ence com­mu­ni­ty took up the chal­lenge with “vary­ing degrees of enthu­si­asm, scep­ti­cism and crit­i­cal dis­tance”, try­ing to find a “lan­guage of inter­ac­tion suit­ed to a world where infor­ma­tion pro­cess­ing would be every­where in the human environment.” 

So of course the UX com­mu­ni­ty has already start­ed con­sid­er­ing what it means to design for ubi­comp. This stuff is quite dif­fer­ent to inter­net appli­ances and web sites though, as Green­field points out in the­sis 09 (pp.37–39):

“Con­sis­tent­ly elic­it­ing good user expe­ri­ences means account­ing for the phys­i­cal design of the human inter­face, the flow of inter­ac­tion between user and device, and the larg­er con­text in which that inter­ac­tion is embed­ded. In not a sin­gle one of these dimen­sions is the expe­ri­ence of every­ware any­thing like that of per­son­al com­put­ing.” (p.37)

That’s a clear state­ment, on which he elab­o­rates fur­ther on, men­tion­ing that tra­di­tion­al inter­ac­tions are usu­al­ly of a “call-and-response rhythm: user actions fol­lowed by sys­tem events.” Where­as every­ware inter­ac­tions “can’t mean­ing­ful­ly be con­struct­ed as ‘task-dri­ven.’ Nor does any­thing in the inter­play between user and sys­tem […] cor­re­spond with […] infor­ma­tion seek­ing.” (p.38)

So, UX design­ers mov­ing into every­ware have their work cut out for them. This is vir­gin territory:

“[…] it is […] a rad­i­cal­ly new sit­u­a­tion that will require the devel­op­ment over time of a doc­trine and a body of stan­dards and con­ven­tions […]” (p.39)

Now, UX in tra­di­tion­al projects has been prone to what Green­field calls ‘val­ue engi­neer­ing’. Com­mer­cial projects can only be two of these three things: fast, good and cheap. UX would sup­port the sec­ond, but sad­ly it is often sac­ri­ficed for the sake of the oth­er two. Not always though, but this is usu­al­ly depen­dent on who is involved with the project:

“[…] it often takes an unusu­al­ly ded­i­cat­ed, per­sis­tent, and pow­er­ful advo­cate […] to see a high-qual­i­ty design project through to com­ple­tion with every­thing that makes it excel­lent intact. […] the painstak­ing­ly detailed work of ensur­ing a good user expe­ri­ence is fre­quent­ly hard to jus­ti­fy on a short-term ROI basis, and this is why it is often one of the first things to get val­ue-engi­neered out of an extend­ed devel­op­ment process. […] we’ve seen that get­ting every­ware right will be orders of mag­ni­tude more com­pli­cat­ed than achiev­ing accept­able qual­i­ty in a Web site, […] This is not the place for val­ue engi­neers,” (p.166)

So if tra­di­tion­al projects need UX advo­cates on board with con­sid­er­able influ­ence, com­pa­ra­ble to Steve Jobs’s role at Apple, to ensure a descent user expe­ri­ence will it even be pos­si­ble to cre­ate ubiq­ui­tous expe­ri­ences that are enjoy­able to use? If these projects are so com­plex, can they be even got­ten ‘right’ in a com­mer­cial con­text? I’m sor­ry to say I think not…

Design­ers (used broad­ly) will be at the fore­front of decid­ing what every­ware looks like. If you don’t think they will, at least I’m sure they should. They’re not the only ones to deter­mine its shape though, Green­field points out that both reg­u­la­tors and mar­kets have impor­tant parts to play too (pp.172–173):

“[…] the inter­lock­ing influ­ences of design­er, reg­u­la­tor, and mar­ket will be most like­ly to result in ben­e­fi­cial out­comes if these par­ties all treat every­ware as a present real­i­ty, and if the deci­sion mak­ers con­cerned act accord­ing­ly.” (p.173)

Now there’s an inter­est­ing notion. Hav­ing just come back from a pre­mier venue for the UX com­mu­ni­ty to talk about this top­ic, the IA Sum­mit, I’m afraid to say that I didn’t get the impres­sion IAs are tak­ing every­ware seri­ous­ly (yet.) There were no talks real­ly con­cerned with tan­gi­ble, per­va­sive, ubiq­ui­tous or ambi­ent tech­nolo­gies. Some basic fare on mobile web stuff, that’s all. Wor­ry­ing, because as Green­field points out:

“[UX design­ers] will best be able to inter­vene effec­tive­ly if they devel­op appro­pri­ate insights, tools, and method­olo­gies ahead of the actu­al deploy­ment of ubiq­ui­tous sys­tems.” (pp.173–174)

This stuff is real, and it is here. Green­field points to the exis­tence of sys­tems such as Octo­pus in Hong Kong and E‑ZPass in the US. Hon­est­ly, if you think beyond the tools and meth­ods we’ve been using to com­mu­ni­cate our designs, IxDs and IAs are well-equipped to han­dle every­ware. No, you won’t be required to draw wire­frames or sitemaps; but you’ll damn well need to put in a lot of the think­ing design­ers do. And you’ll still need to be able to com­mu­ni­cate those designs. It’s time to get our hands dirty:

“What ful­ly oper­a­tional sys­tems such as Octo­pus and E‑ZPass tell us is that pri­va­cy con­cerns, social impli­ca­tions, eth­i­cal ques­tions, and prac­ti­cal details of the user expe­ri­ence are no longer mat­ters for con­jec­ture or sup­po­si­tion. With ubiq­ui­tous sys­tems avail­able for empir­i­cal enquiry, these things we need to focus on today.” (p.217)

So, to reit­er­ate the ques­tion I start­ed with: are there any UX design­ers out there that have made the switch from web-work to ubi­comp? Any­one con­sid­er­ing it? I’d love to hear about your experiences.

Gift outcompetes exchange in design too

I just fin­ished Eric Steven Ray­mond’s Home­steading the Noos­phere. It’s a ter­rif­ic read for any­one look­ing for a thor­ough look at the inner work­ings of the open source soft­ware devel­op­ment com­mu­ni­ty. Like oth­ers, when­ev­er read­ing this kind of stuff soon­er or lat­er apophe­nia hits and I try to tie bits to my own dis­ci­pline, which isn’t pro­gram­ming but design.

In one of the last chap­ters of the essay (titled Gift Out­com­petes Exchange). Ray­mond offers some tan­ta­lis­ing insights into the rela­tion­ships between doing com­plex cre­ative work, moti­va­tion, and reward. While read­ing it I recog­nised a lot of ideas that I’ve long felt are impor­tant but could nev­er real­ly artic­u­late. Now I final­ly have some great quotes, and (over 10 year old) research to back it up!

Psy­chol­o­gist There­sa Ama­bile of Bran­deis Uni­ver­si­ty, cau­tious­ly sum­ma­riz­ing the results of a 1984 study of moti­va­tion and reward, observed “It may be that com­mis­sioned work will, in gen­er­al, be less cre­ative than work that is done out of pure inter­est.”. Ama­bile goes on to observe that “The more com­plex the activ­i­ty, the more it’s hurt by extrin­sic reward.” Inter­est­ing­ly, the stud­ies sug­gest that flat salaries don’t demo­ti­vate, but piece­work rates and bonus­es do.

Thus, it may be eco­nom­i­cal­ly smart to give per­for­mance bonus­es to peo­ple who flip burg­ers or dug ditch­es, but it’s prob­a­bly smarter to decou­ple salary from per­for­mance in a pro­gram­ming shop and let peo­ple choose their own projects (both trends that the open-source world takes to their log­i­cal con­clu­sions). Indeed, these results sug­gest that the only time it is a good idea to reward per­for­mance in pro­gram­ming is when the pro­gram­mer is so moti­vat­ed that he or she would have worked with­out the reward!

Oth­er researchers in the field are will­ing to point a fin­ger straight at the issues of auton­o­my and cre­ative con­trol that so pre­oc­cu­py hack­ers. “To the extent one’s expe­ri­ence of being self-deter­mined is lim­it­ed,” said Richard Ryan, asso­ciate psy­chol­o­gy pro­fes­sor at the Uni­ver­si­ty of Rochester, “one’s cre­ativ­i­ty will be reduced as well.”

So a team of design­ers work­ing in the mode Ray­mond describes would choose their own projects and not be reward­ed for their per­for­mance on projects (which is usu­al­ly mea­sured in effi­cien­cy and client sat­is­fac­tion). In stead, to real­ly keep them moti­vat­ed, they’d be giv­en a large amount of auton­o­my (and would­n’t be instruct­ed on which prob­lems to solve and how to go about it). Of course, this only works with skilled work­ers, but I don’t think that’s the rea­son these philoso­phies haven’t been applied to design work on the scale they have been in pro­gram­ming. I think a lot of resis­tance for actu­al­ly allow­ing design­ers work like this in a com­mer­cial set­ting are relat­ed to a fear of giv­ing up con­trol. Lat­er on Ray­mond fin­ish­es the chap­ter with:

Indeed, it seems the pre­scrip­tion for high­est soft­ware pro­duc­tiv­i­ty is almost a Zen para­dox; if you want the most effi­cient pro­duc­tion, you must give up try­ing to make pro­gram­mers pro­duce. Han­dle their sub­sis­tence, give them their heads, and for­get about dead­lines. To a con­ven­tion­al man­ag­er this sounds crazi­ly indul­gent and doomed—but it is exact­ly the recipe with which the open-source cul­ture is now clob­ber­ing its competition.

When will the first exam­ples appear of design done in this way? When will the first projects pop up that out­com­pete the cathe­dral style designs process (or are they already among us)? Are there any design­ers out there actu­al­ly work­ing in this way? I’d love to hear from you.

Update: I changed the link to Flickr into one point­ing to a post by Tom Coates on how Flickr was built.

On presentations

One of the most enjoy­able things about attend­ing con­fer­ences is see­ing a lot of peo­ple pre­sent­ing in var­i­ous ways. A while ago I chal­lenged my own pre­sent­ing skills by doing a Pecha Kucha. Today, I attend­ed a class (part of a didac­tics course) on giv­ing lec­tures. Two promi­nent lec­tur­ers (Giep Hagoort and Jeroen van Mas­trigt) from with­in the Utrecht School of Arts gave us a taste of their own unique pre­sen­ta­tion for­mat and the way they pre­pared for a talk. 

This trig­gered some things in my head, such as stuff I’d seen before on the web and that could be help­ful to the peo­ple attend­ing the class. A lot of them did­n’t seem to be too famil­iar with it, so I’ve decid­ed to col­lect them here. Maybe they’ll come in handy to those who pass by here:

My Mobile Game Directions Pecha Kucha

Yes­ter­day I pre­sent­ed my talk on mobile gam­ing at the 6th Pecha Kucha Night in Rotterdam’s Off_Corso. I was pro­grammed as the first speak­er, which was excit­ing (and also allowed me to ben­e­fit from the pri­ma­cy effect, as my girl­friend point­ed out). Col­league Iskan­der was kind enough to record the whole thing on his N70 (fit­ting­ly) and I present it here for your enjoy­ment or aggra­va­tion, whichev­er you pre­fer (please take note that the talk is in Dutch). The slides I used are over at SlideShare.

I’m still not sure the sub­ject mat­ter was appro­pri­ate for the event, con­sid­er­ing the major­i­ty of speak­ers were either graph­ic design­ers, autonomous artists or archi­tects. The crowd might’ve been a bit under­whelmed by my com­mer­cial and pop cul­tur­al ref­er­ences. Oh well, I had fun, I guess that’s the most impor­tant thing. 

Many thanks to Nadine and Bart of Hunk Design for let­ting me loose on stage. ‘Nuff respect to all the pre­sen­ters for tak­ing the trou­ble of prepar­ing a pre­sen­ta­tion. There were plen­ty of cool and inspir­ing ideas on show. Final­ly, thanks to the cre­ators of all the images I used, you can find the cred­its in the SlideShare show.

Update: I’ve delet­ed my YouTube account so here’s an embed of the video on Vimeo:



Mobile Game Direc­tions @ Pecha Kucha Night Rot­ter­dam from Kaeru on Vimeo.

Rojo redesign

Rojo has redesigned. It all feels a lot clean­er and more com­pact (as well as slight­ly faster). Head­line scanning’s improved quite a bit. 

The one glar­ing mis­take I’ve noticed is that head­ers no longer link to the orig­i­nal sto­ries, but are some kind of perma­link to the post inside Rojo. You have to click a link beside it, labelled “via [feed name]”. Sil­ly choice!