• Campaign mode – fight your way up in the war-torn Corvus system
• Start out with a single frigate, buy (or capture) more ships to grow your fleet
• Customize your ship’s loadout before battle
• Level up your crew
• Ship weapons and engines can be disabled by damage, adding a new layer of tactics
• Tons of balance changes, UI improvements, AI improvements, and several new ships and weapons

For a full list of the additions and changes in this release, take a look at this thread.

You can download the new version using the buttons below. You’ll have to reinstall the game, but shouldn’t need to enter the activation code again. Thank you all for your support!

A couple of things: one, this is really, really awesome. I can’t express how happy and excited I am that Starfarer is reaching a lots of new players. It means a more active community, more player feedback, and of course, more financial resources to support ongoing development. Two, it also means that our web server is struggling mightily with the herculean task of handling all this traffic. I’m looking into ways of improving its performance, so hopefully we can do something about it in the near future.

In fact, it looks like it’s doing a bit better now – but I can’t tell if it’s because traffic has dropped off a bit, or because the configuration changes I made are helping. Ah, the vagaries of trying to optimize a live server.

Edit: The hosting upgrade is finished. Let me know if you notice something not working!

… now that my feeble attempts at humor are over and done with, let’s continue.

Battles are a key way to progress through the game. They’re not the only way – you’ll be able to build up an economic power base, for example – but that’s not what this post is about. Battles offer an opportunity to get stuff for free, even if you don’t fancy yourself a pirate, but something slightly more honorable-sounding. The flip side is you can easily lose some hard-earned assets, too – ships, crews, even cargo if the outcome is bad enough.

What I’d like to do is outline the mechanics as they stand, talk a bit about the motivations for doing it this way, and sprinkle in a couple of screenshots. For the sake of this discussion, let’s assume the player won the battle. If they lost, things happen slightly differently, but it’s more or less a mirror image.

Casualties, Boarding, and Repairs
If you’ve played the combat portion of the game, you already know that instead of simply blowing up when hull integrity reaches 0, ships become floating, disabled hulks. There’s a small chance for each of these to be repaired after battle (most likely, player skills will allow you to raise that chance).

So a friendly ship can emerge from battle in the following ways:

• Completely unscathed or somewhat damaged
• Disabled and subsequently repaired, with a minimal hull integrity and heavily damaged armor (non-fighters only)
• Utterly destroyed (fighters and ships whose hulks are shot repeatedly until they blow up – unlikely for anything bigger than frigates)
• Disabled and beyond repair, and subsequently scrapped for any supplies

The options for enemy ships are slightly different. Retreating ships have a chance to be captured after battle, and the player has a choice between boarding and scrapping these. Disabled ships that can potentially be repaired can also be boarded or scrapped, while ones beyond repair are scrapped automatically.

Also, if a ship takes hull (not armor) damage, then there’s a good chance that some crew will be killed, in rough proportion to how much damage the ship actually took. It’s possible to win a battle and end up losing enough crew that you can’t meet the skeleton crew requirements to deploy most of your ships – so it’s a good idea to carry enough extra crew for these kinds of emergencies. Outside of combat, it’s assumed that automated systems let you get by well enough to navigate the ships, so even extensive crew losses won’t stop you from being able to move around the Sector.

The Odyssey has taken some damage, but the pirate fleet has been eliminated as a combat threat

Boarding captured ships is relatively safe – the commanders of these have surrendered, and the crews aren’t putting up any resistance. Therefore, the risks to your marines are minimal, and the ships can even be captured by your crew. On the other hand, personnel boarding disabled ships face many dangers, from malfunctioning systems to pockets of resistance by surviving enemy crew. Only marines can even attempt this kind of boarding action, and will often take losses.

To recap, the player gets to make a “board or scrap” choice for either captured or repairable enemy ships during this initial post-combat phase.

Looting
The second phase is all about transferring any recovered cargo to your fleet’s holds. The amount of stuff you get depends on the outcome of the initial phase. Boarding ships produces more loot than scrapping them, and of course any ships that managed to retreat get away with their cargo intact.

Supplies, fuel, and weapons looted from what remains of the pirate fleet

The top half shows your current cargo, crew, fuel, and whatever else falls under the loose definition of “cargo”. The bottom half shows what’s been salvaged after the battle. In particular, the weapons come both from the cargo of the enemy fleet and from what was actually mounted on the enemy ships.

Motivations
I had two main goals when approaching the design of both these mechanics and the corresponding UI: 1) make it hassle-free and 2) offer the player some choices. These two are at odds with one another (figures, doesn’t it?), so as usual the process became one of looking for a sweet spot between the two extremes of “no choice” and “way too much of it”.

A simplifying assumption I made is that the player shouldn’t be asked to say whether they want to try to repair a ship or not – it’s just attempted automatically. The key point is that there’s no cost to making the “repair or scrap” choice, so there’s no need to bother the player with it. If the “repair” choice had a cost (say, some supplies to attempt it), then it would need player confirmation.

The “board or scrap” choice doesn’t come up all the time, but it does have a cost – the player is likely to lose marines every time they do it, so it has to be an explicit call on their part.

How often the after-combat screen comes up is actually an important question, and one I don’t have a good answer to at the moment (and it depends on playstyle, to boot). If it’s not too often, then it’s ok to have more choices – and have it be a little more work. If it’s more frequent, then it needs to be as streamlined as possible. I’m going with the streamlined approach for now, but will be keeping an eye on how it plays out – and whether it provides enough flexibility.

First, a minor matter of nomenclature – the next version is going to be called 0.5a (up from 0.35a) to reflect the large chunk of features it contains.

Now, what’s actually done already? I’ll try to keep this on a high level to keep the post from spiraling out of control – there is already a forum thread with the gory details, if you want to dig deeper.

Everything takes place within a single star system for now. You can manage your fleet, cargo, and crew, and engage hostile fleets in battle. You can engage in post-battle boarding actions and salvage what remains of the enemy (and your!) ships. You can refit your ships using available weapons and hull modifications. Ship weapons and engines can get damaged and disabled in combat, adding a whole new layer of tactical considerations. There have been many UI improvements – most notably lots more tooltips, and much-improved existing tooltips. There are also several new ships and weapons. You can create a new character – just a name and portrait for now – and there’s the save/load functionality you’d expect.

When I put it that way, it sounds just about playable, doesn’t it? The trouble is, right now those things are just disjointed features, and what I’ll be doing over the coming weeks is cobbling them together into something that’s actually fun.

The next step is to add factions and faction-specific fleets into the game. There won’t be any higher-level campaign mechanics yet – for now, fleets will spawn somewhere in the star system. There also needs to be a way to hire crew and buy/sell weapons and ship hulls – so we’re probably looking at some basics of interaction with a populated planet. I’d also like to add player skills and character and crew advancement – though that’s separate enough that it could be deferred to a subsequent build if need be.

But none of those are particularly time-consuming as features. The major, major task remaining is intangible – it’s simply going to take a lot of play-testing, balancing, and more play-testing to get all of the above right.

So, what can you expect?

First of all, I’m going to get a just-barely-playable version of the above together and put out a preview release to those interested. It won’t be balanced, it will have bugs, but it will help a whole lot to get some feedback. This should happen in January. After that, I’ll spend some time polishing it up and making it generally more enjoyable, while incorporating any feedback from the preview release.

I’d also like to release a demo. What I’m thinkining is to make the missions playable in the demo, and only make the campaign available after the game is activated – but to release both in the same version. That way there’s still just one download, you can make sure the game runs on your system before buying it, and it’s just all around simple.

All in all, I’m very excited that the initial campaign release is finally drawing close! … I guess I better wrap up this post and get cracking on it. That code isn’t going to write itself, you know.

A lot of the ones not currently in the game hint at features under consideration. Let the rampant speculation begin!

Click on the image to view at full size

Not every ship needs to bring something unique or interesting to the table – if nothing is “average”, then it’s hard for anything to be special. On the other hand, if two ships fill the same role in the same way, that’s a bad sign – it’s a wasted art asset, and complexity added to the game that doesn’t pull its weight by giving meaningful choices to the player. Still, having more ships is good if they pull their weight – it gives the player more choices and avenues for advancement, never mind more varied opponents. Having enough ships to give factions a stronger identity is important, too.

So, what are the factors that differentiate ship designs?

First of all, there are 5 size classes – fighter, frigate, destroyer, cruiser, and capital ship. We’ve also established three tech levels for ship designs – low tech, midline, and high tech. Low tech ships have high armor and a mix of ballistic and missile weapons. Midline ships have a mix of all types of weaponry, and average armor and shields. High tech ships rely on energy weapons and missiles, and typically have lower armor and excellent shields, in addition to improved mobility. Ships can also have launch bays for fighters – with some ships being dedicated carriers.

Just those factors combine to create a lot of combinations – a low tech cruiser? A high tech carrier? You can also easily make a ship distinct by giving it something special – such as, say, a weapon slot that’s too large to be normally found on ships of that size, or exceptional movement speed. Where the weapon slots are located and what arcs they cover is key to how a ship plays out – for example, having an important weapon battery point slightly to starboard will affect the best way to pilot a ship and will be a constant tactical consideration.

To top it off, not all ships are dedicated combat vessels – they have stats such as cargo, fuel, and crew capacity. Down the line, I’d also like to add active ship systems (such as afterburners, a combat teleport, or an ECM device). Between all these, keeping ship designs varied is easy.

Up til now, we haven’t had any particularly large high-tech ships in the game that could also put out a lot of firepower. But that’s about to change – allow me to introduce the Paragon-class battleship and the Odyssey-class battlecruiser. These two are anything but average.

The Paragon
The Paragon is essentially a mobile battlestation. Its shields are the best in the game, and are backed up by a vast flux capacity. Its armor and hull aren’t quite that of the Onslaught (a low tech battleship), but its overall survivability is better. On the other hand, because it sports a large number of energy weapons – which generate a lot of flux – there’s a greater need to balance weapon and shield use. The mostly-energy arsenal also means the Paragon isn’t dependent on munitions being available, reducing its maintenance costs and giving it greater longevity in battle.

Unfortunately, due to its focus on combat, the Paragon doesn’t perform well in other areas. It requires a lot of crew to run and has a low cargo capacity. The amount of fuel it consumes during hyperspace travel is staggering, and it has low fuel reserves. Using it effectively requires support ships – tankers, transports, and freighters, but even then, it’s not the kind of ship you’d want to have in a trading or exploration fleet. But when it comes to battle, it has no equal both in terms of survivability and sustained firepower.

The Odyssey
In contrast to the Paragon, the Odyssey is a nimble ship for its size and sports impressive firepower. In typical battlecruiser fashion, its hull, armor, and shields are sacrificed as a result – it’s outmatched by some heavy cruisers on those counts. Uncharacteristically for a ship with so much armament, it also has a fighter launch bay.

Unlike the Paragon, the Odyssey is well-equipped for long-range exploration. It can carry a respectable amount of cargo, has lots of hangar capacity for fighters to tag along, and consumes a reasonable amount of fuel for a capital ship. It requires a bit more care in battle, but overall makes an excellent flagship, especially for a player focused on skills that improve the performance of their ship.

… and now, if you’ll excuse me, I’m going to set up a large battle with these ships. Strictly for playtesting purposes! Nothing to see here, move along.

There are three main reasons to have crew in the game: to increase immersion, to add another avenue for advancement, and to introduce interesting resource management mechanics. In other words, having a tangible crew is neat, watching them go from raw recruits to seasoned veterans is rewarding, and having a say in how the crew is used to get the most out of them is engaging. The crew is far from being the main mode of advancement, though – the player also has their own skills, officers, ships, and weapons to upgrade – so it’d be a mistake to look at it solely from the player advancement angle.

However, figuring out just how to model the crew of your ships has been a difficult process. There are two components to the mechanics: advancement and assignment. Advancement is how the crew progresses through experience ranks. Is it linear, or can crewmen specialize in gunnery, piloting, and such? Assignment is just how the player matches up the crew to the ships they run – what amount of control they have over it, and exactly how it works.

The Problem
Those components depend on each other a great deal. Suppose the player just has one ship – we don’t need to worry about assignment at all, then. Free from this concern, we could come up with an involved scheme for crew advancement – with individual crewmen progressing through the ranks all the way from raw recruit to master gunner or somesuch.

On the other hand, suppose the player has a large fleet. Do we really want them to worry about making sure the ISS Unlikely to Survive has the right number of gunners? If they’re losing a ship or two every battle – and with large fleets and battles, that’s quite likely – having to re-crew new ships afterward would quickly become a chore. What we need is to strike a balance – enough detail for immersion and sense of advancement, but not so much that the mechanics become a bother for large fleets. The mechanics should let the player make meaningful choices with a minimum of fuss – not make them perform rote actions over and over.

The crux of the problem for me was the need to assign crew to specific ships. I kept turning that over in my mind, and just couldn’t get around the awkwardness of having to manually do it. You’d have to handle it for new ships, for re-crewing ships after losses, and for switching crews around for key battles – to name just a few situations. It’d be a royal pain.

Not the Solution
An idea I had in mind for some time was to not model crew directly and instead keep track of the experience level for a given ship. That’s simple – the player doesn’t need to worry about manually assigning crews – but it falls short on immersion and mechanics. The crew gets so abstracted away it’s hard to have an emotional connection to them, and you can’t manipulate it in any way at all. Worse yet, it’s a bit of an immersion breaker – you can’t move experienced crew from one ship to another, even if it’s the same type – which is hard to explain away in-fiction. You can certainly try, but it goes something like this:

Game designer: “Well, you see, the ships all have unique quirks that the crew has to learn, and that knowledge doesn’t transfer over to another ship very well.”

Pesky player: “But they’re all made in an auto-factory from the same blueprint!”

Game designer: “Well, you see… hey, what’s that over there? <runs away>”

Ahem.

The Solution
As with a lot of problems, I stumbled onto a much better solution while working on something unrelated (the fleet screen), and all the pieces fell into place.

The crew is now a tangible asset – on par with cargo, and managed through the same interface. Crewmen advance automatically through 4 experience levels – Green, Regular, Veteran, and Elite. After each battle, chances are you’ll lose some crew – and that some crew will also advance to the next level. Crew is assigned to ships automatically based on the order of the ships in the fleet screen (shown below), starting with the most experienced crew. Each ship has a “skeleton crew” capacity that must be filled for the ship to be ready for battle, and after it is, the next ship in line is crewed. After every battle, crew is reassigned to account for both ship and crew losses. All the player has to do is set a priority for which ships to crew with more experienced personnel by arranging the ships in the desired order, and the rest happens automatically.

70 brave crewmen were thrown out of the airlock in the making of this screenshot

You can see rank insignia in the screenshot indicating the experience level of each ship’s crew – and a “needs more crew” message when there isn’t enough crew to man the ship. The fleet screen is still a work-in-progress, by the way.

One downside is that managing crew assignments by rearranging the order of your ships isn’t very intuitive. Hopefully, seeing the most impressive-looking insignia at the top – and seeng the insignia change as ships are moved around – is enough to make it clear. All of the “needs more crew” messages always being at the end of the fleet roster should help, too.

Overall, I’m happy with this approach – it works equally well for different fleet sizes and humanizes the crew somewhat (you can actually see them in the cargo screen). The player also gets to take their crew from green to elite, and to see shiny icons (not to mention much-improved ship performance) as their reward. Most importantly, it gives the player some choices with an absolute minimum of work – once the choice is made, the system maintains itself in the face of losing and gaining ships and crew. No input from the player is needed until they make another decision.

… and that’s the scenario we all want to avoid. Auto-resolve has great potential to frustrate the player, because it can obliterate their progress (in the form of resources, ships, and officers) – but worse, it can do this unfairly. The unfairness comes from breaking the player’s expectations of how the game world works. In our example, the player knows their fleet can mop up that convoy – but auto-resolve plays by a different set of rules, one the player hasn’t been exposed to before, one that isn’t clear. Even worse, the rules are hard to learn because they’re hidden. In the situation above, the player might assume that luck plays a big role – but it may well be that the officer skills weren’t valued as much as they should be, or the weapons you’ve equipped the ships with, or any combination of those and other factors. The player might give up on auto-resolve entirely – there’s no clear way to get better at it, and it’s not apparent whether improvement is even possible – and the player is punished for experimenting.

It’s still necessary though, because the alternative is having to fight every piddling battle yourself. Besides, battles that don’t involve the player need to get worked out somehow. So how can we address these underlying problems? Because I like lists, let’s make a list of things that aren’t fair to do to the player:

• ignoring any improvements they’ve made to their fleet – be it weapons, hull mods, officers, character skills, anything at all that has a bearing on combat
• ignoring the overall rules of combat the player knows – carriers increasing the effectiveness of fighters, bombers being effective vs large ships, point-defense weapons countering fighters, etc
• destroying any ships which would absolutely never, ever get a dent put in them if the actual battle was played out. A wing of Talon-class interceptors should have no chance to take out a wing of Wasps, for example.

To sum it up, the auto-resolve system has to roughly simulate the way combat plays out, take all relevant ship & fleet stats into account, and be very careful that “adding a degree of randomness” doesn’t become “anything can happen”.

One thing we can’t take into account is the actual player’s skill at piloting (not their character’s skill, which can be). That’s ok – a battle where the outcome hinges on the player’s personal skill shouldn’t get auto-resolved to victory, anyway. More importantly, I think the player wouldn’t expect auto-resolve to do as well as they do with themselves at the helm.

In the remainder of this post, I’ll talk about the approach I decided on and give some examples of it in action.

The Approach
A natural way to design the auto-resolver is to approach it like a turn-based game. A “simplified Heroes of Might and Magic battle simulator” is an apt comparison to how it turned out. If you haven’t played HoMM, it’s like King’s Bounty. If you haven’t played that either, it’s like the original King’s Bounty from the early 90s. If you haven’t played any of those, you’d probably enjoy them. For the HoMM series, I’d suggest the 3rd one… but I digress. Where was I? Oh, right – designing a turn based combat simulation based on the real-time combat of Starfarer. Yes.

The first step is to come up with the stats of our units, the ships. We have to do that with an eye towards accurately representing the real-time dynamics of the game in a turn-based environment, of course. The actual set of stats evolved as I kept fine-tuning the auto-resolver, but it didn’t get too far from the starting point. Here’s the final set of ship stats:

Hits, Shields
These reflect how tough a ship is to bring down – two sets of hitpoints, with damage getting through the shields causing the ship to be damaged after the battle. For simplicity, shields don’t regenerate during the battle, but the regeneration rate is included in computing the shield strength. Both stats also reflect how difficult a ship is to hit, with faster ships having increased hits/shields values.

Attack, Point Defense, Strike Attack
The goal of having these three is to reflect the most important counters present in real-time combat – PD vs fighters, and strike weapons (bombs & torpedoes) vs large ships. Notice that damage types are not reflected here – they could be, but it seems to work well without them. It’s an extra level of complexity, and would require a more detailed hits model – you couldn’t fold the ship’s maneuverability into its hitpoints anymore.

Movement, Maneuverability
These are used to modify the hitpoint values, and also affect the chances of a ship to escape/retreat.

Number of Flight Decks
Each flight deck can double the hitpoints of up to two fighter wings in the fleet.

The computations to come up with these values get a bit involved – suffice it to say, it took a couple of days to design the overall system, and at least double that time to fine-tune the calculations until the battles worked out right. Everything from hull mods to mounted weapons to officer personalities and the commander’s skill is taken into account.

The second step is creating a system that mimics how battles work when played out in real time.

First up is a “skirmish phase”, to reflect the jostling for objectives that happens at the start of most battles. The relative strengths of fast ships in each fleet are compared to determine which side got the advantage. No damage is dealt in this phase. The skirmish advantage that can be gained is reduced when small fleets are involved – can’t exactly split the enemy forces if all they have is one ship!

In the second phase, the ships fight it out. A ship is picked at random to attack – but the outcome of the skirmish makes it more likely for a winning side’s ship to be picked.

Then a target ship is picked from the enemy fleet. If a ship has good strike weapons, it’s more likely to go after a large ship, while interceptors are more likely to target enemy fighters. Higher commander skill improves the odds of getting a beneficial target pick.

Then the damage dealt to the target is calculated – a combination of attack, point defense, and strike attack, with coefficients based on the target type. For example, strike attack deals a lot more damage against cruisers and capital ships, and no damage at all against fighters and frigates. The target also gets to fight back, but only once per “turn” – the ability to fight back is reset when a ship is picked to be an attacker.

This process is repeated until all ships on one side are disabled, destroyed, or have retreated. When the number of remaining ships becomes small, the amount of damage they deal is reduced to mitigate the effect of luck.

Sample Battle Results
A good way to test this system is to have it run some battles that we’re already familiar with – and what better than some of the current missions?

Here are the results –  with the chance of the player’s side winning the battle. Each simulation was run 10,000 times – incidentally, taking around a second to do so. The performance isn’t so important for battles the player is involved in – even if it took a second, that’d still be acceptable – but battles happening on the other side of the sector should not cause any delay.

Fair warning – f you haven’t played the game, these aren’t going to make a lot of sense.

Turning the Tables: 75%
The very first mission. It’s an easy one, and 75% seems about right. It’s certainly possible to lose if the enemy bombers get a good strike in, or if the Lasher frigates fire off a well-timed missile salvo. Replacing the bombers with heavy fighters boosts the win percentage to 88 – they have a much harder time handling the heavier ships in the player’s fleet.

For the Greater Lud: 62%
A fairly easy mission. The enemy cruiser poses a big problem on paper, but the player’s fleet has a number of bomber wings to take it out. If it weren’t for those (if they’re replaced with heavy fighter wings), it’s not even close – the score drops to 33%.

Hornet’s Nest: 14%
A medium difficulty mission, with the player commanding a far outnumbered, high-tech fleet. It’s not too hard to do well in the early going, but eventually the enemy numbers start to wear you down. It’s obviously hard to say whether 14 percent is exactly right (whatever that even means), but it doesn’t seem unreasonable. After all, it takes a good amount of piloting skill to get a win. The enemy fleet only has a single small carrier – but removing it boosts the player win percentage all the way to 40, because of all the fighters in the enemy fleet.

Predator or Prey?: 0.1%
This one is tough. The player’s fleet is outgunned, outnumbered, and the enemy fleet is full of strike craft that counter the player’s flagship really well. It takes a decisive attack on the enemy carrier and a fair dose of luck to win. Replacing the enemy bombers with fighters  raises the win percentage to 2.5, but it’s really the combination of a quality carrier with a swarm of fighters – whatever the type – that makes the opponent so hard to handle.

Having played those missions to death myself, I’m pretty happy with those results. If one thing is certain, though, it’s that we’ll keep tweaking and refining this system as development goes on and issues crop up. One thing I wouldn’t rule out is cheating erring on the side of caution to benefit the player, should situations like the one outlined in the opening paragraph still arise from time to time.

I was talking to Alex a while back and he viciously commanded kindly asked me to shed some light on the writing process, specifically regarding the Factions and World Development.

I forgot about that request immediately. But now, he has activated my pain implant graciously reminded me, and here I am with a new blog post for your reading pleasure.

The Factions

I think most of you will agree that one of the keys to having a memorable game experience is the believeability of the game world. Those that do not agree, please go back to playing Tabula Rasa. Oh wait, you can’t! <gloat> Ahum.

Anyway, one of the types of action that the player can perform in the game will be interacting with the Factions. These are large collections of human beings that share the same philosophy, goals and are big enough to be a factor on the political stage in the Sector. So how to come up with these? The truth is, some of the factions were born out of a need for a particular role to be filled within the game. For example, we knew we wanted a big, monolithic, largely obtuse but powerful organization that claimed to be the spiritual successor of the Domain of Man. Thus – the Hegemony. Next, we wanted a counterbalance to this feel, and we came up with the small, intelligent, vicious and astute corporation – Tri-Tachyon. And so we created most of the factions in this manner, as actors fulfilling roles, and their allies/enemies based on the type of feel we wanted to create within the game. Some of the names and portfolios of these factions have a rich history, based on years of wasted time by yours truly, as a young lad writing GURPS Space campaigns and short stories designed to flesh out those campaigns.

While having a number of factions to pick from and knowing what it is they roughly represent, want to achieve etc. is great, I really felt like I had to nail the psychology of each faction more accurately. After all, the situation in the Sector is pretty unique. The pivotal, crucial thought that occupies the minds of most humans within it is the role of technology in their lives. Unlike the present day, while technology plays a critical role in survival, it’s also poorly understood and is retrogressing with each breakdown that can’t be fixed. In addition, I wanted to present each of the factions as realistically as possible, which included having both negative and positive qualities. So, I decided to do some research on personality types and see if I could associate each faction with a particular psychology.

In order to grapple with the large amount of information, I used an excruciatingly boring, colossal spreadsheet to write out each factions’ outlook, motivators, virtues and vice, fears and fixations. Thus, I proved once again that all game design is just mucking around in some spreadsheet. Ah, well.

To give an example, I profiled the Tri-Tachyon Corporation  as arrogant scientist/corporate types. They see themselves as keepers of knowledge, heirs to the technological marvels created by the Domain. Obsessed with efficiency and the acquisition of technology that remains in the Sector, they condemn those that shun them. They are prone to over-thinking problems as a group, and care little for the plight of those outside their inner circle. At their best, they are competent, effective and cooperative with one another. At their worst, they are detached, elitist and cruel. Their belief is that the non-functioning star gates are merely dormant, and they they are actively looking for the key that will awaken them – thus restoring to them the lost technological wealth of the Domain. Secret tech-mining operations run by the Corporation can be found in the farthest reaches of the Sector.

But wait, there’s more! Hey seriously, if you’ve read this far, please get up, stretch your arms and legs, and get yourself a nice treat as a reward for persevering though these, the inner secrets of Fractal Softworks’ design process. Done stretching? Don’t open that other browser tab!

The Worlds

Designing worlds is always a challenging task for a variety of reasons. The main one is, we humans have only ever set foot on one (the Moon landing was faked!) so it is real hard to get a different frame of reference. Also, the sizes we are talking about when we describe planets dwarf the imagination. Our minds are literally incapable of visualizing such vastness. The process roughly follows the following flow. First, pick a defining planetary characteristic. Is the planet surface a scorched volcanic wasteland? A dry, parched desert? A frozen, uninviting chunk of ice? Or is it a verdant, terran-like gem?

Once the biome has been chosen, you have to think about the other layers of a world that make it a point of interest. Which Faction is in political control of the planet? What kind of government is there? How many people live there and under what conditions? Answer to questions like these also tie into gameplay systems, because they dictate the beginnings of the supply and demand based mechanics that underpin the in-game economy.

Conclusion

Well, I hope you guys had fun reading that post. Now I gotta go, and build my fifth outpost on that jungle world. Maybe this one won’t sink into the swamp.