Starcom: Unknown Space cover
Starcom: Unknown Space screenshot
Genre: -

Starcom: Unknown Space

Weekly Update: April 12, 2024

A quick update this week: my wife and I went on a survey mission to investigate a nearby celestial anomaly.

When we got back I started a full playthrough to see how the recent changes felt and get a sense of how much more I want to add to Kepler before releasing it as an opt-in beta.

I'm still in the middle of the playthrough, but I'll have a better idea next week.

Other than that, things done in the past week:


  • New anomaly
  • Added indicator in mission log for critical missions
  • Various balance changes, fixes


Until next week!
- Kevin

Weekly Update: April 5, 2024

Looking at my task tracker recently I realized it's been ten years since I started work on what would eventually become Starcom: Nexus, the precursor of Starcom: Unknown Space. Actually ten years ago to the day, I followed Unity's "space game tutorial" to figure out how to get a 2D spaceship moving on screen.

I've already written a very long postmortem on the process of creating that game, but I thought this would be a good occasion to look at the question "where does the time go?" Like specifically, having spent well over ten thousand hours developing these games, what am I doing all day?

Using data exported from the task tracker, I went through and randomly sampled blocks of time and categorized them to see what kinds of things I was spending time on, and how much.

I organized the data in two ways: features that players would recognize, and hats that I wear. By "hats" I mean what role/skillset would do this task in a mid-sized game company with dozens of employees. I'm guessing a bit on this one-- while I have worked on game projects with small to medium sized companies, it has always been in a fairly narrow role.

Features



[table]
[tr]
[th]All[/th]
[th]Percent[/th]
[th][/th]
[/tr]
[tr]
[td]Gameplay[/td]
[td]11.7%[/td]
[td]General gameplay mechanics and core game logic not included elsewhere[/td]
[/tr]
[tr]
[td]Combat[/td]
[td]6.4%[/td]
[td]Weapon design, balancing, damage handling, VFX[/td]
[/tr]
[tr]
[td]Community[/td]
[td]6.1%[/td]
[td]Interacting with players, support, weekly updates like this one, etc[/td]
[/tr]
[tr]
[td]Gameworld[/td]
[td]5.5%[/td]
[td]Game world specific mechanics: region placement, sector handoff[/td]
[/tr]
[tr]
[td]Shipbuilding[/td]
[td]5.5%[/td]
[td]Shipbuilding logic[/td]
[/tr]
[tr]
[td]Missions[/td]
[td]5.4%[/td]
[td]Mission design and creation[/td]
[/tr]
[tr]
[td]Playtesting[/td]
[td]5.1%[/td]
[td]Playing the game myself to see what's broken, what feels wrong, etc[/td]
[/tr]
[tr]
[td]Anomaly[/td]
[td]4.8%[/td]
[td]Creating anomalies[/td]
[/tr]
[tr]
[td]UI[/td]
[td]4.2%[/td]
[td]UI design and programming[/td]
[/tr]
[tr]
[td]AI[/td]
[td]3.9%[/td]
[td]AI design and programming[/td]
[/tr]
[tr]
[td]Marketing[/td]
[td]3.8%[/td]
[td]Game promotion, trailer creation, youtuber outreach, etc[/td]
[/tr]
[tr]
[td]Factions[/td]
[td]3.7%[/td]
[td]NPC design[/td]
[/tr]
[tr]
[td]Music & Audio[/td]
[td]2.7%[/td]
[td]Music and Sound FX[/td]
[/tr]
[tr]
[td]Planning & Production[/td]
[td]2.6%[/td]
[td]Deciding what to prioritize, misc stuff not covered elsewhere[/td]
[/tr]
[tr]
[td]Bug fixes[/td]
[td]2.5%[/td]
[td]Investigating and fixing bugs outside of the normal dev loop[/td]
[/tr]
[tr]
[td]Interaction Systems[/td]
[td]2.4%[/td]
[td]Anomalies, conversations and general station interactions[/td]
[/tr]
[tr]
[td]Trade & Inventory[/td]
[td]2.3%[/td]
[td]Trade system, drops, resources and item system[/td]
[/tr]
[tr]
[td]Map & Edgedar[/td]
[td]2.2%[/td]
[td]Map system and Edgedar (the icons around the side of the screen in the main view)[/td]
[/tr]
[tr]
[td]Localization[/td]
[td]2.1%[/td]
[td]String symbol tables and translation[/td]
[/tr]
[tr]
[td]Creator[/td]
[td]2.1%[/td]
[td]Content authoring tool[/td]
[/tr]
[tr]
[td]Save & Load[/td]
[td]1.8%[/td]
[td]Save system[/td]
[/tr]
[tr]
[td]Crew[/td]
[td]1.7%[/td]
[td]Crew management, skill check system[/td]
[/tr]
[tr]
[td]Technologies[/td]
[td]1.7%[/td]
[td]Tech research tree and effects[/td]
[/tr]
[tr]
[td]Planets[/td]
[td]1.6%[/td]
[td]Planet visuals[/td]
[/tr]
[tr]
[td]Main Menu[/td]
[td]1.5%[/td]
[td]Parts of the game when you're not in the game[/td]
[/tr]
[tr]
[td]Proc Gen[/td]
[td]1.2%[/td]
[td]Procedural sector and planet generation[/td]
[/tr]
[tr]
[td]VFX[/td]
[td]1.2%[/td]
[td]General visual effects like nebulae, non-combat particle effects, etc[/td]
[/tr]
[tr]
[td]Steam[/td]
[td]1.0%[/td]
[td]Build deployment, store page creation, etc[/td]
[/tr]
[tr]
[td]Business[/td]
[td]0.9%[/td]
[td]Taxes, paying contractors-- the fun stuff that everyone gets into game dev for[/td]
[/tr]
[tr]
[td]Story[/td]
[td]0.8%[/td]
[td]Narrative planning[/td]
[/tr]
[tr]
[td]Regions[/td]
[td]0.7%[/td]
[td]Manual (non-procedural) region layout[/td]
[/tr]
[tr]
[td]Optimization[/td]
[td]0.4%[/td]
[td]Performance profiling, optimization[/td]
[/tr]
[tr]
[td]Analytics[/td]
[td]0.2%[/td]
[td]Player analytics review[/td]
[/tr]
[/table]

Hats



[table]
[tr]
[th]Hat[/th]
[th]Percent[/th]
[th][/th]
[/tr]
[tr]
[td]Programmer[/td]
[td]32.9%[/td]
[td]Any coding/programming[/td]
[/tr]
[tr]
[td]Game Designer[/td]
[td]16.8%[/td]
[td]Designing missions, balancing enemies, gameplay tweaking[/td]
[/tr]
[tr]
[td]UI Designer[/td]
[td]8.4%[/td]
[td]Creation of all the UI systems, icons, layouts, excluding the programming[/td]
[/tr]
[tr]
[td]VFX Designer[/td]
[td]7.3%[/td]
[td]Particle systems, shaders[/td]
[/tr]
[tr]
[td]QA[/td]
[td]7.1%[/td]
[td]Playtesting, reviewing player F8 feedback[/td]
[/tr]
[tr]
[td]Producer[/td]
[td]6.5%[/td]
[td]Planning, interaction with contractors[/td]
[/tr]
[tr]
[td]Community Manager[/td]
[td]5.8%[/td]
[td]Responding to player emails & discussion forum posts[/td]
[/tr]
[tr]
[td]2D Artist[/td]
[td]3.6%[/td]
[td]Anomaly images, item images[/td]
[/tr]
[tr]
[td]Marketer/Video Editor[/td]
[td]3.1%[/td]
[td]Trailer creation, influencer outreach[/td]
[/tr]
[tr]
[td]Writer[/td]
[td]2.7%[/td]
[td]Writing anomalies, dialogue[/td]
[/tr]
[tr]
[td]3D Modeler[/td]
[td]2.0%[/td]
[td]Creating ship modules, other models, coordinating concept artist and modeler efforts[/td]
[/tr]
[tr]
[td]Sound Designer/Music Director[/td]
[td]1.5%[/td]
[td]Creating game sounds, directions for composer[/td]
[/tr]
[tr]
[td]Analytics[/td]
[td]1.1%[/td]
[td]Choosing metrics, analyzing anonymous player analytics[/td]
[/tr]
[tr]
[td]Business[/td]
[td]1.0%[/td]
[td]Misc business stuff: taxes, paying contractors, renewing LLC, etc.[/td]
[/tr]
[/table]

This is just the time I spent. There have been several talented contractors who have composed the game's music, created the alien portraits, created 3D models for the modules, etc. It's also not super precise, because a) there are a lot of tasks that don't get tracked and b) this was a random sample. But I think it's ballpark correct.

In other news, I'm continuing to press on with work on Kepler. There's still a chunk of content I want to add, but in the next week or two I'll start thinking about timing for making available for opt-in.

Until next week!
- Kevin

Weekly Update: March 29, 2024

Last week I posted a survey on the game content, specifically the amount of content currently in the game and the kinds of content players would like to see more of.

I've received about 200 responses so far and overall most players said there's either enough or close to enough content currently. Still, almost 1 in 5 players said there was "way too little". Based on comments, I'm inferring most of these responses are mainly due to two reasons:

  • Players love the game and want there to be as much content as possible
  • There are particular kinds of content that players feel the game needs more of to feel complete (e.g., combat, void exploration, resolution to particular narratives, etc)

If you haven't yet, please take a moment to fill out the survey. And feel free to give details to your thoughts in the free response question.

Google Forms Survey Link

Also, as usual, here's an update of what I worked on this past week:

  • Finished work on the weapon I mentioned last week
  • Started work on a longer side quest

Until next week!
- Kevin

Weekly Update: March 22, 2024 (Player Survey)

I've spent most of the past week working on some new content & features that I don't want to discuss for spoiler reasons, so I thought this would be a good time to conduct a player survey.

Specifically, I want to ask players how they're feeling about the current amount of content in game, and the types of content they'd like to see more of.

If you have finished playing either Icarus (the current default build) or Jupiter (the latest opt-in beta), please take a minute to answer this quick survey.

Google Forms Survey Link

Also, as usual, here's an update of what I worked on this past week:

  • Finished work on the hidden side quest I mentioned last week
  • Started refactoring a combat feature in anticipation of making it a player accessible weapon
  • Continued work with Moritz on new tracks

Until next week!
- Kevin

Weekly Update: February 16, 2024

I spent almost five straight days in this past week working on one "small" feature:

Multi-module selection. I.e., the ability to remove more than one module from the ship and move them.

Why was this feature so hard?

One reason is that the shipbuilder logic is pretty complicated and module selection was designed around manipulating a single module. Anyone who has worked in software has probably noticed that early design decisions have a tendency to get baked-in, as later modifications treat those decisions as reliable assumptions.

Here are just some of the things that need to happen around the process of selecting, removing and placing module(s):

  • Remove the module from the ship's data structure
  • Remove the module gameobject from the ship's transform
  • Instantiate a temporary gameobject to represent the "carried" module
  • Calculate the target position of the module in hex coordinates
  • Transform, rotate, and mirror hexagonal coordinates and their edges
  • Smoothly lerp the model's position and rotation
  • Calculate ship stat changes
  • Check for module overlaps
  • Enforce placement and rotation rules
  • Calculate every hex edge connection
  • Find "orphaned" modules and recycle them
  • Record undo/redo steps
  • Apply color swatches
  • Play "weld" and "recycle" animations
  • Deduct or refund resource differences
  • Determine what grid cells in the shipbuilder are visible
  • Placement hinting in the grid to indicate overlaps, connections, etc

Another reason is that I've found it quite challenging to plan the necessary coordinate transformations. E.g., if you move, then rotate, then mirror a selection with a sub-module, what happens to that sub-module's offset, hex coordinates, rotation and mirror? Moving modules is pretty simple. Rotating was a bit of a challenge, but doable. I'll tell you how hard group mirroring is if I ever figure it out.

The feature I believe is working, sans group mirroring, and so I've deployed it as a patch to the Jupiter Unstable branch.

Now, if you remove any module that creates "orphaned" modules, rather than those modules being immediately recycled, they are added to the selection. You can move and rotate the selection as a group.

There's also a multi-select mode. If you hold "shift" you can select specific modules to manipulate by clicking on them sequentially. When you release shift they will become a selection group. This way you can manipulate multiple modules, even if they would still be connected to the ship without the first module.

Feedback from Jupiter continues to be positive: no major issues compared to Icarus. Named builds are not save compatible, but if you're starting a new game, you may want to switch to the Jupiter opt-in for the added content, bug fixes and new features.

Until next week!
- Kevin

Weekly Update: February 9, 2024

Last week I announced that the Jupiter opt-in beta was ready, but that it might be a bit rougher than previous betas. At this point, the feedback from players is that it is actually pretty solid. There are still some issues, but nothing game-breaking. Anyone planning on starting a new game may consider jumping in with Jupiter, as it has more content.

I thought this week I'd talk about one of the bigger challenges I face in development: how hard it is to predict what players are likely to do. One of the main issues during the early phases of Early Access was players getting stuck with no obvious next course of action. Often players would propose adding some new kind of hint system, but what was really missing was my understanding of when hints were needed as opposed to how to supply hints. This is getting better, but for any new piece of content it's fairly safe to assume that I won't realize what will and won't be obvious.

Similarly, players really like when games acknowledge them doing something unexpected. Whether it's solving a problem in an unexpected way, or just doing something weird (even if it gets them killed). If the player thinks "I bet nobody does X", then does X, and the game reacts in some way, that's delightful.

One thing the game's analytics has told me is that I tend to overestimate how apparent some things are. I think the sweet spot for Easter Eggs is if 1-5% of players who get that far into the game encounter it, that's good. There can be 1 or 2 super rare Easter Eggs, but spending a lot of time on content less than 1% of players experience is inefficient. There is one Easter Egg that I added that I thought quite a few players would discover. But according to the anonymous analytics so far only 1 player has seen it. So with Jupiter, I relaxed the conditions needed to trigger it.

If you've ever tried something in the game hoping for something interesting to happen, but nothing did, definitely let me know. Depending on how hard it is to add the logic to detect that behavior, I may add a reaction.

Here's what I did in the past week:

  • Started work on asset requirements for Steam trading cards
  • Patched the Jupiter build with the following:

    • Numerous optimizations, variable caching
    • Mission goal indicators now display mission name
    • Crew quarters module
    • Ship gains a bonus to repair rate when no threats are near
    • Connectors now cost 1/2 hex and are treated nearly the same as empty space for thermal dissipation
    • Fix for being unable to trade with The Brogidar after treaty
    • Added several missing analytics markers
    • Shrink module point light radius to reduce flickering
    • Changed cruiser and dreadnought lighting color to match other bridge module
    • Fix for research details panel placement when zoom scale not 100%
    • Fix for the reinforced exhaust vent lighting issue
    • Fix for a null reference error


Until next week!
- Kevin

Weekly Update: February 2, 2024

As promised last week, the first Jupiter build has been uploaded to an unstable beta branch.

It's been quite a while since the last named update, partly due to spending more time doing post-launch Icarus patches, but mostly due to my goal of introducing an ending to the game's story. Late in the process I found myself caught in the trap of "the players have waited so long for this build, they won't be happy unless I do X". But this eventually becomes a self-perpetuating cycle as X inevitably takes longer than I originally thought, and I feel compelled to add Y and Z. I finally reached a point of deciding that it's better to get some feedback on the new stuff and defer some known items.

Consider this a warning that this build might be a rougher build than previous opt-ins. There aren't any known game breaking bugs, but some content isn't quite as done as I would like, there have been untested balance changes, and some of the late areas may have performance issues. Some players have already started playing since I posted about it on Tuesday, but as most of the changes are in the late game, no player has made it that far and I still don't have a sense as to whether there are any serious bugs.

So very brave commanders who want to venture forth into the Jupiter build, have at it. Once I get feedback from players who make it all the way through, I'll give some guidance in the weekly update on how rough it actually is. (Opt-in instructions here).

Non-spoiler list of changes:

  • Prologue transition
  • End game credit screen
  • New mid-game story, faction
  • Two new void mini-quests, encounters
  • New late game story, mission
  • New end game story, missions
  • Two late game "easter eggs"
  • Fix for missing void encounters
  • New weapon variants
  • Refactor fixed weapons, control schemes
  • Anomaly soundscapes
  • 18 new anomalies
  • Numerous new actor dialogues
  • New modules
  • New techs
  • New enemies, abilities
  • Damage type logic, refactor resistance
  • Refactored Station operations logic
  • New techs highlighted
  • Additional analytics
  • Hints/fixes for several stuck scenarios
  • Engine turbo sound fades out
  • Numerous balance changes
  • Numerous new VFX
  • Minor changes to dialogue behavior
  • Improved mission authoring tool
  • Improved testing tools
  • Changed autosave timing
  • Fix for vsync not being saved
  • Fix for secondary weapon not being saved
  • Several performance optimizations
  • Various QoL changes
  • Numerous bug fixes


Build 16006 patch:

  • Fix for new analytics telemetry potentially logging player name, which would make the analytics non-anonymous
  • Added canvas scaler for prologue text
  • Fix beams not targeting fighter drones after object re-pooling


Until next week!
- Kevin

Weekly Update: January 26, 2024

I've continued to make progress on the Jupiter build. I've whittled down most of the items I planned for it. There are a lot of things I wanted to do for Jupiter that I didn't get to. I was considering pushing it out a few more weeks, but instead I've decided to not expand the scope any further so I can start getting feedback from players. Once I've gotten the major outstanding issues addressed, I'll do a fast playthrough. Assuming nothing critical broke, I'll deploy it as an opt-in branch some time next week (fingers crossed).

Compared to previous builds, this one is larger and potentially a bit rougher. For example, on my first play through I found the end game enemies impossibly difficult. So I dialed them back and added some more player buffs, but it's likely they're either still very tough (or less likely, too easy). There are also situations with more active ships, so there may be performance issues as well. I touched a lot of systems during this build, so there's a possibility of bugs. Finally, there's a lot more "mission logic" in this one which means more potential bugs.

In terms of content "quantity", here's how it compares to Icarus:

Icarus:
179 anomalies
864 mission nodes
3339 mission logic elements
68,209 words

Jupiter:
197 possible anomalies
4329 mission logic elements
82,182 words

A moderate increase in number of anomalies, but a fairly substantial increase in mission logic and text.

I'll post in the discussion forums when Jupiter is up, then do a news announce after at least a few players have tried it and confidence is a bit higher that there aren't any game breakers in it.

Until then!
- Kevin

Weekly Update: January 19, 2024

Last weekend I finished my full playthrough of Jupiter and noted 195 things that I wanted to fix or add for the next opt-in build. Many were fairly minor things like wording or timing changes. A few I decided I was okay with deferring and added them to the large "eventual to do" pile.

Since then, I've chiseled that list down to about 60.

Here are some of the larger items I tackled:

Added Damage Types



Up until now damage has been just damage, although there is some hard-coded special-case balancing. For example Havok does a lot more damage to missiles and drones, due to being AoE. Without this balancing, Havok would either be absolutely lethal to slow moving ships, or would fail at its intended purpose, since missiles and drones move fast.

Now all damage has a type, so as necessary I can balance different factions and weapons to have different advantages vs. different defenses or targets, without needing messy special case coding.

Refactored Armor/Resistance Formula



Speaking of damage, I also took the opportunity to simplify the resistance formula. Bulkheads, armor, certain techs and factions can have various resistances which get passed to a formula to translate into a percentile damage reduction.

The prior resistance formula was the result of trial and error, but while working with the damage types I noticed that for most values encountered in game, it was very close to a conceptually simpler formula, so I went ahead and changed the base formula:

Each point of resistance equals a 1% change in the total number of attacks of constant damage it would take to do the same amount of damage to a target. 10 points of resistance means it would take 10% longer for an attacker to destroy a target, 100 points means it would take twice as long for an attacker to destroy a target, -100 points means it would take half as long, etc.

Mini-void Quest



I added another small random side-quest that the player may encounter while traveling in the void. I won't go into details to avoid (no pun intended) spoilers. This required one new anomaly and a new faction.

Havok to Secondary



The Havok flak system control has been converted to work like an untargeted secondary weapon, so to activate you just cycle to it and press [SPACE].

Plus numerous either minor or spoiler-y changes.

As always, changes mentioned in weekly updates will not be available to players until the next build deployment and are subject to change.

I'm still aiming to deploy a Jupiter build for opt-in by the end of the month. We'll see how that goes.

Until next week!

- Kevin

Weekly Update: January 12, 2024

I spent last weekend updating the automated test system/mission. I've discussed the mission system before: it handles not only player missions, but all "ad hoc" logic like tutorials, scripted events, random void events, etc. It is also how I run automated tests of key missions: basically a series of missions try to "speed run" the game with a lot of cheats by teleporting around and interacting with anomalies and characters. This is obviously not the same as how a player plays, but it does give some level of confidence that there's no bug making it impossible to reach the end. For example, if a dialogue that triggers the spawning of a key artifact has an unsatisfied condition or error, the test will get stuck on it.

However, the nature of the game means that sometimes unexpected things happen during the test. Not only due to random events, but just the chaotic nature of the universe means that small changes can ripple. So the precise sequence of events that even the automated test encounters is inherently unpredictable. This is not an inherently bad thing. But it does mean that sometimes an automated test fails for reasons not related to bugs: e.g., a new faction hailing the player when the test was expecting to interact with some planet or artifact.

As the game has gotten larger, Murphy's Law conspires with the Law of Large Numbers to increase the probability of automated tests failing. If there's a 0.1% chance a mission node will unexpectedly block a test run, that's not a big deal when a test run hits only 100 mission nodes-- I can just run the autotest again the 10% of the time it fails. But with a 1000 nodes, it will fail most of the time.

So I spent last weekend making the automated tests more robust, including spending a good chunk of Saturday tracking down a bug that turned out to be in one of the mission systems' "cheats".

By Monday, I had the system robust enough that it could get through the content up to the new ending 90% of the time.

Armed with this more robust system, I went ahead and made some refactors that I'd been putting off. For example, the game has two very similar systems of spawning recurring NPC encounter groups. One was the first version implemented and was used mostly in the early part of the game, the other was a more flexible system added later. They both work, but having both is a form of technical debt: if some faction unexpectedly had too few or too many ships I had to investigate which system was being used. So I got rid of the first system.

Finally, yesterday, I started a full playthrough of Jupiter with the goal of identifying changes I want for the next opt-in build. I have a tentative goal of getting it out by the end of the month, but this will depend on how the rest of the playthrough goes.

Major tasks completed in the past week:

  • Updated automated test system
  • Implemented copy/cut/paste for the mission logic editor (I now regret having not done this months ago, it turned out not to be that hard and would have saved so much time)
  • Fixes for various bugs encountered
  • Added mission debugging features
  • Refactored encounter spawns
  • Fixed an issue causing periodic skill checks to generate unnecessary memory allocations (garbage)
  • Began full playthrough

Until next week!

- Kevin