Tau Station’s Tech Stack
People have been asking about our technology stack, so this post will be a bit “tech heavy.” Further, it will be opinionated tech-heavy. You’ve been warned!
When I started Tau Station, I knew that I was primarily looking for a robust Web framework, a flexible ORM (object-relational mapper), and a strong database. Due to my having been heavily involved in open source for years, only open source products were considered.
The Back End
As for the programming language, I was pretty sure from the start that it was going to be Perl 5. I’ve programmed in quite a few languages and, to be honest, I was tempted to start Tau Station in a different language just for fun. However, I knew I wanted Tau Station to be successful and not just an experiment, so I decided to use Perl and all of the powerful and awesome tools that come with it. We’re currently targeting Perl 5, version 24, which was released in May of 2016. There are new versions of Perl 5 released every 12 to 13 months and we’re eagerly anticipating some of the new features, so we expect to be upgrading again soon.
I chose Catalyst for a powerful Web framework based on the MVC (model-view-controller) pattern. Template Toolkit was chosen for managing the HTML templates and DBIx::Class for the ORM (object-relational mapping) we would use in our model. This combination allows for incredibly fast development. If we need to change the database, we just run the DBIx::Class::Schema::Loader and it rebuilds much of our model code for us, rather than the tedious and error-prone manual updating of the ORM to match the data model. In fact, the schema loader is so powerful that it’s caught database design flaws for us.
Aside from the great libraries available in Perl, most of which are available on the CPAN, Perl has been around long enough to have a fantastic community. We’re pleased to have attracted a great team of very talented developers with different backgrounds and a fantastic depth of experience. As a result, Tau Station’s missions are varied, the gameplay is thoughtful, and the code itself is a pleasure to work with.
And speaking of the code, all that was without mentioning the Perl language itself. Back in the 1990s, it was so popular that it was known as “the duct tape of the Internet.” It’s a great language, very flexible, and powerful enough to make the easy things easy and the hard things possible. I like to refer to Perl as “battle-tested.” As one of our All Around The World clients said to us when they asked us to build a new system in Perl, “we’re tired of getting bitten by hype.” Perl’s the strong workhorse that keeps pulling things along with nary a complaint. It’s not as flashy as the JavaScript framework of the week, but we consider this one of its strong points.
The Database
For the database, it was primarily a matter of MySQL versus PostgreSQL and frankly, when you have serious database needs, PostgreSQL beats MySQL hands down. A good database still makes it easy to insert incorrect data (like a misspelled name), but it makes it very hard to insert invalid data (such as an item with a negative weight). In PostgreSQL, we have custom data types, useful check constraints, and non-broken triggers, all things which MySQL has lacked for years. Also, as part of our database development work, we need the DDL (data definition language) to be rolled back if transactions fail, something MySQL does not offer (curiously, Oracle doesn’t either). In fact, there are plenty of things which PostgreSQL offers that MySQL does not. The trade-off is that PostgreSQL is harder to administer, but we feel that data integrity is worth it.
The Front End
This is the part which will surprise a few “modern” types. We’re using a bit of jQuery and some custom JavaScript, but that’s about it. In fact, while there are many modern Web frameworks which would give us some of the tools we were looking for, they all fell down in one way or another.
In particular, there were two issues of concern. First, we’re fans of progressive enhancement over graceful degradation. It’s very easy when you “degrade” to offer a poor user experience to those who don’t use your standard of a “modern” Web browser. Further, many modern front-end frameworks either assume you have JavaScript enabled, or offer limited graceful degradation, something which is not useful for us.
Second, we believe in accessibility. If we’re writing a text-based MMORPG and a blind person can’t play it, we’ve failed. If we use colors to convey information within the game and don’t plan for players who are color-blind, we’ve failed. If we don’t support gamers who rely on switch access rather than using a keyboard or mouse, we’ve failed. Simply put, we want everyone to have fun playing Tau Station and we’ve chosen front-end tools that support that goal.
Most modern JavaScript frameworks either ignore accessibility, or offer limited support for it. We did try to use a JavaScript framework early on, but we spent so much time working around its lack of accessibility or support for progressive enhancement that it was more trouble than it was worth. So it’s taking a bit more time to develop the front end, but we feel it’s the right thing to do.
Miscellaneous
There are, of course, plenty of other technologies involved. We’ve tried to ensure the software can be run on just about any operating system, but Microsoft Windows does not support the fork-exec model of running subprocesses so try as we might, our only developer who worked on a Windows box found that he couldn’t get it to work. Fortunately, the game runs in a Web browser so this is a back end issue that players will never notice.
We use Redis for caching because Redis is wicked fast and just awesome. Nginx was chosen for the Web server for similar reasons. Fluentd is our logging layer due to its incredible flexibility and the fact that we have very heavy logging needs (this is a common issue with MMORPGs: you must know what your players are doing). Most of our database migration needs are handled by sqitch but we’ve had to do some custom work because, like many database migration tools, sqitch is better with DDL than with DML and we have extensive amounts of game data. We also use Markdown for the formatting of player posts and blogs, Plack as a lovely middleware layer between the application and the Web server, and a host of other tools.
A Final Word
So that’s our tech stack, more or less. I’ve been asked “why not C++” or some other, faster language. Many MMORPGs are written in C++, with Python or Lua as a scripting language. However, the reason they use C++ is generally because they’re graphic MMORPGs. We don’t need something like the Unreal Engine, or Unity. In fact, the reason why dynamic languages like Perl are so popular for Web sites is because the performance bottlenecks in Web sites are often I/O (the database) or network latency. For those times we find ourselves CPU-bound, we throw more servers at the problem.
In fact, our primary concern with Tau Station is that the game is “write-heavy” on the database. That’s less common with Web sites, so the database is where we anticipate much of our performance issues will be. Given that many very heavily trafficked Web sites run on Perl, we’re not worried about its performance. C++ would merely have slowed down our development time with no clear gain.
Originally published at taustation.space on August 26, 2016.
