Time is running out fast! 2017 is nearly over, but we made a lot of progress in October 2017, as you can see in the new status report about the development of our science fiction game, Tau Station. Our focus is (still) on getting the game ready for Closed Alpha. Due to the progress on the backend, the frontend team was able to get several core elements in shape for testing. The art team has created a lot of designs. Long story short: several UIs, core game chat, and a couple more missions are waiting for you, while game design is pushing the skill system and combat even further.
Goodbye September 2017, and a warm welcome to October! The team is pushing hard towards getting Tau Station into shape for Closed Alpha. There is a lot of excitement that very soon a select group of Sci-Fi fans will have a first look at the game. Did you sign up for the newsletter? With some luck, you could be one of the fans invited to the Closed Alpha. See below what was achieved in September and what will be the next milestones for October.
When reading through the literature of how games are built, we find that a common pattern for many games is the Entity-Component-System (ECS) pattern, first used in one of our favorite games Thief: The Dark Project. Tau Station uses ECS for items the characters can find and it’s proven very flexible and since we’re not a traditional “graphic” game, some of the known drawbacks of ECS don’t apply to us. However, we also make use of traditional object-oriented programming (OOP) and that’s where we wish to avoid a common trap that many software developers fall into: multiple inheritance.
There’s a little-known secret in the software industry. If you’re in the industry long enough, talk to other people in your field, and maybe head to developer conferences, you’ll hear the secret whispered about from time to time.
Previously we discussed the tech stack that Tau Station runs on, but today we thought that we’d give some in-depth examples of the software hurdles we face. There will be Perl code in this blog entry, but the concepts should be generally familiar to anyone with a software engineering background.
As we mentioned in the tech stack post, we use Catalyst for our Web framework. For those unfamiliar with Perl, you could think of Catalyst as “Ruby on Rails” for Perl, but that’s not really accurate. What makes Catalyst so powerful is that unlike other Web MVC (model-view-controller) frameworks, it doesn’t have strong preferences for how you implement the various components. You’re not forced to choose a particular ORM for your model—you can even skip an ORM entirely—and you can choose whatever tools you wish for rendering your view (typically, the stuff you see in a Web browser). As a result, you can choose exactly the tools you need for each component of your system.
Mission Builder is one of the most important components of Tau Station and yet, ironically, it’s one that not a single player will be directly exposed to at any point in time. So what is Mission Builder, and what makes it such a valuable part of Tau Station? It’s the most heavily used content creation tool in the game, used by our narrative designers to create jobs, missions, NPC dialogues, and more. While Mission Builder isn’t quite one-stop shopping for the narrative team, it’s the equivalent of a Swiss Army chainsaw hanging in the team’s toolshed.
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.