Dan Hickey has a fantastic blog post with a lot of relevance to the goals of JPP. http://remediatingassessment.blogspot.com/2012/08/digital-badges-and-games-for-impact.html
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!
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.
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.
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 firstname.lastname@example.org from your RIT email account.
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:
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:
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!
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.
As Weez said in her last post, we’re changing the look and feel of Just Press Play for the new academic year. But that’s not all that’s changing, not by a long shot. Some of the changes are technical, and we’ll devote a post later to the nuts-and-bolts of the infrastructure. This post is about how things will be changing for the players.
The most obvious change in the mechanics of the game will be around the collectible cards and awarding of achievements. There will still be cards associated with achievements, but there will now be cards for *every* achievement, even the ones awarded automatically or based on materials you submit online. Once you get an achievement, you can stop by the IGM office to pick up the associated card. The cards will be professionally printed playing-card format, and later this year we’ll be developing some card games that you can play with them.
The cards won’t have those impossible-to-enter codes on them anymore, either. We know that lots more people participated and got cards than ever entered them into the system. That meant the mechanic was broken, so we spent a lot of time thinking about how to improve that aspect of the system. What we decided on was to equip anyone who can award an achievement (professors, staff members, etc) with a mobile app that can scan a QR code. Students will still get a keyfob for the game, but instead of RFID transmitters (which we were never able to integrate properly with our game engine) the keyfobs will hold a unique QR code linked to your game ID. When you qualify for an achievement, the person who can award it will scan your code, instantly giving you credit for the assignment. Sometimes they’ll have the collectible with them, other times you’ll need to pick the card up at the office. Either way, you won’t have to enter anything online to redeem the achievement. (For faculty and staff who don’t have mobile devices, we’ll provide a web interface they can use to assign the achievement.)
Another big change is in the core mechanic of achievements, quadrants, and “leveling.” We’ve changed the quadrants to four distinct categories–Create, Learn, Socialize, and Explore. Every achievement is worth 4 points in the system, and the points can be all in one quadrant, or distributed across 2 or more. There won’t be levels in the same sense that we had them in the past, either. All achievements and quests will be available to all players. We’ll reward players with achievements for reaching certain milestones (for instance, 25 points in each quadrant), but the levels will simply be progression markers, not restrictive barriers.
We’ve also added repeatable achievements into the game, which we’ll use for things like the “Flocking to Hockey” achievement. Go to one hockey game and find the JPP rep and you’ll get the base achievement. Go to 5, and you’ll get the next achievement in the series. Go to 25, and you get yet another achievement. We’ll use that mechanic for a variety of repeating events.
For every achievement you earn, you’ll be able to upload an optional text narrative and/or photo to help remember the activity. We hope this will allow people to build a nice record of the activities they engaged in to get the achievement.
And finally, you’ll now be able to make your achievements public if you’d like. By default, your achievements will be visible only to your friends in the JPP system. But you can opt to make them visible to the outside world, and even share them on Facebook if you’d like.
We’re excited about these changes, because we think they’ll make JPP more accessible and enjoyable for our players. What do you think?
There is a reason for a beta phase. You see what works; what doesn’t.
The previous designer was told to go light, and playful and colorful. It didn’t quite hit the mark. A mid-year revision reworked the palette and some of the elements, but it didn’t change greatly.
With this new year comes a decisive overhaul of Just Press Play. There is much happening under the hood, but I can speak to the portion that is visible to the outside. The goal is playful, vibrant and alive. With that in mind, the graphics are solid. There is not a gradient to be found. There are no faux bubbles, nor drop shadows. The rework continues.
So we launched with great fanfare on Thursday, October 13.
And we broke.
And we launched again in a much quieter fashion at 2am, Monday the 17th.
Launches come with great fanfare – true. It is also true that they come with nail biting, tears, fantastic levels of adrenaline, euphoria and panic.
It is now the 28th – a little more than two weeks from the beginning and there is a mixture of great success and hobbling along. The successes do outweigh the hobbling bit. We have a good game here. The students are playing. Many are engaged.
After catching up on some sleep, and a modicum of recuperation, it has been a time of reflection for the entire team. The core players that comprise the designated adults of this venture are digesting significant life lessons. Code, media, text and all the attendant bits are interesting to wrangle. Navigating through feelings, process, and agency, discovering when to support and when to kick ass – that’s the tricky bit. I believe I can report as a team and friends, we are closer and have a greater self-awareness than we began this.
Has it really been two months since we posted anything here? Apparently so. Once we got our funding, all our energy got channeled into the developing, rather than the talking about the developing! We’re making a lot of progress, though, and today at the Games in Education conference I gave a talk about the system and what we have planned.
The presentation is available on Slideshare (http://www.slideshare.net/mamamusings/just-press-play-a-gaming-layer-for-student-success). I could embed it here, but the slides are mostly images that won’t make a lot of sense without the speaker notes–if you go to the Slideshare site, you can toggle the speaker notes on to get that context.