In earlier articles we introduced the economic exchange system we use to help us build Tau Station. Further publications explained how it helps us to write clean code and simplify our combat code. In this technical blog post we look at the economic exchange system in a little more detail.
So, we have discussed the important of clean code before. That article showed how economic exchanges could clean up otherwise messy steps involved in the processes of cloning. But what happens if your mess is bigger than a single step? – In our new technology blog post, we invite you to join us for (code) combat …
In earlier articles we looked at the way we use “economic exchanges” to simplify complex code into a series of small understandable steps. We use similar ideas to build up business logic in our DBIx::Class model layer: combining multiple small predefined queries together to create more complex conditions for generating SQL queries against the database.
Read on below if you take the challenge to read “0011001010” language of our database experts who love to share knowledge with you again about clean code.
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.
Next month our game designer, Curtis, will be giving a talk about Tau Station at the FOSDEM conference in Brussels. We considered sending him with flyers to hand out but decided that stickers would be a lot more fun. Because who doesn’t love stickers?!
Using some of our favorite images from Tau Station’s background art, our graphic designer Tania put together this collection of stickers to give everyone a glimpse into our universe. Some of these pictures are new and haven’t been shown anywhere before.
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.
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.