Starcom: Unknown Space
Weekly Update: Jan 10, 2025
Last week I started a full playthrough of the game to test the new updates/content that I've been teasing for the past month. This was my first complete playthrough since launch. Even using some in-editor dev cheats, this takes quite a while because I'm also noting issues, fixing minor bugs, replaying sections, etc. My save game says it was 11 hours, but actually it was probably closer to 3-4 fulltime working days.
There were a few significant issues, which I addressed. On Wednesday, I uploaded this version (Kepler 21502) to the opt-in beta branch so players can now try it out. It fixes a couple of minor bugs, adds a few QoL features as well as adding some new content, including 25 new anomalies and several new side-quests.
You can find a spoiler-free list of changes and how to switch to the beta here:
https://steamcommunity.com/app/1750770/discussions/0/4516632734722382722/
Should you switch to this beta now? Well, on the one hand the existing default build is very well tested at this point. On the other hand, the new beta adds additional content and side quests, including new hints and guidance to a few areas where players have found themselves getting "stuck". So if you want the most content and discover even more of the unknown (which might also include unknown bugs), you should switch.
The beta is intended to be compatible with existing saves, although see the notes in the above post for details.
Until next week!
- Kevin
Weekly Update: Jan 3, 2025
Over the past couple months I've made a lot of incremental fixes, changes and content additions to my local development version. Every small change has a chance of introducing a bug. So on News Year's Day I started a full playthrough, something I haven't done since launch, with two goals: 1) seeing whether anything has broken and 2) seeing if the collective changes are ready for player testing.
A full playthrough takes quite a while, so I'm only about half way through. I've discovered one new bug that has been in the game for over a year, but was only revealed through a recent change.
Currently, there is a bug where if you load a save, any damage to your ship would instantly repair. So I've fixed that exploit. But in this playthrough I noticed that sometimes I'd reload a save and have damage when there shouldn't have been any.
After investigating, I figured out the cause:
What was going on was that a while ago I added an optimization that cached your most recent save after reading it from disk, so when the player did a quick load or died the save manager could quickly pass that to the game without spending 200ms or so reading it.
The problem is that the various game systems assume that when a game is loaded, they can take any values passed to them and assign them to their respective variables.
For example, if the save file says the player has 2000 RP, then the game sets the player's RP to 2000 RP. This is not a problem and will not cause a bug because RP is an integer and integers are value types. The game can change the amount of RP that a player has, but there's nothing that will change the value of the number 2000.
But some of the data is more complex. Things like the structure of ships are represented as a bunch of ModuleData's. A ModuleData is a collection of value types (HP, rotation, module type, etc) represented as an "object". An object is a reference type, which means that when you pass it around, you aren't passing around copies of various values, you're passing around an address in memory where those values are stored.
So when I loaded the cached save, the save system handed the ship a list of modules which it used to reconstruct my current ship. But when I flew into battle and the enemy started blasting at me, my modules were still referencing the objects in the cached save for their data. Which meant that the enemies were actually damaging the modules my save game.
Now I had designed the save system very much knowing about the possibility of accidentally referencing save data, which is why the save system uses "cloning" to create copies of the game data. But it only does this on the "save" side. I suspect when I implemented the cache I had forgotten this and thought it also happened on the "load" side.
Anyway, I'll be continuing the playthrough for the next day or two. Depending on how that goes I may either spend more time tweaking, or make it available as an opt-in test build. So stay tuned!
Until next week,
- Kevin
Weekly Update: Dec 27, 2024
This week I spent some more time on the side-quests I previously discussed, created several new related anomalies and tackled some bug fixes.
I've previously talked about how I create most anomaly images using an environmental rendering software product called Vue. Earlier this month I got a reminder from the software that my license was about to expire. When I went to renew, I discovered that the company who made the software had been acquired, and development for the product would cease.
On the plus side, they're now giving it away for free. So good on them for that. It still works for my purposes, so I plan on continuing to use it. It's not as general purpose or feature rich as something like Blender (also free), but it is much easier to quickly create cool environment images.
Some anomaly images created with Vue plus some 3rd party models.
Happy holidays and hope everyone has a wonderful New Year!
- Kevin
Weekly Update: Dec 20, 2024
I'm continuing to work on some additional side-content for an upcoming update and don't want to put any spoilers in a news announcement. I don't have an ETA yet for when it will be ready for testing.
One of the non-spoilery tasks I accomplished relates to how regions are added to the universe. As you may or may not know, many of the game's regions are added at fixed locations throughout the galaxy so the major areas have roughly a constant layout. But some content is added dynamically, either in response to player actions, exploration, or content updates.
With this new content, since it is intended to be compatible with existing saves, I'm experimenting with a change to the region addition logic. To avoid trampling existing content, the procedural system will still look for empty sectors, but will be allowed to place regions in "empty but explored" sectors.
As a cue to players, if an update does add a region in a visited space, the fog of exploration will be "re-fogged" for the affected area. I struggled with this when the addition of this new "refog" feature broke fog of exploration entirely. Here's the refog function:
What wasn't obvious, because I was too focused on the code changes (highlighted in green), was that I'd actually deleted the SetPixel line from the previous function. That wasn't highlighted because the diff tool simply thought I'd moved it down. While I don't think I've made this mistake before, most developers are probably familiar with tunnel vision: You are so convinced the problem lies in a certain area, you fail to notice when it's something obvious just outside where you're looking.
Until next week, Happy holidays!
- Kevin
Weekly Update: Dec 13, 2024
Instead I'm going to post some of my rough notes on mission design. I had the idea of making a video on this, but recording and editing videos take a lot of time, so I decided to post the notes lightly edited together. Note that these have some very mild spoilers for current game.
What makes a good quest/mission?
Here are the major elements that I think make a good mission, both from a player perspective and from a practical development perspective (an otherwise good mission idea might not be worth pursuing if it will take three times as long to develop and test, or has a high likelihood of introducing game breaking bugs).
Unique
The core of the game is exploration, discovery and unexpected events. Players are very astute at recognizing patterns and so every mission needs to be unique and structured in a way that doesn't feel like the game is creating a conspicuous loop of ticking off the same three check boxes.
This means not only changing up the goals, but also how missions are revealed/discovered, how the player is guided to objectives, what actions are needed to resolve them, etc.
An unfortunate side effect of this is that every mission can potentially introduce a new problem: either narrative inconsistency or flow bug, but also ways that players might find themselves "stuck".
Connected
While having interconnected missions can lead to "brittleness" both due to changes in one mission potentially affecting another, as well as possible sequencing problems (see Robust below), having missions connect to other missions in subtle ways helps the universe feel more alive.
Efficient
In terms of efficiency, I mean that generally I want a mission to be accomplishing multiple design objectives while the player is completing it. Examples of design goals are:
- Introduce a game feature
- Teach the player a game mechanic
- Remind the player of a previously introduced mechanic
- Put the player in a position to notice a region or object
- Foreshadow some future content
- Present a choice
- Progress a narrative
- Develop a character
- Promise a reward
- Create a connection with a previous piece of content
- Fix an issue with existing content
Robust
In an open-world game, the player can theoretically reach any location at any point at any time. This presents a challenge from a mission design standpoint. If the "happy path" for a mission is player visits region A, gets a clue that leads to region B, which activates an artifact in region C, we must consider what happens if the player goes B->C->A or A-C->B or C->B->A, etc. The mission logic must account for these scenarios in a way that cannot break the game, and ideally doesn't break immersion in a conspicuous way.
This is harder to achieve than you might think.
Ideally, you'd like it if all textual elements, such as dialogues, crew banter, logs, etc. are consistent with the way events actually unfold. Sometimes this simply isn't feasible. There are several major story elements that the player is expected to have encountered early on, such as the Devout. It would be impractical to have every piece of content that references the Devout changes its wording depending on whether player knows who they are at that point.
Even in very polished AAA RPG games you will occasionally notice points where the designers have allowed some inconsistency to slip through because of the graph complexity of handling all potential "narrative states", such as a PC bark noticing for the first time something you've just spent the last hour exploring.
But the most important thing though is you don't want the ordering of the player's actions to put the game in an unanticipated and possibly broken state.
In many games, this can be solved with physical blockers that prevent the player from accessing certain areas until the mission is in a known, well-defined state: locked doors, rock slides, or "city guard" cut scenes. Since Starcom: Unknown Space takes place in space, these options aren't available. Still, many interactions take place in the context of an anomaly or dialogue, some constraints can be put there.
But this doesn't work in all cases. For regions with more involved interactions, I use a different trick: Space is really big. So sometimes the player will learn of a new region which coincidentally turns out to be in one of those parts of really big space they haven't explored yet. This allows me to enforce some assumptions before certain areas are visited.
How I design missions
When designing a mission, it is very natural to imagine it unfolding like a story. While a good mission should feel story-like, I think it is a mistake to approach mission design from the perspective of starting with a story and trying to turn it into a mission. Most stories wouldn't make good missions: they have a well defined narrative structure that demands things unfold in a certain order and put too many constraints on the player's actions.
It is much easier, in my opinion, to begin a list of things I want the mission to accomplish from the above, construct a fairly robust path that goes through those things, then write a story around that path.
For example, one post-launch mini mission had the following goals:
- Added some narrative foreshadowing for the Devout's increased interest in the player
- Encouraged the player to search their ship logs to find a previously visited location
- Give the player some way of finding ships of different factions more easily
These elements suggested the rough outline of a story to me: the player finds a derelict that hints at some Devout nefariousness. Later, someone suggests returning to that location (prompting a search of the logs). Once there, a new location is revealed where the player finds more information on the Devout and a tech that improves ship detection.
That's all my notes for now, maybe at some point I'll flesh them out further and make a video.
Thanks for reading, until next week!
- Kevin
Weekly Update: Dec 5, 2024
I've continued work on a new side-quest storyline. Without too many spoilers, the storyline has a number of design goals, including guiding players a bit more in parts of the existing story where players are getting stuck, as well as providing additional resolution to one of the game's narratives.
It's still a work in progress and there's a fair amount of work left, so I'm being deliberately vague to avoid overpromising.
I'm creating the story using the new Experimental "Starcom Creator" tool. As mentioned previously, if you're interested in playing with it and giving feedback, shoot me an email at kevin@wx3.com and include "Starcom Creator" in the subject (see the Creator sub-forum for details and updates on that).
Until next week!
- Kevin
Weekly Update: Nov 29, 2024
Last week I started sending interested testers keys for the new experimental "Starcom Creator" tool. Again, if you're interested in playing with it and giving feedback, shoot me an email at kevin@wx3.com and include "Starcom Creator" in the subject.
After a few days I hadn't heard anything from testers so I assumed that may be there was less interest than I thought. But it turns out that while I had created a sub-forum for the tool, and directed users to that forum, apparently I had forgotten to click "subscribe" to the new forum so I wasn't getting notifications. Sorry about that!
Here's what I've worked on this past week:
- Started work on a new side-quest storyline.
- Fixed several bugs in the Creator tool.
- Rendered a couple dozen "generic" anomaly images, which I plan to add to the tool in the next update.
Until next week!
- Kevin
Weekly Update: Nov 22, 2024
And I also uploaded the first version of the tool to Steam. I've sent some invites to players to check it out: if you're interested in playing with it and giving feedback, shoot me an email at kevin@wx3.com and include "Starcom Creator" in the subject.
I've also created some documentation, currently available as a Google Doc.
The documentation is still very much a work in progress but I'll be curious to see if/how players use the tool.
I've also started brainstorming a new storyline that I envision as another side quest to the main story, but still in the very early stages.
Until next week!
Kevin
Weekly Update: Nov 15, 2024
At this point the tool is mostly working with a few janky areas. I'm still testing and fixing features, as well as working on creating documentation.
Besides work on the Creator Tool, I've also started work on fixing some minor game issues.
Until next week!
Kevin
Weekly Update: Nov 8, 2024
It's not quite ready yet for beta testing, but in anticipation of that point, I've started recording a series of videos introducing how it works in the context of a demonstration storyline. I've uploaded the first part today:
(Every time I record a video I gain increased appreciation for Youtubers. It's harder than it looks to record and edit a coherent video in a reasonable amount of time.)
Until next week,
Kevin