Archive for juni, 2011

Gamification by Design

fredag, juni 17th, 2011

The book starts out with what has become Gabe Zichermann’s
standard take on Gamification, and with good reason, as it covers
the basic introduction to the subject, as well as some of the
conundrums, thus we pass by:

  • Broccoli
  • Where in the World is Carmen San Diego
  • Greenstamps
  • 10:1
  • SAPS
  • Project Runway vs. Deal/No Deal

We get a short introduction to Flow by Mihaly Csikszentmihalyi,
operant conditioning, Skinner boxes, Bartle player types, and why
people play. These are fundamental things for people in games not
just for people interested in gamification.

I don’t quite get the linear level description:
[PDF] Page 49 “In game design, level difficulty is not linear. In
other words, level one is not half as complex as level two, which is
not half as complex as level three, and so on. Instead, difficulty
increases in a curvilinear form.”

As I read this, then the description says:
lvl1 = 1/2 lvl2
lvl2 = 1/2 lvl3
but then lvl1 = 1/4 lvl3 – this is not linear but a power function:
lvl n = 2^(n-1) lvl1

Which is quite similar to the D&D and AD&D level progression tables, and curvilinear to boot. That said, it is an ‘Early Release’ and it could be fixed.

Then we get to Leaderboards and Badges – the “ooh, I think we can do that”-slap-on and call it Gamification that a lot of people are saying is “the only way” of doing gamification for anything and everything. That is not Gabe’s way of doing it, but as the book is a sort of cookbook, it seems stupid not to touch upon the subject.

The Ruby implementation of a point scoring forum I could live without, but – again – it would seem weird to have a cookbook without examples.

There’s an introduction to Bunchball integration including some rather useful tips on what to be aware of when designing.

The big hit, I would say, is the sadly brief coverage of the virtual economy, this time using BigDoor as an existing API vendor.

All in all: Yet another “required read” by Gabe Zichermann and Christopher Cunningham

The shortest path is rarely the smartest.

lørdag, juni 4th, 2011

As Einstein said:

“Everything should be made as simple as possible, but not simpler.”

Even so, we – as software developers – tend to skip corners for the sake of delivery or to appear productive. We ought to know better, we ought to know that, e.g. unit testing improves on the quality of code produced, yet still we keep on thinking that that’s crossing the stream to find water.

If we were to live our lives using the same daft assumptions, then we’d either tie our shoelaces only using the uppermost holes, or – being programmers – use the traveling salesman’s solution, visiting every hole in the shortest path possible, in essence making a simple loop. Neither of these fulfills an adequate shoe lacing.

The simplest working shoe lacing is the American style – the zig-zag we’re familiar with from sneakers.

different simple lacings

different simple lacings

So is the issue that we don’t see the problem, and therefore there is no problem? Are we simply ignoring the problem because we think it’s a trivial thing? Are we simply not aware of the fact that other possibilities exist? Or are we going as simple as technically possible without seeing that it’s simpler than logic and sensibility should have required?

Event Based

Instead of simply hard wiring the code to do our bidding, it is often more reusable and perhaps more interesting for other developers to build on top of what we already have. This is often the reason for providing APIs. But APIs only do so much, they are reactive parts not really proactive, and as such – being a one direction service – are providing less usefulness.

The most often used notion of bidirectional systems is event based, or some other form of publish/subscribe. Usually this isn’t prevalent in standard code – probably because as a developer you think you know all the possible uses of the system. You have high coupling because the code is assimilated into, well, the code. Sometimes this is fine, sometimes it is not. Often it leads to God objects.

God Objects

God objects are the objects in which you put everything and the kitchen sink, and they are used all over because they are just so useful. Often they consist of thousands of tokens and every conceivable method, e.g.

boolean isSet(Object o) { return o != null; }

Besides stupidity, they often scoop up any utility functionality often just because the object is included anyway, and it seems that simply adding one more function wouldn’t matter, and the bother of creating a new class in a new file simply doesn’t seen to be worth the bother. Thus you end up with an object capable of formatting time, currency, chopping text, html, etc. Some of it is redundant since newer JDK versions, but tidying up never seems to be touching the God object – it’s in use so many places that the workload of altering one method would propagate to hours of work fixing the dependencies.

God Package

Sometimes the God object has an evil cousin: The God package. This is a package where there’s no real connection between the objects in the package, but apparently the cut is difficult to make – or deciding upon a fitting sub-package structure is not a worthy cause. God packages ends up with more than a few hundred classes, some even reaching several thousand classes.

But then, there are other issues such as taxonomy failure, where we believe that if we can just get the right system from the start.

Taxonomy Failure

At some point everyone tries to file a set of items according to one taxonomy system or another. Whether it is e-mail by sender, movies by category, music by album, artist or genre we almost always end up with a broken system. That’s because we’re trying to generalize something, which ends up not fitting into the generalization. Then we start with exceptions to the rules, then exceptions to the exceptions.

E.g. all birds can fly, except ostriches, emus, and cassowari … but these can run rather fast. Except penguins! Okay – if the animal has a beak, it’s a bird, except tortoise and platypus.

We’re always trying to fit things into tree hierarchies, and they rarely fit – most likely because the tree is the simplest graph.

“Stupid is as stupid does” – but stupid is also not fixing the discovered stupidities of old – yes, this may end up in circles where you later learn than something seemingly stupid was done, but that there was a very good yet undocumented reason for doing so. It’s all about (in)competence levels.