Welcome to our latest round of development updates for Free Stars: Children of Infinity. If you’re looking for the latest triangle, square, or other shape, you may also find what you’re looking for. Whatever shape you’re in, be sure to read the previous one, and strap yourself in for an exciting progress report.

Play Time after Time

In our last milestone update, we talked about the importance of making more things fully playable for the story. This milestone, we focused a lot of our design on the other parts of that complex organism. If we started the skeleton several months ago and finally started putting some muscles on the bones, now we’re actually getting the internal organs connected. We’ve got our metaphorical heart and brain driving the muscles, probably a couple of kidneys in there, and I wouldn’t be surprised to find a spleen! Metaphor abuse aside, we wanted to get our play time up by connecting more of our systems which sustain long play sessions which we can feel out to experience what we want players to experience: progression!

Players can now start a new game from a title screen, start with a very weak setup, grow their capabilities, be defeated, and effectively engage in the core systems of progression beyond the alien-centric “quests.” When players start, they will be quite lacking in some fundamental things, including some required tools for getting around in Hyperspace. Over time, now the player can earn many of the things we want them to get, like:

• New HyperSpace abilities for traversal.
• Permanent “player” upgrades, like increases to their maximum cargo and crew, enhancements and choices for HyperSpace traversal abilities, and room for additional ships in their fleet.
• New fleet ships from aliens joining the mission.
• Unlocking additional gameplay features, like the ability to land on gas giants or using Floyd for deeper exploration.

We also have developed mechanisms for how we build these kinds of global progression systems, so as we add more and inevitably want to tune them, it’s very easy for us to do so. We won’t know if our upgrades are working until we do a lot of playtesting. Players also won’t have the resources to have every upgrade they want, and tuning just how much they can access and what choices they will be making will be a longer task.

While we’re reusing some of the tried and true progression systems from The Ur-Quan Masters like acquiring new fleet ships, many are going through a lot of remixing or fundamental changes.

HyperSpace Oddity

The biggest changes to be found are in HyperSpace! We spoke previously about them, but now we have much more of this up and running in a playable slice of HyperSpace. We’ve got gravitational currents and tides which make maneuvering harder or easier, hazards players will want to avoid crashing into, vicious entities which attack if you come near or create “bullet hell” experiences, treasure both visible and secret to collect, and mysterious devices which will help you get around if you can activate them.

HyperSpace is much more interactive now, and getting from point to point isn’t always a straight shot, at least at the start. We introduced the idea in a previous post, but we’ve detailed it much more. Part of what we want to test is how fun this is given the play patterns we intend for players—patterns which involve not just getting somewhere but also making it back alive. Backtracking through difficult sections is an essential part of many games, but it runs the risk of either being too challenging or too tedious.

We have gameplay models where players must beat the challenges multiple times, models where player upgrades make the challenges much simpler, and also models where the player can overcome a challenge once and then be done with it. We’ll be testing all of them, but one thing we’re sure of is that we want players to feel like they have multiple options and tools for how they approach things.

Traversing through HyperSpace has no fuel cost like it did in The Ur-Quan Masters, but as you might imagine, it is hard for different reasons. Fear not! You will have a few abilities in your toolkit in the form of three core abilities, which we just address here with functional, uncool names:

• Dash: Gain a massive boost in speed at the expense of turning capability. It can be enhanced for additional speed and longevity.
• Dive: Plunge into the depths within HyperSpace, avoiding certain hazards while finding hidden secrets. Upgrades will let you “hold your breath” longer and maybe even let you extend its usage with crew members’ lives if you’re out of energy.
• Scanners: A proximity detector that finds secrets. Its range and abilities can be improved, and we’re also playing with letting you tune the scanner to find different things or reveal even more about known objects.

Nothing is free, and your powers will drain your ship’s energy just like Melee. Unlike Melee and Planetside, HyperSpace uses a different damage model. Players’ ships are protected by a shield which begins regeneration after not sustaining damage for a while. As long as the shield is up, damage goes to the shields, but once your shield is down, any damage is lethal. Yes, now you can die simply by traversing a difficult section of HyperSpace. It’s dangerous out there!

We’re playing with different models of ship behavior right now, including assigning different characteristics to different ships outside of Melee. A lumbering ship might handle more slowly, but it could survive a more prolonged assault. A nimble ship may have a weaker shield, but  some clever maneuvering by an ace pilot could guarantee victory.

Duty Can’t Fail

Since traversal comes with no cost in fuel, we wanted to consider how players would be experiencing different failure states. We’ve got good news and bad news for players who love the lethality and consequences of your choices from The Ur-Quan Masters. The good news is that it’s even easier to be blasted to smithereens in Children of Infinity. The bad news is that you don’t have 50 save slots to protect you. The really good news is, you won’t need them! We fully implemented our long-planned new model for failure and save handling, which is pretty simple:

• If you run out of ships in HyperSpace or Melee, you’re defeated.
• Upon defeat, you lose all of your cargo and return to the Starbase.
• Whenever you quit the game and at certain intervals, your current state is saved automatically. You can still have many save “slots” but they’re more for you to start new, different adventures with different progression.

The goal of this change isn’t simply just to stop you from saving in save slots. We could still let you do that if we wanted to. We simply want to make failure not grind your experience to a complete halt with a game over screen and encourage the paranoid save scumming that comes with that risk. We want players to feel like tackling challenges that might result in death during a single player adventure. It’s especially important in cooperative play, where having to save and restore in the middle of gameplay risks being even more disruptive if one player is having a rough time. This is related to the fuel change in HyperSpace, since very long-term attrition mechanisms beg for save scumming.

This is one of the more radical departures from UQM, and even reading it might make it sound strange. All of this simply results in a game loop which is more like a rogue-like (or rogue-lite), since long-term growth like upgrades will be preserved, but economic attrition like running out of fuel is gone. You can think of your forays from the Starbase as missions. Hopefully you come back with a bounty, but you might fail! If you fail, you lose some progress, but not all progress. We have a prototype where you actually drop some or all of your collected cargo at the point where you perished, so you might consider it worthwhile to go back and pick it up.

There will still be some sections where players are placed in special sequences which sometimes break the above rules and that can be failed, but in those cases we will give players the opportunity to restart the challenge or make it very easy to get back to them from the Starbase.

We’re pretty excited about this change and what it opens up. The other remix, which is like the cousin of this one, is how you gear up for adventure at the Starbase.

Gear Prudence

Fail to prepare and prepare to fail, as the saying goes. At the Starbase, since failure makes you lose your cargo, we need a way to ensure the player always has a minimum of what they need for a successful mission. At the Starbase, players can access a mission preparation screen where they choose what to bring with them. You’ll have a gear allotment every time you depart which you can allocate toward different tools, but you only have a limited amount of allotments to spend. You could have twice the fuel as usual, but you’ll have to run with less crew.

Over time, you’ll be able to upgrade the allotment available to you, fitting it to your playstyle. While not used for HyperSpace traversal, fuel is still required for Planetside landings. If you’re spending a lot of time on Planetside missions, you might want to invest in that. Want the strongest battle fleet possible and be able to dogfight your way to victory? Forget the fuel and invest in raising the crew limit, letting you—I mean, your brave volunteers—have a better chance of combat success.

As we continue to polish the mission gearing systems, we might expand this into other territory, like letting players decide if they want to invest in a few strong ships or three times as many weak ships. The point is to let players choose how they want to play, allow some flexibility in their choices for every mission, and never punish players for trying different tactics. Now that failure is free, so is experimentation!

We have a handful of experiments of our own in the works, like “repair kits” which can recover defeated ships. You could leave them behind and make room for more fuel, or you could play it safe. We think letting players have as many interesting choices as possible will be a source of fun, and we’re looking forward to polishing this even more and seeing what people do.

Both Sides, Now

We made it our mission to implement our ideal cooperative play design for this milestone after having it fall by the wayside for a bit, and we succeeded! Now that you have an idea of the new rules for single player, we can translate them to co-op. In co-op, additional players can join you on your adventure as a second in command, having access to and sharing all of your resources. They are not The Captain, but one of your commanders, entrusted with the piloting of a ship but not with the authority to start or end a mission.

The pool of shared resources is effectively everything except the ship that’s being piloted. So all of your RUs, cargo, crew, and fleet ship pool are shared. If you recall the defeat rules described above, this means that both players can access (and destroy) the same collection of fleet ships. Players can switch which ship they’re controlling at any time, and it’ll go back into the fleet hold, available for use by other players.

Both players are able to participate in almost any gameplay experience together or separately right now. That means that both players can hop into the same Melee battle, explore the same planet together, or even solve a Floyd level together. It also means they can go their separate ways, letting players divide and conquer as they explore different solar systems, or one player mining the planet surface while another fights their way through a melee battle.

We may decide to limit or allow certain behaviors depending on how things play out, and we already are limiting certain things. For example, since only The Captain is in charge of the mission, the only way all players will end up at the Starbase together is when a complete loss of all fleet ships occurs. Secondary players cannot go back to the Starbase to finish the current mission and receive their allotment of crew and fuel again. Right now, either player can initiate a comms screen, and you can even have two separate conversations at once, which is going to be problematic in case both players could be making opposite choices at the same time, or one player is still talking to a battlegroup while the other challenges it to combat. We will most likely limit conversations to permit only one at a time even if we let all players engage in them.

There are more experiments on behaviors we want to allow, too! For example, co-op players could opt to not pilot a ship at all, happily riding along with The Captain through HyperSpace and only taking flight in Melee or joining them in an additional lander launched on Planetside. These kinds of things are mostly matters of polish and experimentation, so we aren’t focusing on those just yet.

Goody Two Views

We’d been primarily focused on networked multiplayer thus far. We now have implemented a first pass of both our split-screen co-op, which is more like a twist on online multiplayer with a lot of UI complexities, as well as “classic” two-players-at-one-device Super Melee. Right now, we’ve actually torn down our “pretty” user interface, which was simply built as a proof of concept for our Kickstarter video, so that we can rework how we do things for split-screen. The goal is to make a dynamic system of UI that can resize, reposition, or offer alternate presentations of information without having to quite literally build two entirely separate UIs. Most of our “pretty” user interface has been disabled, but we want to show you some of our different layouts in action! This is extremely early work and purely functional, so some of it might be subject to change as we playtest more.

Here we have our default space view, where the screen has room for a persistent HUD for the player.

The heart of our game is born of The Ur-Quan Masters, which was made for a 4:3 screen, which was much more square than our current widescreen world. We get the most mileage out of splitting the screen vertically, which makes for nicer exploration scenes as well as text layout. In split-screen, we take the main HUD away, allowing it to come up on demand (e.g. when a player presses a button).

Planetside, likewise, can be seen here with its full informative UI.

But when we split the screen, we have room at the bottom for both the radar and UI for the lander’s current stats.

Melee gets a similar makeover, where its square aspect ratio leaves room at the bottom for UI elements.

However, if you’re playing in “classic” 1v1 Super-Melee with two players at one device, players share the viewport and play in the same scene together.

Communications screens are heavy on text, so we optimize for reading space by simply centering the comms view.

We’d like to let co-op players “listen in” on conversations, and in that case the view would just be restored to the full-screen view.

We might play with “overlaid” HUD elements which break our own design pattern of not putting text in playspaces, but we’re trying to stick to our guns to start with. Building the whole system to set this up was the hard part, and now that we have it, we can create and iterate on alternate layouts as much as we want. We might also have alternate cameras to compensate for the limited view. The current camera is great for a full, wide screen on Planetside, but getting to see a little further out to the edges would help. While players are always allowed to roam to different places, we also can do some clever stuff when they’re not, like sharing the radar view on Planetside if they’re on the same planet. 

This is all polishing work which we have to deprioritize for now while we focus on more important things! One of the big tasks left for split screen is building a mechanism for handling what we call focus for our interactive UIs, which is what we use to know what menu item a player has selected and lets them navigate between things like buttons. Godot natively only supports a single UI element being focused at a time, so we’ll be developing our own solution for this.

Speaking of developing our own solutions, Godot similarly doesn’t discriminate between input devices when dealing with key/button mappings. We developed a system for allowing players to be assigned an input device and then connecting it to the right viewport for input. On PC, players will be able to play solo with the keyboard and a controller at the same time (just pick up and press the one you want to use). In local multiplayer, they can play with either a keyboard and a controller, or with two controllers. On console versions, players will simply just be playing with controllers, but we still needed to develop a way of assigning them. “Classic” two players at a single keyboard is not currently planned, but it could be done.

Right Said Fred

The apparent ease of these multiplayer features is only possible because of Simple, our in-house solution developed by Fred! The fact that we’ve been able to take our multiplayer intents and convert them into running reality is entirely due to the slick technology we use to develop gameplay—technology which lets us make designs which are fully multiplayer-ready with ease.

We shared this little technical snippet with our Patreon supporters while our split-screen work was in development, but here’s an example of one of the technically wild things we can do: supporting two local players playing remotely with two other local players in a four player game. This is the kind of feature that was available in a blockbuster like Baldurs Gate 3, but we are even able to support it with our tiny team and budget. Talk about punching above your weight class!

While we talk so much about the game we’re making, one of the goals for Children of Infinity is to learn and prove how to develop all sorts of games with Simple. I mean it very sincerely that we think it’s not just really neat for our project, but an actual game-changer that can impact how people develop games entirely. Having really cool tools that unlock potential has been a part of my development history going all the way back to Toys for Bob, where we all worked with another one of Fred’s tools simply named “the TFB tool”. We never could have made all those games without Fred’s work, and the same is true for us at Pistol Shrimp.

During our last milestone, apart from supporting all of the new split-screen work, Fred was able to enhance our networking backend to match our various platform needs. We already create what we call a “vanilla” version for development which lets you join other players by IP address and lets you host your own peering server for our peer to peer networking. On top of that, we have a Steam version which lets you use Steam features like inviting people from your friends list. Now, we’ve integrated GOG’s networking SDK, so GOG Galaxy users will have access to those same features. On top of that, we support some common features for both of those platforms like rich presence and achievements. We’re excited to be making a first-class GOG release since we have so many backers looking forward to a GOG version. We even launched our GOG page! Tell your friends!

Because we build off of our “vanilla” version, this means if you are looking to play across PC platforms, that would be supported, too. Consoles are a bit of a different story, and we can’t make any cross-play promises there yet. Fred has started to explore and have some success with networking on the Switch. We’re still in the exploratory phase with this one and not sure what eventual support will look like, but we’ll find out soon.

The Write Stuff

Yes, yes, but what about the story?! We want to leave the story as something you get to play, but we can tell you about the development of the story! Our writing machine has been moving at full steam this milestone. We authored conversations for four more aliens which are fully playable in-game, and we have an additional four which are partially playable in what we call playtest form, where you can demonstrate that changes are happening and they can be interacted with, but not all the pieces are there and we’re still writing to fill in the blanks.

Beyond that, we have a few new types of narrative design tools driven by Ink which we now support in a functional way. The first is the classic Report, e.g. a report from planet surface, which lets us place non-interactive messages in the game. The second is what we will call the Quest Log. Based on all of the player’s progression, writers can now populate a quest log players will see which can cover the journey the player has taken so far, the steps they might know they need to take (but forgot because they put the game down for a couple of weeks), and even hint at information the player doesn’t have yet. These are two critical features for having people test our game, since the only way players would be able to figure out what to do is if an alien told them about it, but sometimes they’ll learn things from a report, and sometimes they might have a lot to keep track of.

We haven’t done a deep dive on how our writing connects with our gameplay in a technical sense, but the short version is that writers use Ink to create conversation trees, and the communication layer between the game and Ink is expressed in variables which we connect from Ink to gameplay. Most of these variables are straightforward, story-related things like keeping track of things the player told to an alien. Some of them are much more exotic and require special treatment because the game can influence them, and can also react in unique ways. We support a lot of UQM-familiar things like giving you an alien’s ships for your fleet, giving and taking items from the player, acquiring upgrades, and interacting with the player’s inventory. If an NPC needs some radioactives to power up a space station (why does this keep happening?!), the NPC can now query how many the player has and take them from inventory.

With all of these words, we need to make sure to support all of what we’ll be doing with them! We implemented a really slick technique for marking up our Ink files for the purposes of localization and voice over (VO). Without writers needing to do anything special, we can generate a spreadsheet of lines which need localization, and then populate it with translations for all of our languages. A similar spreadsheet will be generated of spoken lines which we’ll fill in with all of our VO tags and files. In-engine, we now fully support both localization and VO, even though we aren’t creating those assets yet.

This next bit is awfully technical, but as you might imagine, there’s more to localization than just alien conversations. For the rest of our text, like UI elements, names of items and powers, and so on, we don’t have a central place to author them. Godot has some built-in capabilities for handling text in various places, but it’s a little fragile since text can be coming from all over the place and we don’t know where/why it exists. For example, translating the English word “close” to close a menu versus “close” to indicate proximity. We created our own solution where we define text as resources which we can mark up and label, including for handling things like numbers, where different locales will want to treat areas like the decimal point or representation of currency differently. This guarantees a centralized place for all of our text to localize.

Last and certainly not least, we have filled out our roster of writers who will be contributing their voices to our aliens! We’re excited to have Alice Camp, who comes with a broad background in writing, translation, and game development, and Nadia Shammas, who has written comics (Squire, Where Black Stars Rise, Dead by Daylight) and for games (Thirsty Suitors, The Axis Unseen). Part of what we want to achieve with our aliens is a very alien, weird, and funny set of results where they all stand out on their own. Individuals who contribute their own take on what makes each alien alien will make it that much better.

Model Worker

For our 3D art, we met a critical goal: having all of our ship art done! We still have plenty of polish work to do with VFX, but we can check all of our ship art off and see it running. While these ship designs were all created a while ago, we needed time for our artist to catch up and build them out. The only exception is backer-created ships, which will be done later since backers still need to finish them.

Most of our completed ships were straightforward mixes of powers, but one of our new ships has a dynamic design which lets it have a few distinct power levels for the purposes of the adventure mode. The Buckshot (codename) has a fun gimmick with a variable number of gun barrels attached to a spinning rig. The barrels normally take a while to reload, but when you spin the rig, your barrels all reload, though your firing direction changes.

Since all of our ships had been built, we started working on our other 3D art, including unique gameplay elements to fill out our universe. Things like space stations, the trading post, and interactive elements on Planetside. We are sure The Captain will finally be happy to see the Mark II in working order.

We also finalized our Planetside & Orbit texture generation approach for this milestone! It had a long road of needing to be tuned for performance, aesthetics, and variety, and on Planetside it had to coexist with a lot of other elements which proved visually challenging. As of now, we’ve got a great approach that lets us generate many, many planets of many, many colors with a suitable variety while also retaining our desire to have planet types be characters of their own. Treasure World should be someone you want to meet, and Urea World should leave you feeling disappointed every time. This all has to be performant so that we can still function well on lower spec platforms like the Switch. We’ve got plenty of tuning and polish to do, but the foundation is finally secure!

Not all of our planets are simply procedurally generated textures. Mysteries await discovery on strange new worlds.

We also finished our first backer-designed creature, a strange spitting frog designed by The Somethening. We have four more in the works right now, and we’re waiting on backers for the rest.

Also in the realm of backer-designed elements, we sent out requests for backers to start submitting their lander skin designs. We haven’t implemented any of these, but the sooner we get your designs, the better for us. More on that later!

Paint the Sky with Stars (and Tentacles)

Our communications screen art proceeded at an even faster pace this milestone because we were able to streamline our workflow a lot, and some were intentionally special cases where we used a unique workflow. We finished six new comms screens for aliens! We’re keeping these cards a little close to our chest, but we can share a little bit.

What might be even more productive to talk about is how few we have left to go, at this point: six. We have room for an optional one depending on the time we have as we get near the finish line, but if we did six this last milestone, then, you guessed it, we’ll be doing six more this coming milestone and be completely done with all of our comms portraits—another great goal to hit!

The Sound of Violence

Toward the end of this milestone, we started spinning up the last piece of our content puzzle, which is audio. We’re very excited to finally start putting the aural coat of paint on our game, courtesy of a sound designer who wishes to remain shrouded in mystery. Our goal is to keep the fun and weirdness of The Ur-Quan Masters, and let ships express themselves like characters, with memorable, story-laden sounds.

We’re just getting started and don’t have much to share yet, but keep your ears open in a future update when we can show off even more of their work! We have some interesting technical features we’re exploring like positional audio, which would let us make a richer soundscape for audio-dense experiences like Melee, allowing us to give players even more information on where threats are while adding to the sense of space.

Here Comes the Flood

In case you can’t tell, this is the part of the project where assets (art, writing, sound) are coming in very fast! If our game is a bus and we had a few people hopping on at every stop, this stop and the next few are going to have 40 people all trying to get on at once. However, the bus needs to keep moving, so we have to devote a lot of energy to just being able to take all the assets in. It’s not free, and it’s quite a lot of coordination and effort to just ensure everyone makes it to their seat and the bus doesn’t collapse.

The other half of doing that is being very intentional about how many assets we’re producing. To extend the bus metaphor, we want to make sure each seat is filled by the time we get to the end of the line. No empty seats, no people standing without somewhere to sit. We are working from a production position which is very simple: if it’s not in a spreadsheet, it doesn’t exist.

Part of successfully spinning up asset production for sound, for example, is actually detailing every single sound we need. If we don’t have that, how will we know when we’re done, much less how productive we need to be? At this point, we now have a 100% complete asset list for all assets. Writing, art, sound, music—you name it. We’ve got a powerful tool and are working our asset machinery with it as the guiding light.

C’mon C’mon, Release Me

One question we get a lot and have been getting a lot is “when does the game come out?” We aren’t prepared to answer that question just yet beyond the estimate we’ve already given: 2025. However, we can talk a bit about the decision process regarding our release and what steps we still need to climb before we are ready to be there.

Right now, we are in the asset flood, simply filling our game box with tons and tons of stuff. The game itself is still unfinished and unpolished, and sometimes it’s barely playable because things break in the name of progress and feature integration. This coming milestone is going to be another asset flood milestone, focused on checking off from the list of remaining content—more on that later. That’s going to be about two months. After that, we’re going to be going into shorter, monthly milestones where we actually don’t accept any new assets. For example, all of the comms screens are going to be done, and we don’t want to put any more in. 

After milestone 5, we’ll have a one month milestone where we turn down the asset flood into a drip and focus only on things which are more focused in scope: user interface art, visual effects, sounds, and music, for example. Assets already made, like writing and ship art, will start to go through polishing, where entirely new things don’t get made, but we have opportunities to see what would benefit from a little extra love.

At that point, we will say we are “asset complete”. In theory, within about three months, we will be at what we might call an alpha version. You definitely won’t want to play it, it will have lots of usability issues and bugs, and its goal isn’t to be fun but to be a cutoff for what new things we’re adding. We won’t be adding entirely new game features, and the hope is to add no new assets at all, only doing very limited tweaks and polish on what we’ve already done. We will allow some assets to come in later like voice over work because we don’t dare start them until we’ve finalized the writing. Re-recording voice work because text changes are expensive! Same deal with localization.

After that, we start on my favorite part of any project: polishing! This is what will turn the game from a bunch of features stitched together into something that just feels good to hold and play with. We’ll start bug-fixing and preparing for our release. The future splits into a few zones of possibilities. Here are the kinds of questions we’ve been planning around and asking ourselves:

• Do we release on all platforms at once?
• What would be in an early release if we wanted to get feedback, and how would we do it?
• Should we release in all languages at once, or localize the game after an English-only release?

Put very simply, we don’t want to release a game that isn’t fun. All of the possible answers to the questions above are measured against that question. It is quite an undertaking to tackle a multi-platform, multi-language release and make sure all of those versions are fun and polished all at once! We did that at Toys for Bob, for example, and we had a triple-digit-sized studio and a massive publisher to support the effort. We have a lot of things now at Pistol Shrimp, but that kind of workforce certainly isn’t one of them.

For some people, I (Dan) know “early access” can be a scary term signaling a development cycle which is never-ending or non-commitment to a project. I get it! I often avoid early access games because I have so many others to play already, but also because it’s not always clear what the current state of a game is compared to the finished vision. Plus, I develop games for a living. Unfinished work just reminds me of my day job!

For us, if we did go with an early access model for releasing the game, it would be simply because we think it would make the game more fun to get something out there, get it tested by people excited to try, and to involve our community in improving the game.

For example, it could make a lot of sense to just do a Super Melee standalone release, so people interested in playing just that portion of the game could get their hands on it and we could get their feedback. It would help us hone the game and fix bugs. If people are just here for the story, they can wait for the release with the Adventure mode. There are many permutations of that idea, but that’s one example. We could carve out other features and save them for a 1.0 release, like VO, localization, and so on. The idea isn’t to withhold work we want to do, but to make sure we have time to focus on making the best game possible—something our community encourages us to do when this question comes up. For some people, VO is a requirement for fun. For others, blasting each other in Super Melee might be why they’re here.

If we did go down this path, we would be very up-front about what was and wasn’t intended to be part of such a release, and be very methodical about our release plans and timing. That is, if we had an early release, we’d probably also say when the finished release would be. We don’t have much to hide, we just want to get our work done and make something our players will enjoy. Games like Slay the Spire and Hades used this model, methodically plotting milestones as part of their feedback-receiving model while delivering a fully playable, but not finished experience. We’re legitimately curious what you think of this, and if you do like being part of a feedback cycle. Let us know!

What about platforms? We have made a few decisions there, which are mostly informed by the surveys from BackerKit and our work so far. We’re intending our initial release to be for PC on Steam and GOG and most likely Switch. These are where we had the most backers requesting their copies, so we want to satisfy that first and foremost. If we do go through an early access cycle, PC would be the place to do it, too. The console versions for Playstation 5 and Xbox Series X|S will be coming later, as they were uniformly the least popular versions in the surveys. We don’t think there will be a great delay, but when we’re working in terms of months as you’ve seen, a month or two to just focus on those platforms will give us a lot of breathing room to make sure the core game is fun and not just available everywhere at the same time. If you’d like to change the platforms you’re receiving the game on, feel free to adjust your survey! This will remain available to change for quite a while.

Localization is the last piece of the “when” puzzle. It makes a lot of sense to delay localization until after an initial release, but this also depends on if we do an early access approach and the size/scope of that release. Localizing a finished game is far easier than an in-development one, so we will need to assess this one as part of our work when the content flood ends and when we see more clearly when we can ensure our writing assets can be locked down. For backers who are contributing their own writing, like the lost crew member name and message from earth, we’ve grabbed all of your survey responses already and we would like to lock those down now. If you want to change them, you have until the end of March, 2025. Most of the messages from earth have made it into the game and we’ve even reached out to a few of you to help reduce word count or make tweaks. The surveys will remain open in case people need to change their shipping addresses or desired platforms, but we won’t be taking content changes after March!

With that in mind, we have an important request and statement for anyone who backed and is on the hook for designing a lander skin, creature, or ship. You have a deadline too! We’ll be sending you some reminder emails if we haven’t heard from you, but if we don’t hear back from you by the end of April, 2025, we can’t guarantee your work will be in the initial release! We’ll still be able to add your designs to a future release, but we have to lock down our own content, and since your content is part of our game, it has to abide by the same rules.

Papa Was a Milestone 5

It would be exhausting to detail every single thing going into our next milestone, but we’ll go through some of the high-level goals which are around being able to wrap up as many content areas as possible and make all of our experiences playable in sequence. Here’s what we’re targeting for Milestone 5:

• Finish all comms screen art and all creature art and have it integrated in-game.
• Finish all of our space and Planetside story set-piece art (unique items, reports from planet surface, etc.) and have it integrated.
• 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.
• Alien Auction House and all Floyd levels are integrated and playable.
• 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.
• The game should be fully playable in multiplayer in adventure mode, local co-op mode, online super melee, and local super melee.
• All alien comms writing is complete to a first draft level.
• Core menus and their behavior in single/split screen are done, and final art has been started.
• 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.

I Walk the Timeline

Before we start to wrap up, just like the last milestone, we want to take a moment to very honestly discuss our risks and challenges. The first thing I want to call out is that everything we said was behind or felt at risk was addressed this milestone. Seriously, sometimes we have to remind ourselves we’re doing a good job because we’re so busy focusing on fixing the problems!

This milestone’s biggest risks came from our missed plans. We’re behind in a few places, and most of it comes down to our team’s bandwidth being limited. We wanted to start work on more of our UI designs, fleshing out more of the actual art production for HyperSpace, finishing our Truespace art backdrops (e.g. stars and nebulae), finalizing our boss designs, actually implementing the alien auction house, and forming a better picture of how modding support would work.

We opted to punt on some of those simply because we knew we would be able to come back to them. Boss fights, for example, are “okay”, but they’re not great yet. We won’t need new assets to do that, so we are keeping those for later as we prioritize the assets. Similar story with the Alien Auction House, where it doesn’t require assets we won’t already be making, so it can wait. For modding, we have a pretty good idea of how we can support it, but if our very first release just has “okay” modding support, we’re comfortable adding it later. A great game with limited modding support is better than an okay game with superb modding support.

Beyond including those things in this coming milestone to ensure they get done, we have some challenges we’re preparing for and have plans to mitigate. Most of these have been covered above, but there are questions like what form(s) our releases will take, and what we do if backers don’t get us their submissions in time. We have one more piece of our team puzzle we want to figure out in any case, which is how we’ll be running user testing and QA (quality assurance). We’ve got some plans in the works, but it isn’t finalized, and in the spirit of the spreadsheet: if it’s not accounted for, it might not get done! We’ll be focusing on nailing this down.

Closing Time

If you thought that read was a doozy, just imagine what development is like! We call the asset integration a flood because it really feels like that sometimes with how much we’re cramming in all at once. This was all the result of a lot of thoughtful preparation, but the ramp-up is still a shock. While we have a handful of additional content creators all helping us, we are still a tiny team and have to accept and communicate about our limitations. It’s been a learning experience for everyone involved, and we still have more to learn.

We have the rest of our lives to live, but I have accepted my modern schedule of working six days a week to help see this through. “Crunch” wasn’t part of the plan, and even in the founding of Pistol Shrimp we made a point to plan around not doing it. Does anything in life go exactly according to plan? Never. So we adapt, and we are committed to getting our work done. If you email us through BackerKit or send a message on Kickstarter, it just goes to my inbox. I try to respond to everyone who has questions, fitting in emails between time I am using to complete my other work, but please bug me if you haven’t heard back. If there’s one thing I hope you know it’s that we’re committed to the guiding principle of making the best game we can: with our time, our release plans and priorities, and even in our communications with all of you.

On that last note about making something that’s the best, the world still turns while we just want to make a game. It is a strange time to be American and aware of the current dismaying discourse. We are creative people making a game we want everyone to enjoy. Inclusivity isn’t a bogeyman, it isn’t a buzzword, and it isn’t something to take away. Inclusivity is about excellence, and excellence includes everyone. We do not accept anything else, and it’s just smart business. This game is for you, whoever you are.

Join us on Discord, Bluesky, and Reddit to be a part of the community. Our BackerKit page is still available for late pledges