Looking back, Sword of the Stars, upon its release, was nothing less than pure gaming ecstasy. Certainly, the game wasn’t perfect by any stretch, but the combination of an intuitive galactic management system, combined with a cool-looking and surprisingly detailed 3D starship combat model made for some intense and satisfying gaming. Still, the game was missing a certain… ‘something’, and it is to this end that the expansion pack Born of Blood has been released to try and fill some of these gaps in the gameplay.

Among some of the things promised, there are now expanded diplomacy and communication options for other races. Trade fleets can be constructed to provide an alternative source of revenue for a planet. There are new technologies to research, and most significantly, a completely new race; the Zuul.

One of the biggest things Kerberos has addressed with the game is making the universe feel a bit more dynamic. Previously, you’d encounter only a few major threats: Other races, the “Swarm” infestations found in certain systems, ancient asteroid installations and still-active ship hulks, and random encounters threatening your planets. Now, however, expanding players will really need to keep on their toes, due not only to an increased number of random encounters that can occur (I’ve even heard murmurings of a new planet / star killer encounter, though thankfully have not seen it yet), but also because of changes to the Swarm. Previously these guys simply occupied random systems at the start of a new game and provided a deterrent to aggressive early expansion; seeing as how these ‘infestations’ were difficult to wipe out until some decent point defense or siege weaponry was researched, and prevented any form of colonization efforts in that direction until dealt with.

Now however, the Swarm is a lot more dynamic, and any infested system will randomly spawn a queen that will set out in an arbitrary direction and try and infest another planet. This in itself provides an interesting and ongoing threat for players to deal with in the early game stages prior to their first contact with another race, but unfortunately tends to get very tedious at the later stages when you control a massive empire and have to keep dealing with new infestations threatening to break out.

Then there are the new ‘Colony Traps’ – devious suicide drones hidden away on some planets, which are triggered only by a “Colonize” command which zoom up, lock a tractor beam onto any present ships, and then fly them right back into the planet again, smashing your ships against the surface. This can prove incredibly embarrassing for anybody who parks half their fleet in front of a planet for ‘security’ when setting up a new colony.

New encounters aside, the other new touches also add a nice flourish to the game – trade routes, once researched, can become surprisingly profitable. The system has a lot of detail put into it as well, and it’s possible to develop technologies to ‘raid’ the existing trade routes of other races, as well as assign patrols to your own. Careful balance does need to be struck to maximize profit however – the number of available trade routes actively depend on a planet’s priority setting between ‘Trade’ and ‘Construction’, so there’s less of a reason to just leave a planet focused on ‘Construction’ now (given how previously it would just make money anyways any time it wasn’t building something). Interestingly the freighters are also managed under the hood; they aren’t shown as real ships, and once built can only be monitored from the new ‘Trade’ view mode.

Each race in Sword of the Stars has its own unique means of getting around the galaxy. The Zuul use a brute force method called ‘Node tunneling’ to get from one system to another quickly; they must first use a specialized ship to make a node tunnel to another system, and can then use that tunnel by other ships. It’s a pretty slick system and provides more direct control over where nodes are placed (whereas SolForce’s nodes in contrast are randomly generated), but there’s a catch: Any node generated using this method is inherently unstable and collapses after a certain number of turns. In the beginning of a game session this isn’t a major problem to deal with, but it becomes almost maddening in later sessions, where essential nodes keep collapsing and forcing extreme amounts of micromanagement to rebuild them – some way to automate this process would have been very nice.