Welcome, dear reader, to our latest update where we’ll cover our work in the thrillingly named Milestone 5! We’ll be discussing and showcasing our progress, as well as some of our upcoming plans for the even more thrillingly-named Milestone 6 and the overall trajectory of the project. Grab a consumable goodie, an adorable animal, or anything else that will help you settle in, and let’s fly through our progress together.

As you go through our update here, remember that our game is constantly being pulled apart while we work on different pieces. This isn’t an E3 demo or something finished that we want players to have their hands on. Truly, this is what the game looks like on a given day, and this is what real development looks like. Prepare to peer into the house and see how undecorated the walls are.

Adventure Time

One of the first things that was started during development was the story, and one of the last things we complete will be the actual implementation of our story. This is because the story is the impetus for anything we do, the parental bird kicking its child out of the nest and forcing it to fly. The result is actually something that has to be learned by the metaphorical bird actually seeing what works and how to stay aloft.

While our story has been “done” for a long time, it’s also informed by the work we do: what pieces of gameplay are most interesting, what characters develop into undiscovered roles, and what bits of writing have unexpected hooks that we want to use for even more storytelling. Our creations talk to us once we give them voices. Mallory and I have an ancient (at this point) document we worked on together last summer, affixing gameplay decisions to story components, deciding what would be the most compelling way for a player to experience different parts of the story.

This milestone, along with the last, we have been actually putting more and more of the meat on the bones in game. We now go back and look at that document, sometimes laughing at what we thought would work “on paper” compared to the much better and much more focused solutions and creations we’re working with now. Since we have parts of the game we’re able to play through and actually discover what’s fun, we can weave those elements in better. In some cases, our original thoughts did stick after putting components in, with payoff moments having the payoff we imagined. In other cases, since we found experiences that were really enjoyable, now that we can play them, we started using them more.

As an example, in one alien’s storyline, there is a unique interaction with a sun. Since we put it together and it felt fun, we wound up using it for another alien’s storyline, albeit for completely different purposes. One character’s storyline involved a unique journey to find where they were hiding. The process for finding the hiding thing was more interesting than expected, so we are trying to make even more things hiding in a similar vein for the player to uncover.

All that to say, we continued our progress implementing our playable alien storylines. We were not able to get all of them completely integrated (more on that later), but we have winnowed down the playable mechanics that will be used for all of our alien quests through the process of putting more in game. We’ve made most of the unique art set pieces we’ll use for those moments even if we haven’t finished the writing, but the writing is the easiest part to adapt.

We were able to implement five aliens’ quest placements this milestone. We only have three more to do, and then we’ll be able to go back and polish anything that isn’t working. Without spoiling any of our story for you, much of our work was focused on getting in unique placements that have special interactions. For example, the sun mentioned above. Once we have something working a certain way for one alien, using it more is the easy part. One object that produces a report from planet surface might be hard if we hadn’t built that, but now that we have, placing 20 more is easy.

In addition to interactive elements, there are art set-pieces that we are using to tell stories in unique star systems or planets. We finished all of our ones for truespace this milestone and have a system for implementing additional, unique ones or variants as needed.

HyperSpaced Out

Last milestone, we discussed our HyperSpace mechanics and even showed some concept art, but this milestone we also were able to implement a lot of it in game. It’s rare when concept art survives all the way into an in-engine implementation, but the result is almost startlingly like what we envisioned!

Beyond just getting our visual proof of concept in, we also proved the workflow for how it gets created. We use Tiled to create our gameplay in HyperSpace in 2D, and then we use an automated process to convert the shapes on the Starmap into the different things you see here like the red walls.

Some elements are so visually distinct from the collision shapes which we use for gameplay that we’ll be laying them out by hand on top of the imported Starmap, giving us more control over how they display.

From a design and art standpoint, we’ve proven out a nice quadrant of our Starmap! One of the things we’ll be doing in the coming milestones is actually filling out and polishing the rest. As we create setups that work, we’ll reuse them throughout HyperSpace, creating areas of high and low mechanic density.

Play, Pause, Rewind

One of our vague questions we had when we started our work on Children of Infinity, which is awfully hard to answer without having something more to measure, is “how much do we want players to re-play the game?” There are all kinds of things we can do to motivate such things either intentionally or unintentionally, all the way on the spectrum from rewarding players for replaying the game to simply just making sure there’s something fun there for those who do. At this point, we feel pretty confident that players who are interested in the story alone will get a lot of mileage out of replaying the game.

A lot of the various paths and choices in how you relate to aliens have become much more fleshed out. One of the advantages of our type of storytelling is that, while we do have a terminal point for the story, each alien’s own story is much more like a miniseries with its own path. We’ve been seeing a lot of that come to life now, and we feel pretty confident that we’d like to encourage players to re-play the game. We’re not planning anything specific to that end like a “new game plus” since we don’t have scope for that, but we’re also pretty sure players will have a handful of new story pieces to discover on subsequent playthroughs.

Speaking of early plans, as part of the adventure mode, we had envisioned two new core experiences we wanted as part of the story: gas giant gameplay and interior gameplay with Floyd. We were concerned about the cost and complexity of adding them, so we made them goals which we met for our Kickstarter campaign. We wanted to show you a little bit of what was involved and tell you more about them now that both the design and art had been fleshed out.

It’s a Gas

In The Ur-Quan Masters, gas giants were neat elements the player could find, but they were also effectively non-interactive dressing. So what if players could do something with them? One of the principles of our game is, when possible, to give players options about what gameplay they enjoy so they can still succeed if they don’t want to pick fights in Melee or aren’t as interested in scanning and exploring on Planetside for resources. Gas giant gameplay is intended to fill an optional niche that mashes up the controls and ships of Melee with the gameplay of Planetside. Players will be able to scan gas giants like any other planet, but when they go down to land, instead of using the lander, they will have their roster of Melee ships.

If you think Planetside can be dangerous, gas giants are on a whole other level. They also offer a slightly different experience because threats escalate over time, so it’s up to the player to decide how much risk they want versus the rewards. Certain ships which might be weaker in ship combat may shine more here, and even having multiple players can be a huge advantage.

Deploying to a gas giant lets you pilot one of your fleet ships around the planet, blasting targets which will drop minerals that you can scoop up. However, the “landing zone” of a gas giant is something like the eye of a storm—it’s safe, but only for just a bit. After some period of time, the eye starts to close and being there becomes more and more hazardous, eventually getting so bad that the player has to leave. Right now, we actually force the player out after the time ends, but we would like to toy with letting players stay well into the danger zone, tempting fate if they think they’re up to the challenge (or if their Yehat Terminator’s shield will hold out just a moment longer to get that last reward).

Floydian Slip

The other story experience we have been able to build thanks to our backers is what we call Interiors, but what our game will probably call something else. For most backers following along, this part is best known as our “Floyd experience.” Unlike our gas giant gameplay, which provides an optional experience for gathering resources, we’ve included a certain amount of Interior exploration as a requirement to complete the story. While we still have some reports from planet surface, the Floyd experience is meant to represent the “mission” actually taking place for some of those reports.

This milestone, we built many of our Floyd levels but also locked down their mechanics and art approach. While the game dabbles in many abstractions, like ships being ridiculously large next to a planet, we turned Floyd’s experience into an abstraction of what he sees and experiences. Instead of an actual camera pointed at a tunnel, Floyd’s sensors reveal the world in a way that Floyd, a simple robot, understands.

Partly as a nod to our roots in another era and partly as a way for players to focus more on the experience of Floyd’s senses than the human-relatable environs, we adopted something partway between pure pixel art and old-school vector graphics to represent the many hazards which lurk in the strange structures Floyd will be exploring.

We last spoke about Floyd in our Milestone 3 update, and the core conceit hasn’t changed, but we have honed the mechanics available to focus what Floyd will be doing. He’ll largely be encountering a lot of hostile hazards or ancient automatons, but not everything that lurks within is out to defeat Floyd.

We leave a lot of what’s actually going on to the player’s imagination, but Floyd levels are part of the main story path because certain things in the game are too small to be handled with spaceships or conventional weaponry, and perhaps some things the player finds will be sleeping giants waiting to awaken with just a few connecting wires here or there.

While it’s fun to see the more finished stuff, our workflow for producing Floyd’s levels is interesting too! We already mentioned that we’re using Tiled to do the level layout, but we also have a completely 2D workflow for producing our Floyd level art! Put very simply, our artist can take a snapshot of the level, which has been built against a grid, and then lay down a series of art pieces which we render from an orthographic perspective. It’s extremely fast and lets our single designer and single artist make an entire suite of levels on their own, maintaining our goal of being as lean and mean as possible.

Example image of our Floyd level art, authored as a flat image.

Coordinated Fire

We spoke in depth in our last update on our work in Multiplayer for the adventure mode. Apart from a lot of what we’ll call small decisions left to make, the bones of that have remained the same. We did continue to prove a few additional pieces of Multiplayer functionality, largely on the technical side, which apply both to Adventure and standalone Super-Melee modes. Most of them relate to user interface behaviors, which we’ll cover later, but we have a few new bits of our multiplayer design and tech.

First up, as we alluded to in our previous update, we only allow one comms screen to occur at once. We would need a very thoroughly designed system to handle the special-case scripting in our comms screens to navigate the flow if two players were able to hold two simultaneous conversations, with the myriad of possibly mutually-exclusive outcomes. Beyond the technical challenges, we also don’t really want that for design reasons! Players are able to choose their own adventure, but the Captain is still who they are, and their allies are part of their mission. What we do want is to let multiple players experience the story.

If an additional player tries to start a conversation while one is in play, at a minimum they get a message saying they need to wait. Certain situations can be backed out of, so we may let players flee from an optional conversation in case they don’t want to be stuck there. However, for players who are just interested in conversing, we implemented a system which lets players “listen in” on a conversation that another player has started, observing the conversation while not participating in it. Technically, that player is put into a proxy mode, where they cannot drive the conversation but still get all the same signals from the game. That means that players watching can read at their own pace and in their own language, letting them scrub back and forth just as if they were playing alone, but with the choices out of their hands. Right now you can only enter this mode by initiating the same conversation in physical space, but we’d like to let co-op players listen in from anywhere.

We also finalized our rules for defeat and return to the Starbase in co-op. Only the primary player, The Captain, can decide a mission is over and return to the Starbase to offload minerals and more. This simplifies a lot of design and technical work, and also further conveys who the second player is: a collaborator and subordinate under The Captain. This is one of those things that will need a lot of play-testing, but it is working well as far as we can test, which, truth be told, is not very far. Turns out we need a lot more people and enough game to truly test multiplayer! We’re looking forward to it.

Last and certainly not least, as of this milestone we have made many, many flavors of our PC builds and verified that they work together for network play! Count along with me, because as of now we have builds for Windows, Linux, and Mac which integrate with the Steam SDK, builds for Windows and Mac which integrate with the GOG SDK, and standalone (we call them ‘vanilla’) builds which require no SDK integration for Windows, Linux, and Mac. Apart from using them for our own testing and development, GOG’s SDK doesn’t support Linux, so we’ll be supplying the standalone one for Linux GOG players there. That’s a lot of builds! And not only can we produce them all and prove they work, they work across platforms and operating systems, while relying on the native SDK for the best user experience (e.g. friends can join each other through the Steam overlay or GOG Galaxy client). We conceived of it but hadn’t proved it across our platforms until this milestone, and it’s important for any form of online multiplayer we do.

People ask about console cross-play often, and the answer is the same: we’ll do it if first parties (i.e. Nintendo, Sony, Microsoft) allow us, but it’s ultimately their decision and not ours. We are still determining the scope of what we can support on consoles when it comes to multiplayer, and we’ll share what we have when we have more clarity.

Ship’s Ahoy!

Last milestone we discussed some of the changes to the overall adventure flow regarding how we’re handling defeat. One key area where we had made another big change for this milestone was in how you acquire and allocate your fleet ships. In The Ur-Quan Masters, building a ship always cost you resources, but in Children of Infinity, ships are always restored when you return to the starbase. This is in line with our goal of having losing not make you lose more and more when you’re struggling at the game, since you can always get your ships back. It also encouraged our goal of having players experiment with different ships in the adventure mode beyond finding one ship (or upgrading their flagship completely) which solved all problems.

A few other design conceits around this were that we only allowed you one of any given type of ship in your fleet, and part of the player’s growth was going to be in unlocking more fleet ship slots. This served a couple purposes. Firstly, when we had prototyped and planned for fleet ship upgrades, this helped control the power curve, since one upgraded ship was pretty good, but getting multiples of it became ridiculous. Secondly, it helped maintain the fiction that the “upgrades” were tied to the captain or shipyard, which would explain why even when you lost a ship, it would come back with the upgrades. Lastly, it limits the power of single ships. If we wanted to give the player a Chmmr Avatar, for example, we would like to ensure players didn’t wind up with 8 of them, which would be quite strong.

A twist on this approach which we had implemented at one point, long ago, and just brought back is the “point buy” system from standalone Super-Melee, eliminating the limit on fleet ship slots. Players will have an upgradeable fleet ship point limit, and they’re allowed to arrange any combination of ships as long as they don’t go over the limit. Stronger ships will cost more, and weaker ships can cost less. With a simple point value, we can express a very wide range of strengths for ships. A single Chmmr Avatar is pretty good, but what about an armada of 10 Shofixti Scouts!?

By reusing the same mechanism from Super-Melee, we think players will have another vector of experimentation and strategies they could try, and weaker ships have an opportunity to be better by letting players have more of them. Upgrading fleet ships was still a fun idea, but this is working even better while fulfilling a similar purpose. It also gives us the opportunity to let players have extremely powerful ships if we want. Getting a Chmmr Avatar earlier in the game won’t break it, because it can be so costly that a player might prefer to avoid it.

In other ship news, as of this milestone, we have received ship designs from all of our backers who are submitting ship designs! While some of them were in just before the bell, we were able to build a few of the earlier submissions’ artwork, and their designs are mostly in and working. Let’s look at a couple of the ones we were able to build during this milestone.

For all the cat-lovers out there, here we have what’s codenamed the Prowler, a feline ship that recreates the chaos of a cat chasing a laser pointer across the screen. Its WSK-R missiles will devastate ships at close range. At a distance, it has a very risky maneuver it can utilize by engaging the Multispatial Energy-Object Warp, dashing a great range but disabling its thrusters briefly afterward. Dashing through an enemy causes a bit of damage, but the real strength comes from landing a dash on its Purrball, a special object it can drop in space. The Purrball normally has very limited velocity and is simple to avoid, but as the Prowler dashes into it, it can gain velocity and clobber unsuspecting foes.

Blackhole ship and a Yehat Terminator also exploiting its power.

Next up we have what we codenamed the Blackhole. Its special ability revolves around being able to punch a wormhole in space from one point to another. Activating the ability creates one end of the wormhole, and releasing the ability opens the other end. While the ship is initially creating the wormhole, it has some limited ability to maneuver and control where the wormhole appears. Once it’s created, everything goes through the wormhole. Ships and missiles of friends and foe alike can travel between the points, maintaining their orientation and velocity. So far it’s pretty wacky and can create a lot of chaos.

Yet another thing we can make because of the support from our backers are our captains windows! This milestone, we built the system to display them and finished about half of the ones we’re doing, including a mix of old ships and new ones.

We continued our audio work in Melee, adding not just a lot more sounds, but the all-important impact sounds, so we can actualize the booms, buzzing, searing, and fart noises different weapons will produce on impact.

A few other things we won’t be showing here since they aren’t in a very show-worthy state are our first boss battle, which has a complete design and is not easy, as well as a rebuild of our old “starbase defense” prototype that was built on stream many moons ago. We’ll share a few tidbits on these in a later update when they’re a bit more comprehensible, but both Melee twists are used as critical parts of the adventure mode.

UI of the Beholder

Until now, all of the user interface (UI) in our game was built entirely as a learning exercise in our early implementation of connecting Simple to Godot, in service of our Kickstarter video just to demonstrate that our game actually was a game, or just as a good-enough bit of information on the screen to help us play the game, like knowing how much fuel and energy you have during Melee combat.

In the previous milestone, we started pulling apart the UI so we could be unburdened by some of our choices which were not there to serve the actual goal of having a great UI that would make the game more fun. This milestone, we actually started putting some of it back together to meet our requirements for the user experience (UX) before we start applying final art. We call this wireframing, and it has us asking all kinds of questions like:

What buttons and inputs does a user use to navigate?
What design and visual language do we use to help users understand what their UI can do? (e.g. scroll bars, rules for pressing a ‘go back’ button, etc.)
What is the most important information for players to access, and how do we logically present it so players can find what they’re looking for?
How do we handle menus where multiple players may be allowed to control them?

There are a lot of questions, and before we start putting art on it, we want to figure out our design language and rules for UI. It sounds like a no brainer, but we want players to be able to figure our game’s UI out! We also want to provide a pleasurable experience when they spend time in menus, and our game has a lot of UI and menus. We also have a unique challenge of supporting multiple players, requiring us to really think through our rules and how we communicate with players about what’s going on.

How does a player know what pressing the “accept” button on their keyboard/controller will do at any given time when there may be several buttons on screen? That UI concept is called focus. This milestone, we solved one of our big technical challenges for any multiplayer UI, which is supporting multiple, focused elements on screen at once, which Godot does not natively support. Simply put, this means two players can use separate menus at the same time when playing on the same device. One player might be trading while another is picking a ship in Melee during the adventure. Or in standalone Super-Melee, both players will be able to select a ship at the same time before a battle.

Pause menu wireframe demonstrated in single player and split-screen.

One extra tricky bit to multiplayer UI comes from menus that multiple players could interact with. If a menu represents the ships a player could select, for example, and players are playing cooperatively and sharing a pool of fleet ships, we need to ensure any changes one player makes are reflected for other players looking at the same menu. If one player takes a ship for themselves, the other players’ menu options could change on them under their feet. It’s an extra challenge to make a live menu that updates while the player is navigating it, while also communicating with players what’s going on so they understand it.

There are so many nuances to just how focus works and nice touches which we might notice as developers but players might even be unaware of! For example, when you pick a menu option like “Settings” and wind up in a submenu, then you back up to the previous menu, you want the cursor to remember where it was, on “Settings”. Or, in a scrolling/list menu which is clearly in some sort of row, column, or grid, we want the focus to wrap around the edges, so you can instantly go from the bottom of the list back up to the top. As part of authoring our own focus system which is multiplayer-ready, we gain the advantage of being able to put these nice touches in.

One important piece we don’t have yet both for focusing and other menu actions is negative feedback, which is letting the player know the thing they wanted to do is not possible. For example, if the player tries to press left but cannot go left, an animation and sound will help reinforce the player that they can’t do it. These things seem like no-brainers, but you’d be surprised how many UIs wind up missing them! The more a player can predict the outcome of their actions, the more secure they’ll feel when using a menu. Players may not be conscious of it–who sits there thinking “wow this UI makes me feel so great”?—but the difference between a UI that confuses players and one that feels more like an extension of their intent is huge.

While we put a lot of thought and time into solving these details of focus and communication, we also needed to wireframe the various game menus the player would be navigating. We have some rules and a proof of concept we like for one of the most important menus, the simply named pause menu, where the player will be checking in with everything from their inventory and starmap to doing important functions like changing settings and quitting the game. There are still some organizational questions that we might change our minds on as we playtest more, but if we can get the seemingly humble pause menu right, we can apply those rules to the rest of our menus. Just deciding the fantasy for the pause menu, like what words will make sense while also feeling like they’re part of the universe, is no trivial task! And if players can’t use the pause menu or don’t have fun doing it, they will have a lot of difficulty enjoying the other parts.

Below is some actual chicken scratch which represents some conceptual storyboarding for what kinds of widgets and story we want for pause menu and starbase menus. For the starbase, do we want to represent it like a cross-section graphic where you pick different sections of the ship to visit, or is it better to have it be abstract? In case you can’t tell, I (Dan) love UI, and I especially love polish elements for when we get to them. Thinking about how we might animate some of our keystone menus so they’re extra snazzy is something already on my mind.

Beyond the interactive parts, all of the backdrop pieces—which we call our UI frames—were also rebuilt to have low memory footprints and be made in a system which lets us add more, if needed, and reconfigure the pieces we have more easily. The one we built for our Kickstarter video was one of the most monolithic, unoptimized pieces of spaghetti code ever, but it served its purpose. Our new version is as modular as the visuals look, letting us create additional states, animations, and transitions as needed while also having a much lower memory footprint.

Bay doors “rig” in engine accomplishing the same thing but with engine animation instead of an expensive frame sequence.

Last but not least, we solved a classic challenge for game UIs in general, which is having text which can resize itself based on the space available for it. We always want to make text the best size possible for layouts, which usually means making it as large and readable as possible, but depending on things like localization or even playing in split-screen, we need a way to dynamically resize text. I still remember one of my first localization jobs making loading screens for Disney’s Extreme Skate Adventure, awed by the single word length of the level title “The Elephant Graveyard” in German and how we had to make it fit in a limited space.

Specs and Balances

We discussed our many builds above, and, for our PC players, we also started honing in on some minimum specs so we could get a sense of what devices would run the game and what we and players could expect. Here’s an example of the “lowest spec” device I have which still runs the game perfectly well:

Intel i7-4770k
Nvidia Geforce 1060 3GB
16GB system RAM
SATA 6.0GB/s SSD

The hardware in that machine is all about a decade old, so we feel pretty confident that almost everybody will have a good experience! The only requirement we know of is that the GPU must support Vulkan. I also tested it on an AMD setup with a Ryzen 7 5700U and its RX Vega integrated GPU. It ran even better, with fast load times, but that’s a much newer computer and has an m2 SSD as well. Both devices were tested in Linux and worked just as well as our Windows test setups. As for Mac players, any device with an Apple Silicon device seems to run great, though we have only tested it on M2 and M3 devices so far.

We have not been able to test on a Vulkan-compatible Intel GPU yet, though I successfully ran the game on an ancient Intel GPU which only had OpenGL support, so we can at least verify that some configuration works, but we’re not officially supporting Godot’s compatibility mode for OpenGL.

To get ahead of the curve for minimum specs, which is especially critical on more limited devices like the Switch, we also did a handful of engineering work to support players with less powerful devices. Some rendering techniques are pretty but not always performant, especially with lighting/shadows and post-processing effects like bloom, so we built a system where they can be reconfigured depending on certain platforms. Our target resolution is 1080p, but some devices, like the Switch, have less memory available for large textures, so we also have an automated downscaling process where larger textures can be made into smaller ones without manual effort. The goal is to have good performance on every platform, even if we need to reconfigure what visual pizzazz we use, without having to remake assets by hand.

Last but not least, this milestone saw a ton of performance enhancements for our tool, Simple, which we use all the time to develop gameplay. As our game data grew and grew, the Simple application started to take longer and longer to start up. When I’m debugging things, I often need to close and re-launch the tool, and simply getting it to start up faster shaves cumulative days off of our development cycles, never mind the finger-tapping frustration of waiting for a loading screen when I’ve got work to do!

Backers to the Future

This milestone was our last milestone where we were accepting backer submissions for things like creatures and lander skins for the initial release, and we luckily got plenty of their submissions in under the deadline. Here are some of the amazing things they helped us make! Starting off with some of their creative planetside creatures:

We also implemented our lander skin system and started making a handful of lander skins based on our backers’ designs. Players will be able to collect and apply these skins to the lander through the adventure mode. While the lander doesn’t get that large on screen during planetside gameplay, there are other opportunities when we can show some of the details up close during orbit, landing, take-off, and elsewhere.

We have two more backer-created ships we’ll have done by the next milestone and are excited to show you those soon.

Quite the Production

As we start moving into the home stretch of our project, even more of our job becomes maintaining our production tools: the spreadsheets, task trackers, and notes which we use to know how we’re doing. While you’ll never see one of those spreadsheets in the game (with a few exceptions!), they’re critical tools we use to help us know how to work together. In the words of one of our artists: “I love a good spreadsheet”.

We don’t have a full-time producer, the person who would usually be responsible for this work, but it’s one of my responsibilities. I have spreadsheets tracking assets for aliens, the stage of my communication with different backers, and one which simply tracks every single sound we need for every object in the game. The best ones are spreadsheets which represent game data (like our table of planets and their characteristics), allowing the game, itself, to be the source of truth. It is hard to convey just how gigantic our game is, especially relative to the size of our team, so actually knowing what’s even in the game is not a trivial matter. To simply quote what I said after the last milestone: if it’s not in a spreadsheet, it doesn’t exist.

All of that production overhead isn’t free or cheap, but if we want all of our team members to be working on the right things, it’s truly necessary. There are even different trackers for different disciplines, since the way our musician is working does not match the way our narrative team is working. A very real amount of my time is spent simply making sure people know what needs to be done, and if it sounds like I’m repeating myself, I am, and that’s part of the work too! Everyone needs constant reminders about the requirements, and it is a creative challenge, itself, to get creative people to actually stop creating. The creative urge is usually one to tinker and explore, and we are at the point where our explorations and excursions need to be very purposeful. Everyone must be aware that we are past the point of taking risks. It’s an unusual way for creative people to work.

In similar news, we are a business! It was tax month for us Americans, and that was one more thing we had to spend some time on. Nothing ever comes without a cost or some overhead, and every little thing we manage is one more thing that’s a part of our project scope, even though it doesn’t look like a ship in a game. These are the steps that are required to get things done, and we treat them as such: stepping stones to get us somewhere we want to be. No one likes paperwork (or if they do, I am worried about them), but they’re part of unlocking some important doors on our journey.

Retrospective Gaming

As we did for our last milestone, let’s actually take a look back at all the things we said we’d do and check how we’re doing. This is pulled, verbatim, from what we said in our previous update!

Finish all comms screen art and all creature art and have it integrated in-game: Almost. We had a few late creature submissions from backers which we will handle this coming milestone, and we have three more comms screens taken a long way as paintings but not finalized in-engine. These will be delivered next milestone.
Finish all of our space and Planetside story set-piece art (unique items, reports from planet surface, etc.) and have it integrated: Done. There are a few items we built which haven’t been re-used in every place, and we have a few nice-to-haves we’ll see if we have time for, but we’ve got the foundation done.
The story should be 100% playable and progressible from start of the story to the end, even if there are placeholder elements (e.g. cutscenes) or a guide is required to explain some things: Almost. The story is 100% progressible, most days of the week. As we are still integrating writing (more on that shortly), we sometimes break things during development. As for playing through the whole story, the only part you cannot play right now is the very ending, where there are a few ante-upping moments for the player when they get there.
Alien Auction House and all Floyd levels are integrated and playable: Nope. Alien Auction House took a backseat yet again, since there are no dependencies. We do have all Floyd levels integrated and playable, but some of them are still undergoing significant layout changes. We will likely reduce some of the ones we use to our favorites, since we have more than we need!
Adventure mode will have all of the player’s intended progression in place, including lander upgrades, hyperspace upgrades, fleet ship unlocking, and outfit allotment growth: Done. The only caveat is probably lander upgrades, where there’s a bit more Planetside polish to do to narrow down which ones we want. We actually have too many!
The game should be fully playable in multiplayer in adventure mode, local co-op mode, online super melee, and local super melee: Done. It may not always work great, but it works multiplayer in all modes.
All alien comms writing is complete to a first draft level: Almost. We have some late submissions for writing (more on that shortly) and have extended our writing schedule.
Core menus and their behavior in single/split screen are done, and final art has been started: Half Done. We have nice wireframes for our core menus, but we have not started final art. This will be easier when we have more than our core menus, and we prioritized our Interior art which is significantly more complicated.
Melee has started to get its polish pass, including finalizing camera designs for multiple ships, enemy AI behaviors, boss fight sequencing, and first-pass VFX/SFX for ships: Nope. Apart from SFX, no additional polish has gone into Melee yet. We are still too busy jamming assets in, and Melee is our currently most known area.

Even though we missed some of our targets, the result isn’t bad. Most of the things we missed are low risk because they’re known quantities, and we have already scoped them carefully, mostly having content-lopsidedness (e.g. designs without art, or art without a design). Our deadlines are here to help us see what takes longer than expected and what doesn’t, so we can at least get some measurements.

It is hard to overstate this, but we do not have many hands on deck for our project. If things are getting ignored or pushed off, it’s because we need those hands at different stations. For example, our UI art isn’t started because our UI artist is also doing comms screens and our Interior art, and our UI designs (wireframes) are done to a good point, but not the best point because I’ve been supporting other endeavors. We could try to bring in additional resources to multitask more, but then we would have a significant bottleneck for production. Creating a downpour is much simpler than getting hands free to catch the buckets of water.

Milestone 6: Alpha

We are swiftly approaching our next milestone, which is much shorter, and is going to be known as our alpha (for most groups). Once we hit alpha, we won’t be making any new things or even accepting new things that we wish could be put in. The goal is to be feature complete. The game will be representative of the content and gameplay we have in it and what we have planned, though it can also be riddled with bugs, totally un-tuned sections, and full of placeholders for certain asset types.

To reference a joke from a previous project we worked on when we had to shift some dates around, our alpha is a soft alpha. We laughed at the time because we knew it was there to make someone in accounting happy, but in this case it’s there to hold certain asset pipelines accountable. The rest of our focus will be less on making new things and much more on polishing, which is much slower and will feel like smaller strides (because they are!).

First and foremost are our missing features. The Alien Auction House, one more boss fight, the final suite of Floyd levels, a workable multi-ship Melee camera, and button remapping are some of the biggest ones.

We will also be starting to create our final slew of assets. None of these are new asset types—just more of them. Some of these are going to be coming in later or be “good enough” versions, but that’s okay because we just want to get it all in so we can shift entirely to polishing. The assets we’ll be focusing on getting in are:

Our final three straggler comms screens.
UI elements based on our wireframes.
Audio for additional scenes beyond Melee. Luckily the bulk of the work is Melee, so if we get that right, the other parts are much simpler!
Music. We’ve been a little quiet about music (har har), but we actually have some awesome pieces already. We need to start finalizing how many we are using so we can get to polish passes.
VFX. Several ships have all kinds of placeholder VFX for firing weapons and so on, but we need to get the rest of these in where we’re missing stubs.
Writing. I’ll devote a section below to some of the writing schedule plans, but we’re going to start filling in writing for non-comms screen things like reports from planet surface, item and creature descriptions, and even the game intro and outro. Our story structure and flow will be locked in by alpha.
Final Planetside art pieces. As mentioned above, we got some late submissions for Planetside art for lander skins and creatures from backers, so we’ll be getting those in along with our unique gem planet artwork.

Writing gets a special mention here, since it’s one of the few assets where we have deliberately moved its milestone back by a month. We have an amazing team of writers working with us, but certain circumstances of the world have conspired to make arranging all our schedules difficult. In short, we’ll have the story of the game all in by alpha and be able to move to polish for some of our characters (some are already in polish as of this milestone), but we are going to be taking a small amount of new writing after Alpha to give our writers extra time. Since text is one of the easier things to change late and the story structure is set, we feel comfortable pushing this back by a month.

As we warned our backers, any creations for critters and lander skins we get after this point will not be worked on for our initial release. You wouldn’t want to hold up the release of the game, would you? We’re truly at that point, and we’re playing by those rules, too.

The key isn’t to just stop putting assets in, but to move into a phase where we improve what we have, not add more things. There is a long, long list of things we could do but won’t be doing, and Alpha is where we draw the line in the sand and say “no more” to many things. Writing will be one of the few exceptions, but everything is going to stop changing so much, and we’re going to start bolting many things down. It’s hard to do interior design on a room when the dimensions keep changing!

Some assets are so decorative that we will be doing integrations after Alpha because they’re very low risk. Music, for example, will have all of the features the game requires, like systems for playing and transitioning between music, but we’ll still be getting polished, final pieces well after Alpha. Similar with things like VFX, and repeatable UI elements. We have a whole system for making these elements be in the game, we just need to put all the pieces in their slots.

After and leading up to Alpha, we’ll be getting into some of what I think is the most exciting stuff: polish and bug fixing! We have a long list of things we want to get to, including tuning our Hyperspace mechanics and Planetside procgen, Melee ship statistics, and trading gameplay. There is a whole section of work for “game feel,” which includes adding animations for static things in UI, polishing scene transitions, and optimizations galore. That last 10% of feel is the difference between using right-handed scissors as a left-handed person and actually feeling like the thing you’re holding is made for you.

Future Presents

As our Milestones become shorter, the amount of coverage we’ll do in these updates will also be similarly smaller. “We polished a bunch of stuff” only fills so much space on a page, so we may be doing more limited things like showcasing small sections of the game. Of course, as we polish more and more, it becomes easier to show and talk about the game in some ways. We might be writing less but showing more video, since the video won’t need as much explanation since all the representative elements will be in! That said, we do truly take these updates seriously and I put a good deal of time into preparing them (at least a couple days of back to back work, and that’s with someone helping me edit, too), so we will need to scale back proportionally for our month-long milestones since I am very much needed for development.

You can also look forward to order lock-ins for BackerKit. We will be finalizing the amount of different physical goods we’ll be manufacturing so we can start the process. When we started our Kickstarter we did not anticipate the extremely tumultuous world of manufacturing and import costs we’re all going through right now, so we might be waiting this out a bit if we think it makes sense. Seriously, we’re just as confused as anyone else. That said, you’ll still be able to change shipping address as needed, but soon we won’t be taking any more orders.

We’re still weighing options around getting playtesting and QA at the moment. One of the things that is quite hard to test with our tiny team is multiplayer, and we’re thinking how best to tap our avid Super-Melee audience for playtesting multiplayer and helping us balance our many, many ships. We’re still not sure what that looks like, but we’re angling towards being able to do it from a technical perspective.

Lastly, it’s nearly time to start recording voice overs! As we start locking in our writing, we’ll be looking to voice our weird, wild cast. Whether you’re a professional or amateur, if you have interest, let us know and send along a sample we can hear. If you know someone else who is looking or just has a cool voice, pass them our way! Like with The Ur-Quan Masters, we are looking to fill a ridiculously wide range of personalities with lots of interesting eyes, mouths, and tentacles to bring to life through voice.

I probably say this every blog post, but it’s true. I miss you all! Streaming development feels like the quiet, halcyon days when I wasn’t managing piles of spreadsheets, spoilerific content, and constantly jumping around helping support people to do their work. After Alpha, my one wish would be to find a way to integrate some more streaming time into my work. This game has its roots in our community, and I draw so much enthusiasm from connecting with all of you and sharing our development story.

On that note, I also want to take a final moment to thank our incredibly generous Patreon community who is still supporting us even after our Kickstarter! You may not be aware of how quickly our budgets get allocated and go directly to our game, so the extra support from Patreon is enough to help us that much more. It’s the difference between being able to afford that much more contractor talent or even assistance with simple things like provisioning test equipment.
Join us on Discord, Bluesky, and Reddit to be a part of the community. Our BackerKit page is still available for late pledges for only a bit longer and you can still support us on Patreon as well.