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

Starcom: Unknown Space

Weekly Update: Nov 8, 2024

For the past month or so I've been working on updating the game's content creation tool with the goal of making it available to players interested in trying to create their own content for the game.

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

Weekly Update: Nov 1, 2024

For the past few weeks, I've been writing about progress on the new "Creator Tool": an updated version of the tool I made for creating the game's content that I am planning to make available to players/modders interested in creating their own content.

Most of the game's content was authored in an earlier version of this tool and is organized into content groups called "Stories". Not all of these "stories" correspond one-on-one to what you might recognize as game stories. They might be better thought of as the narrative equivalent of code "modules" but I didn't want to call them to avoid confusion with ShipModules. These are essentially namespaces that group related content together and keep me from having to worry if I've already created an anomaly with id ANCIENT_DERELICT a year ago.

Each story contains some or all of the following content:


  • Missions: Where any of the story's logic happens. These may be actual missions that can appear in the player's log, or invisible logic missions that trigger events in response to game conditions.
  • Anomalies: A dialogue-like interaction occuring on a planet, with a ship, or celestial artifact.
  • Conversations: Like an anomaly, but with an actor associated with some faction.
  • Discoveries: A source of Research Points.
  • Factions: Usually an alien race.
  • Regions: One or more sectors and the various PersistentObjects they contain (a PersistentObject is anything in the game universe that will persist if the player leaves and comes back: planets, ships, and stars are PersistentObjects; projectiles, drops, explosions, etc are not.)
  • Ships: Any custom ship designs, typically the ships used by story's factions, but can also be things like investigatable derelicts.
  • Items: Analyzable artifacts that are a tangible source of Research Points, also used as mission objectives/requirements.

For each of these, there's a panel in the Creator Tool used for creating and editing these. As of this point, I've created updated versions of most of these sub-tools. If all goes well, my plan is next week to start creating a new mini-storyline using the new tool as a test to see whether I've replicated all the necessary features and identify any bugs that show up during real use. I'll also probably tweak some existing content.

Sometime after that (fingers crossed) I'll send out some invites to players who expressed an interest in trying out this tool. Since I've never released a game with modding support, I really don't know how this will go: I think the game's players are generally pretty clever and the survey suggests a lot of the people interested in this tool have technical backgrounds, but I may underestimate how much "internalized knowledge" I rely on during content creation. I'll have to see.

Until next week,
Kevin

Weekly Update: October 25, 2024

As a reminder for anyone who hasn't seen this yet, I've created a player survey in Google Forms:

Google Survey

This week I am mostly just continuing to work on the "Creator Tool" project. The goal of this is to transform my design tools into something that others could use to create their own content. Still no promises when or even if this will be made available, but I'm making good progress.

I am currently working on what I expect to be the hardest part of the tool, the Region Editor. I have the working version of it that I used during development, but there were aspects of that version that I don't like, so I'm doing a full rewrite.



Two of the bigger challenges with redesigning the Region Editor:

Coordinate Systems



There are many different coordinate systems that object positions may be represented by: world coordinates that Unity's rendering and physics operate on, the game logic's "SuperCoordinates" used for storing absolute position at scale and across universes, local position used for constantly keeping the sectors immediately around the player active and positioned correctly, the coordinates that the player actually sees displayed, "region relative" versions of the SuperCoordinates so I don't have to design and position the entire universe at once, and then the various screen and UI coordinate spaces that emerge from actually being able to visualize all of these in the tool.

Data and Class Design Constraints



The logic of how the universe "works" evolved over the development process and at this point is both complex and fairly robust. Which means the new Region Editor needs to work while making few if any changes to the existing world logic. At the same time, there are design problems with the original Editor that I want to correct.

For example, the original Editor used the same "GameWorld" class as the game itself to organize persistent objects. This made sense at the time, but in hindsight it limited the tool too much, particularly now when if I want to add new features that the GameWorld logic doesn't support. The downside is re-duplication of some logic that I need in the Editor, but don't want to refactor out of the GameWorld for the aforementioned reasons.

Until next week!
- Kevin

Weekly Update: October 18, 2024

Last update, I posted a player survey about areas for potential future features/content:

Google Survey

One of the questions asked about interest in making the game content authoring tool available. Based on responses so far, a significant number of players seem to be interested in such a tool. I created a version of such a tool for my own use during development of the game, but there are a lot of things I want to fix/improve before releasing it to others. This past week I started that project.

So far, it's going well and I'm making good progress. Part of me wishes that I'd done this earlier, as I'm adding a bunch of improvements which make the overall experience of creating and testing content smoother.

For example, whenever a player has submitted a save in which they are stuck, the process of figuring out exactly what element of a mission was blocking them sometimes involved a bit of forensics. In this new version of the tool, the tool can open an existing save and show a "debug view" of any mission including what conditions are blocking progress:



I'm still not promising that this will be made available generally, but at his point I think it's very likely that at a minimum it will get to a state of closed beta testing.

Until next week!
- Kevin

Post-Launch Update and Player Survey

Starcom: Unknown Space graduated to 1.0 release a little over a month ago and I thought it would be a good time to take a step back and give everyone an update on how it's gone and my plans for the game in the near future. There's also a player survey (see the link at the bottom of this announcement).

Graduation Results



The natural cycle of Steam games is that a significant percentage of lifetime sales happen in the first month of launch as Steam shows the game to many new potential players. So first month sales are critically important (or graduation month in terms of Early Access titles). The game sold a bit over 20,000 copies during all 20 months of Early Access. A typical expected graduation for that number of Early Access sales would be ~10,000 copies in the first month. Starcom: Unknown Space sold well over 30,000 during graduation month, so definitely a result to be happy about!

Future sales will be at a much lower rate, but the game has already hit my success metric of covering my external development costs, plus a fair salary for my development time.

Latest Updates



As many of you probably noticed, the game has had several post-launch updates adding QoL improvements, additional guidance where players have gotten "stuck", bug fixes, revamped controller/Deck support and some minor additional content. The most recent of these went live on the default branch on Wednesday, with a couple of hotfix patches since-- you read the full patch notes here.

There are still plenty of minor enhancements and fixes that I could tackle, but I'm starting to turn my eye towards larger possible updates to the game. Which brings me to...

What Next?



Some of you may remember from the Starcom: Nexus post-mortem that technical details of how content was created caused development iteration to get significantly slower as the game grew in size. This put a drag on releasing updates, so there were not a lot of post-1.0 patches. These issues were addressed in the technical design of Starcom: Unknown Space, so it is much easier for me to continue working on the game. There are some challenges on the design front, because I want any future updates to be save compatible. But that still leaves a lot of flexibility for continued development in terms of side quests, Easter Eggs, procedural anomalies, etc.

While I could continue to iterate on small QoL improvements and bug fixes, I have several potential larger updates to the game I'm considering. I'm not promising to deliver all or even any of these, but barring some unexpected circumstance I plan to continue work on the game for at least the near future. So I've created a Google survey to gauge player interest, (and give you the option of signing up for email updates).

Potential Updates



One of the questions is about ranking potential updates. I'm giving a bit more detail here:

  • One major new quest line: This would be a single, optional new story line that involved multiple objectives. I don't have a specific story in mind, but one potential candidate would be a resolution to the Nimion/Kyrnan conflict.
  • Multiple smaller quests/discoveries: This would be numerous little bits of content that might be small missions, void discoveries or Easter Eggs.
  • Weapon variants: Currently, missiles and fixed guns allow unlockable variants, like the Brogidar cannon or the Swarm Missiles. Maybe there could be more of these?
  • Cosmetic ship modules: More visually interesting ship module that didn't have a major game play impact.
  • An endless survival mode/region: A few players have asked for some kind of region where they could fight infinite enemies. Perhaps as a challenge on how long they could survive?

Content Tool / Modding



The game was created using the Unity Engine, however as part of my experience in creating Starcom: Nexus, I decided to separate out most of the game's content into an external format and created a collection of tools that I use for authoring anomalies, character dialogues, items, missions, regions of space, etc. With some work these tools could be made available allowing others to create their own content and potentially share in the Steam Workshop.



The tool would not necessarily require programming experience, but I should caution that even with the tool creating content is not easy. This is also something that I don't have much experience with and there are few games out there with a similar tool (in fact if you are aware of any, please let me know in the comments).

Separately, because the game was developed in Unity, it's at least theoretically possible to mod the game on a deeper level. This would be more technical than creating content but would allow for changing or adding game logic features. E.g., while it would be possible to create a quest with anomalies and factions with the content tool, creating, say, a weapon variant would require actually modding the game's assets and code.

My expectation is that most players are probably not interested in creating content/modding, but if a significant minority are, then helping them out would be a good use of my time.

Thanks for taking the time to complete the survey:

Google Survey

- Kevin

Build Updated to 17342

Over the past few weeks I've been posting incremental updates to the opt-in beta branch. With no reports of new issues introduced by the changes, I'm now promoting the latest to the default branch.

Build 17342 Notes:


  • Highlight interactions on map now color codes based on category (purple = detected but unscanned, yellow = scanned but unsurveyed, teal = additional investigation possibilities, dark green = trade outpost)
  • Added new tech that has a probability of briefly illuminating ships beyond normal sensor range on map
  • New mini-side quest to unlock said tech
  • Boosted map visibility of void nebulae
  • Skill info on Crew Panel shows related techs
  • Add button to delete all autosaves older than 24 hours
  • Added dev console commands "RenamePlayer(first, last)" and "RenameShip(shipname)"
  • Several minor help/hints
  • Don't show/load saves with a version greater than current version
  • Minor tweaks to difficulty
  • Numerous changes to controller/gamepad/deck inputs
  • Refactored Cargo artifact display to be more efficient
  • Improved gamepad Cargo interface
  • Improved gamepad Research interface
  • Crew will not Battlestation if ship is 100% strength
  • Fix missile autolock logic
  • Deactivate invisible map icons (reduces draw calls in map mode)
  • Fixed various localization bugs, missing symbols
  • Updated translation for French with volunteer's corrections
  • Updated several missing localization symbols
  • Minor change to map logic to reduce updates, VFX calls when not in map mode
  • Fixed possibility of region being added "nowhere"
  • Fixed possible broken anomaly
  • Fix for errors during manual save erroneously appearing successful, now shows error message
  • Misc minor fixes
  • Several typos fixed

    Thanks for playing Starcom: Unknown Space!
  • Weekly Update: October 4, 2024

    It's been just over a month since Starcom: Unknown Space graduated from Early Access to its official 1.0 release. Overall, I'm very happy with how it's gone so far.

    There were a few new issues discovered, mostly in that tricky area of providing enough guidance so that players could find their way to the game's conclusion through exploration and discovery, without too much handholding. But I think considering the fact that tens of thouands of players have played the game in the past month (more than played it during all 20 months of Early Access), the number of players who experienced any significant issues was relatively small.

    Since launch I've been working on various updates with QoL improvements, bug fixes, language patches and improved controller support. There's currently an opt-in beta that some brave commanders have been testing for the past week and there's a patch with some additional fixes in the pipeline.

    Earlier this week I implemented a change to my content creation tools that made things a tiny bit smoother. I'm mentioning it now because it was essentially the same thing as a feature in the game: the ability to zoom toward the mouse on the map. The default zoom centers on the player's ship, but there's an optional mode with the CTRL modifier (which can be inverted in options) that instead zooms toward the player's mouse.

    This was one of those features that conceptually sounded simple, but for some reason I struggled to get it working "right".

    The way the map works is that the game keeps a 1:2500 scale model of the universe with icons positioned for each map visible object, and the map camera normally stays centered on the player icon. "Zooming" changes map camera's elevation.

    My initial attempt at "zoom to cursor" was to zoom, but instead of centering on the player, center on the mouse. This didn't work, because as soon as the player started to zoom, the camera would jump all the way across the map and then additional zoom inputs would send the camera further and further away.

    My second attempt was to use the normal zoom method of changing the camera's elevation, but then also to move the camera toward the cursor by small increments. This was closer to the desired behavior, but I struggled to come up with the correct formula for how much to move the camera as a function of distance and elevation, both of which were constantly changing.

    Some time after putting this feature on hold, I was planning a bike ride and noticed that Google Maps did exactly what I wanted and wondered if I could figure out what formula they used. I zoomed up and down while moving the map around and tried to see how the center moved and then I realized I was thinking about the problem wrong:

    There is a point on the map underneath the mouse. Whenever you zoom, that point stays under the mouse. So if I figured out the distance between the map coordinates of center of the map and the map coordinates of the mouse before zooming, then after the zoom step I just needed to move the map camera by that amount:

    if (shouldZoomToMouse)
    {
    Vector3 endMapMouse = MapMousePosition;
    Vector3 mouseDelta = endMapMouse - startMapMouse;
    mouseDelta.y = 0;
    mapCamPos -= mouseDelta;
    mapPanOffset.x -= mouseDelta.x;
    mapPanOffset.y -= mouseDelta.z;
    mapCamera.transform.localPosition = mapCamPos;
    }

    I've subsequently noticed that this is identical to how zoom works in Photoshop and other applications, but it was Google maps that prompted the connection, possibly because my brain needed to be primed with the "map" association.

    Besides possibly being of assistance to some future dev, the main point of this minor technical annecdote is that often in game development you can describe what a feature is supposed to do, but you don't really understand it until you have a working example in front of you. Sometimes it's an example that you had to spend hours and hours prototyping, other times (like this) it's when someone else has solved it before you.

    Weekly Update: September 27, 2024

    During the weeks just before and right after 1.0 graduation I was putting in an average of 70 hours per week, which is obviously not sustainable long term, even when most of what you're doing is something that you love. Now I'm trying to settle back into a more measured pace.

    This past week I've been chiseling away at a bunch of QoL improvements, fixes to localization, more controller work and some additional content.

    Some of the things I've worked on (none of these are on the default branch yet, although some will soon be on the opt-in beta):


    • Crew Tech info: Displaying info on any technologies that are affected by Crew Skill levels in the Skill Info panel
    • Various controller related changes
    • Some missing localization symbols
    • Interaction highlight ring colors indicating: trade, incomplete survey, unsurveyed, and unscanned
    • New tech that has a probability of briefly illuminating ships outside normal sensor range on the map
    • New mini side-quest to unlock said tech
    • Adding button to Load/Save menu to delete autosaves older than 24 hours
    • Started working with portrait artist on additional alien artwork




    Until next week!
    - Kevin

    Weekly Update: September 20, 2024

    On Monday, I promoted Kepler 17334 to default. This addressed a number of minor issues, as well as providing more guidance to most of the outstanding areas where players reported getting stuck, and improving controller support.

    This week I've been mostly still been working on improving controller support. Feedback from 17334 players is that it's a big improvement, but there are still a few areas that need work.

    Yesterday, I took a break and recorded a dev video in which I talk more about Anomaly creation. If you're interested in a ~8 minute dive into my development process:



    Until next week!
    - Kevin

    Kepler 17334 Update

    Last week I uploaded Kepler 17334 to the opt-in beta branch. Since then, there have been no reports of significant new issues with the build, so I'm now promoting it to the default branch.

    This update adds a number of QoL improvements and minor bug fixes. It also aims to improve two major areas:

    First, is improving controller/deck support in menus. It's still not quite to 100%: there are a couple of screens where either a keyboard and mouse are required, or the controller inputs are awkward/unclear.

    Second, is to provide better guidance in a few areas where players have been getting stuck. While this is a game of exploration and discovery, players should not find themselves with no clear way to progress the main story line for very long. Any place where this does happen is usually due to players not doing something that I assumed they would do. This is something that happened quite a bit during Early Access, and I gradually whittled those cases down, but there were still a few that persisted into 1.0.

    Kepler 17334 Update Notes:



    • Anomaly, character and item sprites are loaded as thumbnails at start, full images as needed. This speeds up application start up and first game load. It also substantially reduces the baseline memory footprint.
    • Refactored Controller/Deck input system
    • Improved controller inputs for many menus, UI screens
    • Allow for rebinding Controller buttons
    • Fixed Map HUD text scaling
    • Show binding conflicts
    • Controller glyphs in menus
    • Controller close dev console with B
    • Fixed Windowed-mode resolution being reset in options
    • Fixed Fog of Exploration preference not being saved
    • Fixed issue with ship max health not being recalculated after design revert (low health percent or even destruction on leaving Celaeno)
    • Finally fixed "negative resource" trade bug
    • Plasma autofire more strongly favors target lock
    • Screenshot composer now uses current color swatch
    • Fix for "screenshot composer" ship data being used in last save
    • Changed artifact analysis sound in response to player complaints on pitch too high
    • Default branch incorrectly logging extra analytics data
    • Incorrect keybindings shown in some tutorial comments
    • Unexplored Flingers display "?" if highlight investigate is enabled
    • Boost brightness difference between explored and unexplored systems
    • Early anomaly infinite Aluminum exploit
    • If player doesn't research anything during the prologue, they will be prompted to return to Celaeno
    • Fix for an anomaly Forboding Planet in Kyrnan space could not be successfully completed if failed the first time.
    • If the Aletheia travels too far from Celaeno, it will automatically be returned to the gateway
    • Missing Diplomat more explicit derelict hint if player missed it
    • More explicit hint if player doesn't purchase the Remnant Spike from the Kyrnan
    • Clarified Nimion Ally mission wording to make it clear there are Kyrnan in other nearby systems
    • If the player misses the Collapsar while exploring the Stalker region, Pirx will say something
    • If the player doesn't enter the Heretic Portal activated by the Pyramid, a crew member will eventually set it as an objective.
    • If the player unlocks, but does not research the Starlance Equation, Dr. Rama will politely remind them
    • Added base Italian, Russian and Ukrainian machine learning translations
    • Missing anomaly name localization in logs
    • Missing Brazilian Portugese icon
    • Numerous typos


    I'm continuing to improve controller support and keeping an eye out for additional "stuck" problem areas, so expect additional patches soon.

    Thanks for playing Starcom: Unknown Space!