Starcom: Unknown Space News

Another busy week of development-- this one produced more visible progress than the last.

I started by working on revisions to the assets necessary for Steam trading cards. In the process I had created a QHD resolution image of two planets in a nebula that I use as my desktop wallpaper. Steam limits the asset resolutions, but I've uploaded the original here if anyone wants it.

Next, I worked on some minor issues in the latest Jupiter opt-in, then created some new content including a "mini quest" and five new anomalies. This brings the game to over 200 unique anomalies!

I also got Moritz, the game's composer, started on some track needed in the late game.

Finally, I implemented some changes to the shipyard. Like last week's multi-module select, these had a bunch of corner cases that were complicated by being build around the existing design.

The first change was a "design mode" checkbox that allows the player to ignore resource shortfalls while planning their ship.

The second change, which required the first, was saving blueprint designs as a "goal". If a design is set as a goal, a new column in the trade screen will show the values for the "in cargo" resources the player needs to build that design. E.g., if you want to build a ship with two more Mk II plasma and an extra engine relative to your current ship, when you go to trade with a faction, you'll see exactly the aluminum, titanium, yttrium and gold you need to buy (or could sell) in order to be able to build it.

One of the challenges of these two new systems was trying to present the necessary information in a comprehensible way without making it overly complicated from the player's perspective. For example, if the player wants to build a ship that requires 100 Titanium, and their current ship is built with 52 Titanium, and they have 20 in cargo, what value should the system calculate and display in the trade window?

My first thought was 28, the amount they need to buy. Then I switched to 48, the amount they need to have in their cargo hold. I've gone back and forth. Should the "need" be constant and the player buys and sells until their cargo equals that value, or should the "need" go up and down as they adjust the trade value and equal 0 when they've reached the goal?



What do you think?

I'm going to try to get this update to the Jupiter opt-in deployed in the next couple of days so players can weigh in on how well the new shipyard features work (and if they create any bugs).

As a reminder, Jupiter is available as an opt-in beta at the moment. It is not save compatible with Icarus, but if you're starting a new game you may want to switch to that build (the build apparently is more stable than that announcement might lead you to think).

Until next week!
- Kevin

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

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

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

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