The game uses the basic conception of classic 3D-Adventure games such as Myst and The Witness as a jumping off point, to explore the concepts of navigation, and how we understand space.
The game is made in my custom engine written in the JAI Programming Language. It has been a joy to work in and would highly recommend others give it a try when it is out of closed beta.
The only rendering backend right now uses DirectX12, but I have been writing the renderer under the assumption that I will support multiple backends. Thus, the game-specific stuff is all mostly platform agnostic, so adding other backends should not involve
On the gameplay specific front. I've implemented some the so-called "Walk-Manifold" algorithm described here for player movement. This algorithm is very good because it provides guarantees about where the player can and can't go that you don't get from most other methods. It also helpfully provides ways to visualize the exact places where the player can move, which helps with iteration times, as well as cutting down on content bugs. The following gif is a demonstration of that visualization in the editor. You can see that as I move around the walkable surfaces and collision geometry, you can see the exact, real-time solution of where the player can and cannot go, and whether they can get somewhere from somewhere else. My implementation of the algorithm is availble here, on github.
The game is not trying to look good yet and is very much programmer art at this point. I want to spend more time fleshing out the game before beginning any serious art development because it will allow me to better fit the art to the constraints of the game. That being said, I have put some effort into streamlining the art pipeline so that iteration can be done quickly and easily. The heavy lifting on this front is done by the engine/editor supporting hot-loading of all game assets, as well as a custom blender exporter I wrote which makes the change blender to seeing the change in engine just one click.
The Editor for the game is part of the same executable as the game. Having a unified process cuts down on complexity a great deal, and makes iteration very quick, as I can easily go between gameplay and editor modes with a single key. This allows me to quickly test things out, see what needs to be changed, make the change and test the change all in the matter of a few seconds, as opposed to some other schemes which are more like 10 to 15 seconds. Those few seconds make a huge difference when multiplied over the hundreds or even thousands of iterations that are needed for a high quality product.
Again on the theme of iteration speed, I have implemented several editor features which have played a huge part in being able to design quickly. One such thing is an implentation of kriging based terrain editing. Essentially, kriging is a method of interpolation thats used mainly in geostatistics, that allows you to specify points, values at those points, and roughly how you expect those values to change and it allows you to estimate the values at positions other than the specified points. This allows me to have the terrain control points behave identically to all the other control points in the engine. This allows me to, for example, select a hill, and all the entities on that hill, rotate it and move it around, undo changes, and it all just works. This is in contrast to techniques such as heightmap painting where editing is a completely separate process from editing everything else, and rotating or translating terrain features is a pain.
