As of this writing, Tau Station is about half a million lines of code. Most of that is Perl, a language that is famously concise. Were it written in Java, for example, it would probably clock in at well over a million lines of code. When a codebase gets to this size, it can be very hard to maintain. This is how we manage that complexity.
Tau Station relies heavily on open source code. Our database is PostgreSQL, with database deployment management handled by sqitch. Our main programming language is Perl 5, we use Redis heavily as a fast cache for non-critical data, and so on. Lots and lots of open source code.
For our developers who want to share some of our code with the open source community, we simply ask that the code not have “Tau Station-specific” code in it. In other words, part of the fun of Tau Station is discovering its secrets by exploring the universe, not reading them in source code.
So we’ve released two more modules which, we hope, others might find useful.
This week, The Perl Conference – Glasgow took place with several of our team members attending. Today, we want to share some impressions with you, including videos of our team’s presentations as well as some photos.
For the week of August 13 through August 17, 2018, part of Tau Station’s backend development team will be in lovely Glasgow, Scotland, attending The Perl Conference – Glasgow. There are major Perl events held worldwide every month and this is one of our favorites.
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.