Triverse – Introduction

Triverse puts you in control of a fully constructible spacecraft, exploring a vast destructible 2D environment and obliterating your enemies to obtain parts for your growing fleet.

Here are some general goals:

  • Few parts: Each part should pull its own weight with behavior distinctive enough to offer varied gameplay and tradeoffs.
  • Unified parts/map: Everything should be destructible, whether it’s ships or terrain.
  • Minimal UI/controls: This is a tough one because I want to support casual players with only a mouse as well as hardcore players who want to play this as a shmup. I’ll continue to prototype to see what forms of gameplay are feasible under these limitations and evaluate how much common ground there is.
  • Avoid optimal/breaking builds: With so much flexibility, players will certainly try things I could never think of or intend. Hopefully balance is an achievable goal without watering down gameplay.

The gameplay is inspired by SubSpace. In particular, I’ve wanted to create a 2D space game incorporating a unified energy system and Newtonian physics. Constructing ships from parts comes from Master of Orion and the emergence of voxel-based games. Warning Forever and Captain Forever have had some influence on the visuals.

Triverse – Storing Parts

Triverse is a 2D space shooter with ships composed of primitive parts. Ships behave based on their composition, including physical effects of thrust, mass, and inertia. To that end, a central design question is how parts are obtained and stored. Here are some approaches I’ve considered:

  • Available parts floating in space: Players would drag and drop parts, or possibly select a type as a brush and “paint” regions of the ship with it. This solution is elegant in the sense that it requires no additional UI elements to support and maintains consistency in the notion that parts have physical properties. However, having many parts floating around space may present performance and usability problems at scale, and may be very challenging or unfeasible to implement in multiplayer. This approach works well for Captain Forever. I tested floating parts both in the foreground (not shown), which would collide, and in the background (shown below), which are intended as a separate layer that doesn’t interfere with physics.
  • Omnipresent inventory: Players would obtain parts in a central inventory not bound to any particular ship. This approach requires UI support, but makes construction convenient and would not present scale or multiplayer problems. However, it raises the question of where the parts actually exist, which may or may not matter for more of an arcade-style game where parts are akin to score. It’s a question of internal consistency: if parts exhibit physical properties when added to a ship, where are they? Certainly not stored “in” the ship, because then it would have greater mass. Perhaps we can explain it away with a dimensional hold of sorts (or Doraemonhold?), but then we have plenty of new questions to answer. This approach may also limit the gameplay potential that could arise from resource gathering activities, which are often a central theme of the space mining genre. Shown below is an inventory bar in a newer build, which would also need to indicate the quantity of each part type available.

So as usual, there’s no clear answer, and it really depends on what I want the game to be and what actually makes it fun. I’m leaning toward the second option and hoping it won’t limit gameplay or believability.

Hexagonal Grid Visuals

Amorphi is a roguelike in which the player controls a not-unbloblike creature using simple rules of movement to evade and attack opponents on a hex grid. Creatures have no concept of hitpoints and effectively capture opponents similarly to chess. Creatures gradually expand their range of motion as they advance through levels. The idea provides plenty of design challenges, which I hope to expand on in the future:

  • Visualizing available moves: How can we show what moves are available to both the player and opponents?
  • Differentiating creatures: Do color and shape distinguish creature types at a glance? What about texture?
  • Differentiating opponents: How can we distinguish friend from foe? Use of color might conflict with the first point.
  • Line-of-sight: With one strike to capture the player, is LOS appropriate? Would casual players understand it? Should we target casual players at all?

Early on, I wanted to answer questions about what the game would/could look like according to my lack of artistic ability and the possibility of running the game on mobile platforms. If I’m limited in what aspects of the game I can visualize, the gameplay is limited as well for many potential players. In particular, I wanted to see whether line-of-sight made sense and whether it could exist with other visual cues such as move highlighting and terrain with limited detail. The following screenshots show early coloring and lighting tests. Since then, the visuals have made great progress, but I want to document the path to where they are now. I considered a few ways to mark unlit regions:

  • Decreased lightness: Probably the obvious way, but we might need more than this.
  • Decreased saturation: I originally thought of this to preserve the tile type, which might be indicated by hue.
  • Different hue: A dark, bluish hue might give the indication of an unlit area, but it means we’re using up an available color.

Ultimately it comes down to having a few vague ideas like this, then using prototyping tools to adjust parameters on the fly to get enough feedback to answer these design questions. Unity3D has been great in this regard.

Amorphi is influenced by hexagonal chess and the clever roguelike ChessRogue.