Fighter Redesign

Let’s begin by taking a look at how fighters started out, to see how they got to the point of needing a redesign.

The first playable release of the game only had combat missions, and the way fighters worked was heavily influenced by that. My understanding of how the campaign would work was at that point quite fuzzy, and so once the campaign did come about, fighters had to be adjusted to fit in. This led to some awkward mechanical interactions and obscure rules.

fighters_mora

For example, if you have any ships with flight decks in your fleet, then you can’t lose fighters permanently. However, you can still have fighters in your fleet if you don’t have any carriers, they just don’t get any replacements in combat, and if you lose all of them, you permanently lose the wing. And if you do have carriers deployed, and lose all the fighters in a wing in combat, they may get replacements or be lost for the duration of the battle, depending on whether any flight decks were available at the exact moment the last fighter was destroyed.

Very much a “good enough for now” state of affairs, and something that’s been gnawing at me for a while. It’s too much of a mess to continue ignoring indefinitely, but why clean it up now, seemingly when there’s exploration, salvage, and everything related to work on?

The answer is, of course, that fighters tie into those things. Can you recover fighters through salvage? Can automated defenders use fighters? What about the eventual/upcoming skill revamp? That certainly needs to include fighters. Despite being a relatively small part of combat, fighters are still a part of that foundation, and it’ll help moving forward to finally have it be solid.
Read the rest of this entry »

Phase Cloaking – a Deep Dive

As usual, after a major release there’s some time to polish up some things that there just hasn’t been time for up to that point. In fact, a lot of the upcoming 0.7.2a is turning out to be about “paying off” technical and design debt – things that are “good enough for now”, but do have to be addressed at some point.

doom_vs_enforcer

One such is phase cloaking. There’s a post from a while back on how the current mechanics came to be if you’re interested in the details, but let’s summarize:

Way, way back, the original idea for phase ships was something submarine-like, being able to hide on the battlefield and deliver surprise attacks. That sounds like fun but didn’t turn out to be practical, so phase cloaking changed to become a way to avoid damage instead – shift to another dimension, let enemy fire pass through/over your ship, uncloak, and fire back. That essential concept remains unchanged in this new iteration; the changes are looking to address some specific issues with the implementation.

What, then, are the issues? Read the rest of this entry »

Expanded Battles

First, a brief summary of what this post is about – a new campaign feature that allows nearby fleets – naturally, including yours – to join ongoing battles.

If you’ve been following the development of this release, you’re probably aware that things are in the “polish things and make it fun to play” phase more so than in the “add more features” phase. Why, then, add a significant new feature at this stage? The answer is that it’s a direct response to playtesting, rather than a specifically planned-for feature on the roadmap – it’s meant to help address several important gameplay issues, some quite long-standing. Now was a good opportunity to do it, and here we are. Looking back, I’m glad I ended up taking this on now rather than later – with how many different pieces of the code this change touches, it would only get more difficult with time.

battle_join

Let’s take a brief look at what the design goals are, and then we’ll dive into the specifics of how it works. Read the rest of this entry »

Sensors

For a while now, the core campaign gameplay has been pretty … let’s say straightforward. You click somewhere, your fleet goes there, you may chase or be chased along the way, and that’s pretty much all there is to it. It does the job as the “thing you do between the fun stuff” – battles, interacting with markets, and so on – but it doesn’t stand up as anything you’d want to do for its own sake. To be fair, not a lot of time has been dedicated to making it into that – until now.

It’s going to take multiple mechanics working together to bring campaign-level gameplay up to par with combat, and I’d like to talk about the first one of these that we’ve been working on: sensors, that is to say, a set of rules that determine when one fleet is able to see another.

It’s important to note that how sensors work will both influence and depend on other related mechanics (to be added in the near future), and so the current incarnation of sensors – the one I’m going to discuss now – is very likely to change. In general, the more specific a detail, the less likely it is to remain exactly as-is.

That aside, why sensors? Why can’t all fleets always see each other, the way they do now? There’s a realism argument for it, as spotting fleets across light-years doesn’t make a lot of intuitive sense, but I’m not a fan of the “realism” argument in general. It takes days to travel light-years of distance, so who’s to say where sensor tech is relative to that? Internal consistency of the rules and good gameplay are more important; given those, an in-fiction explanation for how things work shouldn’t be too difficult, if it even proves necessary.

What else, then?

First of all, suspense and a sense of discovery. If you see everything, there aren’t going to be any surprises. Say you’re traveling from Corvus to Asharu, and you’ve opened up the map to see the route – and you see that it’s clear of any enemies. From that point on, you know for a certainty that there’s no risk to the trip, and it stops being engaging and becomes a wait until it’s over.

If you don’t have perfect vision, on the other hand, space gets big and mysterious again. You start the trip – and see a sensor blip.

sensor_contact

Read the rest of this entry »

Crew Management and You

The title of this post is deliberately misleading. It’s mostly about crew management and me, you see. Specifically, about how the current system came about – and what it is. But now that I’ve tricked you into reading, I hope you’ll stay with it – you won’t get those couple of seconds back anyway, so might as well keep going!

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.
Read the rest of this entry »

Forum Blog Media FAQ Features Digg it! Del.icio.us! Share this on Facebook Reddit Stumbleupon it! Technorati Tweet it! Download Starsector for Linux Download Starsector for Mac Download Starsector for Windows