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.

Eval2D Available for Prototyping Procedural Textures

Eval2D runs C# scripts and displays results visually as you type; it’s a visual REPL for quick prototyping. Eval2D includes a small function-oriented library for procedural texture generation.

It’s worked well enough for me, and I’ve recently cleaned up the API and written some bits of documentation to the point where it might be useful to others. It’s intended for anyone with programming/scripting experience who needs to make some noise. The noise library could be included in a game using the same code written in the app, although it’s not really designed for high performance.

Download: (2.2 MB)

Screenshot of Eval2D showing code view and Voronoi noise.

.NET 4.5 is required, which is available here if you don’t have it yet.

I included a tutorial as the default script that covers much of the API. For additional reference, check the assembly .xml files and the readme. Note that this is an early release and much of the app is in an incomplete state. Feedback is welcome!

Eval2D F# Interop

Working toward releasing a version of Eval2D, I chose for some inexplicable reason to port core parts of it to an F# library (actually, it’s because I already had a dependency on F# code, and figured I’d roll more functionality into it). My C# library is written in a somewhat functional way already, so it should be easy, right?

Of course it wasn’t. Not because of changes in method bodies, but because I wanted to maintain the same fluent function chaining library design of the C# version, available to C# code. As a result, most difficulties came from trying to make F# work it ways it really wasn’t designed for:

  • Type extension limitations: In F#, extension methods (type extensions) cannot be defined on generic types with concrete type parameters specified. For example, I can extend IEnumerable<T>, but not IEnumerable<int>. In my case, I use extension methods to allow dot notation for chaining functions together in the same way that the F# operator |> operates. Without the ability to specify concrete type parameters, many of my extension methods are unavailable.
  • FSharpFunc: Functions defined in F# (of type FSharpFunc<>) are not implicitly convertible to C# delegates, so I had to define a cast function.
  • Less concise default parameter values: It’s an additional line per parameter. Not so bad, and I’m not sure that every feature like this needs to be part of the language.

Some good points:

  • Indentation-sensitive: No curly brackets needed to identify scope. In some cases, I haven’t been sure how to indent, but I can figure it out through Intellisense.
  • Type inference: This cuts down on a lot of type specifications, but it’s occasionally tricky to trace through the code to determine why the compiler inferred a certain type.
  • Type abbreviations: I’m working with Func<> a lot, and was able to abbreviate certain Func<> types that appear often.

In the end, the core code is F# and extension methods are in a separate C# assembly. I don’t like having two assemblies like this, but I don’t see alternatives at the moment. Overall, I’m happy with the results and hope to release a version soon.

Eval2D: Procedural Content Editor

I’m always trying to cut time off my feedback loop, especially when the work involves tweaking parameters without a clear idea of their impact. This has been especially true for procedural content, where much of my time is spent discovering how to compose functions to produce interesting effects.

For a cheap solution, I’ve used NUnit to define tests that output images, then tweaked parameters and re-run the tests. In some cases, I generate multiple images for ranges of parameters. This process works fairly well, especially with test running integrated into VS 2012 or through an addon like Resharper.

I finally decided it might be worth investing some time into a dedicated solution that allows me to write my code and get instant feedback. Building a small utility also makes for a fun distraction justified with the notion that I’ll be working more effectively with it.

So here’s Eval2D, a procedural texture tool where your C# script is evaluated as you type for instant visual feedback:

It’s a preview pane, a code editor, and a results/errors pane. Autocomplete works in simple cases. Evaluation of highlighted code sections is supported (as seen in many SQL editors). The layout changes when the window widens:


  • AvalonEdit: This is the same editor used for SharpDevelop, and gives me most of what I need in a code editor.
  • Roslyn CTP: Works well for executing the scripts, but I had a bit of trouble querying compilations for type information to support autocomplete.
  • MahApps.Metro: Window styling.
  • Noise library: This my own code, which has a fluent interface around noise/math functions that makes for easy function composition. It’s very flexible, but could be much faster with GPU support.

Planned Features

It works well enough for now, but I’d really like to have fully working autocompletion, popup sliders for numeric literals (as might be seen in shader/material editors or LightTable), and a color picker for hex-formatted uints. Access to a time variable within the script would help in visualizing the effect of changing parameters. For my own use, I’m not interested at all in any kind of modular GUI system like most 3D modeling apps have. I intend to keep a minimalist design and add features only as needed.