Iterating on the Blueprints UI

It’s been awhile since a Triverse update, but there’s been plenty of work on it! Most has involved internal systems to support networked multiplayer, large worlds, and Unity integration, but more recently I’ve spent time on UI changes that are a bit more visual.

The previous UI for part selection worked decently, but it had a few deficiencies and needed to support several new features. One of those features was unit blueprints, where players can save a copy of a unit layout and fabricate it later. During prototyping, this looked like a great way to support fleets at a larger scale, and it would also support players sharing their designs later on.

Two big questions:

  • Is it feasible to include both parts and blueprints in the same portion of the UI. In initial attempts, I tried drawing unit outlines and fitting them into part borders, but they didn’t look very good or convey the scale of the object.
  • Can the action bar go elsewhere? I’d initially wanted it to go at the bottom because that’s where they typically go, plus it would be near the other controls. However, it’s also been a bit confusing to see both the action bar and parts bar together.

The latest attempt has proportionally-sized layouts drawn as connected graphs, with cores highlighted:


I tried another variation where only a portion of of the blueprint is shown. Vertical size doesn’t matter much for clickability since these are at the bottom of the screen, where you can always slam your mouse and hit a clickable region. It’s a cleaner, more uniform bar at the cost of omitting a portion of the structure:


Parts show up in the same UI bar alongside blueprints, although they behave somewhat differently during placement:


Finally, unit blueprint placement:


On a side note, I’ve found it incredibly useful to use a shader with replaceable color channels to test out different color variations on the fly. The problem is that I can never find the right color combination, so I end up making adjustments that ultimately probably don’t matter much. Or maybe I just need more colors!

On a related side note, the parts/placement UI is now blue instead of green, which should be good news to any colorblind players who want to distinguish valid and invalid placement regions:


Triverse Neon Graphics Revision

After getting feedback and comparing the old neon look and the new lighted look with a variety of ships, I chose to go back to the neon look and enhance it to support team/faction colors. With the neon look, I found that:

  • Parts are more distinguishable.
  • Part power levels are more visible.
  • Less repetition when tiling due to color variation (aesthetic).
  • Unique, recognizable aesthetic for Triverse.

The main concern was how to clearly distinguish opponents from the player’s own units, which is why I’d started looking at tile alternatives in the first place. With the original neon look, each tile could have a separate color, and an obvious way to show opponents would be to apply an overall tint or hue shift to the colors. However, every variation I tried looked terrible, and it also confused the notion of part colors corresponding to power levels.

Revised Neon Graphics

Fortunately the changes I made for lighting also provide support for defining separate colors for regions within tiles defined by RGB channels, which allows for more granular control over tile coloring.

Here’s a test of a color theme for opponents, with cores glowing red:


So the plan now is to define an overall theme color and a core glow color for each separate team. Using cores as a primary identifier fits well with the game logic because ships require at least one core, otherwise it’s a floating piece of scrap without any owner. Cores also never had any strong color variations from power level as other parts do, so it isn’t much change to use a specific color for them. The difficulty is mainly in getting them to look decent in using the separate region color channels.

Triverse Tile Graphics Update

Graphics have gotten a major update! Here are some ships with the new look:


Gameplay comes first, but graphics bubbled back up as a priority because they were blocking several gameplay issues:

  • Visualizing team membership: The previous graphics supported a single color per part, but several variables need mapping: team, power level, energy/damage level, and whether the part is firing, selected, or highlighted.
  • Streamlining tile asset pipeline: I can create tiles in Inkscape, but it’s a manual approach. I want more automation in the process as well as control over what assets are produced from my original content.
  • Aesthetics: I want a less abstract appearance and a better sense of depth. This is about immersion; ships should feel like solid, physical objects.

New Tile Rendering Mode

Tiles now have lighting applied and region-based coloring. Each tile is still rendered as a single triangle, but vertices hold more data and the shader does a bit more work. Performance is not noticeably different, although rendering is nowhere close to being a bottleneck at this point.


  • Power level visualization: Previously, power level was clearly indicated by the hue of parts, but now it’s generally more subtle through power regions and glow. Build mode might be a good place to enhance the power colors more.
  • Overall ship color to indicate team: This might be limiting in terms of what variations in color specific parts can have. In most games, team color is shown as trim on structures/units/etc, but here the parts are too small for that to work well. Some parts already have power regions as well that could make this ambiguous.
  • Portability: Shaders do more work now, which might present issues when considering less powerful devices (tablets?).
  • Modeling difficulty: My modeling approach amounts to writing functions in a text editor.

Generating Triverse Tiles

To generate tiles, I enhanced Eval2D to use DirectX 11 for sphere tracing, then wrote appropriate signed distance functions to produce shapes that look reasonable as ship parts. Turns out HLSL has built-in automatic symbolic differentiation, which means I can easily obtain normals without resorting to ddx/ddy or additional sampling. All the new tiles assets are generated as a build step or as part of unit tests for convenience. I figured this way would be more interesting than learning/automating Blender.

Normal map generated for a cell junction:


Obligatory noise/sphere reflections (not related to game!):



Next Steps on Graphics

Graphics are out of the way for now, but I expect to revisit these areas at some point:

  • Terrain tiles: The rock tiles are good enough for now, but this will need improvement once I introduce additional kinds of terrain. On the aesthetic side, they aren’t exactly seamless and they don’t quite match the new look.
  • Effects: HUD, projectiles/beams/trails, particle textures can be improved, but changes would largely be aesthetic and lower priority.
  • More tile shading variety: The colors still look too flat and uniform. It might be worth looking at mapping power to lightness in some way.