Perl Startups: Lacuna Expanse

Lately while there's been discussions of various new (for varying definitions of 'new') companies who have chosen Perl, there's not been a huge amount of discussion about how they use Perl. I contacted JT Smith of Plain Black Corporation and he graciously agreed to talk about The Lacuna Expanse, a MMORPG with a Perl backend.

Ovid: Tell us a bit about the Lacuna Expanse

JT: The Lacuna Expanse is a massively multi-player empire building game. Each player starts out inhabiting a planet and just trying to survive without being overthrown by their people or running out of resources. Then the game changes into exploration and expansion as you reach out to the stars to mine asteroids and colonize other worlds. Along the way you might make friends, or encounter hostiles. You may wage war either through espionage or old fashioned fleet battles. And as you continue in the game you'll learn to build space stations and start to engage in the political side of the Expanse.

Ovid: Can you describe your technology stack/architecture?

JT: The server architecture is basically JSON::RPC::Dispatcher running in Plack/Starman sitting on top of Moose and DBIx::Class. It's hosted on Linode (for app servers) and Amazon (for static file storage and CDN). There are clients written in Perl (command line and web), Javascript (web), and Objective-C (iPhone).

Lacuna Expanse Architecture

Ovid: Why did you choose Perl?

JT: Basically every couple of years I do an analysis comparing my language of choice (currently Perl) against the other languages that I've used in the past 10 years. I've been using Perl since 1996, but it became my language of choice in 2001, and so far nothing has supplanted it, though it's come close a few times. Here's how the evaluation went just before the Lacuna Expanse project, in order of best to worst:

  1. Perl - The reigning champ.
  2. Javascript / node.js - Faster execution than perl, and much easier to write async code. Library support wasn't there.
  3. Ruby - Now that Perl has Dancer/Plack/Moose, Ruby has nothing that Perl doesn't have (at least that I've seen). Therefore no reason to switch.
  4. Java - Just as good of library support as Perl, perhaps better. Faster execution than Perl. However, the clunky build process and verbose nature of the language mean its a much slower development cycle.
  5. Python - Basically the same argument as Ruby, except that in my opinion Python isn't half as good of a language as Ruby.
  6. C# - Basically the same argument as Java, except that C# isn't quite as good as Java and it's tied to Microsoft. Mono isn't a real substitute.
  7. PHP - PHP is a capable language, but the way you have to write code makes it feel like Perl's dumber cousin. Especially when you're writing all the utilities and whatnot that aren't web apps.
  8. Visual Basic - This is pretty much the worst language I've ever used.

Ovid: What Perl-specific technologies were used?

JT: I used over 100 Perl libraries from CPAN in building Lacuna. The big workhorses were the common ones you hear about such as Starman, Plack/PSGI, DBIx::Class, JSON, DateTime, and Moose. I also built quite a few, which I'll get to in a later question. However, there were quite a few others that really made the job easier. Things like String::Random which I used to generate all the names of the stars and and planets. List::Util::WeightedChoice which helped out with generating what types of worlds and stars went where during map generation. I used Config::JSON to define and store all of the mission files. And Pod::Simple::HTML, which turned all my API documentation into nice HTML files so people could write their own clients against the server APIs.

Ovid: What was good and bad about the Perl language?

JT: Perl has been able to do anything I've ever asked of it. That's really the reason it remains the reigning champ of programming languages in my toolkit.

These days it's a tougher call between Perl and node.js, than it was when I built the Lacuna Expanse. Stylistically I like Perl better than Javascript, but that's a personal preference. With Moose, Perl's objects are more powerful than Javascript's objects, but in many cases Javascript's objects are "good enough". Perl would do well to copy the node.js async stuff and be able to compile itself down to Javascript for those times when you need the extra performance that a Javascript VM like V8 would give you. If Perl had those 2 things, then node.js would no longer be a threat.

Ovid: What would you have done differently with Perl, had you known?

JT: Directly after Lacuna, we decided to turn an experimental project into a real business. That business was The Game Crafter. So I took everything I learned from Lacuna and created a new framework for building apps, that I call Wing. And then I built The Game Crafter on top of that. There were tons of things I would have done differently with Lacuna, so I baked all those things into Wing. I'll enumerate a few of them here.

First, though I absolutely love JSON-RPC 2.0 as a protocol, it has no mechanism for transferring files. And although it has a "RESTful mode" it's not terribly RESTful. So for Wing, I took the features of JSON-RPC 2.0 that I liked, and created a RESTful interface out of it.

Second, though I love DBIx::Class, I found myself writing a lot of glue code in Lacuna over and over again to turn web services into DBIx::Class queries. So Wing automatically generates all the CRUD style web services and ties them back to DBIx::Class objects complete with privileges and validation.

Third, though I used some exceptions in Lacuna, I didn't use them enough or effectively. I had used Exception::Class in the past for such things, but always found it clunky. So instead I created Ouch, which allows me to do what Exception::Class does, but in much simpler code. And then I made Ouch an integral part of Wing.

Had I had Wing when I built Lacuna, I could have done it in less than half of the time, and it would have resulted in a much cleaner code-base. That said, without first creating Lacuna, I would have never created Wing.

Ovid: Did the availability of Perl developers impact your business?

JT: Not in the least. I've never had trouble finding talented Perl developers.

Ovid: Did the company have a chance to give back to the community?

JT: Absolutely! There are a number of Perl modules that my team and I created to build Lacuna. The most famous and widely used of those is Facebook::Graph, which allows you to access Facebook's API through Perl. Others that came out of Lacuna include: Plack::Middleware::CrossOrigin, Chat::Envolve, Dist::Zilla::Plugin::MetaNoIndex, SimpleDB::Client, and SimpleDB::Class.

In addition, we've open sourced the Lacuna server, and the Perl community has continued to evolve the game substantially.

Ovid: Do you have any Perl-related plans for the future?

JT: We've got no shortage of projects. We're continuing to evolve The Game Crafter. This winter we'll be releasing MobRater, which is a way to do crowd polling and crowd idea generation in a way that doesn't suck. And next spring I hope to release another video game project. All three of these are built on top of Wing.

Ovid: Are there any questions you wish I asked, but didn't?

JT: Why aren't there more Perl startups?

I asked that very question in a lightning talk I gave at YAPC::NA 2013. We've got plenty of talented people and robust technology in the Perl community. There's no reason the Perl community shouldn't be cranking out a new start up at least monthly. After that lightning talk 15 or so people came up to me wondering how to get started with creating their startup. I think the problem is that they understand the tech, but not how to negotiate the business landscape. So I did my best to answer their questions, and sent them away with my email address in case they needed more help. But I realized I could do more, so directly after YAPC::NA 2013 I started a blog dedicated to the topic (http://plainblackguy.tumblr.com). Since then a few people have asked that I submit talks on building a startup to upcoming conferences, so I'll probably do that too.

Ovid: Is there any advice you would give to new start ups?

JT: There's lots of advice that they probably need, but I'll give four pieces that I consider to be the most important.

  1. Do not quit your day job. When you're starting your business, you need to make decisions from a position of strength. If you're making decisions because you're strapped for cash, you're almost certainly going to make the wrong decision.

  2. Become a salesman. It doesn't matter if you think salesman are slimy, you have to become the best salesman your product will ever have. If you aren't excited about your product, nobody else will be either. You need to talk about your product every single chance you get. And if opportunities for telling the world about your product don't drop themselves in your lap (which they often don't) then you need to go out and create opportunities to talk about it.

  3. Build yourself out. In the beginning you're going to become a critical component in the engine that is your business. However, as you find success you need to build yourself out of your business as quickly as you can. Note that I'm not saying "check out", I'm saying "build yourself out". You should remain as involved as you can, without being a single point of failure. After all, you're going to burn out if everything relies upon you. Also, if you get hit by a bus, you're going to want that money engine you created to keep cranking out cash to pay for your hospital bills.

  4. If you have to be there to make money you'll never make any. This is sort of an extension of "build yourself out". Truly wealthy people earn money from many revenue streams. After you've got the business up and running, if you have to be there every day, you won't have any time to create your next start up. Most businesses have a life-cycle. Therefore, if you haven't created new revenue streams by the time the previous ones dry up, you'll be right back at the problem of #1: making decisions based upon financial hardship rather than what's best for the business.


Regarding JT's interesting comments regarding how to create a startup, check out Udacity's free online video course, How to Build a Startup.

I hope to have other companies in the future. If you have suggestions for newer companies using Perl that you'd like to see, leave a comment.

11 Comments

Python is a much better language than Ruby and has much better libraries.

Ovid, why not chat to Rob from www.mob-labs.com/buildar.com? They are doing some neat mobile stuff in perl.

Nice article but you could at least have linked their game correctly so that they get some link juice ;)

Being a junior sysadmin, I spent lot of time whether to go for perl or python as my per main scripting language. I had opted for python, as many told me that perl is no longer being adapted by new generation and python is the future. But reading above, and if its true, I think I got to know perl to a good extent.

A great article, as someone that has always been a follower of Perl but has never had a chance to work with it, I found a tech stack described as such to be very informative.

One suggestion that I have is that an article expanding on what it is about Perl that has you choosing it for projects still over other items such as Ruby, Python, and what not. I'd be interested in reading a more detailed article on that topic, being a PHP developer that's trying to decide what direction to move too next.

Given how ineffective Perl's garbage collection is, and the resulting tendency for any long-running Perl program to eventually blow the heap even if it needs only a few kilobytes at any given moment, what will happen when a user with less than 1G of available RAM (typical Windows user, 4G RAM, 2G Windows 7, 1G browser) tries to play for a 16-hour stretch?

Phil, users probably runs JavaScript in browser, not 'native' Perl client.

"the resulting tendency for any long-running Perl program to eventually blow the heap"

on windows maybe ? or what do you mean by "long running" ? the only situation I encountered where a perl process was leaking memory was when exceptions were thrown from within an eval, more precisely in a Template Toolkit macro

@Ovid either website, they are both the same company. Just go with mob-labs.com I guess, email robman AT.

"Ruby has nothing that Perl doesn't have"

Ruboto and RubyMotion for developing Android and iOS native apps have made me think again about Ruby's capabilities in comparison to Perl. JRuby for the JVM and threads is also a great Ruby asset.

Leave a comment

About Ovid

user-pic Have Perl; Will Travel. Freelance Perl/Testing/Agile consultant. Photo by http://www.circle23.com/. Warning: that site is not safe for work. The photographer is a good friend of mine, though, and it's appropriate to credit his work.