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.
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
Continuing my video series on the Creator Tool, this week's update covers Regions:
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
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:
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:
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:
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
