Aug 312012

Update: Registration is going up and down. We’re working on it. Be patient :)

You can register from ANY computer, so you don’t need to camp the IGM office if you’d like to explore or enjoy some of the lovely afternoon sun!

We had a brief hiccup in the registration system a few minutes ago, but we’ve corrected it and new registrations are working again. Sorry for the inconvenience!

Aug 282012

Just Press Play is all shiny and new both inside and outside. We hope you enjoy playing with us. Let us know what you like, and what things might be causing you grief. We’ve implemented FORUMS where you can let us know how it’s going and give us suggestions on how to make your playing experience better, or ideas for achievements and quests. Thanks for being here.

 Posted by at 12:19 pm
Aug 272012

We’re starting anew, and that means if you played last year, you’ll need to create a brand-new account on our shiny new system.

What happened the  old achievements? A few went away. Many new ones have replaced them.

While none of your past achievements will automatically carry over, this is not to say that they are gone for good. For example, those who earned “For the Lawls” by making Professor Lawley laugh (not an easy task), may ask her to give you her achievement again. Ditto “Knock Knock” from the most evil Professor Pietruch. Others? May be negotiable.

For those of you who played last year, we have a special achievement.

You've played the game before Title: Early Adopter

Description: You were a player before it was cool.

  •  Earned at least one achievement in JPPv1 (2011-12)
  •  Have the IGM office staff scan your PlayPass
  • If you can’t make it to campus, email from your RIT email account.
 Posted by at 12:02 pm
Aug 182012

The summer has flown by, and we’re now only two weeks away from launching version 2 of the game. And, remarkably, nobody’s panicking! We’re very much on track for our launch date, and that’s due in large part to our learning from our mistakes.

This year, we took on the task of fully redesigning the technology, content, and interface of the game in a single summer–that’s nine weeks to encompass planning, development, and testing. Given that very small time frame, we spent what might have seemed to some people to have been an inordinate amount of time on planning before we ever wrote a line of code. As we come into the final stretch, that emphasis on front-loading the design and architecture (of both the back-end technology and the front-end user experience) is really paying off, as we watch pieces click nicely into place with no last-minute realizations that we missed something critical. So this post is devoted to the topic of what tools and processes we used for that design process, and how and why we used them.

We began the old-fashioned way, by locking all the key faculty and staff from last year’s game in a room for two days and doing an in-depth breakdown of what worked and what didn’t from a game design perspective. What pieces did we want to keep? What pieces were clearly broken, either technically or from a user standpoint? Were our core ideas of what we wanted the game to be still solid? Were our core mechanic for delivering that experience solid? During that retreat, we sketched out the basic structure of how the game could change this year, retaining our core goals and objectives but retooling the presentation and mechanics. Without those two days of intensive thought and planning, we wouldn’t have been able to move forward. That kind of deep-dive design work requires sustained attention, not a meeting here and another there squeezed between other obligations. This was not a high-tech process, either–we relied on whiteboards, notebooks, and piles of index cards (for card-sort exercises). The one technology tool that was valuable during that process was Evernote, since it allowed me to take photos of our white board diagrams and be able later to search for them based on the automatic text recognition.

Once we had a clear sense of direction, the next step was to write detailed functional specifications for the new system. Who were our users, what were our use cases, what content would we have, how would it be presented, and what functionality needed to be supported? This document was primarily my responsibility, because writing specs is not something that typically works well by committee. However, it was an iterative process that required regular input from other members of our team. I wrote the specs in Google Docs, granting read and comment permissions to the rest of the team, and encouraging them to add comment in areas where things were unclear. At the same time, our technical architect (Chris Egert) began creating a data model for the new site, taking into account both what I was drafting in the specs and the need to better record data for ongoing analytics.

As the specs took shape, I worked with Elouise Oyzon, our design lead, to mock up the pages of the site in wireframe form, focusing on functionality rather than aesthetics. We chose to use Mockingbird, an excellent web-based tool for creating application mockups, both because the tool itself worked well for our purposes and because as a cloud-based app it allowed for us to work collaboratively. We paid for the $20/month version, so that we could maintain separate wireframes for the public version of the site, the logged-in version of the site, and the administrative interface. All members of the development team had access to the wireframes, which helped enormously in clarifying the functionality in the specs. As we mocked up pages, I updated and clarified the functional spec to match what we’d determined. Eventually, the mockups became the definitive design document for the whole team, since the visual representation of the functionality was very effective for communicating requirements. Here’s an example from the administrative interface wireframes:

Mockingbird - Admin Wireframe

Once the mockups and the data model were largely complete, our dynamic developer duo of Chris Cascioli and Ben Snyder began work on the actual application engine, which was built using the .NET MVC framework. (We looked at a few other web application frameworks, including Django and CakePHP, but ended up going with .NET because our development team had strong C# coding skills.) Because that part of the project was outside of my expertise, I’ll leave it for our devs to talk about that side of the project. While they toiled in the code mines, though, Elouise and I went back to work on design issues.

To manage the many aspects of the content and visual design production process, we chose to use Trello, a free web-based project management tool made by Joel Spolsky’s company Fog Creek Development. Trello provides a flexible and very visual framework for representing tasks as “cards” that can be moved between lists. Here’s what our “front-end” Trello board looks like today, as we near the end of the process:

(2) JPP Front End | Trello

Trello is wonderful for tracking to-dos, and for maintaining an at-a-glance sense of what’s happening and needs to happen in a project, but I found when we tried to use it for organizing achievements and quests in the game that its limited search and sort capability made it less effective for large amounts of structured content than a spreadsheet or database. I finally ended up moving all of the achievements and quests into a single Excel spreadsheet, which I’ll eventually move into Google Docs.

Our final go-to tool for the design and production was Dropbox, which I have a love-hate relationship with. I love the ease of being able to share documents with a group, particularly for things where there’s little confusion about who can modify the documents–like the folders of icons we need for both print and online representation of achievements. The inability to restrict access in any way in Dropbox is consistently frustrating, however. Any person with access to the file can move or delete it, making it unavailable to other users. There’s no way to make a file “read only.” I’ve begun investigating Microsoft’s SkyDrive as an alternative, but the challenge is getting a large group of people to all be willing to shift their tools and workflow, and that wasn’t a challenge I wanted to take on with this project.

While this particular project was a game, the process and tools I’ve described are applicable to any complex web-based application (and probably non-web-based applications, although I’ve got less experience in that domain). I get asked often enough what’s involved in building a complex website that it seemed worth outlining our workflow in details for others to learn from. If you know of other tools or resources that are helpful in collaborative design and production processes, I’d love to hear about them!

Aug 022012

It’s hard to keep a sustained interest in many things. I think, often there is a tendency to take a plunge, dive in, drink one’s fill and be happy to say, “Been there, done that.”

There have been a bunch of casual games that became a temporary obsession and once over, not revisited. That’s normal. The trick is to find a casual game that has a sustained ability to engage over a long period of time. I don’t think it is possible to have constant obsessive engagement. One burns out. Again — normal.

So my thinking in terms of designing this experience – this Just Press Play thing, is that when we launch in the Fall, I expect there to be a good amount of activity the first week. Then it will taper off significantly after the third. There will be things going on the remaining seven weeks of the Fall quarter, but only the hard core will play.

Our mistake last year was that we didn’t have anything in our back pocket to make the game shiny and new in the successive quarters. I was responsible for organizing “Flash mobs” – essentially, large group ephemeral experiences, which were great. Those were bright and shiny moments, but as I said, ephemeral. Not quite enough a kick in the eyeballs to get people into the game who weren’t already actively engaged.

This is a design problem.

We have a population that do have a sustained interest in playing games. What comes to mind are things like League of Legends, and World of Warcraft. Multiplayer games where they work cooperatively or competitively have an entirely different dynamic. The only reason I dipped my head into WoW last year was because of the people involved. (Granted, even that was not enough to keep me in the grind.)

I am proposing a solution to this. So we roll out Just Press Play in the Fall. Players get collectible cards for every achievement. When Winter rolls around, we provide an expansion pack of achievements, but also a card game that uses the collectible cards. So we have an added game that uses resources from Just Press Play. My thesis is that we snag a different kind of player with this card game, and reenergize those already invested in the game.

When Spring comes, we switch focus a bit and make room for players to design experiences. Some Quests will have an associated card. (Every achievement has a card, Quests – not yet). Perhaps every JPP created quest will have a card. This is me still thinking this through. But the kicker is this — users should be able to group achievements to create their own quest lines. (Some of those may be vetted and earn the ability to have an attached card). Additionally, depending on the success of the card game, perhaps users suggest cards for that as well.

So the long thinking is that we design the game to be pushed in spurts, understanding that a sustained interest is not possible.

 Posted by at 8:55 am