Sunday, December 29, 2013

Bitcoins and MMORPGs.

I've been mulling over this question awhile now:

How do you make a free to play MMORPG that is not driven by a cash shop but is still sustainable as a business. In other words, how do you make a "clean" game in which no gameplay decisions are driven by the concept of microtransactions?

When gameplay decisions have to factor in the business side, the game inevitably suffers: see a million generic Korean grindfests where the only way to escape the monotony and get to the action is to pay for items. Very few games seem to escape this fate. The fewer players there are, the more expensive and disruptive items have to be in order to be profitable. The more players there are, the less items have to be disruptive -- the free to play community at large won't want to deal with players who "boosted" their way to the top but have no idea how to play the game.

But what if you designed a system where every player paid to play your game, but invisibly, in the background, with no effort and cash required?


It came to me a few hours ago as I was mulling over some game concepts. A minimalistic survival game, with no real UI to speak of, no macros or quest hubs. The game is its own user interface, similar to how Dead Space handled inventory management: every interaction you had with your inventory was part of the game. Nothing stopped, the world kept running as you fumbled through your equipment while the lights in the hallway ticked off one by one and the howl of monsters got closer and closer.

In a game like that, you can't have cash shops. Can you imagine walking up to an NPC vendor in the game, talking, then clicking through some immersion breaking dialogs to click through an immersion breaking gateway in order to buy some credits for $5 that will help you cut down trees faster, all because the tree-felling portion of the game was made more grindy to encourage players to buy something to cut down trees faster?

To me, it seemed like the only real option for sustaining a game like this was a subscription, which may as well make the game stillborn. The time of subscription-based games is over. WoW has sucked the air out of the room in that regard.

But I was browsing /r/bitcoin earlier, not even sure how I got there, but just passing the time when it hit me:

What if your users mined bitcoins for you while they played the game?

Their computers provide labor in exchange for being able to access and play your MMO*. In that sense, the concept of a subscription-based MMO* can survive through cryptocurrencies. You receive a currency (Bitcoin, Litecoin, even Dogecoin) while the user themselves put no tangible effort giving that currency to you.

It seems too perfect. For end-users, the entire thing is seamless: they turn on the game, they play, they turn it off. For you, you get paid when your players are playing. If you have a love of games, this is Heaven: the more fun you make your game, the more users you get, the more money you get. You never have to compromise your vision of fun in order to make money, because a fun game that people like to play is metaphorically a "gold" (Bitcoin!) mine.

It's a crazy thought, but it does make me wonder...

Wednesday, April 03, 2013

JRuby on Heroku? Bah, humbug.

My experiments with JRuby on Heroku have mostly been a bust.

I migrated a fairly simple 2.0.0 application over to JRuby, which didn't involve much other than switching to Kramdown from RedCarpet 2, and spending some time fucking around with my `database.yml` so the `activerecord-jdbc-postgresql` gem would actually connect.

But goddamn, the problems.

I let the JRuby 1.7.3 version of the application run for a little less than 24 hours, and in that time I got:

* about 6 hours of downtime spread sporadically throughout the period
* four or five "memory quota exceeded" at peak time, which didn't seem to do anything
* several random dyno crashes I wasn't seeing under Ruby 2.0.0, which were followed by...
* ...many, many "boot timeout" errors, which I never saw under 2.0.0 unless I had a bad configuration / initializer that was causing the app to crash

And those are just the critical errors. Performance across the board was crap: the New Relic comparisons from last week versus the switch to JRuby were pretty bad looking. Lots of request timeouts. Lots of request timeouts. And request throughput was apparently crap.

That last thing -- throughput -- bothers me almost as much as the random crits above. The setup is running puma, a threadsafe web server for Rack, so I was expecting to see much better request throughput than what I actually got. For those of you not in the know, JRuby has "real" threading, where-as Ruby MRI has a GIL and green threads, which means threading performance is not very good.

Switching to JRuby should have given me a real boost in throughput, but, unexpectedly, performance was piss-poor and there was a significant increase of request timeouts. The site's not getting _that_ much traffic, and the assets are stored on Cloudfront, so...

I don't have any idea what to make of this. Apparently the setup is working well for others (I don't see any complaints on Google, at least). But with such a simple setup on Heroku going sideways, I'm not sure what to make of it. Is it a bug in JRuby 1.7.3? A Heroku-specific problem?

Meh. I've redeployed on MRI, and the numbers are turning back to normal.

That concludes that experiment.

UPDATE 4/4/2013:

For curiosity's sake, I ended up chasing the source of the downtime to a bug in Kramdown not being able to deal with some erratically formatted content. The code doesn't throw an exception, it just... hangs, I guess. New Relic reports a ridiculously long runtime of 1.5 million milliseconds, but I'm not sure if that's because it actually takes that long to render, or something (probably Herkou) killed the process, and that's just how long it took. RedCarpet has no problems with the markdown in question, which explains why I wasn't seeing any problems before the switch to JRuby.

Monday, February 18, 2013

OS X 10.8 vs...

Fedora 18 / Gnome 3.6

Gnome 3.6 is very, very nice. It's not as refined as OS X yet, but you can see the Gnome team clearly closing the gap. The new lock screen is very nice and polished. Utilizing work-spaces is a snap. Gnome 3.6 has a very distinct, appealing style: once you open an application, there is little to no clutter. All you have is your app and the top bar showing you vital system information (battery life, wifi status, etc).

The user interface is where the polish ends. As you'd expect if you've used any non-Ubuntu Linux distribution in the past few years, installing and updating applications is terrible. The built in method of installing applications from Fedora's repositories is awful; application packages (RPMs) you download from major vendors like Google (Google Chrome) have to be installed from the command line.

It's unfortunate such a pleasant user experience like Gnome 3.6 attached to an unpleasant way of managing applications.

Ubuntu 12.10 / Unity

Unity feels like a kind of forgotten Frankenstein's monster. HUD, the system for quickly selecting items in an application's menu, only works sometimes. The global menu bar suffers the same schizophrenia, leaving you with an overall inconsistent experience. When they work, they work beautifully. When they don't... well, meh.

The dash is nice and responsive, but often the search results hit the barn wall. Dash draws in search results from websites like, cluttering search results with unrelated items: searching for "photo" brings up Shotwell Photo Manager, as well as Birds of Prey, Kindle Fire HD, and what literally looks like a pornographic video. ... okay, no, it's apparently a smutty adult novel with a risque' cover. Still, not exactly what I was looking for, and definitely not what I want anyone to see if they're looking over my shoulder.

Installing applications is nice and straight-forward: the Ubuntu Software Center is a little sluggish, but search results are easy to browse. Installing applications from the Internet -- Google Chrome, Scrivener for Linux -- is straight-forward and very painless.

Unity needs a lot of shine, but seems promising.


Some things I really like about OS X that have no Unity / Gnome 3.6 parallel.

 * The Command button. I didn't understand how great this single button was until I started using it. Mac's have the standard Alt and Ctrl buttons, but the Command button is the primary modifier for interacting with applications. Command C always copies, Command V always pastes. Command W always closes a window, and Command T always creates a new tab. And because these keystrokes are divorced from the Ctrl key,  you can actually copy and paste inside of a terminal window exactly the same as you'd copy and paste from a GUI application. The uniformity is great.

* Built-in gestures. You can summon application window overviews with a simple swipe, move between windows, open the notification panel, pinch and zoom... gestures don't feel like a tacked on feature. If Unity or Gnome 3 have a similar feature, they're hard to discover. OS X told me straight up during the setup procedure how to use the mulit-touch gestures.

* Coherent animations. When you download a file from Safari, the file's icon goes flying into the "downloads stack." When you minimize an application, you watch it disappear to its place on the dock. There's never any question of where a window went or a button just did. Most things in OS X have a nice, smooth animation that visually elaborates. It's thoughtful.

Tuesday, February 05, 2013

Ruby: Ensure blocks can alter flow control!

This one bit me -- I've only found it documented in one place, here, but I also discovered the behavior after debugging a strange problem I was having with some command line processes not exiting properly when they received the exit command.

Basically, if you exit from an ensure block with "return" it behaves the same as if you had done a "rescue Exception" statement, which means it swallows up all exceptions, including exceptions raised to terminate the Ruby process when it receives SIGTERM, SIGQUIT, SIGINT, etc.