Posted January 16, 2016 by dgbaumgart in Art, Development
Or, if you like, “A Charged Subject”.
Or “David gets Alex to basically write half the blog post by quoting his emails”.
Right, so let’s take a peek into the process of back and forth commentary and iteration Alex and I go through when adding a new weapon to Starsector. I think this may give some insight into how this game gets made and how working on one small piece of it rolls odds and ends off into other areas of development.
Our story begins with a simple request for a new weapon asset.
Update (12/05/15, 2:10pm EST): another hotfix up! A few more assorted issues. Update (12/04/15, 10:40pm EST): another hotfix is up; more fixes related to procurement missions. Update: a hotfix for the mission destination issue is now up. Please re-download using the links below.
Starsector version 0.7.1a is now out! This is mostly a bugfixing and polish release, but there are some new features making their way in as well.
Faction commissions – align with a faction to fight their enemies and gain access to their technology
Faction hostilities – take advantage of opportunities presented by temporary hostilities between major factions
A much easier easy difficulty
Higher sensor ranges during the early game
Lots of bugfixes and a few balance adjustments
The full patch notes are here. You can download the new version here:
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.
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 »
In an earlier post, I’d talked about terrain. An astute observer might have noticed that the terrain discussed there is all more or less normal stuff – nebluas, asteroids, etc. Nothing that’s a good fit for hyperspace, which has more of a “weird” feel.
The first question is, what’s the goal of adding terrain to hyperspace? Obviously not having any terrain there would be a bit boring; spicing things up with some variety is not a bad goal, but something more specific would help guide the design better. So: “make hyperspace travel something that can be done well or poorly by the player”. This fits with the overarching goal of terrain making travel more interesting. Unlike normal terrain – which generally makes things interesting by impacting your interactions with other fleets, i.e. hiding from someone inside a nebula – the goal for hyperspace terrain is to be interesting by itself. This fits nicely with the primary role of hyperspace as a travel medium. Read the rest of this entry »
