I’ve finally released a playable version of Triverse with experimental survival and sandbox modes. It’s far from complete, but it showcases some of the basic mechanics.

Triverse is a game about building drones out of parts and battling them. You can build by placing various parts like cores, thrusters, hulls, or turrets in triangle grid cells to form functioning drones. Designing a drone involves tradeoffs in mobility, power, defense, etc. Drones move on the vertices of the triangle grid (which form a hex grid).

I’ve prototyped the game sporadically for quite some time, and it’s gone from a top-down shooter to an RTS to a grid-based roguelike to its current form. Tower defense might be another promising direction. These are the biggest challenges:

• Excessive microing: Allowing control of individual turrets/units versus deferring to the AI
• Means of building: Allowing direct building versus placing plans for the AI to build
• AI: Making an AI that can act reasonably given a player-designed unit and surroundings
• Overpowered builds: Certain builds could be optimal across many scenarios, defeating the point of variety
• Lack of strategic variety: Sheer numbers could be more important than careful planning (hopefully mitigated with more part variety)
• Explaining the mechanics: Simple rules, visual overlays, and a training mode would help

For this initial version, I’ve removed most of the complex or broken things and stuck with simple gameplay that somewhat works. For now there is no direct control of units and no AI building, just player building and simple AI steering and targeting. There is also no minimap/zoom and limited variety in parts/strategies.

One recent addition is the concept of territory, which are regions on the map you can freely build on. Territory appears near your own units but must be far enough from enemy units. That means there may be no territory if all your units are in battle.

The intent of territory is to allow direct building by the player, which is far simpler and more convenient than laying out plans for the AI to build (which I’ve certainly tried and may revisit at some point). However, it may be too convenient, so I’m still working out what the costs or limitations should be.

Implementation

I originally wrote the game in F# and recently ported it to Rust to learn the language. I’m using wgpu/winit for graphics and Fyrox for sound, and I’m adapting some ECS/asset/etc code I wrote for my voxel game. The UI is currently an ad-hoc jumble of drawing and input handling logic without much of a framework.

Unlike the voxel game, almost all of the logic and state is in a struct with an update function that takes player/frame input and returns frame output like vertex data and audio. It’s deterministic and relatively easy to test, port, or swap out frontend dependencies. It’s all single-threaded, with bigger calculations like AI done incrementally across frames.

I’m quite happy with the workflow. I can incrementally compile and see most changes within 2-4 seconds. I don’t know if that’s due to using a minimal set of Rust features (no async) or because I’d previously split up the code into separate projects to improve F# compilation speed (now 28 crates, half game-specific and half engine). I’m using opt-level = 1 for dev builds, which has been a sweet spot of perf and compile time (but I do need to rely more on printf-style debugging due to optimizations).

Next version

I plan to add an EMP part next, which is necessary to make shields useful. Currently, shields are underpowered, but the eventual intent is to make them highly effective against cannons. Since EMP will have the capability to take down shields, shield strength can be increased in the next version.