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

We’re excited to share an update on what we’ve been working on as we wrap up our latest milestone, Milestone 2! For players who are excited about the story of our game, this update is guaranteed to be mostly spoiler free. As we have more milestones, with even more exciting names like Milestone 3 and Milestone 4, we’ll be sharing these updates so we can show our progress.

Sometimes it might not look like much, but the achievements are in securing technical, design, or creative goals. We usually want to prove anything we’re doing is really worth our while before investing in it, and a critical step which won’t be obvious until the very end is actually polishing what we have. Until we make a lot more stuff, actually play it all together, and evaluate it against every part, we won’t know exactly what parts are fine as-is and what parts need extra love to shine.

Get ready for some things in various states of completion!

That’s a Lot of Stars!

Our game currently has 718 stars. I actually hadn’t counted in a while and tallied them just for this blog post! The stars in HyperSpace are laid out in a program called Tiled, and Simple uses a bespoke plugin to ingest the Tiled data and create the actual, playable map of HyperSpace. All of this was already working, but there were a few things left to do to finalize our vision.

First was enhancing our procedural generation. Our game is built out of two distinct parts: Simple, which handles our physics-based gameplay and multiplayer needs, and Godot, which we use to do audiovisual representations of the gameplay. Godot observes what’s going on in Simple but otherwise has limited awareness of what might show up and executes no gameplay code. Many months ago, we started to do procedural generation of solar systems, where we create a collection of planets and position them around a star programmatically, as well as override certain things when we want to place special things like Rainbow Worlds. All of that work was done within Simple, since it’s important to gameplay.

The problem is, Godot doesn’t run Simple logic, so it couldn’t do the same procedural generation. It only knew how to visualize planets, minerals, and so on when the player was actually there and they had been generated. 

This created a challenge for how we would go about tracking progress or guiding players to things. It would be difficult to know what, exactly, a player would find or had done in a star system if we didn’t know what was happening there except when a player was in that star system (say that 10 times fast)! Beyond that, we have a design for an interactive Starmap which helps a player take notes about what they’ve discovered.

We needed a way for Godot to be able to get the same information about procedural generation that Simple was using, but at different times, like from the Starmap menu. We now do our procedural generation in a C++ plugin. Godot and Simple both run the same, shared code to generate a star, even though they will each do wildly different things with the information. Simple will actually make a solar system, planets, and minerals when the player enters the appropriate game space, while Godot will get the same information about what will be made as a JSON response.

Second was authoring some of what we call our “HyperSpace topography.” We were currently using Tiled only to generate stars, which are always the same shape and were always the same kind of thing (a star). For Children of Infinity, rather than a straight shot through space on manual or auto-pilot, we wanted the player to actually experience some texture in HyperSpace. We’ve talked about it forever and did some prototypes, but it wasn’t clear how we’d handle it at a large scale. Using nautical metaphors, what if there were currents, shallow areas, deep areas, treacherous rapids, and other navigational hazards in HyperSpace? What if there were many things in HyperSpace besides just gravity wells?

We now support a bevy of features that let us make unique shapes and gameplay. Using Tiled and Simple together, we’ve been able to demonstrate fun gameplay with 2D shapes and actually make the Starmap much more of a game map, with tools the player will gain to help them traverse new challenges. More on that shortly!

Lastly, we wanted the ability to create dynamic experiences in HyperSpace. Luckily, stars don’t need to move around, but we were starting to place things that would appear or disappear based on different rules. We had mechanisms for placing all kinds of things, but what about deciding if they should be there at all? What if those rules would change over the course of play? Spheres of influence are a good example, but we’ve got a lot of new things cooking beyond just spheres of influence. Here’s a proof of concept showing the player using their metaphorical metal detector to find some similarly metaphorical buried treasure beneath the metaphorical waves of HyperSpace:

We still have a lot more work to do in HyperSpace, especially in deciding how we want to visualize some things, but we can now build all of our prototypes at scale and see how the whole map plays. And it is a big map!

Introducing the Introduction

We have sliced our game’s story up into different playable segments which usually revolve around the subplot of an alien or two, and we have been designing and building each piece one at a time. Last milestone, we got our first of these playable segments put together. This milestone, we tackled one that is very likely to change before we finish, but is a critical part of seeing how the game plays: the start of the game!

The beginning of the game has a lot of heavy lifting to do beyond the story elements. We want players to be able to pick up and play the game well enough to be motivated and feel capable. For that to succeed, we don’t want to introduce players to too much overwhelming complexity too quickly while they might just be coming to terms with the very long mastery curve of the unique physics of Melee combat.

We now have a start of the game, including a story, where the player is introduced to ship controls and Melee, then to the notion of scanning and landing on planets, and then finally to exploring HyperSpace. They’ll meet different characters who will be part of the player’s story and can help guide them. We’ve built what we lovingly call ‘the kiddie pool’ where the player can safely learn the core concepts of the game before they’re unleashed on the entire galaxy. We’re still playing with how much we want the player to be forced vs. encouraged to stay in the shallow part of the pool until they have complete freedom, and this is something we’ll know how to tune when we have more playable story segments and player growth.

Last but not least, the beginning demonstrates a starting point for the player’s capabilities. We want players to feel encouraged to grow in strength. Whether it’s getting new ships, practicing Melee, or acquiring some of our many upgrades which will help them progress through the game, we’ve created the floor from which all those things will rise.

Want Success? You Planet!

If you were to identify places where the player was more likely to lose crew, Melee might be the worst thing in space—but being planetside is dangerous. We put special attention into actually creating a spectrum of planets, from peaceful to absolutely deadly. We had proven the bottom and the middle, but what about planets where you absolutely do not want to go without being properly equipped and skilled? We’re very satisfied to finally have planets where you’re likely to die before you can even finish uttering your shocked expletives.

Planetside work also hit some asset goals. As of our milestone, we have finished creating our entire creature roster, only needing the ones our backers will be helping us design (more on that shortly). We might choose to create more creatures later, but since we only have one artist working on these, it’s great to unleash him on some of our other art needs.

Planetside has proven to be the most challenging art space to nail down because of the mixture of very different types of art: a procedurally generated texture, modeled objects like the lander and critters, and VFX for hazards. The player needs to understand what all of these things mean for gameplay, and from an artistic standpoint, we are trying to strike the right balance between artistic interpretation and abstraction and “what it really would look like.” For this milestone, we created a new workflow for generating planet textures that an artist can interact with. The artist can now actually spend some more time polishing and tuning that texture in an environment with our other Planetside objects to balance that push and pull between reality and computer-generated artistic abstraction.

Speaking of plans, we had long had a plan for how we wanted to handle our camera in Interplanetary view once players are in a star system. This was a bit of a polish task, but because it was never really proven and remained quite unknown, I spent a little time verifying it was going to work. There’s still more polish to do, but here you can see our Interplanetary camera capturing some of the vibes from The Ur-Quan Masters as it provides different zoom levels depending on how close you get to the sun. Elements like battlegroups and other players at different zoom levels all move at different speeds, and we’ll indicate to the player what might be close or far away with some size changes. The idea is that the player’s ship size stays constant even though the size of the world around them changes. Everything’s still subject to change, but we think it feels pretty unique and will encourage players to want to get closer to things to learn more about them–the core exploration principle of Children of Infinity!

Last but not least, we continued to work through our alien conversation portraits. We finished three more of them this milestone and started working on our next two. We’ve also created what we call our mini-comms screen, which we will use in special situations where characters might want to talk without pulling you into the main fully interactive comms screen–-like for tutorials, cutscenes, and stuff like that.

Let’s Split

We made a number of technical achievements that will unlock further design work. We finally completed the technical heavy lifting which would allow us to prove local co-op play. We now allow the Godot viewer to request an additional viewport for a local player, and our user interface plumbing is set up to support the notion that multiple players might be playing. If you are familiar with programming concepts, this is very much the equivalent of undoing a lot of assumptions, removing singletons, and inventing objects which can come and go as players come or go. This coming milestone, we’ll actually be doing some of the real work for co-op play in general, but this was an exciting technical piece to have under our belt.

We started work on our Switch port this milestone, and as of now, the whole game is playable there! (Well, as much as it’s playable anywhere, at least.) We have a long way to go to accommodate the Switch’s more limited technical requirements, but just getting it running was no small task. We are excited to work with W4 Games to make Godot go-go, but because we have some unique engine components like Simple, we need to do a lot of our own work as well. We’ll be determining strategies to optimize for memory and performance now that we are actually running.

We have a lot of other technical odds and ends we were able to do this milestone which are far from flashy but will make our game so much better. We implemented threaded loading of game scenes so players can play the game seamlessly without loading screens. We have a lot of progression systems functioning, so we can trigger events based on interesting, secret bits of data like how many star systems the player has visited, who you’ve talked to, and other bits of knowledge the game accumulates. We have rudimentary controller support for playing without a keyboard. We made some very cool music mixing tests with multi-tracked music to go beyond simple musical loops for our gameplay. Like we mentioned last milestone, a lot of our technical work is in tackling the biggest unknowns—and there are lots of little ones like this that help us shape our work.

The Big Production

During this last milestone, I also finished a massive spreadsheet which represented the entire itemized list of every asset, task, design, and feature required for us to finish the game. While we had started working in our milestone chunks already with a roadmap toward completing the game, we couldn’t actually finalize everything until our Kickstarter wound down and we actually learned a bit more from our first milestone about how the work was going to, well, work.

The last time we had such a complete summary of tasks to complete was actually in the lead up to our Kickstarter, where we detailed every single asset, plan, and goal we’d need to do before we could activate the Kickstarter.

With our entire game roadmap, now we can actually say with complete confidence that we’re done with all of our creature assets. We also have it mapped against time and effort, so we know when we need to be done with all of our ship art, for example. We can guarantee all of our contributors will have clear deadlines and we can scope all of our work and make sure they really will have time for what we’re planning. It is also easy to distribute the work so we aren’t trying to do too much all at once.

It might sound a little weird to say I’m excited about a spreadsheet, but it’s a really empowering spreadsheet. We’re working with a team of people and we’re serious about delivering on time, so it’s critical that we can all look down the same runway together and see the steps we need to take to prepare for takeoff. From a personal, creative standpoint, it’s honestly thrilling to see every single part just described and accounted for. The vision we want to achieve is accounted for, and I personally am excited to actually have an accurate plan for how to get there.

This also helped us make decisions on when we might look to do things like playtesting. We know we’ll have a few willing victims, er… participants. In addition to our supporters who are participating in a private playtest, we planned out when and how we’ll be taking in designs for creatures, lander skins, ships, and the Precursor Legacy. We know the last two months of the year are typically busy times for people, but if you backed at one of those tiers, look out for an email in the next month with some fun “homework” to do. We’ll establish some deadlines (don’t worry, you’ll have time!), but we’d love to start working on your creatures at the start of next year, with your ships and lander skins following.

For everyone else who has already been submitting text in our surveys for the Lost Crew Log and Messages from Earth, we’ll be starting to slot them in this milestone. We’re excited to finally start putting your contributions in the game!

What’s in Milestone 3

We have a few big goals for our next milestone. Of course we’ll be continuing to make things like our playable story slices and alien comms portraits, but we’re going to finalize some big parts. In short:

• Complete design for co-op play in Adventure (the story mode) with all parts working. Start preparing our UI and game to handle the user experience for local multiplayer, split-screen co-op and single-screen Super Melee (the player versus player mode).
• Finalize the requirements for every playable story slice, even the ones we aren’t building yet. This will help us ensure we’re not over-scoping anything and can stitch multiple story segments together.
• Implement our Trading and Alien Auction House systems.
• Finish our gameplay experiences for Gas Giant Gameplay and how the player is using the Mark II (!).
• Implement player ship and lander upgrade mechanisms so they can actually grow beyond the starting point we made this milestone.
• Finish all of our new ship designs and art (besides the ones we’ll be making with backers).
• Start finalizing our Interior experiences with Floyd, including building art assets.
• Start supporting more fully-featured and platform-specific network play, like making use of Steam’s “invite to game” feature for playing with your friends.

Definition of Done

One of the unique parts of game development is identifying what is or isn’t easy to change, and then navigating with that knowledge. To use a metaphor, if you’re building with Lego and you’re making something that’s only two bricks high, you can swap and rearrange different parts quite easily without destroying the entire piece you’re working on. Once you start building a dozen bricks high and start making more interesting shapes like towers or bridges, taking things apart becomes a lot trickier. You might wish you had more blue bricks, but they’re all stuck in that massive sculpture you built. The problem is, maybe you didn’t know how cool blue bricks were until you put many structures together.

Part of creation is letting your creations speak to you. Games are meant to be played! That metaphor really feels apt for how games shape up. Assuming our finished game is a swath of dozen-brick-tall features, it would be a huge mistake to try to stack everything up that high right now and commit that deeply into ensuring every structure is a dozen bricks tall. With a finite amount of time and a broad collection of experiences we’re making for players to enjoy, the challenge is that we don’t know exactly which experiences are going to be best yet. They aren’t all sitting together, and some are only five high while others are just getting their second brick added.

In describing the big spreadsheet above, one of the critical allocations of time is for polish. What are we going to polish? We don’t know! For all we know, many things will be great being only five high, while others will be so much fun that we want to make them the full dozen. That’s why we reserve time to polish the whole product and experience, since we’ll know what isn’t working only when we compare it to all the other parts. You could call it triage, but it’s more like a positive version of triage. What aspects of the game will benefit the most from additional investment? It’s too early to tell.

Finish Now, Polish Later

I am continually learning on this project. I learn about new technologies, new game design ideas, and how to work with other people on a team. If there’s one thing I hope everyone on the team embraces, it is that we are all here to learn together. One of my biggest lessons I’ve been learning on this project is how to teach and even enforce that notion of leaving polish for later. 

We are fortunate to work with so many creative individuals who are filling our game with their dreams. We want their contributions because they have those talents and capabilities! How can something be visualized? How can a story be told? How could a strange alien sound? It’s wonderful what we can come up with.

I’m used to seeing a lot of games in progress, and it’s honestly a joy to share all of the incomplete work with the team and everyone following our development. For our creatives who dream and are unfamiliar with the process, it can seem confusing or outright mortifying! Maybe even for you, reading this update right now, you are wondering or anxious about certain things which don’t seem finished. You are right—they are not finished. As Fred likes to say, nothing is ever finished.

This is true for our game too. We live in a world of constraints, and we will call it finished when we get there. I’m looking forward to actually having players play the game! We still have time to polish, fix bugs, and do playtests, and it is critical that we reserve that time for later instead of trying to achieve perfection before we know if it’s even worth perfecting. You might never know what we didn’t do, what we decided to leave behind at any stage, and what actually got the most polish put into it.

A cake has both cake and icing, and we’re still making layers of cake. It’s not ready to taste, and it’s our job to imagine the icing long before it’s there, not rush to put the icing in before we have our cake layers baked and ready to stack up.
We will have what we think is a pretty great game, and we’re encouraged by the incremental improvements we’ve made to our work so far. We’re so excited to have your support and involvement along the way! Join us on Discord, Twitter, and Reddit to be a part of the community. Our BackerKit page is still available for late pledges and you can still support us on Patreon as well.