Category: ruby

Atlanta, ruby, startups, Technology

Why I created Badgy

Posted on by rkischuk

Saturday afternoon, I announced the creation of Badgy at http://bad.gy/.  Simply put, Badgy is intended to be a social game for Twitter (@BadgyApp) that fits naturally with how people already use Twitter.  I’ve referred to it as a “native” app, which means that it’s written around the capabilities of Twitter, not copied from some other game that worked on Facebook.

If you haven’t used Badgy yet, just mention “badgy” on Twitter to get started and get some context for the rest of this post.

Initial feedback has been somewhat mixed but overall encouraging.  Some users disagreed with the retweet required to earn the second badge.  Some people just don’t get it.

It seems helpful at this moment to reflect on why I created Badgy, and why it’s built the way it is:

  • Fred Wilson wants games – in a recent blog post, New York VC and Twitter investor Fred Wilson reflected on the state of the Twitter platform and what sort of apps might succeed on Twitter.  Many of these areas, such as enterprise, discovery, and analytics represent areas where Twitter could either create or acquire a single company to cover the gap, but he also mentioned social games.  The problem with social games on Twitter is that…
  • Current Twitter Games Suck – “popular” games like Spymaster motivate you to follow people you aren’t friends with and tweet things your friends don’t care about.  In essence, they are Mafia Wars clones that are too invasive and render your Twitter account useless.  Fun!  A proper Twitter game should be compatible with how people already use Twitter.  (FourSquare doesn’t count as a Twitter game – it is a mobile app game that uses Twitter as a promo channel.)  Although ever so slightly intrusive, asking users to mention “badgy” on Twitter to begin playing is totally native and much less awkward than going to a web site to join a Twitter game.
  • People Love Badges – Look at FourSquare badges, Facebook game bragging opportunities, or achievement systems in console games and you’ll see that people LOVE to feel like they’ve earned something and can brag about it.  Using badges as the basis of a Twitter game seemed totally natural.  Someone I follow on Twitter once said that they wished Twitter would give them some recognition for tweeting exactly 140 characters.  I’ve often felt the same way.  Something like Badgy can do that, and recognize many other interesting Twitter actions that are totally natural to Twitter but still fun to recognize.
  • Twitter Integration – I wanted to learn how to integrate with Twitter.  The combination of the tweetstream and twitter Ruby gems made this easy.  The ease and power of Twittter’s APIs gives me new respect for Twitter’s platform team.  It takes literally 3 lines of Ruby code to receive near real-time notification of every Tweet matching a set of keywords, leading to a fast…
  • Fast Minimum Viable Product – it was relatively easy to find people who mentioned “badgy” and reply to them, giving them a badge.  It was not easy to check the Tweets of a bunch of individual users and see what else they said, which is why the Square One badge is given when you retweet the message giving you the Badgy badge.  Sure, the retweet promotes badgy, but it was also easy to search for that unique phrase, retweeted, rather than starting to follow individual users.  The badge requiring a retweet is a bit intrusive, and will not be a key pattern for future Badgy badges.
  • To learn – Game mechanics and basic motivation tactics aren’t just part of games, they are a useful ingredient for almost any software.  Badgy itself may become a vibrant game, or it may serve to teach lessons that make other games and applications I write better.  If nothing else, Badgy provides an avenue to rapidly test and measure theories about what does and does not work in social games on Twitter.
  • Fun – It’s fun to make games and watch people react to them
  • Potential Business – on top of all of the other reasons, there are actually some interesting applications of the technology that would be needed to fully build out Badgy.  Time will tell.

A couple of obvious questions have been asked:

  • Why nag people to retweet their first badge? – This decision was part technical compromise, part promotional decision, and part social experiment.  It’s difficult to rapidly scale following individual users.  It’s easy to track keywords.  This decision helped launch Badgy sooner.  I was also curious what types of Twitter user would be willing to retweet our Tweets to their audience to get a virtual badge.
  • Why only 2 badges? – It’s enough to prove the idea.  Get people to “sign up” by mentioning the fairly unique keyword “Badgy” on Twitter, and see how many people would respond to a request to retweet to earn another badge.  Some people are willing to incorporate Badgy into their Twitter behavior.  Badge #3 will be less obtrusive.

I hope that you will give Badgy a try and give feedback and suggestions on what you’d like to see next.  I hope we see more Twitter games that don’t suck.

Advertisement
4
Atlanta, ruby, Sports, startups, Technology

Touchdown Nation finds a rhythm – Atlanta Startup Weekend 3, day 2

Posted on by rkischuk

Touchdown Nation was formed yesterday (the name was updated from Football Nation so we could secure a web domain, twitter account and be unique on Facebook).  As a part of Atlanta Startup Weekend 3, we’re building an engaging social game for Facebook in less than 3 days.

The first 24 hours of Startup Weekend are a volatile time.  During ASW1, a huge swath of business and marketing types ran away after we chose to work on Skribit, and more attrition followed during early and mid Saturday afternoon as the team lurched into action.  During ASW2, many, MANY teams flamed out when they realized that the person who pitched the idea was trying to find free development & sales labor to build their idea in the coming months.  This year, at least 2 of the 8 teams totally cratered in the first 24 hours.

It happens.  Teams realize they can’t agree on what to build, that they can’t build what they want to, or that someone else already built the whole thing.  It’s not always a reflection on the people involved.  In some cases, I think it IS a reflection of the idea pitched.  Vague pitches about ill-defined products that will take a year to build are recipes for team implosion.

The first 24 hours of Startup Weekend are kind of insane.  You have teams of 5 to 20 people trying to get on the same page to figure out exactly what their project is, how to make money, and how to work effectively with a dozen strangers.

Touchdown Nation was no exception.  We had a great working session on Friday night deciding many of the things the game was and was not.  It changed a decent bit from my original pitch, or at least what I had in my head, which is a good thing and a great reflection on the team.  We came into this morning with a list of things to get done by noon, and we basically hit all of them, but there was still this sense of urgency.  We had a loose plan, a new name, and the technology infrastructure was in place, but hadn’t had any time to actually build the technology, the business, or the marketing.  It’s an uneasy feeling, which makes people on a team want to spend more time generating certainty instead of building something.

In the afternoon, we started to do less planning and more doing.  There are amazing times in startups where I believe the core team is in a rhythm.  In a rhythm, people on different teams understand the common needs enough that problems are worked out in conference calls, not huge meetings, and I believe Touchdown Nation hit that stride today.  When everyone is running toward the same goal, you need less meetings to reach that goal.  Course corrections happen through natural conversations, not huge meetings.

We hit that moment today.  Code started flying, blog posts started getting posted, you name it), but we got everyone technically ready to do their job.

That’s enough for now.  We”re very exicted and having a blast.  Check out @TouchdownNation for the latest news.

Game On!

-Rob

ruby, Technology

Flex Remoting in Ruby? Easy Choice.

Posted on by rkischuk

I’ve had a rocky relationship with Adobe Flex.  An awkward attempt to migrate an existing app to Flex caused several strong reactions and cost a good bit of developer goodwill.  The details of that decision are messy and irrelevant.  The experience sucked.

On the other hand, I could not have built the FeatureFrame technology without Flex.  There’s no simpler way to build a widgetized video player with embedded applications.  The same pains of horrible documentation, irrational design decisions, insidious bugs, and painful workarounds remain, but the things it makes easier pale in comparison to the obstacles of any other approach.

And of course in building a virtual world such as Elf Island, Flex is an obvious choice if you want to play it in the browser and build maintainable code (binary Flash files make a poor foundation for a sustainable product).

For most languages you might want to build a Flex app in, free, open options are available.  I had a recent need to prototype a solution that might also turn into a test fixture for our vendors to use in producing Flash apps, so Rails seemed the natural solution for simplicity of deployment and prototyping speed.

The main choices to support Flex Remoting calls in Ruby are RubyAMF and WebORB.

In trying to decide, I encountered a very useful comment in this thread:

"The biggest difference between what WEBorb provides and what RubyAMF(only
AMF alternative I am aware of) provides is workflow.  Weborb is a great
product written by guys who do java primarily.  So it follows the patterns
of having a Service layer that connects you to your application.

RubyAMF is written by a ruby developer."

Immediately, I know what my choice is.  WebORB is obviously the trap of over-architecture and suffering that pervades “correct” Java development.  A quick search on how to use RubyAMF (in a controller) confirmed my suspicions:


respond_to do |format|
format.html # index.rhtml
format.xml { render :xml => @people.to_xml }
format.amf { render :amf => @people }
end

When I see code like this and compare it to the WebORB or GraniteDS implementations, I just can’t imagine choosing those other paths.

Rails + RubyAMF is concise, clean and obvious in what it’s doing.  Yes, please.

3