While you get ready to count in the new year, we’re ready to count up our milestone numbers. We have less than usual in the way of flashy things to show for the game as we’ve been hard at work getting our track laid down for next year, but you have a lot to look forward to coming up  since that means soon we will be unleashing a lot of exciting things in a very small amount of time!

In this update, we’ll be mostly sharing progress we’ve been making on our Melee build, as well as following up from our previous update where we spent some time discussing what our plans with the Melee build might be. (In short, we’re releasing it for y’all to play with!)

We’ll also share some behind-the-scenes stories of how we’ve been getting our totally insane Kickstarter physical reward fulfillment machine going and what was involved in getting thousands of goodies made for everyone. Be sure to check our previous post for information on shipping if you’re getting physical rewards!

Since these are such long updates, here’s a tl;dr:

• We’re finalizing Melee for wider playtesting, and have conducted our first informal tests with great success.
• A standalone playable Melee experience will be released publicly next year, targeting Steam and GOG. Switch is a possibility but we need to weigh it as we get closer. The Melee experience will serve as Children of Infinity’s demo.
• Adventure mode is still being worked on by our narrative team, and the full game is coming next year.
• We have almost all of our physical goods in one place and we are starting to ship them out. Backers who are receiving Star Maps will be getting their shipments later since we are still waiting on them.

Melee: Battles in the Beyond

Last time we shared our work on Melee, we had begun to build out more sophistication for AI-controlled ships, and had functional VFX in for almost all of our ships. This milestone, our focus was on all the pieces necessary to turn the build over to another human being for them to play—and also then doing that. A few key areas for the actual Melee combat experience were polishing the feel of ships and physical interactions, starting to tune some ships, and fixing lots of bugs.

We began our Melee journey by recreating the ships and combat from The Ur-Quan Masters with dogmatic rigor. All ships were built using similar relative tuning values to one another, and those tuning values were all based on timings and sizes from UQM. Timings were used for things like motion (thrusting speed, turning, missile movements, and so on). UQM ran everything at 24 frames per second, while we run our physics at 60 frames per second. There was some conversion involved in changing how long things take, but the idea was that a lunker like the Ur-Quan Dreadnought would trundle around in as familiar a fashion as possible, and a zippy Pkunk Fury would feel as fast as you remembered.

Sizes were used for relative scales of ships, the size of the arena, and the ranges of ship weapons. The official unit of measure is, humorously, an Arilou Skiff, based on a formula and convention Paul made very early on which let us define a Skiff as one meter in diameter, since meters are our game units. Everything in our game is technically in fractions or multiples of Skiffs. Sure, they’re also meters, but Skiffs are more fun. The idea was that, by combining UQM sizes and timings, we would start by recreating the closest thing to the Melee experience from UQM, itself. 

Over the many months of exploration, especially in pre-production, we fiddled with introducing or tweaking other elements of UQM’s universe. One of the things we challenged ourselves with for a while was how much smoothing we should introduce with our newer, more modern framerate. We played with many different flavors of recreating the fixed firing and turning angles before accepting that completely smooth thrusting, turning, and aiming just felt more fun. Not a lot of the fundamentals changed beyond that for a long time, though.

This milestone, after many months of implementing different ship powers, getting AI controls in, and effectively building on our stable foundation of Melee, we took a giant step back and re-approached the very simple question: “What’s missing from making flying a ship in Melee fun right now?” We had done a pretty good job with tuning ships relative to UQM and one another, but we were missing some of the kinetics of UQM’s Melee. Namely: the behavior of gravity (whips), how thrusting interacts with your speed, and the feel of ship collisions against other physical objects.

One of the things that’s just different in our new engine is that it uses a physics simulation very unlike the one from UQM. Our new ships were faithfully, physically bumping into one another and transferring their kinetic energy to one another, but one problem is that the player has a lot of control of their ship. You can always steer left or right, effectively negating any rotational momentum from a collision. Similarly, your ship has a thruster which could too easily override any imparted energy.

The net effect was that ship scuffles would become “sticky”, with ships staying uncomfortably close to one another. Great for your Pkunk Fury, but maybe not so great for your Druuge Mauler. Critically, it just wasn’t as fun as having all the motion and potential chaos of a bouncier universe. UQM was pretty bouncy compared to what we had, but so many things were different in our new world, so we had to re-examine how to create similar feelings.

Our first step was actually questioning the thrusters’ behavior and tuning, which was based on some UQM conversion math and we just assumed was correct. Surprise! It wasn’t. After not looking somewhere for several years, it becomes somewhat foundational, so it takes some active effort to examine it.

Due to a simple mathematical mixup, thrusters were thrusting too well across the board. Toning that down helped collisions a bit, especially for ships with weaker thrusters like a Druuge Mauler which really started to feel heavy again. The problem remained, though: ships could too easily undo a collision.

Breaking the Law(s of Physics)

The next step involved getting the initial impact of a ship against another ship to feel appropriately powerful. Fred, who actually knows things about math and physics, stepped in to design this solution, which he dubbed “reactive armor”. The short and sweet version is that we simply amplify the physical bounces ships get from other things. 

The longer and even sweeter version is as follows. We look at what we think a ship’s momentum is at the end of a frame when our designer-made scripts, which do thrusting, turning, and special powers, are done. During the next script frame, we look at what physics did to our ships and the difference between how we set it versus how it came in. If there’s a difference, it means a physical collision occurred. We then amplify the difference in the new direction we’re heading. On top of that, we also inspect our rotational velocity as an additional factor to measure how powerful the collision was. Since ships can turn under player control every frame, ships won’t ever actually feel like they received rotational velocity as far as the player can tell, but if you were to hit a ball with a bat, that ball would spin more the harder you hit it. A smart person like a real physicist or a Fred could explain it better, but the net result is we have a measurement of how powerful a collision was, and then we can amplify what physics did past what real-life physics would do.

As is often the case in games, realism isn’t always fun. To borrow Fred’s words: we take the parts of reality which make fun and then build on them. We now have “real” physical collisions between ships, and our science fiction conceit is that they are built with Fred’s reactive armor which gives them additional propulsion. It made Melee feel much more kinetic and exciting! Big, hulking ships like the Ur-Quan Dreadnought will barely be moved by a Pkunk Fury bouncing into it, but the bounce the Fury will get is much greater than before. Two Dreadnoughts ramming into each other will satisfyingly rebound off each other. Ramming into the planet, though ill-advised, will send you flying away. We’ll be tuning it as we go, but if you fire up UQM and ram ships into each other, you’ll see the kind of pinball table bumper effect at play. We haven’t exactly recreated it, but we’ve made something very similar.

The last piece of our puzzle for making satisfying motion was in how ships decelerate when they’re over their top speed. If we return to that thruster logic, it was actually written, originally, to be a 1:1 clone of UQM’s logic with a few conversions in there for framerate. One part that was not recreated correctly was the logic for changing directions. We started by actually recreating those rules correctly. Ships trying to thrust against the direction they were traveling wouldn’t be able to change direction as easily, adding in extra feel of weightiness, while ships retain the feeling of being under the control of their own powerful (or weak) thrusters if they’re generally going the same direction.

UQM was written to be frame-based, meaning that the logic was built around doing something every time the software ran its next update (i.e. frame), which happened 24 times per second. It had rules which stopped ships from thrusting every frame, even going so far as to differentiate them with what’s called their thrust wait if you look at the source code. Ships with a long thrust wait would have to, well, wait a long time between each thrust impulse. In Children of Infinity, ships can thrust every frame smoothly. That presents a problem if we want collisions to feel like they have impact. Now ships could try to thrust against their travel direction every frame equally well. Upon reimplementing the UQM logic, this gave birth to a new, per-ship property we could tune! Though the Ur-Quan Dreadnought and Druuge Mauler have fairly similar thrusters, there’s now a factor for how well ships can fight against their own inertia. The Dreadnought is a heavyweight that can actually steer pretty well, but the Mauler is going to have a harder time changing directions. While different from UQM’s logic, the net result is the same: we can make ships feel different in their handling.

The last thing we needed to fix was deceleration after a ship had exceeded its top speed, whether from a gravity whip, a collision, or a special ship power like the Thraddash’s afterburner. Our initial implementation created a fairly rapid deceleration curve—or, more accurately, a rapid ability to take control back. Following in the steps of what we described above, we replaced it with a much more gentle deceleration curve which, again, can be tuned per-ship as we see fit. The idea is that a ship should never be allowed to exceed its max speed, unless it already has, but we don’t want to take away from your ability to thrust entirely since that’s how you also change directions. With Fred’s wisdom and math, we now have a satisfying formula for what we do when you’re over your top speed, while also letting you thrust enough to change direction, lose speed, and feel more or less like your thruster has control depending on your ship.

This was a long way from our humble beginnings of perfectly recreating UQM’s Melee. We had finally gotten to the point where we had to reassess our dogma, because it was one of the last hurdles on our way to having fun in Melee. Melee will still feel familiar, but it also has something fresh and fun happening! If you get the calipers out, you will find that certain things are different. We’re talking about a quarter second of difference in the 15 seconds it might take to traverse the playfield with a particular ship. Going in and scooping out our innards allowed us to make something new and more fun to play.

Preparing for Play

All of these details are in service of validating what we just asserted: “This is fun!” Part of getting there is actually tuning and attempting to balance our ships. Before we even get there, we have to fix bugs! I (Dan) had long been happy to live with all kinds of ship-specific bugs and issues because I was more concerned with getting things working than with getting things working perfectly and holding up to scrutiny in all scenarios. No more! Of course, we will still have bugs that turn up over time, but we truly want to start tackling the show-stoppers that prevent legitimate playtesting.

We tested this concept by actually putting our volunteer designer into Melee to face off against AI opponents, after some thorough fix-up and after all the enemy AI was mostly functional. The designer had no idea what the new ship powers did, and was simply thrown into the deep end to experiment. This was our first legitimate playtest where we tried to simulate what would happen with a new player being given no guidance. I watched silently and offered no help unless the designer actually snagged on a blocking bug.

This whole experience surfaced far more bugs than I was originally aware of, and it also demonstrated all kinds of things a player might try to do with the ships. The testing gave us our first good look at which things were readily understood, which things were too subtle, and which things were too broken to use (even if those things were “working” as intended). Of course, this is a sample size of one—but observing our test subject generated a huge task list of things to fix and do. Being able to prioritize work informed by a player’s direct experience is a critical milestone. If we’re doing those things, then it means we’ve tackled a lot of big problems.

As part of our bugfixing and polishing flurry, that designer also helped create the physical collision shapes for most of the new ships—work that hadn’t been done yet because it hadn’t become a priority. With ships all now having accurate and newly bouncy collisions, we also put some polish into the asteroids, planets, and gravity itself. We got our Adventure planet art generation shimmed into Melee so you can see (and bouncily collide with!) all kinds of different looking planets. As the last bit of icing on the cake, we re-tuned some of our lights and starfield backdrop to increase everything’s visibility—especially for some things that we noticed our playtester was having trouble seeing.

There are many more things we’ll be tuning for Melee, but you know when we’re getting to the point that we’re touching minor things like lights, we’re really in the home stretch! As of now, most of the work that remains for the actual melee experience makes for a pretty limited list:

• Tuning ship characteristics (cost, crew, energy, thrusting/turning, physics interaction numbers).
• Tuning weapon characteristics (energy costs, firing rate/range, damage, health of missiles you can shoot down).
• Re-tuning gravity behavior as/if needed.
• A few very-ship-specific AI features which haven’t been built yet. Most notably is being able to know how to interact with other, neutral objects like crew in space generated by the Syreen’s song.
• Camera tuning during victory.
• Ship audio for some ships.
• Ship-specific bugs.

As you might observe, a lot of that work isn’t “big” or new, but simply tuning the numbers. This is some of the easiest work to do, but also will benefit the most from actually getting humans involved since the real test of how well it’s working will be seeing what interesting interactions players dredge up.

Pre-Match Setup

Ship-to-ship combat is only part of a playable Melee experience. The other half—maybe more like a third or a quarter—is in getting in and out of the actual match. That means being able to configure the match you’re about to play as easily and enjoyably as possible. At a minimum, we need to let players pick who they’re playing with: an AI opponent, a local human opponent, or a remote opponent. For remote play, there are some additional steps to link up with whomever you’re trying to play with. Then players can set up their rosters of ships to bring into battle, and in the case of fighting against AI, you can decide which ships your opponent has.

Last milestone, we wrote a bit about our work on this section. The user experience (UX) for doing this was functional enough for us to test our features, but it was not necessarily fun or intuitive to use. This milestone, we finally put some work into making a UX that we thought players would enjoy using so they could actually have some success (and fun!) getting into a match. Animations show this better than words, but the goal of the UX is that players understand the questions we’re asking and understand how to change their minds if they want to. Our flow for the game is simply:

• What do you want to do? Play Melee, play Adventure, change settings, etc. Assume we pick Melee.
• How do you want to play Melee? Locally, or networked (inviting someone or joining someone). Assume we pick locally.
• Who’s the second player? An AI or a human. Assume we pick a human.
• Select your ships and prepare for battle.

The idea is to have an understandable outcome with whatever choices you make, with the “questions” and ability to change the “answers” made clear. If you are playing against an AI and change your mind because you want to play with a player, you should be able to figure out how to accomplish that in the game. If this sounds like UX 101, it’s because it is! It also provides a foundation for us to change the flow if we see players struggling or wishing they could do things differently.

It’s not necessarily fun work to describe, but just as we had to fix many bugs in Melee so that players wouldn’t immediately run into walls, the same work happened for our menus. We actually have a pretty sophisticated set of menu needs since there are so many ways to play and control our game—keyboard alone, keyboard and controller as a single player, or keyboard and controller with two players, or controller or controller with two players.

You could accidentally get yourself into so much trouble in our working builds, by doing things like pausing over menus where we didn’t expect that, or changing which device is doing what at different times, or even when we switch between two-player and one-player controls. We have the somewhat unique need for two different input devices to be able to either control the same menu (like navigating through the settings menu)—or to control two separate menus at the same time (like both players picking ships for their roster independently). Even crazier, you might be playing with a remote player who is controlling a menu on their side that you want or need to see.

An important part of the experience of being together with a networked player involves sharing and observing player actions. In-game during Melee, that’s easy! You’ll both be watching each other pilot your ships and fight. During a menu, we want to represent what the other player is doing, even if that’s just moving a cursor around the menu. It’s not exactly world-shaking gameplay, but it’s important to the shared feeling of making decisions together. To make this work, we created a novel, low-bandwidth method to pass this information back and forth across the network so even the experience of selecting ships (especially that!) can be a fun experience. You get to both watch each other and debate what’s happening, if you have some method of voice comms.

Part of the soul of competitive play can be coming up with bespoke “house rules” to follow on top of whatever restrictions the game itself puts on top of players. Letting people connect while they play in the menus encourages this! And, hey, it’s a thousand times easier to take a feature away if we don’t want it than it is to create it in the first place. We can imagine players opting into a “hidden draft” feature which conceals what’s going on in the menus for players to have fun secretly drafting their roster with only the point tally visible. 

Melee for All

Melee is coming to Steam and GOG to serve as our Children of Infinity demo. As mused upon in our previous update, Melee is not quite the perfect demo for the story mode since there’s no story mode in it! That said, releasing it this way nets us tons of advantages. Chiefly: we can get something out in the wild to get people playing Children of Infinity, having fun with it, and talking about it.

We know full well that many of you are excited for the story and might even be holding out primarily for that, but getting something out before that is for everyone else, as well as us! Player responses of all kinds are invaluable feedback for us. Everything from “this crashes” to “my sister keeps crushing me with the Druuge Mauler, pls nerf” will be something new we haven’t been able to find out yet.

On our road to this Melee release has been work on the multiplayer backbone of our technology, which has been most of Fred’s focus, but he’s also been responsible for ensuring the game runs on all of our platforms—platforms like the Switch. Thus far, the prospect of network play on Switch had been, let us say, highly speculative. Of course we want all of our versions to support the same things, but there are all kinds of limitations and nuances to each platform. All of them seem to share a common rule, though: the more players we let play together, the less performant the game becomes. And we really weren’t sure about some of the Switch’s limitations.

Our networking code is serverless and peer to peer (P2P), which has given us many advantages already, but new ones continue to be revealed to us. It just so happens that our networking solution was a shoo-in for how the Switch does its networking, and in the course of exploring what networked play would look like there, Fred was able to get a few exciting proofs of concept running.

As far as we can tell, there is an extremely limited subset of games which support the Switch’s local wireless multiplayer feature. This feature lets you and another player with a Switch play together on separate consoles just by standing nearby, even if you have no Internet connection. This was a perfect fit for our P2P networking solution, since the Switch happens to expect no server in this case, and Fred was able to prove it out.

From there, it was a baby step (for Fred, anyway) to get local area network play functioning as well. As of now, we were able to play not just two player Melee on Switch, but when I (Dan) went up for a visit, I brought my console and we proved that three player Melee would run as well! As a reminder, we’re not targeting more than 1v1 for any initial Melee version. We’re still not sure what the actual release will permit on Switch, but it was fun to see things working on a technical level. Fred continues to explore Switch’s online networking.

We think it’s pretty cool that we can support such a niche feature for Switch! We actually don’t know of any other third-party (i.e. not Nintendo-published) game that does this. This is just one example of how we’re trying to cater to platforms’ specialities as the opportunities arise. If you’re used to playing with friends on Steam or GOG, you’ll know that they have friends list features for playing together. We want you to be able to use those! On platforms which allow it, we’ll also allow for what we call vanilla networking, where you can join together with our P2P networking without requiring any intermediary service. This is part of our goal of making sure our game can still function well into the future, even if Steam, GOG, and Nintendo services all vanish. We’re not expecting that, but preservation of our work is important to us—just as it was for the UQM project—as we see an increasingly software-as-a-service model take over. It’s your game, darn it! It should always work!

In a very recent and exciting extension of our vanilla support, Fred was able to add completely standalone networking to our game! Previously, we had relied upon someone running a service which was needed to connect peers together. You could run it yourself, and as you can see from the link, it’s freely available and provided by Valve. It’s not a server. It is more like a switchboard operator since it doesn’t do anything besides route the initial connection. With Fred’s new work, that functionality is simply built into the game, making it that much easier to play with friends on a local area network.

The last bit of technical work on the road to getting our Melee release ready for public consumption was, funnily enough, being able to make a decent Melee-only build of the game for the first time. We had a technical solution for splitting our data up, but we still had to go in and restructure our huge pile of data to match the intent. For example, just because an alien’s ship is in the game doesn’t mean we need its conversation assets or dialogue lines. Plus, they’re secret! You can have them when we’re done. We successfully split up most of our data so that we can add on the Adventure elements as needed, and there’s still more we can do which is largely for the sake of optimizing our build sizes/complexity. As of now, the Melee build is only 2GB, while the full Adventure build is around 6GB.

Last and but not least on our technical checklist was upgrading from Godot 4.3.x to Godot 4.4.x. This is most important for the Switch as we want to track W4 Games’ changes as closely as possible, but it also contained a few boring but important technical features and fixes which we were bumping into on our previous 4.3.1 version. Upgrades always bring a momentary disruption as the earth beneath the software shifts around, but tackling it makes life easier when we want to release something. For the layperson: number goes up = good! Editor’s Note: I am surprised if the layperson is still reading at this point.

Shipping and Handling Included

There are so many stories to tell about the Kickstarter reward creation at this point that it warrants an entire retrospective when we’re done with everything. As of today, we’ve moved to the final stages of our manufacturing and getting everything ready to ship. As if making an entire game wasn’t a big enough undertaking, we’re preparing to send out over 2,000 packages with all of your rewards! We had to acquire the packing and shipping materials, organize everything in our shipping depot (my kitchen), and make a logistics plan for how we were going to actually pack those 2,000 packages. Then we had to get the right shipping labels and, for our international folks, the right customs declarations on them.

Below are some photos of the whole journey to actually get everything here before we get it all to you.

Since the last update, we managed to get our 10,000+ pins and thousands of patches manufactured in China, shipped here, and approved through customs. Of course, all of the boxes except one were delivered all at once, with the last one being sorted separately. It even went out for delivery once by itself, but was returned to the shipping depot.

This got especially anxious when I was taking inventory, and found all of our items accounted for…except the Yehat pins. Each of the boxes delivered only contained about 1,000 pins. I was waiting for one more box, and I was missing 2,000 Yehat pins. You can only imagine my anxiety until that last box arrived wondering what we’d have to do if everything was here except a tiny fraction of one item. I ended up contacting our manufacturing partner before the box’s arrival, and they confirmed: yes, our wayward package had 2,000 pins in it. Maybe that’s why it was sorted differently! Or someone really just wanted to get a look at the Yehat pins.

With that out of the way, I now have over 10,000 pins sitting in my home. They’re really, really cool! They’ll be even cooler when I get them out of here and into your homes. Before the pins arrived, we started planning how to actually pack and ship everything. We covered most of this, including a video showing some of it, in our last update regarding shipping. The information there is still accurate, but backers who are receiving Star Maps will be getting their shipments later since we are still waiting on their delivery.

A few interesting tidbits not previously mentioned: we actually put a bit of work into finding the right shipping supplier. We had to find supplies which matched very particular dimensions and be as efficient as possible with size and weight while fitting our particularly-sized things that need to not become bent in transit. If possible, we wanted to find a local manufacturer and avoid America’s omnipresent shipping supplier (thanks to whoever anonymously runs that site for helping us with resources, too!).

After checking with dozens of manufacturers for what we needed, we were able to find someone local in California. The bubble mailers have some plastic just because we don’t want things getting damaged, but otherwise we were happy to do what we could to be as conscientious as possible with our materials usage and to also support a nearby business.

The Year Ahead

As this jam-packed year ends, we look forward to the next one and all of the exciting things it will bring. While it seems like we’ve been at this for a while (we have!), and we’ve had to maneuver around many obstacles (we have!), it’s also hard to describe how exciting it feels like to see our myriad goalposts not just coming into view, but getting so dang near.

As mentioned above, we’ll have our free Melee version coming to Steam and GOG. That will be one piece of the beginning of building our marketing ramp toward our final release. We want to make a great game, and we also want people to know about it and come participate in our community. This isn’t just running ads or trying to trick people into anything, but marketing with respect: informing people about the game and why we think it might appeal to them. Just like our lead-up to the Kickstarter included things to get you aware and excited, our game release will have some pot-stirring as it prepares for liftoff too. Just as some of our awesome community helped us spread the word before, you will be a part of this important mission too!

We’ll be reorganizing our Discord to better serve our community that has been along with us for this ride. We expect new people to be joining our spaces—people who want to still participate while avoiding story spoilers, and even people meeting up to play Melee! We’ll be moving from people coming in asking about when COI is coming to asking about how to beat a particular ship. We touched on this in the last update, and we’re going to be focusing on Discord in the next year. One community member suggested cross-posting these updates to Steam so people there could be in the loop, and we’ll be going forward with that to help us reach as many people as we can, wherever they are. We can’t be everywhere at once for discussion, and it’s already some manual labor to post these updates on Kickstarter, Patreon, and our own blog. But we can manage having conversations on Discord and want people to join in there.

After over four—or five, if we include Fred’s foundational work on Simple!—years of development, it seems like it’s been such a long effort. We’ve been in full production for a bit over two years, which is longer than most of our other projects besides the first Skylanders, but this is also such a different project with a different team, too. Compared to those long-seeming chunks of time, we have to remind ourselves that being months away from releasing something is enticingly and relatively close. We’re really in the home stretch now. We can probably say it a hundred times and the feeling still won’t be expressed completely, but: oh my gosh. It’s happening!

We don’t want to give a hard or even a soft release date for the finished game at this point, but our schedule has us on track for an English PC/Linux/Mac release on Steam and GOG in Q3 of 2026. The Switch would follow (or coincide with) it, and then we’ll be tackling PS5/Xbox and localizations. Why don’t we want to give this date? Unlike a studio with a publisher or a larger staff, we are more affected by our team members’ individual needs that may arise. Any changes that could come up are more likely to make this move.

One question we’ve gotten from people is if we’re able to provide some of the physical rewards from the Kickstarter for individual sale, for those of you who are excited now that you can see how cool they are. The short answer is: probably! The longer answer is that we have a lot on our plate already and need to be mindful of taking on more. We did manufacture more than we needed, so we have extras of some items. We’d love to run a little operation to let people get their hands on things they missed, and we’ll let people know how that will work if we can get to it. It will likely not be right away, since we must prioritize fulfilling rewards for everyone who has already backed—and, of course, we also have to get the game done.

A Happy Holiday

It’s time to wrap up: this blog post, your presents, and 2025. This is the season with many holidays for many people. Many of us will be taking some time to have a quiet break, to be with loved ones, to celebrate, or to gorge ourselves on sumptuous meals. Maybe all of the above! We hope you have time for whichever of those you desire, whatever the holidays mean to you. For me, the winter holidays always mark special activities and being extra busy, but they’re also a time for reflecting.

Especially as this year of what feels to me like larger-than-previously-ever-seen tumult closes, I reflect on just how important people are to me. There are so many in my life: the people reading this message, the people who’ve supported this project at any step of the journey and sent kind messages, all the people I know as friends or work with, and my loving partner. Without those people, my life would be so empty. Our lives would be so empty without each other.

Against the often-seemingly unstoppable odds of the crushing machinery procured and pushed by those which we seem helpless to reason with and who, themselves, seem hellbent on shaping our futures from their—according to them—unassailably correct vision of the future: you, humans, are still what matters. We are irreplaceable and we are more than can be summed up by anyone, much less anything.

Happy Holidays from us at Pistol Shrimp.

A special thank you goes out to our Patreon community who continues to support us. Whether you have been loudly cheering us on from the beginning or hopped on board as the train picked up speed: thank you

Please join us on Discord, Bluesky, and Reddit to be a part of our community. You, too, can still support us on Patreon as well.

Hello, beautiful backers of our project who are receiving physical rewards! We wanted to share a brief shipping update with all of you. Starting next week, we’re going to be locking your address in BackerKit. You should receive an email alert on Monday or Tuesday giving you a final chance to make any changes in case you changed addresses. You can change your mailing address through your survey link at any time until we lock them mid next week. If you lost your survey link, enter the email address you used on Kickstarter/BackerKit in the “Lost your Survey” box at our BackerKit page. If you miss the email deadline and need to change your address or can’t access your survey, please contact us immediately through BackerKit! For digital-only backers, no action is needed.

There are still a few backers who still need to fill out their surveys, and Apple’s Private Relay might be causing some difficulty with our emails getting through to those folks. Likewise, we’ve had trouble charging a few cards for late backers and cannot ship your rewards until that succeeds. We’ve been trying to reach you! Please get in touch if you need help updating your payment method or haven’t been receiving emails from BackerKit.

The current plan for shipping is to have packages going out starting around December 15th for some backers, and finishing as late as early January depending on how quickly we can work. Delivery to the United States should be pretty fast, but international delivery will probably take longer! Domestic shipping will be done via USPS (United States Postal Service), and international shipping will be done via USPS First Class International or UPS Worldwide Expedited, depending on the destination. For international backers, we’ll have customs forms on our packages to help with any duties/VAT involved for receiving. If you are concerned you’ll be unable to receive a package during this time, we can ship it later! Message us on BackerKit.

We had hoped to start shipping sooner, but there was an unfortunate, longer-than-expected manufacturing delay with the Starmap. The other delay has been getting our pins and patches through customs, which should be done by next week (we say, crossing all of our fingers and toes). As the Spathi say, “We’ll believe it when we see it!” And also probably “We’ll run when we see it.”

The plan for shipping in December is contingent on those things happening on time. There are a sizable number of backers who aren’t getting a Starmap, and if that’s the only thing still delayed, we’ll simply start sending out Starmap-less packages first.

Even amidst all the delays and hurdles, getting everything prepped and seeing it come together is so exciting! We really can’t wait to get these things in your hands. We have a longer update in the works with more details about development, but for now, please enjoy this tour of our mailroom and shipping warehouse.

If you have any questions about your survey or shipping, please reach out on BackerKit.

Humans of Earth! It is that time again, or possibly past that time. No matter: grab your favorite liquid, prepare a good repast, and buckle your eyeballs into their sockets for the thrilling text adventure that awaits as we review the progress we’ve made on Children of Infinity and its attendant parts!

Before we go deep, there are two important pieces of information we want to make sure you see, even if you read nothing else: spoiler warnings incoming as well as cards being charged in BackerKit for late backers or those who got add-ons.

First: going forward, this is the last update you can expect which we guarantee has no game spoilers at all. That’s not to say all future ones will all have some, but we expect information to breach containment slowly as we show more and more finished work. Names and images of aliens in the game are likely to start entering the wild, at a minimum. Nothing that you wouldn’t find out from reading marketing material, and we do want to tell people about what’s in our game! Our Lorebook, which we’ll get deeper into in a bit, contains bits of information that we almost certainly won’t share, but that backers will receive before the game is out. They might share information and we can’t really stop them! As we start to want to explain more of what the story is about, it will become clear just who from UQM or The Beyond is involved, along with vague story arcs and possible names of villains and friends.

Second: if you pledged funds on BackerKit either as a late pledge or to get add-ons, this is your final heads-up that we’ll be locking all the orders and charging your cards shortly. Please be on the lookout for emails around this, especially if we have trouble charging your credit cards. BackerKit will send emails nagging you, but be sure you’re getting them! As a reminder, we know we’ve had trouble with Apple’s private relay bouncing emails in the past. If you signed up with one of those addresses and aren’t receiving any emails from BackerKit or have any other troubles with your order/survey, please contact us. If you don’t have your survey link, just use the “Lost your survey?” section on the BackerKit page.

I Wanna Be Updated

Some of this update will be sharing the progress and what we’re working on, but we’re also going to be sharing some of our plans that are about to go into motion as well as look for your feedback on the things you’re excited about. We are in the middle of some big decisions, and they all revolve around all of you! If you pledged for physical rewards, we’ll have some information and updates on those as well.

We have been mostly focused on polishing a very narrow, essential part of the game: Melee! In particular, the ‘stand-alone’ melee experience where you can pick a bunch of ships, get into a match with an AI or human opponent, and start playing. We’ve been creating VFX, updating ship hit boxes, finalizing ship designs and fixing bugs, and putting in all the work so that we can reasonably put a player who knows nothing into the Melee experience, let them pick whatever ships they want, and see if they have fun. This is a critical benchmark for being able to do what we had brought up before, which is playtesting.

Getting this all right has caused our plans for what the released version of the game looks like to spread out a bit, and we’d like to share these plans with you.

When our previous games were released in the 90s, they were technically two games released in sequence! Before the Ur-Quan Masters, there was a game before it which had a little taste of the story and universe told mostly through the 1v1 combat of Melee.

We’re not suddenly making a separate game, but we decided it would make a lot of sense to take the Melee experience to completion as soon as possible so it could get into more hands. We put together a plan which would actually give us a total of four possible versions which would serve as our next milestones and also allow us, if we wanted to, to even make them into releases to certain audiences. We’ll talk more about our thinking and our questions about that, but let’s first talk about the four iterations of our game we’re going to be building towards. When they come out and if they come out (beyond internal playtesting) is separate and covered in a bit.

Introducing our four builds: Melee Playtest, Adventure Lite, Adventure Medium, Adventure Full, and, finally, the one which is most certainly released to all of you: Version 1.0.

Like a Version

The Melee Playtest is what we’d consider the first, fully playable version of the game. It just doesn’t have the Adventure mode with the story! It will have 1v1 melee play in all of its intended forms: local against an AI, local between two players, and networked between two players. Whether or not we include all of our ships is an open question if we want it to be, mostly revolving around who plays it and if we release this version. There are actually a lot of things in this version from a tech backbone standpoint: support for different input devices (controllers and keyboards), nuances around just playing a network game, and also being able to carve our game data up into a melee only subset. This and our subsequent versions until 1.0 would be for PC/Linux/Mac working with Steam & GOG (i.e. not consoles).

Adventure Lite is the first playable version of our Adventure mode with a very small slice of the story centering around just a handful of aliens. Only single player would be supported, but along with the Melee gameplay experience we’d also have HyperSpace, Interplanetary, Planetside, and Comms. The storyline would be set up to focus on a particular climax of our characters’ stories in the middle of the game. Think of it as the first third of the game’s main story, but with a lot of caveats about order since it’s an open world game. In a full playthrough, players might find other things first! It’s possible we’d actually use a limited Starmap or other barrier in HyperSpace to further contain the experience. Likely included in this version would also be the work from the Melee Playtest, just as a standalone Melee mode a la UQM.

Adventure Medium is an extension of Adventure Lite but with more gameplay features. We would include Gas Giants, Interiors with Floyd, and Trading Posts. We’d also allow multiple players to play cooperatively. The amount of additional story and characters we include in this version is a bit of a sliding scale, but the main focus would be on features and not additional story.

Adventure Full is what it sounds like! It is the full experience of the story. All of the game’s story would be playable from the very beginning to the end along with all of our aliens available. It would include all of the intended gameplay we had built in the prior versions and be playable solo or cooperatively.

Lastly, for the purposes of the current releases, we come to version 1.0, which is just Adventure Full but with full VO support. There may be platform-specific features we didn’t fully implement which would be available here too, like Achievements or being able to play network games via your platform’s native tools (selecting your friend on GOG and joining their game through that interface, for example). It should go without saying, but we always expect some number of bugs in everything we do. 1.0 would strive to have as few bugs as possible from Adventure Full.

There will be some amount of post-1.0 work, as well. At the very least, this will include localization and console versions, with the Switch taking precedence before we do the Xbox and PS5 versions. Depending on how things go, Switch and localization might just become part of a 1.0 release. One thing on the edge is really extensive modding support. We have planned for it from the very beginning, but it’s possible focusing on making it awesome will take our limited resources away, and we’d rather have a great game out first. There is a wide world of possible post-1.0 work, with plenty of people asking about things like Switch 2, but we want to finish all of our commitments we made first before making any new ones.

The only date we’re firmly committed to and track for right now is our Melee Playtest being done in October. Beyond that, we have some working dates, but it depends on a few other decisions: namely what versions we release and to whom. We can at least say the absolute earliest that Adventure Full will be done is May 2026. We are going to need some time to get all of our ducks in a row to our satisfaction.

Wait of the World

Our choice to spend more time is simple: it will make the game better. However, we didn’t want to just say to ourselves and all of you that it would be that long before we can get more people playing it, since getting it in players’ hands is also a key part of making it better. The compromise became putting Melee in front and working on our Adventure Lite slice. So why did we put Melee in front and what does it have to do with the time it’ll take for Adventure?

Firstly, it’s not just a fun observation to point out that we’re following in the footsteps of the originals, since there’s a reason to approach it that way. We bit off a lot for our adventure mode, and one of the challenges there which does echo the originals is that improving one area of gameplay doesn’t intrinsically improve the others. Making Melee really nice doesn’t improve gameplay on Planetside or improve the experience conversing with an alien. By freeing ourselves mentally from trying to lift the quality bar of everything needed to experience the story across the whole galaxy all at once, we can get a better, more focused result.

Secondly, our writing has taken longer than planned for a few reasons, and we want to allow for that time. The one we could see coming was simple: doing voice-overs for a game like ours is hard. We don’t mean just finding a great voice actor and getting lines recorded and in the game—we mean that once we record something, it’s pretty much set in stone. We can sometimes have the opportunity to do additional recording sessions, but that involves a lot of coordination and budget concerns and is overall something we want to avoid. There’s a reason it was our costliest stretch goal, and it is a real stretch as we had predicted.

Because there was a knock-on effect of slower writing leading to a further delayed voice recording schedule, it adds an extra slice of work for our Narrative Lead, Mallory. She is the one who holds the whole story in her head and can effectively communicate what’s needed to writers or voice actors. If she’s helping a voice actor, she isn’t helping a writer, building a conversation flow, or writing herself. If we had finished with our writing sooner, she wouldn’t be having to split focus. Getting everything truly, one hundred percent polished so it could be recorded involved a lot of playtime and feedback from not just Mallory, but myself as well.

By creating our Adventure Lite and Adventure Full versions, we are giving ourselves permission to build and play our game without having the VO deadlines constantly in front of us. There are still some VO deadlines we are trying to hit because we have found voice actors and have a lot of writing truly done, but otherwise we get to put that on pause.

After doing the scheduling shuffle where we scoped our different versions, we were immediately able to work in a more productive fashion! With new deadlines leaving more time for reviews, we also didn’t have to put time into helping voice actors do the recordings too. We feel much happier and confident about the end result since we have more time to play the game and truly experience the writing in situ, especially for characters which have longer, more complex arcs that interact with others (okay, that’s almost everyone in the game, but some are more sophisticated than others). We’ve built in additional buffer time for some of those characters so we get a chance to revisit them too.

The last reason our writing has been taking longer is that our writers needed more time than we gave them. Some reasons were not on the writers as we called out above. If we can’t review it, they can’t finish it! However, some of our writers were directly impacted by international, armed conflicts. For obvious reasons they have needed more time to finish their work, and we really couldn’t have predicted or imagined the impact because we’ve never dealt with it. We all wish for a world where people aren’t dealing with life and death decisions, but they are far more important than any work for our game.

These are just the things that slowed us down, with a few nods towards the advantages of taking our time that we’re already realizing. There are many upsides to having these versions, and our biggest questions are around what our strategy ought to be for actually playtesting them or trying to spin them into full releases.

Left to My Own Devices

There are effectively three types of releases to consider for any of the versions we’re working on:

• Playtest: Something meant to represent the final result but clearly not finished, where we’re mostly focusing on getting feedback and observing results. We wouldn’t expect someone to necessarily want to buy and play the game after this.
• Demo: Something meant to represent the final game which feels finished, even if the player can’t experience all of it. We would want someone having played this to leave wanting more: “Wow, this is awesome! I can’t wait to buy and play this game and tell all my friends and enemies about it!” 
• Early Access: Something meant to represent the final result, finished enough to be coherent and fun, and with a clearly described path toward completion. Players who want to try this would be willing to accept some missing things, but we would want players to be excited to come back and see what’s been added along the way or upon 1.0.

We have written a deep dive as a separate piece if you want some more context and information on the three release types. Give it a read if you want to explore the myriad considerations we’re putting into our decisions!

Here’s what we’re thinking right now.

We would love to get Melee in the hands of people to play with as soon as possible. We’re not sure how wide that group of people is, but we’ve been the only ones playing Melee for far too long, and especially the 1v1 version is at a point where we’re all curious what people will do with it. Because it stands alone from Adventure mode and there’s not a lot of story secrets contained in it, we’d just love to let people play with it and have fun! We think it’s fun. We want you to try too!

We have already decided to take our extra time for the story to make it just the way we want. The more we can just focus on the Adventure mode being a great experience, the better it will be. It really is like a separate game! Having an Early Access period does feel like it would be a marketing risk, since, although we aren’t labeling it as a Demo, if it feels like the game is unfinished, it can still leave a bad taste in players’ mouths. As Greg Kasavin has said regarding his own Early Access release of Hades: players pretty much expect a finished game. Parts can be missing, but what’s there better be fun to play! This tends to point us toward at least some sufficient playtesting and polish level before an Early Access, if we did that. Would Adventure Lite be a good Early Access? Or would something a little further along serve it better?

If we did go down the Early Access path, we’d be pretty strict about the duration and our schedule. It wouldn’t be an indefinite, “finished when it’s done” development effort, but something with a clear schedule with deliveries we’d provide. We think some of our Adventure Lite to Medium to Full lends itself well to Early Access, since we can graduate some of the things in Medium. For example, one release could include Adventure Co-Op. The subsequent one could include Gas Giant and Interior gameplay. Then we could add on the Trading and the full HyperSpace experience. Then the one after it would be Adventure Full with the whole story, with the subsequent 1.0 release being our 1.0 release.

One last simple advantage to Early Access is also income! Right now we have gotten ongoing support from Patreon as well as plenty of late backers supporting us in BackerKit, which is wonderful, but not everyone is going to pay for something they can’t play yet. More funds means more investment in our work, especially things which are at the end of our ‘feature tail’. For example, we don’t have the bandwidth to work on our ports or localization in tandem with our initial 1.0 release, but what if we could afford to bring in additional support to do that? That would be a win for us and the players looking to play on other platforms or in other languages! 

The final consideration is simply: what about our players who don’t need convincing about anything at all, like our Kickstarter backers? We know there are some people who are happy to wait. We also can imagine there are people who are champing at the bit and hungry to get their hands on some of our work. Is there a serendipitous path that lets everyone get what they want? For example, using the Early Access concept above, if you wanted to play it as soon as possible, you could do that! It might not have voice overs, for example, but with the above strategy of clear deadlines for features we’d be hitting, you’d know how long to wait for the features you care about.

As you can see, there isn’t yet a clear decision, but there are some possibilities. We are pretty certain we want to get Melee out there as a standalone version, whether it’s a playtest or some other form. Where we’re still weighing our options is in the Adventure mode and if using one of the more limited versions as an Early Access or a Demo makes sense.

Whatever we do, if we are able to follow a strategy which creates a great game, we want to do that! The better our game is, the more it makes everything… well, better. It’s better for you, and it’s better for us, since our success with this game means a brighter future too.

What do you think? We want to know! While you mull that over, let’s take a look at some of the work we’ve been doing besides just planning!

Take a Chance on Melee

As you might imagine since we’ve narrowed our focus, Melee has progressed by leaps and bounds since we last shared it! All of our 38 ships are fully playable as intended and have visual effects tied to their weapons. While we finished the ships’ core art, visual effects are a separate effort to add character, color, and in some cases communicate gameplay. Shields and other unique behaviors need a visual language so they are understood by a player.

Several ships have gotten audio passes, which couldn’t happen without the visual effect to indicate what the audio might be, and we started adding some of the more general audio behaviors like collision sounds for when ships bump one another, or asteroids, or the planet. All of the captains’ windows are connected, including some which have special behaviors like the Scout and the Spirit (a new ship).

Last but certainly not least, we’ve put in a little bit of polish work on the theatrics of ship destruction in Melee with the one moment of calm: the sequence between destruction of your ship and picking a new one. We are very excited to bring forward a favorite feature from UQM by having a unique musical ditty play depending on the victorious alien! They were all composed by Justin McGehee who had a ton of fun making unique, expressive tunes which players will relish—or loathe, depending on which side you’re on—hearing.

We put a pass into our HUD (the non-interactive UI elements on screen) to support our intended vision as well as some of our new design features, like a minimap, which is possibly nifty in 1v1 mode but will be an important part of communicating target selection when more ships get involved. 

There’s a lot of things which can happen before you actually start duking it out in standalone Melee. Having what we call a “lobby” where players can join up and configure their ship rosters is an important part of a match. Right now, we only support setting up a 1v1 match against either a local player, remote player, or local AI, but in the future we’ll add controls for setting up other match types with more players. The core 1v1 experience is finally working, and completing it lets us provide a setup where players can configure a match, play it, and then return to either play a rematch or reconfigure things for a different type of match. This required a lot of under-the-hood work and also was a lever for building some more complete menus.

Beyond just what was needed for the lobby, our Menus (interactive UI) have also seen a ton of progress and new features. We had completed their art assets last milestone, but there was work to actually hook them up and get the correct behaviors in-game. We implemented a few of the first art pieces for regular buttons and menu frames along with unique widgets that have different interactions like checkboxes (e.g. ready?), sliders (e.g. volume), and toggles (e.g. language). are starting to have menus which don’t just look like a bunch of placeholder items and even have some of the intended user experience for buttons which interact differently, like a slider. We’ll still have more work to do here, especially for the Adventure modes with a lot of unique menuing needs, but, ironically, Adventure has already received a bit more UI love since we knew it would have some more bespoke elements like the Starmap.

Local 1v1 Melee presented a unique UI challenge which was somewhat different from our other modes we had been putting effort into (online Melee, split-screen Adventure co-op). Both players share one viewport (physical gameplay screen) but each player will often want to have their own menu screen, possibly at the same time. For example, when players are selecting their ship rosters for a match of Melee, each of them should be able to independently play around in their menus to pick and change ships.

This was previously possible in split-screen because the menus were tied to the viewports, one-to-one. Some work had to be done for the special case of local co-op with a shared gameplay space, since that rule wasn’t valid anymore. Now we can have menus for both players in a shared viewport, and we can even follow that same rule when playing single player by letting one player control both menus—think of playing 1v1 against an AI and wanting to go change the AI player’s ship roster. We also are able to have shared menus both players can interact with locally, like the pause menu, which can overrule gameplay-specific ones like ship selection.

Describing some of these nitty-gritty features, all of these things seem like features which ought to exist! They don’t until they’re created, though, and it’s not always trivial to make them. It is, however, a lot of fun to see our vision come to life for all of these seemingly small touches, which will make controlling the game fun and not frustrating. Of course we want friction and frustration in gameplay challenges that require it, but “getting into a match to play with the ships you want” shouldn’t be the hard part.

We Are the Robots

Most recently, Fred and I have been putting work into our Ship AI for playing against computer opponents, which is important since it is needed in both stand-alone Melee or the Adventure mode. We could do a really deep dive on the ship AI at some point, but the short version is that it’s a collaboration we’re developing that combines some flexibility on my side to support different ships’ powers and creating some unique character when a human isn’t behind the helm, while also ceding the “smarts” to the smart half of the operation, Fred.

We spent a couple weeks creating a decent proof of concept Melee AI probably two years ago and even showed it during our development streams. I was able to script a few unique ships around it, from simple ones like the Ur-Quan Dreadnought which just wants to shoot you to more complicated ones like the Kohr-Ah which has a more specific version of shooting based on how it controls—holding the key to launch a blade and releasing the key to stop its flight. It was enough to convince us the strategy was sound, but we left it on the shelf until recently.

The way it works, at a high level, is that the AI has access to a few pieces of information: things it wants to pursue (usually the enemy ship!), objects it might want to avoid (enemy missiles, the planet), and what steps it would need to take to land a shot with its weapons. Fred’s AI code just tells me which of those are most imminent and what direction a ship should go if it wants to achieve that goal.

In the case of the Druuge Mauler, it is just going to do its best to keep its distance, train its weapons on you, and fire. Its secondary power, sacrificing crew for energy, doesn’t really have much to do with the state of the world, so it doesn’t need to know as much. It’s not a terribly maneuverable ship, so it’s unlikely it would ever try to dodge fast moving things, but it would still try to steer clear of the planet. The “winning strategy” for the Druuge is just going to be focusing on the weapons all the time.

In the case of the Yehat Terminator, it wants to get pretty close to you and fire as much as possible, but it also has a shield to block damage. Using the avoid rules above, a Yehat knows it doesn’t need to dodge things like enemy weapons, but it can detect when a collision is imminent and react by raising its shields. An incredibly rude version of the Arilou Skiff was also made by having it teleport any time a collision is about to occur. It’s absolutely infuriating (success!).

For a Pkunk Fury, it also wants to get close to you, but it’s a fairly maneuverable ship with a very short range weapon and slow energy regeneration. The Fury pays more attention to avoidance and keeping out of range of its opponent’s weapons until it has enough energy to do some damage when it tries to close in. Since the Fury can avoid a lot of weapons fire, it will actually try to steer to avoid missiles. Once it gets in close and expends its energy, it’ll soar off until it can come in for another pass.

What’s especially cool to us about this AI approach is that, while the AI can have a spectrum of ‘knowledge’ about the battle and the physical relationships of objects, ranging from perfectly calculating all trajectories to maybe being a little imperfect sometimes so it’s not too good, it can’t cheat. All the AI scripts do are emulate key presses! While they can be really good at timing the presses, they can’t do anything a human can’t do. If you’re familiar with some tool-assisted speedrunning which just plays back a sequence of inputs that a human could hypothetically do, it’s a bit like that.

I could go on and on explaining the nuances of how it works, but the last, important take-away is that we’ve only found what makes a good ship AI by trying a whole bunch to make good ship AIs. As I go through each ship and try to make it behave in a way which is fun and at least understandable, I might stumble on new questions which Fred and I figure out answers to together. Until we started to make ships like the Pkunk Fury, who can avoid a lot of weapons, and the Earthling Cruiser, who can’t avoid many weapons but pretty much always wants to stay at an ideal range, we didn’t have the concept of separate chase and avoid information. Fred’s code would just give me one option, but we quickly discovered that both pieces of information would be relevant.

At time of writing, we’re through almost all of the UQM ships and have done a few of the new ships as well. As we polish the AI more, we can give them additional pieces of information, like inspecting the flight and weapon characteristics of an enemy ship to slightly alter its optimal play. For example, an Androsynth Blazer should prioritize use of its comet form against a Dreadnought because it’s so slow, but it might want to consider more bubbles against a fast ship that it can’t ram as easily like a Pkunk Fury. There can be special case matchup tables as well, so a Ur-Quan Dreadnought knows not to even bother with fighters against an Earthling Cruiser, since they’ll just get shot down. 

It’s really cool to see our design panning out and the improvements we’re making having an impact on playing against AI in Melee. From a design standpoint, even setting up ships to just “play a certain way” that’s fun and unique, even if a human player might not always do that, is also a surprise treat. Ships have a lot of unique identity even just in the hands of a human player, but having their AI do specific things will make them even more characterful and even possibly give players ideas about how to play them.

Space to Face

We can write and write and write—and we will write and write and write—but it’s at the point where a video will be a lot easier to appreciate than our explanations. Check out the video below which just showcases some Melee gameplay as it can be experienced now. Audio levels and mixing have not been tuned yet, and there is still polish to do, but it’s pretty close to feeling real at this point! For now, we’re only showing UQM ships per our spoiler warning above, but the rest are there too.

Let’s Get Physical (Rewards)

Regardless of our game release date(s), we are on track to deliver physical Kickstarter rewards this year, barring any extreme surprises! We’ve been updating everyone about our progress on these as we go for most of them, but we’ve started on (and in some cases finished) our print items, the Starmap, Lorebook, and Thank You Card, which we were saving for the end.

We talked about the sticker sheets and the patch in our previous updates, and we were awaiting one last revision on the sticker coating to verify our work. The bulk sticker order is ready to go and should be going out by the time you read this. Our patch was already perfect, and we’re just waiting to finish tweaks to our pins to do the bulk order together, since we’re using the same manufacturing partner for both.

Speaking of pins, let’s talk about the pins! They have been the most complicated to manufacture. Mandy, our pin artist, has done manufacturing before, but we’ve had a few extra challenges thrown at us that have slowed us down. Since our last update, we did one round of samples where we were able to see the results and then make corrections as needed. In one case, the first pass was already perfect (Chmmr). In a couple cases, the design worked just fine, but we had a few color corrections based on how they looked in real life (Spathi, Yehat) or needed to tweak the metal treatment for better results (Ur-Quan). You can see what the samples looked like here. They’re super cool, even the ones which needed fixes!

Ironically, the villain of UQM has been the villain of our pin production: The Kohr-Ah Marauder! We’re sharing this with you because it’s funny, not because it’s what the end result will look like. With that in mind, in the first pass of the Marauder, you can see how beautifully shiny it is, and also the polishing has stripped away some of the red details on the runes.

Look, we all know it’s not supposed to be silver, but there was a mixup with the manufacturer, and I’m guessing they’ve never played UQM either (their loss!). This is why we’re taking our time to do samples! Once we clarified that it was supposed to be black—black nickel plating, for the metallurgists following along from home—we still needed some back and forth to figure out the way forward. The original design called for a black and bronze metal treatment as well as the red color parts, but the factory was actually having trouble with this process. Most two-color metal pins, if you look around, tend to be silver and bronze/gold, not black and bronze like ours. So the factory actually needed to do some of its own learning to figure out how to do it. Even then, once it did, the metal process would have made it hard to create the red details because they’re so small.

We’re now waiting on the next round of samples, which will include a modification the factory was able to do to the mold which will let us use a UV printing process for the small color details. We used it once on the Yehat to make the hazard stripe motif, so the factory and we think it will work well here. After years of the players racing against the Kohr-Ah clock in UQM, it is fitting that now they are the ones holding up us Earthlings with delays.

Next, on to the Lorebook and Thank You Card! We’ve been working with a local printer down in Santa Clara on these, and they have come out amazing. It would be hard to measure exactly how much time and effort was put into the Lorebook, but it does all come out to about 13,000 words across all of its pages. While we were working on it, we thought it was going to be really cool and unique, but once I received a printed copy for proofing, I became truly excited. Maybe it’s just because we spend so much time making virtual things exist or I spend so much time reading text on a screen in our game, but getting to hold something physical full of words and art about the game really makes me envision one of you getting the same feeling of excitement. We really think you’re going to love it, and it does feel extra special since we never would have done it without the Kickstarter as motivation!

The Thank You Cards have also come out wonderfully, and Fred and I are loading up on markers in preparation for a sign-a-thon where we are going to personalize almost two thousand of them. We’d love to show you what they look like, but we also want to make sure you’re surprised by at least one thing that’s delivered to everyone who is receiving physical rewards. I will at least share that it’s a two-sided print, with one side being nothing but beautiful art done by Robert and the other side with the writing. If you just want a nice piece of art to hang up, it will be great as that!

The Starmap is the last printed item we’re making, and we went on a bit of a journey to get it made! Our printer we’re working with couldn’t handle the many folds the map would require, so I had to do some calling around until I found another local shop here in San Francisco that had specialized equipment for doing multiple folds on a big, big sheet of heavy paper. We’re currently wrapping up the final art for that now, and then we’ll start doing that print run.

Though we think it’s a fun nod to getting goodies folded into a box as was often the case with games of the 90s, we do know some of you asked about having unfolded starmaps. To address this again: the logistics and price of shipping and tube mailers is just too hard for us to take on right now. Down the road when and if we have more bandwidth, if enough people absolutely love their Starmaps and wish they could just have one sent to them in a tube mailer at the high cost of shipping it’ll work out to be, we’ll circle back and find a way to create and ship some flat ones. If we can get a minimum number of folks interested who already got a Starmap, we’re thinking we’d just charge the cost of shipping and handling as a fair middle-ground for folks who had already purchased one.

Virtual (Reward) Insanity

How about digital Kickstarter rewards? There are a few special ones like the Precursor Legacy, Private Playtest, and Design Tutorial experiences, but there are also things like the Digital Deluxe Edition which includes the Lorebook and soundtrack. For the unique/limited ones, we’ll be in touch with backers who supported us for those things individually. We’ve already been in touch with our Precursor Legacy folks, but for people who backed for the Private Playtest, we’ll be figuring out scheduling slots with all of you. We’d love to have you be some of our first playtesters of the Melee version, but we also understand how busy lives can get or that you might rather wait until the game has gone through more polish! For the Design Tutorial, that will be easier for us to do later and we won’t be scheduling that until next year.

How about the digital deluxe version of the game? This depends on a couple factors: when we finish things and how we distribute things. The Lorebook we made is designed for printing, not distribution. It’s oversized and laid out specifically to allow for clean cutting with bleeds. We could just distribute it, but giving it proper chapters and cropping will make it much more fun to read on a device! The digital version of the Starmap is in a similar state but with a lot less work to prepare digitally. Finalizing the soundtrack, however, will take us into next year.

As far as distribution, there are at least two ways to do it. The most straightforward is to pack it in with the digital distribution of the game. That is, if you have a Steam or GOG key for the digital deluxe edition, you get the extras along with it. It also sets us up to sell that version on Steam/GOG if we want, but that’s neither here nor there, since we could decide to do that at a future date anyway. Without having launched some version of the game, distributing through those platforms will be a little trickier, and if you backed for a console edition, we’d still need a way to deliver your goodies. That takes us to our second approach, which would be to distribute them as totally standalone objects on separate platforms (e.g. a link to download a PDF, a Bandcamp page where you are gifted a copy of the soundtrack, etc.) and not packed into the game.

We are definitely going to need a way to distribute digital goodies to people regardless of platform or location, so it’s safe to assume we’re going to do that at some point. The question is: do we do it now? Right now, we’re leaning towards no, not because we’re mean and want to withhold things, but because it will feel better when we can launch a truly complete digital experience for backers that’s been done well.

The soundtrack won’t be done in short order, and, as for the Lorebook, it’s not that we don’t love it, but it’s more that it’s meant to be a companion to the game in digital form. As a physical object, it’s extra special and we don’t want to hold up shipping physical things out; digitally, it’s a little more tied in to the game experience. The Starmap as a digital thing is a bit more neutral. Would backers be excited to have a gigantic digital map of a game they can’t play yet? We’re not sure! It could be great fuel for fan wikis and stories! The most important consideration is that it’s simply one more logistic hurdle to figure out how to distribute multiple things at different times while also juggling our other things, versus doing it all at once and likely doing a better job.

If we see a path to doing this nicely in a staggered way, we’ll take the opportunity! We might figure it out accidentally as we go just distributing our wallpapers (we didn’t forget the small things everyone is getting!).

Together Again

Before we get into the wrap up, we wanted to cover a few more odds and ends with communication and our communities.

We did an open casting call for voice acting and got your submissions! Unless you type like a robot trying to sell me on AI-powered lead generation with 10 business acronyms I don’t understand and are asking to schedule 15 minutes of my time, which would send it to junk mail, I got your email. If you haven’t heard back from us, it’s because we’re going to be doing voice overs for a while and we’re not ready to say yes or no to anything. I’ve got a big ol’ casting sheet with all of your emails, and we’ll follow up with everyone when it makes sense, whether that’s a few months down the road when we’re looking to start voicing a character or we’ve finished all of our casting and will at least let you know when we’re done.

We know there are long spells between these updates! This one felt especially long, but we also had even more to say too. It’s not because we have things to hide, but it’s because we really are busy focusing on our work and have a lot of it to do. We’ve been considering some ideas to bolster our communication and our community, especially thinking about what our ideal community looks like and what kinds of things we can foster with it. Though it’s quieted down now, we’ve already created a space where people are able to grab on to Simple and use it if they want to, for example; so we’re thinking about what other things we would love to see happen.

This becomes especially important to us as more and more things start getting into more hands. Imagine if we were going to launch an Early Access version that anyone could play! We’d want to have our communication cadence and schedule down since we’d be opening up the floodgates to anyone willing to come and join us.

With that in mind, our most successfully active place is still our Discord, and we’re thinking about how to best set up our communities for success, both within our Discord and without. That includes setting up structure for making our already great community even better, like adding more moderators or ambassadors who can help us talk about the game, organize thoughts, and help direct people to resources (whether we make them or just foster what the community wants to create). Our subreddit has been intentionally closed (i.e. only we can make posts) for a while since we had formed it as a community to mostly help us speak with you and ask questions. Now it would probably serve everyone better as an open forum to talk about what we’re talking about. We could likely do that with the help of a few moderators, too, but that may be more aspirational compared to “doing one thing well” in the places we’re already doing well, like Discord and Patreon.

Since we’re going to be letting some more proverbial cats out of proverbial bags, it also brings us closer to returning to another place we had a great community: Twitch! Part of the journey we set out on is more than just completing our game, but sharing the process with all of you. We want to educate, inspire people, and wear our transparency on our sleeves. We think we have unique assets others don’t have, and we want to use as much of what makes our process special as we can. Sharing openly is one of those important ones. Once everyone can know the names of our aliens, for example, I’ll feel a lot less shy about going on stream with those names clearly visible.

No More Words

We feel comfortable sharing because we also know you have been along for the ride and all of us are better off for it. One thing we want you to get out of reading these updates, watching a livestream, or participating in our Discord is that making games is hard! Not just that statement in a vacuum, but all the different ways it can be challenging. It is no walk in the park to have to juggle all of the parts of the game, all of the responsibilities we have to our players, and also do it in a way that’s true to our values. No DRM, no microtransactions, no live service, no <insert-investment-fad-of-the-moment>.

The time we spend sharing these updates, working with someone to manufacture an object, or describing a single thing to someone is all time that we are choosing to spend on top of just creating our game. It meshes with our own mission to share how exciting and dynamic working on this is, but also just how challenging it can be. We hold a lot of responsibility for the game but also a responsibility to all of you to show up as our best selves by being honest about what’s involved. When we imagine our ideal community, that’s part of it too—people who are there to be honest and bring out the best in everyone, themselves included.

We alluded to this when talking about our writing schedule, and it bears repeating: right now is an especially challenging moment to find and bring out the best in everyone because of our global social environment. There is a pervasive air of helplessness that I see in all my interactions and everyone is fighting against it in different ways, through escapism, denial, or even paralysis. There is a world of difficulty out there that we can all find and are tapping into, whether or not we want to admit it, and it gets projected and reflected by others. Things must be difficult. Things can’t be easy. One challenge of my work is navigating that with everyone! Must things be difficult? They might be outside, but why are we bringing or creating that in here?

When we are surrounded by suffering (real or imagined), what does it mean to be happy or succeed? It’s a little scary. Our game alone has had more than a few unforeseen bumps in the road, from legal challenges, to Paul and Ken moving on, to trying to get some objects shipped into the country which suddenly can’t be delivered under budget, to having to rearrange our schedule around immovable parameters. It would be pretty easy to focus on those as emblematic of what our work must be like: hard, uphill, and just one thorn after another. It’s easy to feel despair, but I mean this honestly: what’s the point of despair? It’s a trap. Don’t fall for it! Optimism is much more reliable because it lets you access curiosity and growth, and the upside of challenges is that they require us to grow. The challenges we didn’t ask for or anticipate are more than an opportunity, they’re a demand. We must define our own future. How will we do it? 

To paraphrase David Deutsch: optimism is not to be confused with blind optimism—the hope that things will be better because the alternative of acknowledging challenges is too hard. It is understanding that even if solutions to overcome obstacles are not immediately apparent in the present, they will become available once sufficient knowledge has been acquired. There is a proven track record of that in our history, and he would probably argue it is part of human nature—or the human spirit, if you want to wax poetic.

I don’t think I’ve written this out in a while, but I often say to people I work with, “Aren’t we all here to learn?” Not be perfect, not get it right, but just learn. What’s the most fun thing we can do with the constraints we have? What’s the path forward? How do I do this thing I’ve never done before, or this other thing I’ve done before but now I get to do again but better or with different constraints?

I see that if we ask people to just show up and be as amazing as we know they can be, they can, paradoxically, instead react by choosing to forever stay safe in their comfortable pillow fort of self-doubt. Ask someone to move out of it and believe in themselves, and out of nowhere is an unconscious monkey-wrench thrown into a process because if it went well, it would be scary. Now more than ever, I can see that people are actually afraid of succeeding. What does it mean for the people who can’t do it? If we believe our project can be successful, what about the ones that weren’t? It’s a disquieting thought that people may not even know they’re having. If misery loves company, then self-doubt and fear of what lies beyond that are the communal instigators

With that in mind, a big thank you to our generous Patreon community who continues to support us. While I am writing about my experience encouraging people to believe in themselves, you are encouraging us very directly, and we all feel it.

We are glad to continue to share this journey with all of you and have you here.
Please join us on Discord, Bluesky, and Reddit to be a part of our community. You, too, can still support us on Patreon as well.

“Here comes the summer!” I sing, moments before being torched on the surface of an alien planet by the 1000 degree centigrade sunrise.

Speaking of “centigrade,” if you are well versed in counting to ten, you already know what’s coming: that’s right, it’s our update on Milestone 6! This update will be a little different than other ones, as we have been finishing pieces of work in an order which doesn’t necessarily make the game look or feel better in the immediate. We’ll be a little light on showing parts of the game, and a lot heavier on content which will be going into the game, as well as describing where we are and where we’re going in our development cycle.

As we often say, polish is not the focus right now! As you see images or animations of the game, this is just what the game looks like right now, and in many cases the parts that look unfinished are just that: unfinished. We’re happy to show you the foundation, unfinished drywall, and loose wiring of our metaphorical house. Even our numbering scheme is now goofy, since we technically had two short milestones since our last update. Welcome to game development life.

The Big Production

Broadly speaking, our time has been spent with a heavy amount of production, meaning the creation, maintenance, and decision-making about our list of assets and features. Think of it like a packing list for a trip you’re planning, and you’re trying to both plan the trip and source the items at the same time. As mentioned in the last milestone update, I (Dan) have been mostly at the beck and call of the production’s needs, and working to ensure everyone has what they need to continue so our long chain of dependencies keeps up. We’ll have more of a dive into this with our voice acting workflow as an example later.

This last milestone, our goal was to hit what we called our “soft alpha,” which means that we should be able to lock down a subset of assets and features which are done—and the focus is on that locking down, rather than making more things. We are now content-complete for all of our 2D and 3D in-game art, meaning we’ve got all our hand-made creatures, ships, comms screens (with the exception of one final portrait coming this month), and placements (reports from planet surfaces and other space oddities). The last pieces of 2D artwork we’re making are for our Lorebook and standalone in-game things like the intro, outro, or splash/loading screens. There will be a lot of polish to do with how our assets get used—things like ensuring planetside creatures are behaving properly, or tuning animation timings in comms windows, but their actual creation is done.

The final pieces of audiovisual content, like user interface art, sound effects, music, and visual effects, have been created and only need to be iterated or expanded on. As we pass this milestone, we’re focused on the completely missing assets. An explosion visual and sound effect can be not polished or perfect, but there’s something there. We can decide how much polish everything ought to get after alpha, and this will include things like tuning our many planet colors and environments, lighting and color tweaks for different scenes, and polishing our hundreds of procedurally generated space backdrops.

One reason our alpha was “soft” is because we will be needing time to finalize our alien conversations. Some are completely finished and have been for a while, while a few are still just structural placeholders with the real writing still happening. Most are pretty much done and are going to go through some polish passes. All of that said, we have to truly finish the writing before we can record any voice over. We’ll detail some more of that in a later section, as well as talk about the roadmap for what I know we’re all excited for: getting something released.

Before we get there, we want to show a few more of the things we have actually been getting done. Some of this hasn’t been seen (or heard!) before, and one of our more difficult decisions is deciding just how much to trickle out versus keep close to our chest. I’ve actually started a “reveal list” which is just a spreadsheet of things we have shown, things we haven’t shown, and things we want to show at a particular time just to have a plan for the coming months.

We aren’t sure what different people following along will want, like not being spoiled versus knowing all of the intimate and gruesome details of our development, but one thing that we do care about is leaning into transparency. As Mallory joked with me recently on one of our calls, she is used to not even being able to tell anyone the name of the project she’s working on, much less the gritty details. It’s been largely true for me, too. This is the first game that’s been announced at the same time I started working on it!

Shipping Out

We showed two of the backer-created ships last milestone, and we finished the other two this milestone! Their gameplay still has some polish to do, but we wanted to show off our backers’ cool creations.

First up, we have a ship we’ve codenamed the Warp, which is actually a combination of a ship prototype I had built months ago and a unique power the backer designed, with art that they concepted. Because of its aesthetic, this is one of the few ships we built in full 3D. The Warp’s primary ability shoots a beam which does damage proportionally based on the distance to the enemy ship while also doing a knockback, like the reverse of the Chmmr Avatar’s tractor beam. The resulting gameplay rewards you for getting close to the enemy ship, while also letting you use your ability to play keep away. A very fast ship can quickly overpower the Warp, though.

The Warp’s secondary ability and namesake is lifted straight from an old prototype, which allows for the ship to warp back to a previous point in time, restoring its recorded position, orientation, and velocity. We’d like to experiment with other statistics, like restoring crew or removing VUX limpets, but it needs more playtesting first. The fun part of this mechanic is that, while it seems powerful, going back in time is not only gated by energy, but may not even be a good idea depending on where you were. You might put yourself in a worse place than you were before you activated it! We also want to play with how much information is provided to both players about this behavior—like showing a ghostly trail so a player could predict its trajectory if it were to warp back.

Our second ship is called the Spirit, and was made very sweetly in memory of the backer’s departed brother who was a huge fan of The Ur-Quan Masters. Making this ship was a special experience for me, since I got to not just meet the backer and get their own story, but that of his brother. A few “messages from Earth” were written for their brother as well, and we’ll be sharing more of his story in the Lorebook. Our artist concepted the ship based on the idea of a sort of beaten up junker jalopy in space.

The Spirit’s primary power is a very close range circular attack, like a colorful, miniature Kohr-Ah special. The secondary power launches a pair of Ur-Quan Fighter-like drones which start seeking toward an enemy ship after a delay, exploding on impact or after their lifespan. Homing missiles are usually quite powerful, but the Spirit has a little twist to tamp down on them beyond our usual tuning knobs. Occasionally, the Spirit loses power, halting energy regeneration and possibly disabling the thrusters or turning. If the player can manage to jump-start the ship’s power, it will hum back to life. We still have to play around with the power loss mechanic, since it might work better in response to non-random things so players can predict and play around it.

We have all of our captains’ windows completed as of this milestone, too! Robert and Mandy (our 2D artists) had tons of fun with these, and the captains’ windows are one of the charming, direct carry-overs from The Ur-Quan Masters. We’ve made a combination of direct “remasters” for old ships, and imagined new things for all our new ships—and it’s all been possible because you helped us meet the stretch goal.

Know Your Placements

Our universe is more than just ships, creatures, stars, and procedurally generated things. We are creating tons of artwork for telling our story, which we call placements! After aliens tell players about something hidden somewhere on a planet, we want players to be excited when they finally discover it. Most of the things players will find are on planet surfaces, but some of them, like space stations, are floating in space. We’d rather not reveal much of what these things are for, but simply show you some of the work that’s been done because we love sharing.

Just like in The Ur-Quan Masters, some things aren’t giant space objects and will instead be items going into the player’s inventory. While Wimbli’s Trident may or may not be making its return, the player will be encountering a colorful collection of new items in Children of Infinity. What on Earth (or somewhere else) could these things be?

Progression of Note(s)

We’ve been showing at least slices of almost everything as it’s been in production, except for one thing: music. In the future when we have more time, we’d love to do another deep dive on the whole story of the making of the music for Children of Infinity, but for the time being we want to at least tell the short version and share some of our work in progress!

Everyone put your hands, tentacles, and pseudopods together for our amazing composer, Crill! We were directed to him by Eric Berge, one of the original composers from The Ur-Quan Masters, as they had been collaborators in the past and worked together on something you may have even heard before: a lyricized version of the Melnorme theme, POTATOJUICE.

After giving some of their published music a listen and thinking they’d be a great fit, we were able to get in touch with him and start talking about our project and what we’d be looking for. At the same time, one of my friends from a LAN party group I’m part of in southern California suddenly reached out to me and asked if I was behind the project their friend had been asked to compose for. It turned out to be a very small world, as a group of my friends had been long-time friends with Crill too!

At that point, around a year ago this time, he started producing some tracks for us. We prioritized several different types of tracks, like exploration, combat, and communication screens, and he started putting together some different sketches of what it could sound like. In some cases, we wanted something new, and in other cases, we intentionally wanted to remix or reuse parts of Eric Berge’s tracks from The Ur-Quan Masters.

We think the music speaks for itself and we are finally ready to share it, so we’ve put together a sampler platter of some of the tracks in progress for you to hear. We’re keeping the spirit of the tracker music that UQM used, with some of the weird variety from song to song, while also bringing it forward a little into the present, and we’re really happy with the results so far. 

We’ll talk a bit more about the scope of our music later, but if you like what you hear, you should definitely check out Crill’s other music! You can hear it on Bandcamp or follow him on Twitch or Bluesky.

Manufacturing

As we mentioned in previous updates, we have been finalizing our order counts for all of the Kickstarter goodies we’re manufacturing for everyone who backed for physical rewards! We have a lot of physical items we’re making, and we wanted to show a bit of the process we’ve been going through.

We started by prioritizing our most complicated items, things we might have difficulty manufacturing locally, and things which would have a longer production time—meaning anything that isn’t printed. We started with the pins first, which are just about to have a sample run produced, which involves making a reusable mold. Below you can see some of the CNC imaging showing the shape of our 3D pins (the Kohr-Ah and Chmmr).

While those have a much longer turnaround time, we were able to do test runs for a few of our items. Here we have a 2” and a 3” version of the Free Stars patch. We’re going to be going with the 3” design, but these 2” samples will no doubt be worth thousands of dollars as super-collectors items some day.

Lastly, we have our sticker sheets! We created a few different types from different manufacturers so we could get a sense of which ones we liked the most.

Mandy (the artist making all of these) and I did some QA tests with the stickers comparing their durability, how they looked, and the quality of the material. We peeled and unpeeled them, we stuck them on stuff which went through the dishwasher repeatedly and got scrubbed with soap, and I even left them out in the sun for a few days to see what would happen. We want to do one more test print to see if we prefer glossy or matte coating, and then we’ll be making thousands of these to fulfill our backers’ orders.

Lastly, we have our printed items, like the Lorebook, Star Map, and the thank-you cards Fred and I will be signing. We finished the Star Map before our Kickstarter, so most of our work is going into the Lorebook, which is going to be our most special thing we’re making. We’re filling it with as much “off stage” information as we can, with background information on the characters of Children of Infinity as well as tons of concept art and development stories we know you’ll be excited to have. While our mock-up we put together for the Kickstarter was just an idea, having all of our art assets compiled and done gives us the opportunity to make something real. Here’s a little sneak peek of a couple pages.

We’re manufacturing our printed items last because they’re more than just art, and beyond just the Lorebook, we want to have time to put final touches on them. They will have the shortest turnaround time and are much easier and cost-effective to manufacture nearby at one of our local printing shops. It also helps that we’ll be able to communicate more closely with them based on our needs.

There is a whole budgeting post-mortem to write about our Kickstarter, but one sticker shock which no one could have seen coming was the impact of suddenly rising manufacturing, importing, and shipping costs rippling out from American policy. We assumed we’d have some margin of error when budgeting these things, but some very abrupt changes caused costs to rise dramatically. When sanity checking our duty costs when importing things, we were very fortunate to come across a community member who had expertise in this area and could confirm we were doing things correctly. Thanks, helpful community member, for confirming things are as awful as we thought!

We have to finalize our manufacturing pipeline before we can commit to a hard date, but we expect our physical rewards will be shipping out later this year. For those of you who are late backers on BackerKit who pledged for physical rewards, we won’t be charging your cards until we have that clear date.

One often-asked question is if we’ll be making some of these things available even after our campaign. The simple answer is: we don’t know! It would make a good deal of sense, and if people like what we make, of course we’d want to make more for people. On the other hand, we are a very light crew and need to prioritize finishing our game too, no matter how much fun making ship pins are (and it is fun).

It was kismet that we were able to bring Mandy Draeger to our art team. She has the unique experience of not just making 2D art, but in turning it into stickers, pins, and other swag! Check out some of her other wonderful designs at the shop she runs for Rocket Cat Rescue.

Backer & Kickstarter Tail End

We’ve covered backer-designed things like creatures, ships, and lander skins. We’ve covered physical goods we’re making for our backers. One thing we haven’t talked about in a while are some of the special experiences backers pledged for, like our private playtest and the design tutorial! We haven’t set a strict date for either of these experiences, but for both of them we want to have a more fully-finished game to share with those backers. While we’re happy to just shoot the breeze with someone in our private playtest, we would much rather have our Super Melee experience polished up and ready for a good play session if that’s what someone wants!

At this point, our timing commitments around those will be based on our game’s schedule as it shapes up.

Production Snapshot: Writing Lockdown Workflow

As described earlier, the most critical set of assets we’re working on finishing up right now is our writing. That’s because even after we finish the writing, there are many other steps we need to take involving other people outside the team. Once the conversation is fully written, then we can record the audio. Once we record the audio, then we can slice and process the audio. Once the audio is processed, then we can actually call that conversation finished.

What does it mean to finish our writing for a conversation, though? It’s important that we not only have actual writing in all the spots we intend, but we also have to make sure it makes sense in the game. This is part of our own, internal playtest process. While we’ve had our overall narrative structure clear for a long time, we learn new things once we actually put all the parts together. It’s important to play the alien conversation. Imagining ourselves as a player, we might want to make sure some things receive more time and attention, or we’ll see how maybe some parts have too much valence and drown out other more critical pieces. There is also a whole role-playing element to the player’s voice—there might be situations where the alien has said enough to communicate a plot point or objective, but we want to let the player have some fun with additional, expressive conversation choices.

Adding voice acting to the game is an additional pressure to really finalize things in our schedule. If we had the license to change anything we wanted later, making minor changes would feel safer. Now, though, we really have to make sure the words are right because someone is going to record them, and then we’re going to process them! It’s one thing to have to redo some of our own work, but it’s a much bigger logistical challenge to change voice lines since we have to coordinate with another person. We call that kind of additional recording “pickup sessions,” and we can do them, but it’s always tricky.

At this point, we have four characters we consider signed off on and ready to record. One has even already had their recording finished. As for the rest, we’ve staggered their sign-off dates over the next two months, placing characters we think will undergo more revision and changes toward the end, with characters who might already be done but just need a final sign-off toward the front. We can always sign off on someone early, but the purpose is to give us time and also allow us to predict when we will have our finished voice assets.

We will talk a bit later about our thinking on when and how we release our game, but you can see that there is a real amount of time necessary for each step in the process, and by choosing to take additional time in one step, we run the risk of causing a chain of delays at a minimum, or lose the ability to get work done at a maximum.

Last but not least: I have been flooded with voice acting auditions! If you sent one in, don’t worry, I got it. I can’t respond to all of them just yet because of the schedule above, and there’s a dependency jigsaw puzzle of peoples’ availability and our budget. As we progress and fill in some of the holes, I’ll be reaching out. If we do fill in the whole puzzle, then I’ll be in touch to let you know the window has closed.

By the Numbers

I wanted to share a bit of data from our production flow. We just use it to help us work, but to outside parties might be exciting as far as building expectations, intrigue, or other primal emotions! Plus, at some point we’re going to have to write some really nice marketing copy for our game, so this helps us get some practice.

One of the questions we scratch our heads over a lot and we are asked often is: how big is the game? This could mean so many things, but people usually think of expected playtime. The true answer is, we’re not sure yet! We need to playtest it more and polish the pacing, and the play time almost becomes one of the last things to tune when we see what is taking too long and what players get into that we can give them more time to enjoy.

However, we do know how many bits and pieces are part of our game, and while we can’t answer how big the whole is, we wanted to start sharing some of the parts we’ve itemized. Think of it like a production shopping list! Our game contains the following:

• 38 unique playable ships and 39 captains’ windows (the mismatch can be a source of your intrigue!)
• 26 comms screens
• 27 characters with voices
• 30 planetside creatures
• 36 tracks of music (at least! this will almost certainly be greater)

We could have forgotten, but that might be the first time we announced some of those stats! We’ve talked about stars, planets, and procedurally generated things before, but not so much the hand-made pieces. Enjoy and speculate away!

What’s Next?

We’re running all of these production pipelines focused on finishing things intentionally! One of the reasons we ran this Kickstarter was to raise funds so that we could hire help to create those things. In the evolution of our project and our team, we’re wrapping up the current content phase in two significant ways. First, we want to finish the content so we can put it all in the game. Second, our game does have a budget, and we have crested past the point where we can afford to create more things.

In some of our previous updates after the Kickstarter finished, we mentioned some of the new members who had come on to join our production. As I write this now, most of those people are either done or are wrapping up their stint with us—not because we want them to go away, but because we actually have no more work for them to do or can’t afford to keep them even if we did! Mallory and our writers are staying on a little longer to finish their work, but our hired, full-time art help is wrapping up.

If pre-production was determining the sites where we wanted to mine and setting up facilities, and production was the quarrying process, now we’re about to take all of our rough stones and start cutting, polishing, and setting them in jewelry. At this point, we’re going to be winding back down to how we handled our pre-production process: working as a very small team.

One thing that is hard to explain, much less believe, is just how gigantic this game is compared to the size of our team! Even when we were at our “biggest” with a total of six full-time contributors, it required a lot of production effort to just manage everyone’s contributions. We reached really high and really wide by focusing on supporting our temporary staff. For the next phase, we narrow down and go deep.

The question we all want to answer is, “When is the game coming out?” It’s probably come up in every one of our updates, including the one prior where we asked, “What is the game coming out?” Our last full-time artist, Mandy, will be wrapping up with us this July, and at that point we can actually take a deep breath, and start to really consider the work that remains and how we want to approach it. The only sure thing we can say relates to our writing assets and schedule: we will need until September to finish our voice overs.

This gets into some of the personal stuff for me which I’ll talk a bit about in the next section, but when I talk about our small team and our production overhead, I’m talking largely about my own efforts, which are about enabling the team to make progress. Once those responsibilities subside, I will be back into one of my other roles: the manual labor of finishing features, polishing things, and fixing bugs. At this point, until I know how quickly that process goes when I have my hands free again, it’s too hard to estimate when we’ll be able to finish up.

The upside of this, and part of our plan all along, is that our operating costs for our limited crew will diminish back to our pre-production levels. As I enjoyed reading all of the responses from our community, one of the frequently-occurring ones is “Take your time!” Often I would think, “Sure, but on whose dime?” We’re finally coming to a point where we actually can make those kinds of decisions because we aren’t funding a giant (relative to our team size) production, and Fred and I can decide what would be best.

What would be best is going to be what will produce the best possible game.

We’ve discussed it a bit in the past, but one of the big puzzles to solve as we get ready for releasing something is how we can get some playtesting done. We have our very small internal team of volunteer contributors who we can likely wrangle into playing, but figuring out how to open the game up to a larger set of players to actually help us playtest will make the biggest impact on our end product. Can we playtest the game without voice over? Absolutely! Do we want to release the game without voice over? Probably not. Are there parts of the game that don’t require voice over? Yes! Super Melee as a standalone thing has crossed our minds many times, and there are no alien conversations there.

Our next update will likely focus on this plan, including what we’re thinking for how, when, and what we will release. To recap, the only thing we’re pretty sure of for our releases is that we’re focusing on the English versions of the Steam and GOG versions for Windows, Mac, and Linux  as well as the Switch first. Localization and the PS5 and Xbox versions will be a step afterward.

A Longer-than-Usual Personal Note

This takes us to my closing notes. I referenced having my hands free because a lot of this upcoming work is on me, at this point, apart from the narrative pieces which Mallory and her team are taking to completion. This is actually my favorite part of every project, and I am looking forward to pivoting my role back into where I started: doing a lot of manual labor and polishing to make sure our work is as great and shiny as it can be. Running our big production-sized team involves me all the time, and there isn’t a back-up to help cover for me when I’m not around or trying to polish something for the game. I had to drop all of that to support the team!

This means some things didn’t happen as fast as we had hoped. It doesn’t mean they won’t get done—it just means we couldn’t do as many things in parallel. I couldn’t do as many things in parallel for this very demanding project, and the last couple months included some additional demands on me. What I’m going to share is truly personal. As this is a small team with a big project, I hope you can appreciate how much of the project is in a small set of hands and how intertwined our lives become with working on our game. It’s why even this update is coming a few weeks later than we wanted.

On May 13th, my bird Topal passed away. Unlike with Buhar, his sister, who passed suddenly, I at least knew Topal’s passing was coming. Since about February, I started making regular trips to the vet to monitor him and was giving him end-of-life care. I gave him medication twice a day, which he hated. Three times a week, I would give him subcutaneous injections with the help of my partner who learned to hold him for me so I could insert the needle on his tiny leg. He really hated that. This was just a small part of his fifteen years with me, but it was a daily stressor and was quite devastating to me when he finally passed. He was a longtime friend and a frequent voice on our live streams, and I will miss him dearly.

In June, just in time for my birthday, I came down with Covid. Unlike the previous stints I had with Covid where I’d get knocked down and then get right back up within a week, this one actually plagued me with symptoms for over three weeks. I have had to fall asleep in the middle of the day, I have been unable to exercise (usually about 10 hours of my week), and my mind has been so addled that it has often been hard to even work at all. With deadlines coming up and contractors I only have a limited amount of time with, you can imagine the stress! I thought I’d catch up from the four days I took off during the initial infection, but there I was, weeks later, still trying to recover. When I asked my doctor about it, he said “Think of it like recovering from a concussion: you’ll feel confused by what isn’t happening day to day, but you’ll improve week by week”. Fortunately, I have not had a concussion, but the frustration that I cannot do what I ought to be able to do and knew I used to be able to do is exactly how I feel. As I write this, a whole month later, I can say I am finally better.

On another team, one person’s bumps in the road may just be someone else’s work to pick up. On this project, there is no other person! I don’t have a back-up Dan who is doing the same kind of work and can fill in. This is the same for everyone working on the game in their domain. Apart from these unforeseen hiccups, we wouldn’t have it any other way, though. This is a very personal project in every sense. And people are, well… human!

Made by People, for People

It’s nice to be human, though. One of the interesting experiences I’ve gotten through backer communications is seeing how surprised people are to hear from me. I’ve noted it before, but it continues to surprise me (and them!). I think it’s emblematic of what’s going on in the world that people are actually shocked to talk with a real human, and, moreso, that they are treated like a real human! Sometimes people will send support emails in very, ahem… colorful language, sometimes in quite a demanding tone. I’m not offended! I can tell they are used to cutting through the noise of corporate machinery in the hopes of talking to a real person. There is no “support department” here. There isn’t a ticketing system. I don’t have a form response I copy from. There’s no chatbot. I’m just a person on the other side of the Internet like you, and so are the people working with us. I value every interaction, even if it’s just an email with someone!

It’s a reminder that people—especially in technology settings—don’t always get that experience. It makes me think that people have just gotten used to being dehumanized, told by so many things in the world that they don’t matter. But you do matter! Our game matters too, otherwise you wouldn’t be here reading this, having supported our work. There’s a direct correlation! If you, the player of our game, didn’t matter, then why would we bother making a game for you? This isn’t for me or for us (the developers). This is for you, a person who matters because our game was made with the intent of you enjoying it. It shouldn’t feel remarkable, but it is when we point it out.

Why is it remarkable? It feels sorely missing right now. Speaking from my American point of view living through current events, it feels like our humanity has been sacrificed in the pursuit of profit. The amount of control, funding, and messaging being concentrated for no other reason than generating revenue is not only deeply disturbing, but also insulting to our collective well-being as people creating community, life, and joy. If a person’s value to society is just the profit they make, what does that even say about how we treat people? I can’t even leave my home without seeing a bus stop billboard which proudly claims “stop hiring humans”. Yes, I know it’s just real-life clickbait to get attention, but if your marketing involves a race to the bottom to demean people, what, exactly, are you selling and promoting?

If the only thing that matters is the bottom line, why bother applying your humanity—your most valuable and unique asset—to anything? This reductive treatment isn’t a new phenomenon, but it is coming to a head in America. It’s beyond sad and distressing, and I am seeing how it takes a toll on our collective well being. Of course people I’m communicating with sound stressed. They probably are. We all are.

I’m not sure we can heal the world even if we wanted to, and I’m not sure how that will be resolved. We feel it’s important to do the work we can do, which is in our game. It’s a statement of our values which we want passed on to you. For me, this game and being able to do it in the open with all of you is a celebration of our humanity and what we feel is calling upon the best in everyone.

We want players who pick up our game to feel they matter, they are welcome, and they are included. Right now, we need you to know that you matter, in spite of the many flashing lights surrounding all of us which might be saying otherwise. Especially if you feel like you are one of the “othered” people with a scary spotlight shining on you. You don’t deserve that, and you’re more than that to the people around you.

I want to again take a moment to thank our Patreon community for continuing to support us after our Kickstarter in return for essentially nothing. Everything you’re contributing goes to supporting our work and our game. If what I wrote above is about how much you all matter to us, getting your direct support certainly makes us feel important to you. We continue to have no obligations to any investors, and we are committed to making the best game possible without strings attached or deleterious choices made to maximize profits.

Please join us on Discord, Bluesky, and Reddit to be a part of the community. You can still support us on Patreon as well. All of it means a lot to us.

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

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

Adventure Time

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

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

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

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

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

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

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

HyperSpaced Out

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

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

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

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

Play, Pause, Rewind

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

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

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

It’s a Gas

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

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

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

Floydian Slip

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

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

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

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

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

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

Coordinated Fire

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

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

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

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

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

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

Ship’s Ahoy!

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

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

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

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

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

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

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

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

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

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

UI of the Beholder

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

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

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

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

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

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

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

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

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

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

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

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

Specs and Balances

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

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

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

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

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

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

Backers to the Future

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

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

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

Quite the Production

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

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

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

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

Retrospective Gaming

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

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

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

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

Milestone 6: Alpha

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

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

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

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

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

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

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

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

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

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

Future Presents

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

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

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

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

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

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

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.