This week was GDC, and wow, what a week it was! I had a chance to demo the latest version of SubLight to a bunch of folks, and nothing beats seeing people play your game in person! If you want to check that version out, it’s currently available for download here.
Scanning a planet for settlement
No planets here!
Trails now show where you’ve been
More variety among star systems, including black holes and supergiants
Upon settling a system, you get a score based on the planet you chose
This release of SubLight includes new features, fixes for bugs, and the beginnings of a new gamemode: sandbox. While I’m driven to create a fleshed out narrative for SubLight, I also want it to be repayable, and more importantly, playable throughout development. As a fan of sandbox games, I love the challenges that come with making a sandbox game. To start, I added some features inspired by Seedship, a great game that you should totally check out and support the creator of on Patreon. This game has always been on the back of my mind as I’ve created SubLight, and anyone that’s played it will see the resemblance. However, I’d love to expand on the core experience of this game, adding visuals, more interactive narratives, and strategy for how the player explores the galaxy.
Hunting for Planets
The biggest addition to the latest SubLight build is the new, core gameplay loop. You’re now searching for a habitable planet to settle on. Every time you move to a new system, there’s a chance of finding a planet to scan. Some planets can be fully scanned, while others need a surface probe sent down to complete the scan. You only start with 10 surface probes, so you have to use them wisely. Some planets will be too difficult to scan completely, even with a surface probe. If this happens, you’ll see NOT SCANNABLE appear in the system readout. Currently, there’s no way to find out what that is without settling the planet, but in future versions I’m going to add a way to upgrade your orbital and surface scanners to find out what these values are.
Check out the video below for more on what this looks like!
Trails
As you explore, a trail is left behind to show where you’ve been. It ends up making some fun looking constellations, and has inspired me to work on showing other ark’s trails in a future update. It could provide an intriguing path for players to follow and investigate.
SubLight Original Soundtrack
Our composer, Ian Earle, has done an awesome job with the latest track for SubLight, check it out!
Trailer Incoming
I spent some time last week on a trailer, I’m really excited to share it with all of you! The visuals are all done, and now I’ve passed it off to Ian so he can do his music magic. More on that in a future post!
Creating an interesting narrative for SubLight, one that takes place over many millennia, has a unique challenge: who is the player, and how do they live so long? Some games, like the Civilization series, simply cast the player as some immortal ruler. That’s fine for Civilization, where the story of the game emerges from the player’s actions, but I wanted a more hand crafted narrative for SubLight. I came up with three main options, all of which had their benefits and drawbacks.
The player is the will of the people
Leviathan, 1651
The concept of the player as a faceless representative for their ark was my first idea. This solved the problem of why the player never seems to die: they’re simply the next incarnation of whoever is running the ark. Ultimately, this created more problems than it solved. For example, how do you have character development between different societies across thousands of years? While I don’t think the problem is unsolvable, I’d actually love to make a game about that, I think it was outside the scope of SubLight’s narrative goals.
The player is cryogenically frozen
2001: A Space Odyssey, 1968
Another solution I considered was adding consistent and safe cryogenic freezing to the SubLight universe. With the ability to sleep away their voyage between stars, we could explain how you keep running into the same people over and over again. Unfortunately, this would destroy a huge chunk of SubLight’s uniqueness as a game about generation ships. If we’re going to add cryogenic freezing, we might as well add faster than light travel. This was not acceptable, and additionally, I wanted various encounters that dealt with the dangers of cryogenic freezing, rather than using it as a narrative crutch.
The player is an artificial intelligence
Alien, 1979
Early on I dismissed the idea of the player being an artificial intelligence. I figured SubLight’s universe would consist of near future tech, and intelligent AIs seemed a little too out there for my taste. However, the idea grew on me more and more, especially when I considered how fun it would be to “upgrade” your AI with the ability to use empathy, aggression, and deception in conversations with other arks. Additionally, the player would have to balance the goals of their computer AI with the needs of the population they’re protecting. That dichotomy could lead to really interesting stories and tough decisions for the player to make. For example, do they save a distressed probe with a lonely AI, but risk their population in the process? How will they fend off mutiny when they make poor decisions? Making the player an AI added new problems, but they were interesting problems, ones that would add depth to the narrative.
Who is human, and who is AI?
Now that I resolved to have AIs take control of interstellar arks in SubLight, I needed a way to distinguish them from the humans of SubLight’s universe. The avatars in SubLight are currently works in progress, but I wanted something that was “good enough” to get the point across. I decided to use silhouettes for humans and abstract geometric designs for AI.
I made these avatars in just a few minutes, but they’re enough to use while prototyping encounters. I’m excited to work more on the AI avatars, I think there’s a lot you can convey through shapes alone, especially when taking advantage of pareidolia. There can be emotional depth to certain shapes, like the friendly roundness of circles versus the hostile edges of triangles and chevrons.
For fun, I also added a very computer-y background to the AI, with scrolling text. It’s visually noisy at the moment, so I’ll have to play around with blurring and contrast to make it more subtle.
For those curious about conversations in SubLight, you can check out an example of one below.
Not sure if YouTube has any plans to process a 1080p version of that video, so I’ll have to warn you that the text is much clearer on an actual build.
This encounter will replace the silly informal one in the last build. I wanted to really drive home the fact that the player is an AI, so I put them through a diagnostic check answering arithmetic and ethical questions. I also took this opportunity to give the player a preview of the abilities they’ll unlock when adding empathy, aggression, and deception modules to their AI. These upgrades allow them to add emotion to their responses, unlocking new branches in the narrative.
I spent this week responding to feedback from the previous build. The biggest change is the removal of the transit lockout. As cool as it was, and as hard as it was to say goodbye to it, I believe cutting it was the right choice. It broke up the flow of gameplay far too much. Instead I’ve added a more subtle red ring that spins as you travel.
I also added lines to show where you’ve already traveled. It’s a small thing, but I think it already adds a lot of useful context to the navigation area.
A video of the transit history in action.
New options have been added to the preferences menu, including a way to increase the size of interface elements. This will be particularly useful for folks with 1920×1080 monitors, which are particularly common but didn’t show conversation text clearly.
In addition to all this I spent time combing through and fixing a lot of little bugs and off-by-one-frame issues. I really dislike seeing weird popping or other graphical glitches in games, it shows a certain lack of polish.
Next week will be spent adding in the initial encounters for the main story, as well as a new resource: metallics. Metallics will be used for repairing your ship, though likely not until a future update. If I have time I’d like to add the ability to turn on a resource map, that lets you see what are good systems to pick up resources at.
I’ve put together a build of SubLight this week! It’s very rudimentary, but it shows off the basic systems in the game.
I pulled a Hitchcock and introduce the game myself during the initial encounter, proving the speed of light is an impassible boundary, but the 4th wall is not.
This will be replaced with a more appropriate introduction tutorial when I have time to write one.
The temporary interfaces show important stats required to play, these will obviously be replaced once gameplay is cemented.
The temporary interfaces are visible at the top of the screenshot
Right now the goal is to travel to Cygnus X-1, a black hole several thousand lightyears away. You can adjust your velocity and your rationing, as well as plot your course among systems. Your population will increase or decrease based on the rationing you choose — make sure you have enough to operate the ship, but not too many to overtax your life support!
I haven’t played with the difficulty too much, and would love feedback on it. This is what it looks like when you reach Cygnus X-1
I also added some additional options to the Main Menu, including links to SubLight’s blog, twitter, and discord. Feel free to join the discord and let me know your feedback, or submit it here.
For fun, here’s a picture of what happens when I bugged out the game by setting the ark’s velocity past the speed of light. Note: I don’t plan to have faster than light travel in SubLight, that goes against the name of the game!
You’ll notice the velocity is “NaN”, or “Not a Number”, an appropriate value for faster than light travel! The ships chronometer also rolled around to the minimum value for a 64 bit integer.
Having completed SubLight’s navigation system, I thought I’d take a moment and reflect on how I created its visual language. Most importantly…
How did the design of SubLight’s interface go from this,
To an implementation like this?
The Prototype
I started off with a top-down view for navigation in SubLight’s prototype.
It was a raw, ugly prototype. What I disliked the most though was the vantage point. I wanted SubLight to have an air of realism, believability. I knew I’d have to find something better than the typical bird’s eye view.
Finding an Aesthetic
I created design pillars for my interface, and since SubLight is so interface heavy, these extended to be pillars for most of the game’s interactions.
Diegetic
All interfaces should exist in the world of SubLight. There shouldn’t be a 4th wall, the player should be reaching in and touching the actual interfaces of their ark when they play SubLight
Avoid Visual Noise
If anything can be tucked away behind another menu, it should be. If an icon can be minimized or hidden, it should be. Only data relevant to the user at that very moment should be shown.
Juicy
It should feel rewarding to explore the interface, open drop-downs, and highlight items. Attractive animations should take the place of anything that would normally be instantaneous.
While SubLight is not a VR or AR title, my time working in those fields has influenced my design philosophy. I wanted a diegetic interface, one that exists in the world and not just for the user playing the game. This was doubly important since most of the action in the game would be presented through the interface alone. Avoiding a game that feels like it’s “all menus” while making a game that is “all menus” was the goal.
The idea for presenting SubLight’s gameplay crystalized in two simple sketches.
I wanted to create a “holographic pool” that would project the navigation view. Initially, the computer consoles on the pool’s circumference would serve as additional interfaces for SubLight, such as ark management, main menu, settings, and so on. Ultimately, I decided to use the central holographic pool for all interactions.
A high contrast holographic foreground and dim background would be essential. I created a proof of concept with Blender and Photoshop, something basic to see how it would feel.
This immediately felt promising.
As a fan of typography, I found it inspiring to pick a font to work around. I knew I wanted a lot of circles and roundness to my interface, so I chose Avenir Next. I was also drawn by the many attractive weights it was available in.
Creating a User Experience (UX)
Using Adobe XD, a tool new to me, I created the UX for all playable aspects of the game I could think of. This required a few weeks of iteration, but it was worth it to have a robust set of designs.
Samples from SubLight’s 160+ page UX document
I added these designs to my example scene in blender, and they still felt right with the ark’s control room in the background.
While the main menu was low priority, working on it first let me experiment with getting a feel for this unique interface.
Implementing dialogs was a great example of how various interfaces would be “dimmed” to focus something in the foreground.
Scale Carefully
The navigation view took several months, mostly iterating on controls and how zooming between various levels of detail would work. I knew early on I wanted to keep a realistic scale for SubLight’s galaxy, which was to be a stylized version of our own Milky Way. I figured zooming smoothly like Google Maps, with one level of detail slowly transforming into another, would feel good. I was wrong, very wrong.
It’s one thing to say space is big… it’s quite another to try and show it all. Zooming out from local star systems to the local cluster of galaxies is extremely tedious, there’s simply no great way to preserve the feeling of scale while doing this. I tried making the speed at which you zoom change over time, but that didn’t feel right either. Even defining various “steps” that the level of zoom would drift to when zooming stopped felt wrong. These all seemed to take away control of the zooming from the player.
Turns out the simplest solution was the best. I defined several levels of zoom the navigation view looked good at, and immediately zoomed the player to it when they scrolled up or down. The player now felt like they were scrolling between levels of zoom, instead of having control taken away from them while zooming. In the future I’d like to replace the level of zoom above local systems with another view showing faraway systems of interest, but for now this is very functional.
Transit Between Systems
The most challenging aspect of the navigation view was the many selection and highlight states, some of which I had to cut and save for a future pass at the navigation view. Breaking the views up into discrete states helped manage complexity. I could then animate these elements based on their selection, highlighting, visitation, range, and classification.
Once selected, a system can be clicked on again to initiate a transit to that system. Normally your travels will be interrupted by unique events, which you’ll interact with in a separate communications view. For now, here’s a video of the transit animation.
I think this transit portion of the game will evolve over time as more detail is added to the ark’s control room. I’d love to make the holographic display flicker in and out, the windows dust up, and have blurs of crew members swirl by as the centuries are ticked off by the ship’s chronometer.
What’s Next?
The initial prototype had a functional encounter system, with support for branching dialogues and so on. My goal is to create that system in the new aesthetic I developed for the navigation view. Here’s some samples from the UX document I’ll be working from.
There’s many more design and gameplay decisions I made over the last six months of development I’d love to talk about, but those will have to wait for future blog posts!
Strange Star 