@andrewchen

I was always more of a Barren Realms Elite fan, but this picture was cooler!

And now you learn how I spent my childhood…
Some of the fondest memories from my childhood are playing BBS door games. Back before the web existed, I was a 10 year old kid in Seattle dialing into 3 or 4 different  different BBSes using a pirated version of Procomm Plus. There, I found that you could download all sorts of awesome products (though in 20 different parts, which you had to put back together), and more importantly, they had the ability to launch “door games” like Tradewars 2002, Legend of the Red Dragon, Barren Realms Elite, and a number of other games I grew to love. I spent so many hours tying up the phone line after getting back from school that eventually my parents banned me from playing these games – but that only convinced me to set an alarm for 3am to wake up in the middle of the night to play!

Furthermore, it became a critical thing in my life to get all my friends from school to also play these games with me. Together, we’d team up into a powerful, coordinated unit, and dominate the other players on the BBS and regional network. (Or at least that was the plan) Eventually years passed, I learned the internet was more than gopher, and I moved on to better and more powerful massively multiplayer games.

It’s obvious, in retrospect, that a lot of the door games that existed 20 years ago pioneered a lot of the same techniques that social games use today. Let’s drill into a bunch of these similarities, covering the following topics:

• Door games are the “apps” to the BBS platform
• Social gameplay with friends and neighbors
• Turn-based, RPG-like gameplay
• Low-tech graphical experiences, delivered as a persistent social experience

If I’m missing anything, please leave a comment! Anyway, let’s get started…

Door games are the “apps” to the BBS platform
First, let me describe what a BBS actually is – you can read a more official version on Wikipedia here. Anyone with a phone line, modem, and computer running the right software could start up a BBS. The software would tell the computer, when it received a call, to automatically pick up the line and start talking to the computer on the other end. On the other side, anyone could dial into the BBS with the right terminal software and once the connection was established, you’d get a screen that looked something like this:

On these BBSes, you’d typically find a couple different sections:

• Private communication (reading and writing messages)
• Public communication (message boards)
• File sharing (downloading and uploading)
• External applications, including Door games

The external applications were integrated with the BBS as described by Wikipedia:

The BBS software starts the external program, and the door system passes data back and forth between the door program, the BBS, and the remote user. To supply the door program with the user’s information (such as the user’s alias and the amount of time they had spent online), the BBS software creates a dropfile containing information for the program to read.

This “dropfile” typically contained all the user information, so rather than the standard API where the app asks for that information, instead it was provided in one big file. The door game would then parse this data and use it for the game. For the extra nerdtastic detail, you can go here for the dropfile specs.

Now of course this process of extending the BBS’s functionality isn’t as flexible as things are now – after all, you couldn’t just upload a new Door game to a BBS and get it running. You also couldn’t update your game and instantly propagate the new version out to all the users. But the central idea is still the same.

Social gameplay with friends and neighbors
One of the interesting properties of BBSes is that because they are all accessed by phone, and you don’t want to pay long-distance bills, you end up dialing into BBSes in your own area code. For me, that was 206, and it means that I was mostly gaming with people in my same regional area. Similarly, I convinced all my friends to also dial into the same BBSes and play games with me. For the games that had leaderboards and user-to-user interaction, it was easy to feel the same fun game-like motivations that make social gaming work today.

As an aside, while doing research for this blog post, I found this funny ASCII based dating site with Myers-Briggs based writing, and a Wall!

You can tell from the number of dudes on the screen above that the world of lonely nerds has not changed much over the last 20 years.

Turn-based, RPG-like gameplay
One of the big design challenges for any BBS game is that you want to encourage social gameplay, yet it can’t be real time. This is because, of course, people can’t be logged in to the same BBS simultaneously unless the BBS had a ton of different phone lines (not likely). As a result, each of the Door games had to support an social, asynchronous play style that allowed people to dial in one after the other and still engage.

The way that was done depended on the game, of course, but usually combined a mix of computer players (aka NPCs) and “slow” real-time action where each loop of action lasted a day. Then on any given day, you are given a number of turns which you can expend. Once you play these turns, then you need to wait until the next day to get more turns. This made it so that for a game like Tradewars 2002, you can log in, do your trading/mining/attacking, and interact with computer-controlled characters. If you encounter another player’s ship, then you can interact with them with the computer taking control of the other player, so when attacking them, they will automatically defend.

Some of these games played very much like RPGs, with levels, currency, monsters, swords, quests, and the usual mechanics. One of the most popular games was called The Legend of the Red Dragon:

Having the combination of social gameplay with the traditional RPG mechanics created a rich world that allowed for months of play time.

Low-tech graphical experiences, delivered as a persistent social experience
You may notice from all of these screenshots that these games are very, very basic. Many of my friends at the time criticized the simplicity of the gameplay, only to be  sucked in for social reasons Similar to the current incarnation of social gaming, the emphasis is not on graphics. The primary advantages of a persistent, continually updated world with social gameplay far outweighed the fact that downloadable single player games had much better graphics. Of course I still downloaded and played Wolfenstein and Doom when it first came out, but throughout that time, I stilled played BBS games.

If there’s one thing to be learned from the BBS games and their related cousins, MUDs, is that great social interactions can trump pretty much everything else. Of course the products that can deliver higher production values and great social experiences are even better off.

It was fun to write this article! Such a blast from the past. Hope you share your memories of BBSes in the comments

Want more?
If you liked this post, please subscribe or follow me on Twitter. You can also find more essays here.

(This blog was republished by the excellent blog Inside Social Gaming)

Why does everyone hate on desktop applications? Homer and spiderpig love them.

Desktop apps have better retention, while websites have better user signup rates – which factor wins?
There’s a lot of conventional wisdom that it’s dumb to build a desktop app, and it’s marketing suicide to do so.

This argument usually has two parts:

• Poor conversion rates: Maybe 1-2 out of every 100 – will download your application
• Poor virality: Since desktop apps are often standalone utilities, they lack the social element that makes them viral

You can compare this to web products which often have 10%+ registration rates, up to 50% when they are through friend-to-friend invitations.

It seems obvious that going down the web route is a slam dunk, but in fact it’s not – desktop applications often have a better long-term retention, and this can easily offset the lower download+install rates. The way to look at this is that the number of active registered users is a function of signup rate AND retention, and you can balance one with the other. (And of course, ideally you have both). To me, this discussion opens the way for more innovation in browser extensions, downloadable apps, and other low signup % products as long as the long-term value is great enough.

Note that this blog post will focus exclusively on the signup rate versus retention rate, and leave the virality discussion for another day. Let’s dig into this further.

Comparing applications versus websites
Here’s an example of the simple differences between the two channels:

Starting with the same number of new unique users, it’s obvious that this can lead to a huge difference in account registrations.

However, because web products are so easy to get into, they are also easy to get out of – it’s hard to be sticky. The one true retention mechanic is using e-mail notifications to get the user back. Compare that to a desktop product that use techniques like:

• Open itself whenever a file extension is clicked
• Install itself on the system tray
• Add itself to the desktop
• Start up automatically when the OS loads
• Run nicely in the background to pop up when appropriate
• … and many other retention-happy features

(Of course, you should never use these techniques without contributing value to the user, lest you get uninstalled and reported to Symantec).

Similarly, there is also emerging a world of in-between web-triggered applications like Firefox extensions and Adobe AIR apps, which are easier to install but also take advantage of a wider set of retention hooks to stay relevant.

So when all of this has been taken into account, you can see how our 100,000 new users fare after a couple time periods below. Here’s a table that describes two retention rates period-over-period, and how many active users are left after each period, starting with the initial numbers (1k vs 10k) discussed previously:

As you can see, after the course of 5 months, the application now has more active users than the website, even though it started with a 1/10th the registered users.

Note that retention rates usually improve period-over-period, and are not constant as shown above – I’m just using a constant retention rate so that we can simply the math in the next section!

Looking at the math
For the readers that fall asleep when an equation is shown, please skip this section

Ultimately, the function for describing the number of active users at any period is:

# of active users at time t = initial user signups * (retention rate)^t
= (new users * signup %) * (retention rate) ^ t

So if you have 100,000 new users, a 10% signup rate and 50% retention rate, then your equation looks like:

# of website actives at time t = 100,000 * 10% * (0.50)^t

If you want to calculate when a website’s active users falls below a desktop app’s active users, you can set the two equal to each other and solve for t:

100,000 * 10% * (0.50)^t = 100,000 * 1% * (0.80)^t
10% * 0.5^t = 1% * 0.8^t
10% / 0.1% = 0.8^t / 0.5^t
log 10 = log(0.8^t/0.5^t)
1 = log(0.8^t) – log(0.5^t)
1 = t * log(0.8) – t * log(0.5)
1 = t * (log(0.8)-log(0.5))
1 = t * log(0.8/0.5)
t = 1 / log(0.8/0.5) = 4.9

Thus, after 4.9 periods you’d see the higher retention product start beating the high signup product. In the cases where they never intersect, you’d get a negative number there. I will leave it as an exercise for the reader to solve this in the general case where you know that a website’s signup rate is X times more than desktop app, and Y times in retention.

Conclusions
Ultimately, I believe my calculations show that desktop apps have natural advantages (and disadvantages), but are not strictly worse than building a web property. You still need a long-term value proposition that drives great natural retention. You need expertly-done “hooks” into the OS, email, and other notification systems that encourage repeat usage. And finally, you need social hooks into viral channels (whether web or beyond) that encourage virality and user-to-user interaction

I think it’s not a surprise that there have been great success stories in desktop apps in recent years, such as Skype, Twitter clients, new browsers, and other tools that follow the design patterns of the above. And of course, nothing beats building a killer product that spreads naturally through word-of-mouth – that said, you can stack the deck using great retention and virality

Want more?
If you liked this post, please subscribe or follow me on Twitter. You can also find more essays here.

Sometimes platforms can be dangerous to your health…

Recent platform news
I’ve been interested in the rush of recent news about the various challenges that app developers are facing relative to the platforms they’re building on, whether that’s Facebook or iPhone:

• Couldery Shouldery: the Lookery post-mortem
• CNet: Does iLike price show the cost of Facebook dependence?
• The Case Against Apple in Five Parts

Reading the excerpts
Each of these stories is slightly different, but worth repeating – here’s the relevant paragraph from Scott Rafer’s Lookery post:

So far so good on using an ephemeral opportunity to create a company, but this is where I place Coulda-Shoulda #1. We exposed ourselves to a huge single point of failure called Facebook. I’ve ranted for years about how bad an idea it is for startups to be mobile-carrier dependent. In retrospect, there is no difference between Verizon Wireless and Facebook in this context. To succeed in that kind of environment requires any number of resources. One of them is clearly significant outside financing, which we’d explicitly chosen to do without. We could have and should have used the proceeds of the convertible note to get out from under Facebook’s thumb rather to invest further in the Facebook Platform.

Similarly, here’s the excerpt from the recent article about iLike:

Some in Silicon Valley have speculated that MySpace isn’t willing to pay more for iLike because it fears Facebook will boot iLike once its main rival takes control of the service. But that doesn’t go far enough in describing the situation, said one of the sources. What has pushed iLike’s valuation down is a problem with control. The company’s managers have no way to prove to potential acquirers that their business model has a bright future because they can’t predict from one day to the next which direction Facebook’s Platform will go. The source said that leaders at iLike, or any other company on the platform, are not truly in control of their fate–Facebook’s Mark Zuckerberg is.

“The cash flow of any company doing business on Facebook’s API, or Facebook Connect, or Facebook platform is inherently at risk,” said the source. “The multiple that an investor can place on that cash flow is not that much greater than 1, because you never know at which point Facebook could change the terms of the relationship or change the technology and cut off that cash flow.”

And finally, the discussion on the iPhone platform, which Jason Calacanis makes in 5 parts with the last 3 points involving their App store platform:

1. Destroying MP3 player innovation through anti-competitive practices
2. Monopolistic practices in telecommunications
3. Draconian App Store policies that are, frankly, insulting
4. Being a horrible hypocrite by banning other browsers on the iPhone
5. Blocking the Google Voice Application on the iPhone

The mismatch of agendas
Ultimately, the vast majority of these disagreements between platforms and applications seem to be over the inherent mismatch of agendas between the two parties. Applications seek to maximize their distribution and gain customer share, while minimizing their dependence to the particular channel. For platforms, they seek to control the applications which depend on them, and prioritize the long-term success of the application ecosystem rather than any individual application’s. The ecosystem around a platform is complex because there’s a 2-sided market built in – the customers they serve, and the applications that want to use them. Prioritizing application developers above all else leads to sloppy, disjointed experiences – that’s one of the things you have to admire about Apple’s tight-fisted approach to App Store discovery, payments, etc. I haven’t had a bad experience yet, versus the constant complaint comments I get from disgruntled users whenever I wrote about Super Rewards or Offerpal.

As I wrote about in my previous blog post Benefit-Driven Metrics,  ultimately the platforms should try to help the the applications that build on them make as much sustainable revenue as possible. As long as there’s a long-term business there, more developers will continue to be attracted to building more functionality and richness. I believe that the Facebook economy has (surprisingly) shown itself to be capable to support several VC-backed companies making 10s of millions in revenue, whereas the same cannot be said for the iPhone platform yet. I’m sure someone in the mobile world will figure it out eventually, though.

For any application developer though, the core lesson is – don’t get too comfortable

Conclusion
How will these recent issues steer the platform agenda in the future? In particular, let’s look at iLike’s exit – what are the implications for other startups?

Will people conclude negatively about:

• music startups
• ad-based app companies
• startups that are building horizontal apps on Facebook/Twitter
• any startups building on one of these platforms

Perhaps it will be all 4, or perhaps just localized to a particular sector. Only time will tell.

Hope you enjoyed this article, and leave me any comments if you have extended thoughts!

Want more?
If you liked this post, please subscribe or follow me on Twitter. You can also find more essays here.