The following briefing is cleared for officers at Hegemony COMSEC level ALABASTER. If this document has come into your possession outside of protocol 20 then you must destroy this document and report immediately to your unit intelligence officer for enhanced debriefing.

# # #

Here be spoilers to Hidden Fun Content in Starsector. Many of you have clearly not been following important Hegemony COMSEC directives, leading directly to speculative rumour-mongering among the civilian population about the art and design of certain deep space objects which are the subject of today’s blog post.

Proceed at your peril!

Now that we’ve got that out of the way, how about those battlestations? Pretty big, right? They took some doing. And we’d been planning to implement them one way or another for quite a long time. It was quite rewarding to see people freak out when they ran into a fully armed and operational Remnant Battlestation.

And there’s more planned to do with stations in battle, of course. Which seriously is all you’re going to get out of me on that front. (At least someone around here respects important Hegemony COMSEC directives!)

# # #

Upon reviewing correspondence with Our Benefactor, it appears that we first discussed stations … quite a long time ago. The conclusion to that exchange was to put off further discussion until “the time was right”. I mean, this is a space game, of course we’re going to think about putting big stations into combat. It’s obviously an awesome idea. But how would they work?

There were a few core mechanics for stations that followed logically from the concept of stations in general and considerations of combat mechanics in Starsector in particular. This is actually largely covered by Alex’s post, Orbital Stations In Combat, but I’ll repeat a few points in my own words because they inform the artistic direction for battlestations:

1. We knew from the start that stations had to rotate. A station is stationary. But movement is supremely important to defense in Starsector and an immobile target is an easy target. What to do? Make the station rotate! (Like in Master of Orion 2! Which also had separate directional shields, which we also stole because it’s a great idea.)
2. Stations also need extreme weapon range so that they don’t get stuck in a place that rewards long-range player ship builds plus tedious combat grinding. So: the player must close with the station. There are still degrees to which range comes into play, but you’re (almost) never going to be able to kite/snipe a station battle.
3. Stations are built from modules. This means they’re like one big Starsector ship with a bunch of smaller ships attached at various points. From an art creation standpoint, this means that I don’t have to draw ungodly huge sprites 4-5 times larger than the largest capital ship and make every little piece unique.

So there we’ve got the imperatives for stations in Starsector. How does this translate to art?

Stations need to be huge. If they’re smaller than ships, then what’s special? Nothing! They can’t move! Yeah, not very exciting — so they must be huge. Starsector sprites aren’t exactly pixel art, but they’re something closely related and as such they’re fairly labour-intensive to draw. As sprite size increases, the area which much be drawn increases geometrically. See here:

There’s not way it would be reasonable for me to go in and do pixel-by-pixel fill for every detail of the station sprite. It’s a good thing then that there are many useful methods to make large-scale Starsector art viable: using repeating textures, digital painting, marquee and shape tools plus fills or airbrushes to form geometry and shading, and mirrored/repeated elements are all important. I’ll talk a bit more about these methods further in.

Modules are also extremely helpful because they break the problem down into repeating pieces which range from small destroyer to small cruiser in size.

Let’s back up from technique for a moment to focus on a question of overall composition. Here’s what stations first looked like when they appeared on the Starsector campaign map:

Clever modders who dug into the files will know that there was a larger base image for that station which was this:

This was drawn in a fairly standard manner for early Starsector sprites; heavy on pixeling, though with a touch of larger-scale geometry and airbrush shading. You can clearly see principles of copy & rotate as well as repeated use of modules bearing some medium weapon slots and hangar bays. These are of course the assets used in Alex’s ISS Placeholder battlestation.

I’d like to note the fundamental composition assumption made here: this is a top-down “wheel” style spacestation. Where have we seen this?

Correct! That’s 2001: A Space Odyssey. (It is one of my dad’s favourite movies, so I’ve seen it like a billion times. Its imagery is etched into my subconscious.)

Of course, most stations in Starsector now look like this:

Where have we seen these before?

Correct! That’s from … oh jeez, one or a few of the Star Trek movies with the original cast. (Another bunch of my dad’s favourite movies. Is a pattern emerging?)

It’s still fundamentally a round thing that rotates, but the advantage in portraying round, rotating stations side-on is you can get a lot more interesting variability out of the design. Side-on is fantastic for the campaign map! But as soon as you want a player’s ship to interact with the thing in battle mode, a lot of problems come up. First, if viewed side-on the question of the third dimension is raised because presumably the station is round, so would not the outer rim be “higher” on the battlemap in its center and lower on its edges? And very low on the central spindle? So where’s that fit into the “plane of battle” for weapon/movement collision? And if the station is rotating on an axis parallel to the viewing plane, how is a fixed sprite going to portray that rotation? And how are weapons mounted along the sides of the station going to rotate into and out of view, and what about perspective as this occurs?

Given that Starsector is a 2D top-down space shooter with very clearly defined means for portraying weapon slots and firing arcs, to say nothing of all the other mechanics, a side-view rotating station is never going to happen.

Cool, that’s settled. Let’s take on the question of scale: how big can we make it? A while back I made Alex a set of crude mockup assets to consider what it’d take to put a station into the game. The layered PSD looked a bit like this:

The idea was that there would be (*counts, gives up*) a whole bunch of separate rings rotating at different speeds, each with little gunnery modules. The dark gray portions would be areas the player could fly over, the light gray would be on the “plane of battle”. The whole thing could be this spinning arcadey vortex of bullet-spam where you try to fly to the middle and take out the reactor or something like the Millenium Falcon in Return of the Jedi.

This didn’t fly for a few reasons; Starsector doesn’t quite play like that, and I made this thing a little over-huge. Here’s a crop of the image at real size with a Hammerhead for scale:

Drawing this would be a formidable task, but manageable with copied elements and repeated use of modules. Fitting this into texture memory however? This station mockup was built of 13 separate images; a few can fit into 256×256, but most are rather larger, and some exceed 1024×1024. Allocating 8k x 8k or thereabouts of texture memory for a single station is getting into serious business territory for Starsector. First, Starsector is not a game aimed to be played on top-end machines. If we raise system requirements unduly, it’s going to leave some paying customers behind and that makes somone sad*. Second, is this really where Alex should be spending his development time? Sure it looks like this would produce an epic battle, but it’s only an epic battle — not a complete game. Third, what if it sucked? It’d be stupid to draw this thing then find out it was a waste of time. So this never got anywhere near in-game playability or mechanics testing. It’s way too big for a test case.

(*Mod-makers, of course, have made no such implicit commitment and can do all sorts of crazy things that bring even the mightiest gaming machine to a shuddering crawl.)

So this design was pulled way back to become the smaller ISS Placeholder station you saw above. But once we had that, and the time was right to investigate post-v0.7 features, where would the ISS Placeholder fit into the game?

An abortive effort at creating a larger cousin of the ISS Placeholder.

We’ve already established a bunch of different station aesthetics with the campaign-level side-view stations. This begs the question of being able to fight all of those stations in battle, each with their varied aesthetics and sizes. Would it be plausible to roll out an entire set of (very large) sprites and modules to roughly fit all of those at the same time as a completely new set of station battle mechanics? Maybe-sorta. But it’d definitely be a bad idea to deploy that much new content based on a new feature all at once. It’d be expensive to create that many assets, to implement them, to balance them with the rest of the game – and even then they’d be a system sort of sticking out on its own without much interconnectivity: so you blow up Jangala station, what happens next? This begs so many questions from the high-level gameplay that can’t be answered yet.

A sheet laying out some ideas for textures to use to build up station structure over a large area.

… And then what if we found out it didn’t work, or wasn’t at all fun? Or at least major elements needed rethinking? What if I had to redraw all the damn things after rolling out an enormous content update?

Conclusion: Feature scope must be constrained.

The way forward was to find some special case to test the concept of player combat with battlestations. Or two cases: the Derelict Mothership as the introduction, then the Remnant Battlestation as the “end game challenge”. These were chosen because they tied in with the new procedural system generation and exploration/survey/salvage themed skill features. Mutually reinforcing feature development is the way to do it and allows these battlestations to really tie some mechanics together.

So, first up: Derelict Mothership.

It’s technically a very large, immobile but slowly rotating ship with parts you can blow up. Therefore: a good place to figure out a process of creating and implementing the battlestation feature without getting completely lost in the potential scale of the thing.

Now let’s talk art!

I love drawing derelict spaceships. I’ve wanted to do more with them in Starsector since the start. So of course I had this thing sitting in my ship sprite work folder since forever ago:

 

It looks a bit like … a phallic object. And this is the second or third iteration wherein I had the good sense to pull it back a bit. In terms of technique, you can see a lot of use of down-scaled digital painting to create forms with texture brushes applied to create detail and weathering. Geometric shapes are masked off and shaded with lighter or darker airbrush to create depth. Pixel-level details are added to tie everything together and call back to the aesthetic of Starsector ship sprites. There’s also plenty of evidence of copy-and-pasted-and-modified elements, and mirroring with editing to make forms and details asymmetric. A bunch of parts of the above where taken from existing ships, or other unfinished ships in eternal limbo.

(With respect for Hegemony COMSEC, I cannot, of course, discuss the particulars of the content of my unfinished ship folder.)

More iteration:

Doubled it up so it looks less like a flying space-phallus, lots of colour shifting toward something a bit more unified and in-line with the faction’s scheme. More texture all over, more of all the same methods applied. Looks a bit small though, about on-par with an Onslaught. This won’t do.

Upscaled! Great, we’re fitting right into a 512×512 texture now, which is about where I want to keep it. (I will now accept the criticism that this ended up making the Derelict Mothership a bit boxy.)

The cool thing about adding modules as attachments to ships is that they can reach past the 512×512 texture edges and make the ship look larger than its base. This is why the Derelict Mothership features a big long spar on the front when you see it in v0.8+. But back to iterating the art  because that upscaled blurriness really needs cleanup:

 

This isn’t even the final sprite, but there’s more interesting technique here. I’m setting off the primary blue-green colour with an orange-yellow rusty look in the rough details. The form of the ship is roughly mirrored, but the paint job does a lot of work to make that less obvious. Here it is in-game with all the bits attached:

Drawing unique modules for each ‘active’ piece of the Derelict Mothership didn’t exactly take advantage of the principle of repeatable elements, but it sure looks nice.

The ISS Placeholder proved that battlestation mechanics could work at all. The Derelict Mothership showed that our development pipeline could produce content that fit with the new feature-set of Starsector v0.8. Now how far could we take this to provide an end-game challenge for players drunk on victory after victory, stomping on fleets of capital ships? How could we give the AI revenge for what it has had to endure?

Let’s find that out in part 2.

(… Where we’ll also find out just how many times I restarted the design for the Remnant Battlestation before finding something I liked, and only later realizing that it was in fact a giant Tri-Tachyon logo bristling with guns and artificial malevolence.)

---

Comment thread here.

Tags: graphics, important Hegemony COMSEC directives, photoshop, pixel art, station, [redacted]