UmShun is a delightfully competitive multi-player um-word-counting strategic game. Play against friends and other attendees at any conference or presentation. Get the most points by being the first to press the correct button each time the speaker says “um”, “like”, “uh”, or other filler words. Be warned that UmShun causes irreverent giggling, and may get you kicked out of a conference or fired during a board meeting… so try extra hard to be considerate.
Download From the Windows Store
Marketing Points
- Easily find and join others with the live events panel
- See your ranking vs. other “active listeners” on the live scoreboard
- Check out the useful speaker feedback in the live stats panel
- Tweet the stats at any time with integrated Twitter support
- Share detailed scores and stats with other applications
Developer Points
- Hosted on Microsoft Windows Azure
- Uses Microsoft SqlServer to track game play
- Developed in C#/XAML
- Uses geolocation to find local events
- Supports OAuth to tweet game stats
- Provides a sharing contract to e-mail game stats
- Sports a parallax background for good looks
Screen Shot
Notes to Testers
- Imagine someone behind a podium giving a presentation as you test UmShun.
- As they speak, touch the appropriate um word as you hear it. It's that easy.
- The number of times you heard each word is displayed on the word.
- Use the app bar to change the words you are playing
- Use the app bar to configure the multiplayer information/authorization.
- Use the sharing charm to send the stats to any application like e-mail.
- Use the settings charm to authorize twitter to tweet on your behalf.
- Use the app bar to tweet.
Details for Developers
The neat thing about this application is the multi-player aspect. Each time the user hears the speaker utter an “um” word, the user quickly presses the corresponding word in UmShun. In response, UmShun issues an asynchronous post to our aspx page on our Azure-hosted site. The post includes the gamer tag, the word heard, the event name, and the event’s geolocation. This information is added as a new row in a SqlServer table.
Scoring is performed with a rather complex SQL select statement. The idea is that each time you hear a word, we count the number of other users at the same event that heard the same word AFTER you did (and within 3 seconds). This count is then added to your score. The scores of players are retrieved periodically by UmShun via another web request that executes the select statement. The data comes back formatted in XML.
Another web request provides the statistics for the speaker. The statistics provide the average number of times each “um” word was spoken. Finally, a list of nearby events and their current status is also periodically retrieved.
All of the data in these queries are obtained by SQL select statements of the single table mentioned above. There is not a special table that records gamer tags or event names, so there is no need for a user to register an event before playing that event. The user can just enter the event name using an AppBar command, or pick an existing event from the list.
One final feature was added – to prevent players from randomly recording events in the hopes of obtaining a higher score. This is to simply rate-limit words that are played to once every 5 seconds. Therefore, if the user randomly plays a word, they then might miss out on a real word (with higher scoring potential) uttered by the speaker a few seconds later.
It should be clear that in developing UmShun, a lot of work was required to develop the SqlServer select statements and the aspx pages that glue the client to the database.
Isn't it disorienting to switch layout orientation when the user changes to portrait orientation? Seems... well, not right.
ReplyDeleteJerry,
ReplyDeleteI don't know where I got the notion that UmShun should scroll up/down in portrait mode. To me it just seemed right. Also, I thought I read it somewhere.
Maybe it was because I read that snapped mode should scroll vertically so I inferred portrait should too.
So I went back to dev.windows.com and found this "...your app should continue to pan horizontally in portrait view."
http://msdn.microsoft.com/en-us/library/windows/apps/hh868272.aspx.
So that certainly gives support to your concern!
I think I need to make a change. Thanks for pointing this out