Moonlit Sonata
When: 2022 - Present
Status: On Hold
Pics
About
Sent to a distant moon to repair a base's facilities, you must utilize the terminals in your observation deck to conduct research and complete tasks, all while ensuring the outmoded malfunctional androids don't cause your demise...
Moonlit Sonata is probably my main passion project. A game I've continued to come back to and work on year after year. The core gameplay gimmick is that it only supports keyboard input. You have a monitor with a terminal on it, and several other monitors you can control with said terminal. The player has to read through "man pages" and use "--help" on various commands to learn how to complete their tasks, how to control their interfaces, as well as how to defend theirself.
A bit of story: These robots aren't evil. Many years prior, a passing cruise ship ejected them, and they crash landed on this moon. The damage to their processors caused them to lose many of their critical thinking skills. They now roam the moon for all eternity, chasing the light of the sun for solar energy to keep themselves alive. With the abandoned lunar base being brought back online, they flock there in hopes of being able to find work again, and be loved again. But when their power runs low, they get desperate and make rash decisions, lashing out on mankind for the way they've been treated.
The development of this project has a fairly long history. Originally, I considered making it use realtime graphics in Unity's HDRP, but I was unable to get the results I wanted. So I started learning how to render things in Blender, a skill which I had no experience in prior to this project. I learned how to use Blender to render out a scene and its depth map separately, and designed a shader that would let me have a model be obstructed by scenery in the pre-rendered scene. However, I wanted much more detailed shading on the characters too, and so I learned how to make blender render out the characters separately from the scene. The result was a texture for the scene, and two images for the characters: Their color, and their indirect lighting influence map. With these three images, I made a shader that would allow me to combine any number of characters onto the scene, each rendered as their own files. The benefit of this was being able to render each character only once, rather than needing to render out every single combination of character which would have had a much lengthier iteration time. However, around when I started noticing flaws in my rendering system, I decided on a different style for my renders. I wanted to make them lower resolution, with a much more limited color palette applied in post with Error Diffusion Dithering. The style looked so much nicer, and it made the render times short enough that I can easily render every combination of character in a scene to a separate texture file without very long render times, all automated via python scripting in Blender.
I wanted more for the terminal in game, however. My fake terminal was fine, but it was rather tricky to make any sort of ascii application with it, with proper monospace character alignment and state management. So I looked to a framework called "sadconsole". Switching over to Monogame would allow me to use sadconsole for my game's terminal, and because my game is mainly pre-rendered graphics anyways, it would actually be easier to draw those scenes in Monogame than in Unity, which tends to make directly drawing textures a bit of a pain. I already have experience working with 3D rendering in Monogame, so rendering the monitors in 3D as I was doing in Unity would not be very hard.
I have lots of plans for this game. I basically have most of the game planned out. Hopefully, some day, I will be able to finish it!