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.

Triverse Part Group UI Design

Depending on their size, ships in Triverse can have 2-7 part groups, which typically consist of weapons. These groups allow players to select a subset of parts with a single click, which they can then fire or target on enemies. Groups also provide the basis for auto-targeting and I hope to use them as gunner slots in multiplayer. As a ship is modified, groups are automatically updated to provide sensible coverage around the ship (e.g. one group is the forward-facing weapons, another has the ones in the back or the side, etc). The player can also configure groups manually (with no extra screens!).

New Design

Group visuals have long needed an update. Until recently, I’ve just used the primary weapon type as an icon, which is terribly ambiguous given the build bar below it using identical icons, albeit in a different color. Type icons also provide no information about where the parts are located within the ship. So I prototyped a few variations in Inkscape before choosing a new kind of icon that captures the spatial distribution, although unfortunately no type information.

Before, with groups on top:

Original design with group icons on top

After, with groups on bottom with new icon style:

New design with group icons on the bottom with spatial layout

The sections within the icons indicate rough regions of the ship that contain a part in the group, a bit like Talairach coordinates without having to unfold gyri. Hopefully the icons aren’t too abstract given the huge variety in ship layouts.

Aesthetics Versus Usability

I also ran into a design problem. Previously, the group icons were on the top bar, pointing downward. In the new scheme, it would be unintuitive to show icons representing the ship upside-down. I’d also tentatively planned to put gunner status information close to the group icons, so I didn’t want to put them at the very bottom of the screen. So the choices were:

  • Keep the orientation upside-down. Not good because forward is intuitively up.
  • Swap top/bottom and move both bars to the top of the screen. Not good because virtually every game has status on the top and buttons on the bottom.
  • Change from the interleaving teeth layout so both rows have point up. Tried some variations, but the layout is something I want to keep.
  • Swap top/bottom and figure out status later. Not ideal, but the other choices were worse. There’s another slight complication because I’ve mapped number keys to the build bar and function keys to groups, and those keyboard locations previously matched the UI positions.

I went with the last option. I’m not keen on seeing the build bar/icons upside-down now, but  they don’t need to convey spatial information.

Serializing Ships

I’m a big fan of data in transparent formats that allow or encourage hand editing by humans. For Triverse, I’ve imposed the constraint that all ships and maps have a textual representation that captures all information about them through the arrangement of parts.

Other metadata might be useful, such as weapon group definitions or forward direction, but I’m hoping to generate reasonable defaults or possibly to cache user-customized weapon groups for layouts on the client. (Actually, since I first wrote this, I’ve been thinking more in the direction of disallowing arbitrary forward direction and forcing it to be a function of layout.)

A small ship:


This form is also acceptable (slash required):

   . p .
   i . i
 u . o . u
   u u u/

And the resulting ship in-game:

A larger ship:

  /i\./.\u/     \u/.\./i\
/.\./o\u/ \g/o\g/ \u/o\./.\
\./.\./u\ /u\./u\ /u\./.\./
    \./.\i/     \i/.\./

And the result:

Each letter represents a type of part. Only one slash must be present to define cell orientation, but I find it helpful in visualizing the ship to include them throughout. This format was not obvious; I went through several other variations before settling on it. I’ve also considered using images to store large maps, which are stored the same as ships internally but would be wasteful in a text format without compression. Margins are irrelevant; they can be trimmed and would have no significant performance impact.

Part types are read in and mapped to a part definitions using a table. This table defines character codes (‘i’, ‘u’, ‘.’, ‘o’, etc) and attributes of parts, including energy requirements, weapon behavior, and any other information related purely to gameplay logic. Other info, such as visuals and audio, are decoupled from these definitions and placed in a separate table. I can imagine modding scenarios where one or both tables could be easily swapped out or added to. However, this use of character codes does impose a convention on custom tables if a modder wants to support existing ships: if a thruster is suddenly mapped to a weapon, the ships wouldn’t work as intended.

Creating this visual serialization is one of the best things I’ve done for testing and development in general. I implemented it early in the project, and it makes defining test cases incredibly easy and allows for quick comparison of results. For example, code to rotate a grid (I’ll cover the math in another post):

let cg = grid @"
    /i\./u\         /u\./i\
      \i/.\./u\ /u\./.\i/
          \./p\./p\./ "

for i in 0 .. 6 do
    let rot = GridVector.Rotation i
    cg.RotateTriGrid rot |> formatTriGrid |> printf "%s\n\n"

And the output:

/i\./u\         /u\./i\
  \i/.\./u\ /u\./.\i/

      /i\u/ \u/.\./.\

      \i/u\ /u\./.\./

  /i\./.\u/ \u/.\./i\
\i/.\u/         \u/.\i/

\./.\./u\ /u\i/

/.\./.\u/ \u/i\

/i\./u\         /u\./i\
  \i/.\./u\ /u\./.\i/

I imagine copy+paste as a useful way to get ships in and out of the game in a sandbox mode, but Unity3D does not expose any cross-platform way to access the clipboard. Dragging + dropping files into a game window would also be convenient. For a browser deployment, I’ll probably have to use a text box outside the game and use Unity’s interop to access it.

Working with text this way, and especially getting rotation working, makes me ponder roguelike potential here. Making time and space discrete would avoid a lot of work, and there might be a better overall game along those lines. Might be fun to prototype, but for now I’m still going down the original path of a real-time continuous world.