Tau Station Updates
I haven't blogged lately because of ridiculous amounts of work on the Tau Station MMORPG (the game formerly known as Veure and written almost entirely in Perl). I had reluctantly stopped my last contract with ZipRecruiter because of surgery (long story, but not life-threatening) and then experiencing the joy of physiotherapy. Near the end of physio, we decided as a company to make a serious push on Tau Station and bring it to alpha. Here's an update.
(If you're curious, the above graphic is some low-res concept art I threw together for a desktop wallpaper. The font and its color are wrong, so we didn't use it, but I still like it. The image in the background is of the ruins of one of the space stations in the game. Click on it for a larger version.)
If you're not familiar with the game, it's an attempt to create a text MMORPG with the richness of top-tier graphic MMORPGs. It's hard, and the "text-based" moniker is hanging around our neck like an albatross. We've heard people from other companies think that it's a simple amateur Web site. People are thinking MUD, or Zork, or some weird Web version of those old "choose your own adventure" flip books. It's none of those. For example, here's our sickbay:
So yes, it's text, but no, it's not simple. As for the game theme, I like to think "Firefly meets Mad Max." This blog post explains more about the setting.
A few notes about it:
- It's designed "mobile first," but naturally still looks awesome in a regular browser
- It's "progressive enhancement" instead of "graceful degradation" because the latter is often isn't
- We're working hard to make it accessible as possible so that anyone can play
- Our standing rule for devs: they're free to open source anything (with approval) so long as it doesn't give away game play
Internally the code is pretty darned clean. It's not perfect, but for a business, it's the best code I've ever seen. We also have awesome test coverage to the point where if something is broken, we almost always find it immediately in the tests. That sounds like a "duh" moment, but in reality, it's simply not true for the vast majority of company test suites I've worked on.
$ prove -rl t t/001sanity.t ..... ok t/002selenium.t ... skipped: Skipping Selenium tests by default t/003templates.t .. ok t/perlcritic.t .... ok t/sqitch.t ........ ok t/tcm.t ........... ok All tests successful. Files=6, Tests=1377, 399 wallclock secs ( 1.11 usr 0.17 sys + 630.44 cusr 11.22 csys = 642.94 CPU) Result: PASS
Note that the
t/tcm.t tests use Test::Class::Moose and are actually around 7,500 individual tests. That may not seem like a lot, but many of those are full integration tests and capture a huge amount of behavior. Due to how inter-related so many features are--especially compared to "normal" software--this has been hugely beneficial.
As for features, I'm currently building out the career task system. In addition to missions and odd jobs, careers are long-term, such as politician, operative, criminal, and so on. You can get promoted or demoted by succeeding or failing at enough career tasks. Of course, you don't really know how much beneficial each task is, and illegal or dangerous tasks just might send you to the brig or sickbay ...
Sign up for our newsletter if you want to keep up with the latest news.