Starcom: Unknown Space Update — Mod Compatibility Status & Broken Mods List

[h3]Greetings Commanders,[/h3][p]It's been several months since my last news update. Coming up on the seven year anniversary of [i]Starcom: Nexus[/i] entering Early Access, the end of the year, and a current big sale on [i]Starcom: Unknown Space[/i], this seems like a good time to give an update on what I've been up to and what my current plans are.[/p][p]As you may recall, Unknown Space had its 1.0 release in September 2024 after about 20 months in Early Access. Then I spent the next nine months working on bug fixes, some content updates, localization, Steam Deck verification, etc.[/p][p]This past summer, after a much needed break, I started thinking about what I wanted to do next: take a longer break, start work on another Starcom game, work on a different kind of game, or something else.[/p][p]Around that time I posted a survey asking people for their input on what they liked and wanted to see in a potential sequel. As a reminder, that survey is here if you haven't filled it out yet:[/p][p][b][url="https://docs.google.com/forms/d/e/1FAIpQLScTS93QUjNnlrEQZiXLL_q6TxQG6y9nX2btAU7B_-3l7ViEjQ/viewform?usp=header" buttoncolor="#0c54a7"]Starcom Future Game Survey[/url][/b][/p][p]Finding that I was getting itchy to work on "something" I decided that I might as well be spending my time investigating ways I could improve Starcom if I decided to do another game.[/p][p]I've spent the largest chunk of time investigating architecture decisions, i.e., the core game logic that the various gameplay systems like movement, combat, etc., are built from. That's because those are the hardest decisions to revise later.[/p][h3]The ECS Experiment[/h3][p]I invested a solid 10 weeks into creating a prototype of some of the gameplay in ECS (Entity Component System), which is one part of DOTS (Data-Oriented Technology Stack), Unity's new-ish high-performance development pattern.[/p][p]Unfortunately, I ended up abandoning most of that work. There were a lot of reason for this, and maybe I'll do a long-form video or post eventually, but here's the summary:[/p][p]The ECS model [i]is[/i] extremely performant. While I'm very happy with Unknown Space's performance, there are a number of places where I had to make trade-offs to ensure it was playable on a wide range of systems. E.g., limiting the size of player ships, maximum number of active projectiles, detail level of simulation, etc. Obviously that's always going to be true for any game. But if a different architecture could allow substantially more performance, it could allow me to experiment with systems and mechanics that aren't possible otherwise, plus just adding "more" to existing systems.[/p][p]How much more depends a lot on what kind of gameplay is going on, but based on a simple performance test, an ECS version of a test project could maybe handle 4-5x the number of entities and colliders as the existing architecture while maintaining the same framerate. That's likely overly optimistic because in reality the game would have a lot of systems that don't benefit as much from it, but it definitely would be significant boost.[/p][p]Okay, so why would I choose not to take advantage of this?[/p][p]Because while everything was much faster to run, everything was taking [i]substantially[/i] longer to develop. Some of it was due to the fact that it's a new system that I'm unfamiliar with. But it's also the case that while ECS is optimized for "performance by default", a lot of functionality that is easy to do in the traditional Unity architecture becomes much harder in ECS, even if you were equally proficient with both.[/p][p]Why? There are several reasons:[/p][olist][*][p]ECS is a lower-level system. In order to achieve performance and parallelization, it places a number of constraints on what kinds of data it can operate on and how. E.g., no reference data types (so no classes/objects).[/p][/*][*][p]It tends to offer less generalized tools with the expectation that the developer will need to create the higher-level functionality exactly tailored to their gameplay.[/p][/*][*][p]It has undergone substantial changes in its design since its first version. Searching for how to do something often results in outdated examples.[/p][/*][*][p]There are a vast number of resources out there on (non-ECS) Unity. Most common gamedev problems have well-known solutions in Unity, while for ECS there are much fewer.[/p][/*][*][p]The Unity Editor has a lot of great tools to visualize, inspect and modify gamestate during play. Most of this functionality was designed for the standard MonoBehaviour model and either doesn't work, or doesn't work as well, with ECS entities.[/p][/*][/olist][h3]The Hit Box Problem[/h3][p]To give a specific example, in [i]Starcom: Unknown Space[/i], ships are composed of modules organized onto a hexagonal grid. You can break off parts of enemy ships by focusing on specific modules, disabling their engines, cleaving off a vulnerable section etc.[/p][p]How this works is a little bit complicated, but it starts with the question: when a projectile collides with an enemy ship, how do we know what module was hit?[/p][p][i]Starcom trivia: From the perspective of the physics system, ships are almost entirely composed of spheres. Spheres are the fastest shape for collision detection and very closely approximate hexagons:[/i][/p][p][img src="{STEAM_CLAN_IMAGE}/42185452/5984025e076a8bd0c3cfd6c37ffa188ce1aa9081.png"][/img][/p][p]And this question is relatively easy to answer in traditional Unity: Behind the scenes, the engine has reorganized the individual colliders on all the modules into a single compound collider, but it will call the OnTriggerEnter method on the projectile and tell it "this is the GameObject that corresponds to the Collider you entered". Which means we can get any component on that specific GameObject.[/p][p]The simplified MonoBehaviour code (aka, classic Unity) on the projectile might look like this:[/p][p][c] private void OnTriggerEnter(Collider other)[/c][/p][p][c] {[/c][/p][p][c] if(other.gameObject != null)[/c][/p][p][c] {[/c][/p][p][c] IHealth health = other.GetComponent<IHealth>();[/c][/p][p][c] if(health != null && IsHostile(health))[/c][/p][p][c] {[/c][/p][p][c] health.TakeDamage(dmg, factionId, transform.position);[/c][/p][p][c] SpawnImpactVFX();[/c][/p][p][c] }[/c][/p][p][c] }[/c][/p][p][c] }[/c][/p][p][/p][p]By comparison, my ECS version ended up looking like this (included as an image because it would make the post ridiculously long as formatted text):[/p][p][img src="{STEAM_CLAN_IMAGE}/42185452/7beed9f5bcfe1a093b85cfa9a90dbe683da7cc79.png"][/img][/p][p]You may notice that there's an "unsafe" block necessary to access the collider's pointer, something I've never had to use previously. This was a solution I'm unlikely to have found on my own: the code necessary to get the collider key I discovered in a forum post. The documentation for ColliderKey simply describes it as "an opaque key which packs a path to a specific leaf of a collider hierarchy into a single integer," a phrasing which suggests Unity didn't intend for gamedevs to try and unpack it. [/p][p]Plus, we also have to assemble the compound collider ourselves in a way that lets us match specific collider spheres back to the corresponding module:[/p][p][img src="{STEAM_CLAN_IMAGE}/42185452/3816fca67ad6eddbf028670bd94c1e1481c8d9df.png"][/img][/p][p]This is one of the more egregious examples of "easy in normal Unity, very hard in ECS", but I would say the majority of functionality I managed to implement required significantly more work to implement than the MonoBehaviour version, and these are features I've already built before and knew precisely how I wanted to work.[/p][p]You can imagine then how much much faster it would be to iterate on design in regular Unity than in ECS. If I have an idea for some new combat mechanic, I generally can hammer out a clumsy prototype in a few hours to see if it actually works in a way that can be polished into something fun. [/p][p]The same feature in ECS could take several days or more.[/p][p]My job is to deliver enjoyable experiences to players. Performance can be helpful in giving more options to create fun interactions, but it's nowhere near as important as how quickly I can test out and iterate on a design. To the extent that if I ever needed to use ECS for a new project, it would probably still be quicker to build a version with MonoBehaviours first to figure out all the design requirements. [/p][p]So apart from that less than successful experiment, what else have I worked on?[/p][h3]New Path: Optimized MonoBehaviours[/h3][p]Well, for the past month plus I've been working on creating an architecture that still uses MonoBehaviours for most logic, but aims to optimize the more performance critical paths.[/p][p]Which started with me performance profiling Unknown Space in a variety of scenarios.[/p][p][i]Profiler View of Combat:[/i][/p][p][img src="{STEAM_CLAN_IMAGE}/42185452/bf34e826d21be8f13a54cdeaa1296b0896e7e590.png"][/img][/p][p]Mostly, the game has already been optimized to the point that there's not "just one thing" that could be easily changed that would dramatically improve performance. But there are a number of operations that are very fast in isolation, but if you do them hundreds or thousands of times per frame, they add up.[/p][p]If you're curious, here are the areas that I've determined the CPU spends a significant chunk of time in Unknown Space, not necessarily in order:[/p][list][*][p]Updating individual ship systems, e.g., plasma firing, repair system, etc. How much CPU this uses is extremely dependent on what actually is happening. If there are dozens of drone fighters flying around, then the drone system takes a good chunk of time. If the player has dozens of plasma turrets blazing, then the plasma system takes a good chunk of time.[/p][/*][*][p]Physics simulation: This covers almost everything in the game that moves, as well as de