Astrobase Command, a sandbox base-building RPG by Jellyfish Games, is a character-driven throwback to those old 70s style sci-fi ideas of what living in deep space would be like. You’ll laugh, you’ll cry, and as your crew struggle to make it through the day some will die. Players will be tasked with creating their own species and building up their base any way they see fit using a ‘Lego-style’ module system to slot in various rooms onto the space stations infrastructure.
Alongside the base building elements, Astrobase Command promises some interesting RPG elements as you explore the stars, with procedural content thrown in to help keep content fresh and unexpected. To get a better understanding of what the folks at Jellyfish Games are trying to achieve, we got to throw some questions at them, and here’s what team member Dave Williams had to say.
The Indie Mine: The game appears to have a big focus on the lives and activities of your individual crew members. How deep is the character development system?
Dave: Character development is a major part of the game, so it’s quite deep. The best metaphor is that when I played D&D in my early teens, it was all about min/maxing and getting that character which was completely optimized in his stats and abilities. And this was loads of fun. But what was even more fulfilling was playing D&D in college and as an adult because then it became about the character and solving challenges from the perspective of the character. The stats were there to inform the roleplaying and flesh out one aspect of character development, but they weren’t the be-all-and-end-all.
So Astrobase Command is really based around the premise that the characters living on your station are not just “bags of stats”. but they’re actually people in the same sense that characters in a well-made D&D universe are.
And I think this dovetails nicely with what’s interesting to us about science fiction. While lightsabers and Star Destroyers got me excited about sci-fi, I feel like it’s really the characters that make the genre compelling on a level so deep that fans go to conventions every year, do cosplay, and exhibit an uncanny willingness to wait in line for a day to get tickets for a theatrical release. This isn’t because of the awesome futuristic technology and panoramic shots of spaceships and pew-pew; it’s because of really compelling characters and their stories which take place in a believable sci-fi world (which is where the technology comes in).
So in my mind, science fiction isn’t about technology itself; rather it’s about exploring the conflict inherent in technological development and how characters meet those challenges. So I think if you dig into it, what’s cool about lightsabers is how this archaic technology (by Star Wars standards) embodies the values of ancient wisdom and tradition represented by the Jedi, and how this fundamentally clashes with the Empire’s need for relentless progress. It is against this backdrop that Vader proclaims “don’t be too proud of this technological terror that you’ve constructed, the ability to destroy a planet is insignificant next to the power of the Force.” So what’s interesting is the storytelling opportunities afforded by the technology as a backdrop, not the technology itself.
As a result of this notion, we have a heavy investment in the personality trait system which hooks into our AI story engine in specific ways. There are 280 personality traits (so far) and a given character can have up to four. Each trait has a very long list of properties, affinities, and relationships and it’s actually these more atomic units that the AI story engine interacts with. But we wanted the mechanics of the system to be invisible to the player, because he or she should care about the character as an individual — the sum of its parts. It’s the code that does the work to make it believable, and we’ve put a lot of effort into this.
Our test as to whether the trait system worked was being able to construct our favourite characters from various sci-fi universes and have them behave as you would expect. Part of the iterative process was ensuring they could be represented in this system. Because if the trait system could theoretically use its Lego pieces to construct anyone from a believable Picard to a believable Vader, then you can make anything.
And just to be clear, the player doesn’t get to pick the traits of the crew. They develop over time as an outcome of the AI Story Engine. Personalities of characters emerge from the situations the player puts them in.
Much of the fun is taking these deep characters (who may have some great aspects combined with other aspects that don’t fit your playstyle), and figuring out how to best utilize them on your station. The Star Trek example is Lieutenant Barclay. He was an extremely talented diagnostic engineer, and he might have been the smartest human on the Enterprise — his intelligence was at the genius level, even by Star Trek standards. But he also was completely paranoid, an introvert, and plus he was pretty arrogant. And this is what made him interesting. And plenty of TNG episodes explored how his perceived weaknesses actually became an asset. His paranoia actually saved the day a number of times, as did his arrogance to insist that he was right and everyone else was wrong (which ended up being true).
So the idea’s that there are no intrinsically good/bad traits. It’s simply about the kinds of characters the player trusts and what characters best suit the player’s playstyle.
The Indie Mine: How will the player maintain a steady stream of crew members? Since you plan on having several ‘disastrous scenarios’ like alien infestations and accidental deaths amongst the crew, I’d imagine there must be a way to replace those unfortunate red shirts.
Dave: Yeah, there are a number of ways. The most fundamental method is recruits. One of the jobs on the station is Recruitment Officer, and it’s the job of the character in this position to feed the player a steady stream of recruits. Like HR in real life, better Recruitment Officers yield better candidates. Then it’s up to the player to accept or reject the application. Because Crew Quarters are a module that needs to be built/supported, you don’t necessarily want to accept everyone that comes your way. There definitely a danger of “dead weight” — which is something that can exist in any real-world organization, and indeed in Astrobase Command. Sometimes the player is looking to fill a need or role on the station, and then looking at recruit applications and deciding who the best fit is. Other times, a superstar may come along and the player may feel he’s a good hire even if there’s no immediate job for him.
Other than this, there are instances where travellers, or people you rescue, or defectors from other civilizations, etc, will want to join your Astrobase. The story engine determines these moments, and gives you the opportunity to do something about it.
I think red shirts are ultimately characters that don’t yet have a developed personality, nor has there been any particular investment into their skills. Since there’s no emotional attachment, sure they can go explore the Planet of Death because maybe there’s some needed resources on the surface. What’s interesting is that when those red shirts do something interesting, and maybe get a personality trait of it. Then you care about them. And indeed, this is how things worked on Star Trek.
Chief O’Brien is a good example about this. At the beginning of TNG he was a fill-in character, completely expendable. After awhile, you got to know him and he did some things. Then by DS9 he was a primary character. And you really cared about his story, even though he was still a Petty Officer. That’s kind of how things work in Astrobase Command. You want NCOs you can trust, just like you want Commanders you can trust.
The Indie Mine: How much customisation is available when building your space station?
Dave: We use a module metaphor, so the player essentially crafts modules out of parts and then the module has the cumulative attributes, including the relevant duty stations where the characters physically work. The characters assigned to build the modules also play a part, so better engineers will construct better modules. There are no map sizes or hard limits, so you can basically build whatever you want. You can make a Death Star, you can make a Babylon 5, you can make a DS9 — or whatever mash up fantasy is living in your head. These goals are intrinsic.Well, since Astrobase Command is a lot about sci-fi fantasy fulfilment, it was paramount to us to make it feel like you were actually building a believable station.
It is important that the game doesn’t push the player to building any particular thing. It’s more that every opportunity is a choice, and every choice is a tradeoff. So you’ll want to build the station that best fits your playstyle and accept the good with the bad. So for example, a Death Star has lots of points of failure. Security is a pain. Its energy needs are extremely high. It is a city that has everything, but this is also its weakness. It needs experts in every field imaginable to be fully operational. Whereas a small science station has a lot less points of failure, but the trade-off is inherent in the narrow focus the player gives it. Simply put, it’s about risk v reward but also playstyle.
So a lot of design has gone into these sorts of natural mechanics. One very simple example of a natural tradeoff is power vs. security. Power is distributed through modules which have resistance, so the farther something is from a power reactor the less efficiently it’s sucking that power. Power reactors have a set output, so in general you want to utilize the output by having modules that are nearby. Incidentally, the code works out the most efficient way for the modules to draw power given the distance and resistance of the modules in-between it and the reactor. The way the algorithm works, if you don’t have enough power then rolling brownouts occur naturally as the algorithm walks though the module list and tries to power everything. This was a validation of the process, because it’s what you would expect. We didn’t code it deliberately, but rather it’s a natural result that emerged from a sensible way to represent station power.
In terms of trade-offs, being extremely power-efficient trends towards a “highly connected” base, which makes sense in real-world terms. But this is the opposite of what you want for a very secure station. Security works by having checkpoints take up some of a module space, and security personnel will work out routes. Super efficient security means having a tubular (or ring-like) station, with choke-points where you can trap enemies. Because it’s a lot easier to sweep an area with just a few access points. So something that’s very efficient for power ends up being very inefficient for security, and vice-versa simply due to a natural outcome of module connectivity. That’s just one example.
The Indie Mine: You say the game features real-time squad-based combat in some situations, so how will the battles play out?
Dave: I could say that battles play out a bit like a cross between Rome: Total War and tabletop miniature games, but in a 3D space. But this is highly dependent on the conflict size.
Unlike Rome: Total War (or RTS games in general) where each unit is identical to others of its type, in Astrobase Command every unit is unique because it is a character. The player creates groups (could be squad sized, or regiment sized) and gives orders at the group level. For small conflicts, the player is able to really take a hands-on approach and direct every movement precisely. For large conflicts, there’s too much going on for the player to micromanage every small action, and he’ll need to give high-level objectives to Commanders on the ground. The AI will execute those orders using the character personalities. So it’s about promoting Commanders you trust.
A counter-analogy I like to use is Starcraft. I loved Starcraft, but I could never compete at the high levels of play because it ultimately was about clicks-per-minute which required a lot of practice and a huge investment. And I felt like to be able to compete I would have to lessen my enjoyment of the game, and invest a lot of time doing that. Astrobase Command isn’t about how fast you can click — you have Commanders to do this for you, if you’ve cultivated them.
And this means the game scales up quite well. In the early game, where you don’t have a lot of characters and none of them are particularly well-developed leaders yet, you’ll be fighting small engagements and directing every squad yourself in the moment-to-moment gameplay. As you progress and the battles get larger, you’ll still probably focus on one area of the battle where you really want to take personal control, but for other areas where you can’t give your undivided attention you’ll put characters in charge and give them an objective which might be “assault this position” or “take this hill” or “hold my flank” or “bombard their capital ships to distract fire away from the fighters” and the AI will fulfil those orders, to the best of the ability and personality of the Commanders you’ve assigned. This is how we plan to support huge fleet battles and armies, without requiring the character move every unit by hand.
The Indie Mine: Astrobase Command boasts a “robust AI-generated storytelling system”. How will the game keep things fresh and exciting for the player?
Dave: I think one of the weaknesses of rogue-like games is that they often play like a series of disconnected events, where things happen randomly. We feel like that invalidates the concept of meaningful choice. Because a big part of player choice is having outcomes which are a consequence of player action.
The goal in Astrobase Command is to have events which occur in the game world that are a direct result of the actions taken by the player, and by the player’s crew. And that it makes sense when compared to the internal logic used for sci-fi shows. Because that’s the metric: “Could this string of in-game events be a Star Trek episode, and over time when story arcs emerge does it start to look like a season?”
So the idea is that we give the player a maximum possibility space, and ensure the game responds appropriately to his actions within a maximal set of reactions. This in turn prompts the player to make new choices to respond to the new situations. Then, it will always be fresh.
The Indie Mine: What’s the craziest moment you’ve seen when making the game?
Dave: I think being indie is necessarily filled with crazy moments. Obviously, Astrobase Command is very much a technology and systems driven game at its core. And the team composition reflects that, but it also means we won’t have an artist until after the Kickstarter. But part of doing a Kickstarter means showing gameplay, and we got to a point where we needed in-game assets just to proceed. We were like “who has the most 3d Studio Max experience?” and Adam our primary coder had opened it like once, two years ago. He had the most experience, so he’s now also our 3d modeller. We call it our “Inglourious Basterds moment.” Banjerrrno!
If you want to know more about Astrobase Command, check out their Kickstarter campaign (In which 30 Canadian dollars will net you access to the beta when it’s released) and the game’s official website.
© 2013, The Indie Mine. All rights reserved.