Gamification and Serious Games

As part of a Serious Games/Gamification course, I was directed to read/watch the following links in order to get a better idea of Serious Games and Gamification.  Below are summaries of the main points, and what I took away from the experience.

Meaningful Play: Getting Gamification Right

Sebastian Deterding

“I basically made a game out of it by deciding ok, I imagine there is lava and...I should not step on the little cracks in the pavement, which turned that very boring walk home less boring, and more exciting for me.”

User experience designer and game researcher, Sebastian Deterding, summarizes a few attractions of Gamification and discusses what's frequently missing from implementations. Long and dull tasks can be made more bearable by means of make-believe: creating interesting rules and challenges. Daunting tasks can be broken up into smaller sub-goals, which provide more frequent feedback, to make them less daunting. Providing an unobserved, unregulated space to play can lead users to learn and explore.

Deterding expands on these attractions, defining the aspects of Meaning, Mastery, and Autonomy (respectively) as areas of Gamification that are often overlooked. Goal-setting can be a driving force for user participation, as long as the goals are clearly defined, paced, layered, and varied. These goals are more desirable if there exists a community of users who share a similar interest. Adding storytelling elements can help add meaning to the user's goals and actions. The author reminds designers that play is voluntary, and users should be guided not forced to perform tasks. He also warns of some pitfalls such as gaming the system (emergent behavior), devaluing of service (offering sweepstakes for sign-up/participation), and creating social awkwardness.

Gamification is Bullshit

Ian Bogost

“...Gamification is marketing bullshit, invented by consultants as a means to capture the wild, coveted beast that is videogames and to domesticate it for use in the grey, hopeless wasteland of big business, where bullshit already reigns anyway. “

Media Philosopher, Ian Bogost, addresses the over simplification of the of the video game allure into “Gamification”. Bogost uses the term 'bullshit' to demean the intelligence of corporate officers, who he claims treat Gamification as a trendy, buzz-word check-mark, right next to social media. He believes that, despite the critiques of players and game designers, Gamification continues to be reduced to “adding points”, a simple, repeatable process which instantly makes things better. Bogost offers the term “exploitationware”, as the term for the capitalization upon video games by sellers with “questionable expertise”.

Gaming Can Make A Better World

Jane McGonigal

“...gamers are a human resource that we can use to do real-world work..”

Game designer, Jane McGonigal, pitches the idea of harnessing the average gamer's time, enthusiasm, and skills, on a global scale, to solve serious, real-world problems like world hunger and global warming. She identifies the feeling of constantly being on the verge of an “epic win” as the addictive quality of gaming. She also notes that the feeling of being “bad at life”, and the fear of failing drive people away from trying hard in the real-world. McGonigal cites Malcolm Gladwell's 10,000 hour rule (that spending 10,000 hours on a single task will result in mastery of the task), and the fact that today's average child will spend 10,000 hours gaming by the time they turn 21, as the advent of a generation of “virtuoso gamers”. She provides historical precedence by telling the story of the kingdom of Lydia, who's ruler stifled civil unrest amidst a twenty-year famine, by ordering citizens to play games to distract them from their hunger.

Everything You’ll Ever Need To Know About Gamification

Tadhg Kelly

“ It only works if you reduce your objectives to the improvements of one quantity that players can influence and one kind of emotion sitting behind that. “

Game Designer, Tadhg Kelly, provides a set of guidelines for Gamification, three different “kinds” of Gamification, and discuses the mindset required to implement Gamification. Kelly suggests that designers create a numeric representation of success, but warns that this number must be meaningful, and not overly complicated. A game should be simple enough that it can be summarized in one sentence. Kelly notes that users need direct feedback and that they like immediate gratification/rewards. Kelly notes that following pedestrian mechanics (badges, levels, and experience points) can be boring. Moreover, he states that mimicking another game too closely will simply breed contempt from users. Kelly identifies three drives that keep users playing: validation, completion, and prizes. Validation is provided to users in the form of increased popularity, social approval, and community forming. The feeling of Completion rewards users for putting forth substantial personal effort, and serves as an intrinsic motivator. Prizes (extrinsic) can be useful as they drive users to participate, but users will only play as long as there's a carrot in-front of them.

The Game is a Lie.

After going through the above resources, I can't help but feel like the difference between Gamification and Serious Games is in the implementation details, but that neither should include the word “game”. If one were to take a serious website, and apply Gamification, it might be called a Serious Game. At the same time, a Serious Game that wasn't designed very well might be viewed as something that was Gamified.

I want to believe that Gamification is bad. It sounds bad. It sounds lame. It sounds to me like a shallow copy of badly implemented video game mechanics. I watch as Deterding pull up sites like tumblr and Stack Overflow, and think to myself “these aren't games, serious games must be better”. They aren't. I cringe as I hear McGonigal say that one of her games wants users to imagine a scenario, and blog about it. This is homework, not a game. While some games may require “creative thinking”, no successful video game ever required writing. I am a gamer, and I am lazy. I will solve puzzles, complete quests, and kill indiscriminately. I will not blog to play a game. These examples are not “games”, what's really meant by “game” is “motivation”. Not the same.

I believe Serious Games can be both entertaining and solve serious, real-world problems (See Foldit and freerice.com). I also believe that Gamification can make things less mundane (maybe even “fun”). However, I don't think either of these two ideas will ever fully match the addictiveness and entertainment value of a true, triple-A rated video game.

The Grid

As the semester draws to an end, so too does this project.  PM gave us notice that this would be the last week we work on our sites.  I'm a little sad to see it be over, there have been some really neat ideas, awesome designs, and creative solutions.  It was fun to see what everyone else was doing from week to week.  Plus, have multiple people working on the same problem made the project a whole lot less stressful.  It took away a lot of the burden and mediocrity of what otherwise would have been a belly flop into a sea of endless divs . 

My goals for the last week were to finish cleaning up the site (the energy, prizes, & activities pages).  I also wanted to integrate Elton's Epic Grid.  I'll simply point to Elton's blog, and leave it up to the reader to educate themselves.  Elton's Grid is pretty slick.  At the last meeting, Elton pulls out his phone, brings up his Grid, and the group is wowed.  He pulled it off.  He made a hulking 9X12 interactive grid fit on a mobile screen. 

So of course I had to beat him... of course.  But the fact is, I can't.  Elton did a bang up job, the only small thing I could add was to fix a small issue where the title boxes for each row overflowed.  I did so by rotating the titles sideways, and elongating the divs.  The result is that the gird fits nicely on a 290px wide screen, which is just about any phone screen in portrait mode. 

Desktop View

Mobile view

Back to Square One

So after a pair of meetings on Friday, the PM lays out the following requirements for the Homepage:
1.  It should be in a list (and wrap freely)
2.  Elements should always be centered.
3.  By default, 3 elements per row.
4.  Flexible enough for 6-8 elements.
5.  It should be responsive.

The list seems simple enough, but in reality, items 1 and 5 are contradictory.

The original homepage had two rows of three elements (there were only 6 elements at the time), which were responsive, but overflowed their rows.  The result was that each row of three elements rendered as two elements pushed to the left, and one lone element wrapped on the next line.

My fix for this was to throw all the elements in a list, so that they wrapped freely, maximizing the number of elements in a row.  But this caused difficulties in centering elements.

The (lame) solution was to simply fix the over-flow problem, and have two rows of responsive elements.  However this looks strange on a very wide monitor, as you have three super long elements in each row.

The ultimate solution would probably to use jQuery or MVC-templating to dynamically determine how many elements to put in each row based on the screen size, and handle margins accordingly.  However, I felt like the PM might view this as "hackish" or too time-consuming, and so avoided it.

The Latest Build

Mobile view

Anyway, back to the meeting.  The PM tells us to ignore the larger screens for the moment, and try to get something that works well at a width of 1050px (his laptop resolution) and lower.  My latest bid goes back to square one: fixing the responsive rows to keep them from overflowing.  I did however integrate the multi-column mobile view from last week. 


A cool trick that I picked up this week was the use CSS selectors

:nth-child({ number expression | odd | even })
and

:nth-of-type({ number expression | odd | even })

I'll direct you here for a more detailed explanation and some nice samples:
http://css-tricks.com/the-difference-between-nth-child-and-nth-of-type/

But essentially they let you (in CSS) select elements of a parent using values and expressions.  Notably, they let you select every other, every third, or every nth element.  In my case, I used them to select the seventh element and give it a margin-left: 20%.  This essentially centers the last row of elements.  Neat right?

Link to the file in question:
http://kukuicup-rui.googlecode.com/svn/trunk/Bloggable/4-17-2012/home.html

and the CSS file:
http://kukuicup-rui.googlecode.com/svn/trunk/Bloggable/4-17-2012/css/home.css

Sometimes the Best kind of Responsiveness is no Responsiveness

After playing around with the HTML, and exploring Twitter Bootstrap's CSS, I've finally found the difference between class="row-fluid" and class="row".  Both containers scale with the page size, but row-fluid will also scale the components within that fluid row.  A plain row will keep the items a static size, and wrap them when there's not enough room.  After this week, I can appreciate having both options. 
  When doing my news page, I had the choice of either letting my elements flow and wrap as the page re-sized by using rows or making them stay put simply scale using row-fluid.  I would have opted for the standard row, but there's still a little bit of glitchyness caused by the overrides to the Bootstrap codebase made by senior developers.  So I ended up going with the fluid rows to keep things from hopping around excessively.



  Speaking of trouble with jumping elements, I had an issue in my homepage.  The homepage normally features several large icons-links with accompanying text.  Originally these icons were centered above the text, but I felt that this took up too much room, and so pushed the images inline with the text, and pushed them over a static number of pixels. 






This caused chaos when the divs were re-sized, images and text boxes went flying ever which way.  To rectify this, I had to make sure that the divs stayed a static width.  This effectively meant I couldn't use Bootstrap's built in responsiveness (but that didn't prevent me from trying for several hours).  Anyway, after a hard-fought but pointless battle, I realized I had a simmiliar issue weeks before.  The news page features a widget called "Lounge Members" which is made up of a div containing imagelinks that don't scale, and arrange themselves to fit within a scaling div.  Bingo.  After looking through the source, it turned out that the widget was an unordered-list (<ul>), with each imagelink being a list item (<li>).  To fix my homepage, I did the following:

<div class="dynamicallyResizingDiv">
    <ul>
          <li>
              <imageicon goes here>
          </li>

         <li>
              <imageicon goes here>
         </li>
        ....
   </ul>
</div>

 Of course I messed around with the margins on the li elements to make things look pretty.  And now that's sorted.


links:
news page: http://kukuicup-rui.googlecode.com/svn/trunk/Bloggable/news.html
home page: http://kukuicup-rui.googlecode.com/svn/trunk/Bloggable/home.html

BootStrap Take-2

So after playing around with bootstrap for the past week, I've come to the conclusion that it's pretty smart.  I mentioned last week a potential problem regarding the arrangement of divs of varying heights.  Well, it was a non-problem, I just threw the divs in question into another div and gave that div a span6 class (which makes that div dynamic).  I also gave a row three span6 divs (the sum of spans in a row should not exceed 12), and it handled them nicely, aligning two on the same row, and throwing the third to the next row, left justified.  The biggest challenge in this project is that the senior development team overwrote the auto-sizing/dynamic placements with media queries so that the navbar and infobar (the two strange looking bars) would span the entire width of the page.  This means that I have to handle my own margins, and that some of the custom-defined scaling parameters cause bad/awkward placements at some browser widths.  I've been trying to deal with these oddities on a case-by-case basis, but I've ended up writing a long series of media queries for very small,specific ranges of width.  Not very dynamic at all.  I think the solution in this case is to ditch the screen-spanning nav and info bars (plus the overridden CSS), and maybe use a hero-unit (one of BootStrap's features) instead. 

"A difference that makes no difference is no difference".
At the last meeting, I had a discussion about using rows vs fluid rows (class="row-fluid") .  It was advised that I use fluid rows, but from what I've seen so far, the difference is negligible.   This might stem from the fact that some of the CSS was overridden. It may end up being of some significance down the line, but I'll deal with it when I get there.  In the mean time, I can't complain about the performance of standard rows.

LESS is GREAT!
Last entry, I griped about how it had to be compiled, but honestly, it isn't that bad.  But after getting to play around with it, I found that "LESS-ifying" my CSS files was a simple matter.

<link rel="stylesheet/less" type="text/css" href="your-theme.less">
<script src="less-1.3.0.min.js" type="text/javascript"></script>

The above snippet is all that's needed to "compile on the fly".  Essentially there's a .js file that compiles the .less file on demand.  Pretty nifty.  My biggest fear was having to compile a LESS file every time I made changes, but this approach is just wonderful :).  For performance, once the LESS file is perfected, it can be compiled to a straight CSS file for faster page loads.
 
Here's the link to the .js file: http://lesscss.googlecode.com/files/less-1.3.0.min.js

Twitter Bootstrap & Dynamic CSS

BootStrap
This past week I took a look at BootStrap, Twitter's New(ish) RUI Framework.  Overall, I'm fairly satisfied with what I see.  Bootstraps similar enough to other RUI frameworks (like Skeleton, SimpleGrid, etc.) that it's easy to get into if you have prior experience, but offers a bunny-hill of a learning curve even if you haven't.  Being grid-based, it offers the usual flexibility of defining dimensions based on columns (the responsive grid offers 12 columns in a 960-pixel page), or fractions (one-third, one-fourth, etc).  It also offers basic alignment and in-lining class definitions, but nothing really special. 

 Aesthetically, BootStrap's default theme is very clean, with a color pallete of white, soft-greys, and bright blue accents.  This makes it great for quick mockups that still look professional.  Of course, these can all be overridden, and when combined with BootStrap's compliment of well-drawn icons, makes for a nice "grab-n-go" package.

Where BootStrap really comes into it's own is in it's Responsive package.  The elements scale very nicely, down to a certain point before jumping into a mobile-friendly, wikipedia-style format.  I also appreciate how navigation links collapse into a drop-down menu for easy access that doesn't take up a lot of screen space. 

The PM linked our group a nice little tutorial:
http://webdesign.tutsplus.com/series/twitter-bootstrap-101/

With respect to the Kukuicup site, it seems like moving to BootStrap would be fairly straight forward.  (Note I didn't say easy)  I'm thinking that the "widgets" can be migrated into the gird fairly easily.  The only obstacle I can foresee is that the widgets are different heights, and BootStrap probably wants divs to be the same height.  This might cause issues where the left side of a page is one long widget, but the right side has two shorter ones.  This might be overcome by using negative spacing to "stack" the two shorter divs on top of each-other.


LESS (and it's peers, SASS & CoffeScript)
The PM also raised concerns over the high-levels of repetition within the Kukuicup CSS files, and suggested LESS as a solution.  LESS is a Dynamic CSS language that lets you create methods and variables for CSS files.  For example, one could define a variable

@primarycolor: #FFF; 

and reference primarycolor anywhere in the CSS.  Additionally, LESS allows users to apply classes to other classes by adding the .class notation into another class definition.  For example, I define .shadow to have a drop shadow, I can add that shadow effect to a .box class by

.box {
      .shadow
}

Finally, LESS supports paramaterized methods, for example, letting you dump

     //radius defaults to 5px
.rounded-corners (@radius: 5px) {
      border-radius: @radius; 
}

#header {
      .rounded-corners(10px);
}

The downside to all this is that it requires compiling.  In a world where scripting languages run the web, this seems a bit odd. 

Kukuicup Design - pt III

This past weekend, the PM responded to my submission, and that both have "potential".  Additionally, he posted a laundry list of improvements to make to all of our sites.  The most notable item was that none of us had really touched the info, nav, and quest-bars.  I had been under the assumption that we weren't supposed to touch these.  Moreover, I had actively chosen to leave the quest-bar in theme-2 black. 

In our last meeting, the PM elaborated on his list of grievances, and noted discontinuities in shadows, rounded/square corners, and color palettes for the aforementioned bars.  So I spent this past week trying to revamp these elements.  Initially I tried using an image manipulation program to modify the existing images, but found it EXTREMELY difficult to get the radial widths (despite knowing their values) of my rounded corners to match with those generated by the webpage's CSS.  After a while I realized this approach was a dead-end and ditched it.  My next (and only other obvious) avenue of attack was by manipulating the images/divs with HTML/CSS.  As it turns out, this works really well. 

I ditched the actual image, instead compressing the containing div, and using a combination of padding and margins to keep things in their proper place.  In the illustration, the blue area is the actual div that contains the area highlighted in yellow.  Naurally, shrinking a div of this size down creates layout problems.  I was able to overcome this by adding a small top margin and a giant bottom margin (margins are shown as the yellow area).  This keeps elements in their proper place, while allowing me to use the encompassing div as a useful background for my nav and info bars.  The rationale behind this whole song and dance is  that I can't actually mess around with the html files, as they have to be the same for every theme.  So I had to use CSS to mess around with existing divs.

I also found that I was able to make transparent gradients using the rgba() method.  For example:

    background-image: -moz-linear-gradient(100% 30% 90deg, rgba(239, 214, 120,.67), rgba(255, 255, 255,.67));
    background-image: -webkit-gradient(linear, 0% 0%, 0% 50%, from rgba(255, 255, 255,.67), to rgba(239, 214, 120,.67));

the above two lines normally define a gradient, but by using the rgba method, I was able to set an alpha transparency, and make them transparent.  Neat trick.  The only caveat is that you have to convert color codes from Hex to Decimal.

I present, the finished product: