Spring turns to summer, and we celebrate our long days full of sunlight with blackout curtains so we can see our gaddanged monitors. It’s time for the next Milestone update! We’ll cover what we’ve been up to—which has been mostly dedicated to polishing and playtesting Melee for our demo release on PC—as well as what to expect next.

Before we get into the full nitty gritty: if you pledged for the Kickstarter or as a late pledge on BackerKit for any physical rewards and did not receive them, please be sure to check our last post because we really need all of you to finish your surveys. I know a small group of you had shipping issues and have already reached out. If you need any help, please contact us.

For those of you at digital deluxe tiers, completing your survey also will net you the digital Lorebook and Star Map. There’s a reason to complete the survey no matter what! We will be badgering your inbox with questions if you’re on our unfinished physical pledge tier list (there are fewer than 100 of you).

Last but not least, if you did miss out on the physical rewards and would like to up your pledge, we will have a limited number of additional physical pledge items available to coincide with the launch of our Melee demo.

If you’re just here for the highlight details for yourself and don’t want to read a whole update, here is a short list of things to note:

• Please read our previous post if you backed for physical rewards and didn’t receive them yet. You may need to complete your survey, and we need you to complete your survey!
• The Melee Demo will be released for PC this summer. There are no plans currently to release the Melee Demo anywhere but PC, but that could change.
• Children of Infinity does not have a hard release date, but it will release for PC (Windows, Linux, Mac) on Steam/GOG first, then Switch, and then PS5/Xbox Series.
• We’re restarting our development streams again! Be sure to follow us on Twitch to be notified or watch our Bluesky where we’ll post going-live announcements. Miss us live? We’ll share recordings on our Vimeo.
• Our actual development task tracker we use every day is now available for public observation.

Now buckle your hands behind your back and put on your whimsical pants while we get into all the prep we’ve been doing for our Melee Demo, which we are pleased to formally introduce as Free Stars: Battles in the Beyond.

What’s in a Melee Demo

In the beginning of the universe, there was nothing. Then there was the Big Bang. Then, we decided we should have a Melee Demo. What’s the purpose of all this, and why would we do it? Many great philosophers have pondered these questions through the ages.

The point of our demo, first and foremost, is to release something people can have fun with. It doesn’t have to be the full game, and it doesn’t need to even have every feature we’d like for Melee in the full game. But our demo actually does more harm than good if people play it and don’t have fun. If we give players a taste and the taste is bad, why would they pony up money for the full meal?

Our demo is a powerful, double-edged sword. One of the greatest risks is that people won’t even realize there is an Adventure mode and won’t bother coming back for the full release. If Melee combat isn’t peoples’ thing—and we fully expect it isn’t for everyone—then this demo does a poor job of representing the other aspects of Children of Infinity.

So our strategy is to emphasize the side of the sword we’ve got and overwhelm people with fun. We won’t win everyone over, but if enough people pick up something, play alone or with a friend, and enjoy it, then we’ve succeeded. If we get people telling other people about the demo, or the whole game, or the Kickstarter campaign and what we’ve been working on, that’s another kind of success. As long as people have fun!

Our “marketing” goal for the demo right now isn’t to get people to play Children of Infinity. First of all, the game’s not out, so that’s impossible. Second of all, while we think Melee is tons of fun, it’s not really the best representation of what the story mode is all about. It’s a fun piece of it, but it’s only a piece.

So what is our overall goal? To make people aware! If people are receptive to this and talk about it, it creates a space for all of our upcoming work. If people play one of our releases and enjoy it, or join our community, or get interested in what the heck Free Stars might be about, that’s a win. We won’t earn anything financially from a demo, but it’s an investment in our future. It may go without saying, but we also want the demo to live in perpetuity and be freely available for people to play forever. It’ll be DRM-free on GOG, and we hope players can keep playing it even if they aren’t here for the full game.

Even though we’ve adamantly stated that Melee doesn’t represent the story of our game, it does have a lot of our universe. If players see a picture of one of the aliens in the captains’ window or the colorful characters which are our ships themselves, they might get a whiff of what our world is. It’s a bit like having someone sit down before a play and seeing the set, lightning, and costumes without knowing the words that will be spoken. Players will get to see the staging even if they don’t get to experience the script. In that way, our demo is a useful teaser for the full game.

Now that we know the high-level goal and what we want to include in the demo, how the heck do we (and did we) get there?

Preparations

If the number one goal for the demo is for a person to have fun, we needed to get some playtesting going to actually test our hypotheses. And before we could drag random people off the street to do that playtesting, there was a certain minimum number of things we had to finish. As developers, we’re used to turning a blind eye to all kinds of placeholders and janky interface interactions, but for fresh-eyed human players, we don’t want bright, blinking lights subconsciously signalling that things aren’t okay. That would detract from the feedback we actually do need: is the part we think is fun actually fun? We know playtesters will ignore a certain amount of unfinished elements, but we needed to clean up some of the obvious cracks in the walls.

Before and after the actual Melee parts with the shooting, there are some user interfaces you have to go through with some practical and emotional intents. Preparing for the match is where you pick your ships and decide on your fleet composition. It’s also where you connect with your friend if you’re playing online. We want players to be thinking about what ships they might like to use and to have a zero-friction experience playing around at this stage. For totally new players, we want them to be curious but not overwhelmed by the frankly insane variety of ships, especially before they’ve ever had a chance to play.

Getting the pre-match setup experience entirely up to snuff enough wasn’t something we really wanted to wait on since we knew it would be a lot of work. We knew we could get it to be good with enough time, so we spent a large chunk of this milestone getting there. We really needed people playing the game and checking out the ships, and we created a simple play guide which would guide brand new players through some of the thornier parts in the UI. At this point the UI has received so much love that the document is pretty out of date, but it was important for getting us off the ground.

Even if we thought players would accept a less-than-perfect experience before the actual match, there were enough little bugs which we knew about and had just been living with. Since we aren’t sitting there live with our playtesters to help them over hurdles, we didn’t want them accidentally getting into bad states because they accidentally hit a random button we have assigned to a debug feature, or clicking in some space that would softlock the game. We just wanted them to get to the ship-fighting part. Even then, our default CPU roster when playing alone was quite evil/mean for an unfamiliar player, so just toning that down helped. There’s a lot of little things like that so we can actually run a useful playtest and see if players really are having fun.

Beyond that, since this was the first time the build was going out beyond the walls of Pistol Shrimp, we had to make sure all of our legal bases had been checked. We obviously are not using illicit materials in our game, but it doesn’t mean our internal builds have been as fully compliant as a public release must be since we’re actually distributing it. We added documents to the build and in-game screens indicating the licenses of all the materials in the game, especially for things like fonts (which can have quite different licenses). We ensured our own work was copyrighted, which is important to us too. In short, we’re happy for the build to go “into the wild”, but if someone unpackaged the build and data-mined it, we wanted to be sure there’d be no liability surprises hiding in there. We had kept good hygiene for a long time, but as is always the case, one last check did us good.

Last but not least, we needed a way to encourage and collect player feedback. To that end, we added an in-game issue reporting screen as well as a bot which could help file bug reports in our Discord where we were planning to gather all the playtesters.

It’s Playtime!

With all the necessary paperwork out of the way, we were finally ready for the big reward (for us!): getting people actually playing! We obviously wanted to playtest before we were ready for release, but we really wanted to playtest the Player-versus-Player experience since that’s the most difficult to test internally. For our first batch of playtesters, we turned to one of our own Discord moderators who is highly active in the UQM competitive scene and has even worked on their own balance mods. We asked if they’d been willing to give it a shot, and also to rope in a few other players from their competitive cohort for some head-to-head play. We began the test with this very specific type of player to see how they fared.

This was the most exciting moment! For the first time, we would be able to get feedback from real players who were left to their own devices and actually experiencing the game hands-on, not just watching our curated video clips we put in these updates or our development streams. The opposite side of the excitement coin is also always being a little scared, since we didn’t know exactly what could happen, even after all of our efforts to tidy up our work as much as possible and ensure they had a good time. If we knew exactly what would happen, we wouldn’t be running an experiment!

The initial result was not just positive but also incredibly rewarding for us. We got so much helpful input! Getting and responding to real-world feedback—instead of our own internal wants and observations—is an experience that feels gratifying in a quite different way since it’s an inherent collaboration.

It’s fun when the feedback matches your own sentiments, too. Playtesters have been filing feature requests for all kinds of things we have on our own wishlist but have simply been left for later polish or as a true wishlist feature. Even if we already know about it, comments and input others provide help inform our own priorities.

It’s also fun and equally helpful when the feedback is totally surprising and is something you never would have come up with on your own! Feedback in these situations generally is a mixed payload with a couple of subjective pieces in it: what they don’t like and how it makes them feel. For example, someone might say that they think a ship is bad, but alongside that sentiment is that they feel like they can’t be successful trying to use the ship (or they don’t know how). Our job when receiving feedback is separating which part of the feedback is the feeling, since that’s always the valuable piece to acknowledge even if we don’t or can’t do anything about it. If we do act on it, then we absolutely do want to address the “feeling” part, since players are great at expressing their feelings—which are undeniable, personal experiences—but not necessarily able to connect the dots between what changes in the game would address that feeling, no matter what they might say (along with the context and space the feedback comes from).

That’s where we come in as designers! It’s a little bit like mind reading plus psychoanalysis plus being willing to experiment. It’s the knowledge a physical therapist might have to know that if someone walks into their office complaining about a pain in their toe, that the toe is connected to the leg, and the start of the nerve which travels through the leg might be aggravated from the motion of the hip. Treating the toe would be a mistake! In similar fashion, we observe the collective pains our playtesters may be feeling, and try touching things in our complex chain of inter-connected parts to see what might address the pains, or at least create a more desirable experience. Melee is a competitive game, after all, and we do want players to be frustrated in a good way if someone is getting the better of them.

Buggin’ Out

We’re incredibly grateful to our testers for being our volunteer QA squad whether they realize it or not! We have had no dedicated QA team, so we’ve also gained some valuable QA time from this real-world testing. As we received playtest feedback, we prioritized the bugs first, since any bugs in game behaviors will mask the intended behavior for different parts of the game. Gameplay bugs, especially when it relates to how ships function, are some of the trickiest things to spot if you’re not explicitly looking for them. Especially if you’re not engaged in a competitive match trying to better another human being! The moment that happens, if you’re aware of how things ought to work, you’ll notice what’s wrong when your opponent is out-competing you by abusing buggy functionality (whether they know it or not).

Our playtesters quickly found a few amusing (to us, maybe not to them) bugs which they happily exploited to ruin matches. One playtester nicknamed the Melnorme Hellnorme because there was a bug where you could fire an uncharged shot for free, effectively giving you an infinitely spammy missile. Our Utwig, an already pretty powerful ship, was accidentally able to fire while shielding, giving players a beyond-unfair advantage by never having to decide between blocking or shooting.

There are too many bugs to list here, and some of them have been much more benign than the ones listed above. The good news is that most of the scary bugs we had been afraid of, like the game getting softlocked or crashing outright, weren’t happening much. That players were able to get through multiple matches without any of those critical incidents was very welcome news. If people are unable to play at all, it doesn’t matter how much fun the game is or even if some ships have bugs in their behavior.

That said, testers were able to help us uncover a few crashes which we have fixed. As this was going on, Fred worked on instrumenting some crash reporting information so that we can collect a report of what may have gone wrong. We have one playtester who is pretty good at crashing the game for reasons we are investigating, and these tools will help us understand what they are experiencing so we can address it. In the future, if someone else finds a new crash scenario, those same diagnostics will help us.

Lastly, one reason our playtesters have been able to find so many bugs is because testing multiplayer on your own is hard! I (Dan) do multiplayer testing on my own devices just to ensure two hypothetical players can get in the game and get things going, but that’s usually laser-focused on a specific thing I’m implementing or correcting. Nothing can really simulate two humans actually trying to act like humans playing the game, besides two humans. Even more so when those humans are trying really hard to win against one another.

To that end, we’ve been looking at how to get some part-time QA helping us. We’re appreciative of our playtesters, but it’s not really a playtesters’ job, and someone purely focused on QA would be a tremendous boon. Any time we make changes, we risk introducing bugs no matter how careful we are. Our game is pretty vast even just in the scope of melee! It has tons of wildly different ships which can create totally different unforeseen interactions, and network multiplayer means we have a lot of “shallow” surface area for potential bugs to crop up in niche scenarios. That’s a big challenge for a small team like us, since we certainly cannot afford not just one but two QA members, and there isn’t enough work for them to do full-time if we could. We’ll be exploring novel solutions!

Polish Until it Shines

After the initial salvo of bug-fixing, we finally got to the scenario where things were “working as intended,” and that led to the next collaboration with our playtesters: polish! We’ve been polishing certain areas on our own and polished different rough edges in tandem with our ongoing playtests (more on that later), but since there’s a potentially infinite amount of polish to do, playtesting revealed what actually would benefit the most from polish. It’s not that we don’t know what we’re doing or what we want to clean up—it’s that once the rubber meets the road, we can see which parts of the tires are getting the most wear and need the most attention to provide a smooth ride.

One of the first things our eagle-eyed UQM pros were able to spot much more easily were little discrepancies in behavior from original UQM behaviors. Even though we’ve intentionally strayed from certain constraints of UQM to make a fresh experience, we want the old ships to feel familiar as a baseline. Playtesters noted small things like slightly wrong reload times for weapons, different relative movement speeds, altered ship mass (used to determine how ships bounce off one another), and even minor weapon characteristic differences like the energy cost to use a weapon. Little touches like those can make big differences in how matches play out, especially to a group of players who are completely familiar with how certain ships perform against one another. Once we achieved as much parity as we wanted to be pleasurable, we began to experiment with breaking some of the old rules. As an example, right now we have Ur-Quan Fighters surviving collisions with asteroids instead of dying to them. It’s a minor tweak, but maybe one that makes it more fun!

While playtesters were going at it, we implemented a boatload of other polish items we hadn’t addressed yet. Many were just small things, but some were larger elements. As an example, most weapons in the game don’t produce objects which physically interact with the game world (i.e. bounce or get pushed by collisions), but there are a few exceptions. Objects like the Orz space marines and Ur-Quan fighters want to physically bounce off the planet. Previously, they had logic to make them home in on their target just like a missile, but the problem is missiles don’t physically interact with the game world! To make matters worse, homing missiles just generally move in a specific direction with a specific speed, but these objects also want to obey gravity’s rules and be able to use gravity whips like a ship. If you’re familiar with object-oriented programming, this is a typically devilish split-hierarchy problem, where we wanted some characteristics of totally different objects to all belong together.

As for the new ships, they were their own novel learning experience. While our players were plenty familiar with the old ships—and I’ve seen first-hand how players of UQM can pick up the new Melee, grab their favorite ship, and play like they are a pro—no one knew how best to play the new ships or how they’d really play out in real-world scenarios. I (Dan) used to be a pretty avid League of Legends player since their ancient beta, and I’m pretty familiar with the usual introduction curve for new characters over the years. New characters almost consistently come in over-tuned, and then as the playerbase figures out how to play them and exploit them, they get tuned down to be less oppressive. Riot does their own rigorous internal playtesting, but even that’s no substitute for players who are motivated by ranked ladders, streaming, and pro competitions.

Making it Shippable

Perhaps being over-sensitive to players’ potential skill ceilings, after observing the playtest, most of our new ships came in undertuned. While I had perfect knowledge of how I thought I should exploit a ship and could outwit the CPU opponent or sometimes other players who didn’t understand it, once our playtesters understood the ship and its tricks, they were usually comfortable but unable to reliably best an opponent with it. To paraphrase one of the testers: “The new ships are fun, but they seem harder to win with.”

After seeing some initial results, the new ships really boiled down to three categories, requiring different tacks to address:

1. Good Ships! Players can understand their abilities, use the ship, and maybe even start to master it and its match-ups.
2. Undertuned Ships! Players can understand their abilities, but they feel underwhelming to master. Why pick this ship when I can pick a different one which seems more consistent?
3. Undesirable Ships! The ship doesn’t offer the player enough tools to succeed at. It needs some radical changes before a player would even consider it worthy of play.

The goal, of course, is to make all ships Good Ships! For ships already there, we left those alone. All they might need are simple numerical tweaks (more/less energy cost, slightly different speed characteristics), and they may even be just fine as is. In any case, there wasn’t much work to do on them since we’d learn over time what, if anything, they could benefit from.

If ships were just undertuned ships and only one step away from being a good ship, they needed the least attention. Similar to the good ships, they just needed numerical bumps here or there so that they could be more competitive. The solutions were pretty obvious for those, or were things we didn’t prioritize since the ships were at least functional to the point where players could try them.

Undesirable ships (and their evil counterparts—more on that later) received the most attention. That’s where we applied the aforementioned clinical diagnosis. Players had lots of helpful feedback on what they wished the ship had, or ideas on what the ship needed to succeed, and I mostly looked for patterns and pain points. As you might imagine, there is a wide world of possibilities to address a ship’s needs. Players may have specific wants for a given ship, but some ships have set design goals—those goals may be purely atmospheric, or the ship may have a specific niche we want filled. Some of our ships have behaviors connected deeply to the piloting aliens’ own in-game stories, and we wouldn’t expect players to know what those stories are (yet!).

As an example, here is what I wrote down as a mission statement after observing some play with the ship codenamed “TBone”, which is a ship that can lock up an enemy with slow-deploying energy nets and charges forward with a very powerful weapon that is intentionally unwieldy and kind of crazy to use: “TBone is functioning mostly as intended as far as feast/famine but isn’t as strong as it should be when it’s feasting. We want to keep the success factor of landing your charge but it’s too easy for an opponent to avoid it ever happening. The charge should still feel unwieldy or like it requires some clever set-up.”

The problem is it was too unwieldy in ways that tweaking the numbers wouldn’t address. If TBone was given too much power, it would be too forgiving and no fun to play against since it would be strong too often. As is, it was just a worse pick than any other ship. The write-up given is intentionally not meant to be prescriptive, but it is a mission statement for what we as designers want the player to experience when playing the ship. We want to keep the ship’s character no matter what changes we apply! To follow up on this specific example, I made notes on what I wanted to try:

• Charging into your own energy net replenishes energy (or at least stalls the energy drain from the charge)
• Energy net deploys faster and shoots further.
• Raise the limit (number, lifespan) on energy nets.
• Landing a direct hit with the energy net should immediately lock up the opponent for an extended period.
• Beam damage could be tuned to deal more depending on how close you are (if you’re hugging someone it should be toasting them)

Having both our strategy and our tactics for the ship laid out, we were able to experiment with all of those possible changes and see how it played out. In this specific ship’s case, the current version received all of these changes plus a little bonus change discovered during the course of implementation. The main gun had a fairly long wind-up period before it could even start doing damage, and the compromise to letting the beam do more damage when it’s close was to immediately give the weapon a little “hot spot” when it starts charging so it can always do damage. As it stands now, the ship is now probably overtuned, but it’s succeeding at what we wanted: letting players feel like, with some skill, they could have moments of success. Now we can simply fiddle with the numbers to make it more reasonable.

Stopping the Unstoppable

For the two categories besides “Good Ship,” there are also their evil doppelgangers. The first is simply an Overtuned Ship! The TBone is now probably in this group, but fixing it is just a matter of number changes. The darkest and most insidious is the opposite of an Undesirable Ship: an Unstoppable Ship. We had a few of those by accident, and in all cases it was only discovered by human playtesting by competitive players.

A player playing to win is going to do anything they can to win, even if that behavior is not intended by the designers! My favorite was with a ship codenamed the Duo, which has a form-switching behavior that is intended to take it from “weak and useless” to “very dangerous”. Enemies would want to chase it down during its weak phase to punish it, and the player would want to play keep-away so it can build up its energy to transition into its dangerous phase. I was excited to see players play it, following the patterns we wanted them to play. How naive! One player realized that they could abuse one of the behaviors of the weak mode to permanently circle-strafe an opponent from a great distance, never even touching the intended dangerous mode and leaving their opponent effectively unable to punish them at all.

There were a couple other unstoppable ships, which was made obvious by players being players. One ship is themed around its capacity to expend and recover its own crew, but it was too good at recovery! Players could just sit there and stall fights forever by never even trying to fight. Another ship had the capacity to make a physical object in front of itself which it wants to bounce at an opponent, but a player discovered they could just use the physical object as an unstoppable, impenetrable shield instead of its intended combo. The former ship received a pretty significant rework, while the latter just had some numbers changes applied so it could still play that way if it wanted, but it would be trading offensive power if it wanted to do so.

We had a few other ships which were in the undesirable group that needed some love. One was actually a ship that was unfinished because it has a unique ability to “mount” an allied ship, but the demo is only 1v1. We still want to maintain that novel ability, but it wouldn’t do to have an effectively pointless ship in the game. We let it mount asteroids to make it more viable if no friends are around. We could (and may!) do a whole before-and-after deep dive on some of the other ships which got significant reworks—there were about four others which received significant overhauls to make them more competitive. Another time we’d love to do a showcase of the before-and-afters for all of them, but we don’t want you to be here all day.

As of now, we actually think every single ship in the game is playtesting pretty well! We have no more ships in the Undesirable or Unstoppable categories. If anything, we likely have a few too many that are overtuned, but that’s a great and straightforward problem to need to solve! We want our ships to be competitive, but if we remember all the way back to the beginning of this update, we also want players to have fun. We’re feeling very confident that all of our ships are actually fun now.

Last but not least, we can’t forget one of the important experiences for players when they’re not defending themselves: the victory sequence! For a long time, the camera simply snapped to frame the victor, but now we have a nice, smooth transition, giving players ample motivation to do celebratory dances to the victory ditties.

User Interfacing the Future

At this point at least half (if not more!) of our polish and bug-fixing time is going into the user interface (UI), which is what the HUD and menus look like, and the user experience (UX), which is how players interact with the menus. In many ways, the point of the game is to get into the game and duke it out with ships, but we still have a lot of user interface required to get players there. Even if all you want to do is play with a friend right away, there are some steps we have to take:

• Get two players linked up. If playing online, that means connecting to one another somehow. If playing offline at the same computer, that means getting each player set up with the input device they’re going to use to play the game.
• Let players pick their fleets and indicate they’re ready.
• Actually start the match!

That’s not quite the frictionless experience of popping into any old game since you have to make a lot of decisions before you get to the combat. The more fun players can have getting ready to play, the better, and there is a lot of fun to be had in setting up your fleet for battle. One of the highlight experiences for seasoned players—but also one of the most difficult experiences for a new player—is selecting ships. We have to serve both of them. An expert player will just want to pick out their desired ships and get ready to go, but a new player will be visually assailed by 38 ships they know nothing about, having never even played the game.

The roster configuration may be the most important menu in the game since it is carrying so much weight and needs to satisfy a broad spectrum of needs. It’s been an ongoing work in progress and we’re still not totally satisfied with both the experience and the visuals, but it’s gotten so much better. Our playtesters, who are more of the expert sort, have at least been able to use it effectively, and the feedback is that they just wish it did more.

We gave the humble configuration menu a lot of love for this milestone! Your roster setup is remembered between sessions, so your rosters are always the way you last left them even if you quit the game. We added the ability to save and load rosters to disk, to name them, and to share them as files if you want. We’ll be packing in some pre-made rosters for players who are overwhelmed by the possibilities and want to have some fun setups to play with. We previously limited you to 16 ships for technical and UI reasons, but now you can have a roster of up to 56 ships (which is its own somewhat arbitrary limit).

One interesting permutation of how this works is in online multiplayer. Since each player is bringing their own last-selected roster into the mix, we do a little bit of cleverness when players get to the lobby because Player 1’s (the host’s) roster is going to be different from Player 2’s (the joiner’s) roster. The way our networking tech works, the only thing players are allowed to do is send input which affects the shared gameplay experience they’re having. That input is usually just literal input, like thrusting or turning your ship, but it can also take more exotic forms like pressing a button in the menu. Once we finally arrive in network play, each player sends along their roster configuration as a form of input too, manipulating their own roster based on data which is saved on their local device. It’s pretty magical, especially since players don’t even know it’s happening. Okay, well, now they do if they read this paragraph. Sorry, the magic trick has been revealed.

We could have written an entire update just about all the progress and focus that has been put into the UI. We added visual support for “multi-input” menus where two players are allowed to control one menu (think of letting both players manipulate the pause menu, for example). This is extra-important on consoles where there are often requirements to always allow a single controller to exit the game even if another controller disconnects, but it’s still a good user experience on PC. As an unintentional accident of implementing better support for typing into text entry fields like naming your rosters, setting up network games, or even in the-game issue report, we wound up with some rudimentary mouse support implemented for the menus. 

Because it’s valid for a player to play with both a keyboard and a controller at the same time, we support button prompts which adapt to the last-touched device. In local multiplayer, where each player will be using a different device, we show players prompts relevant to their device. In one of our aforementioned multi-input menus, we show both prompts. There’s a lot of permutations we need to support! We also used to have a terrible UX for assigning devices for each player when playing two players at one device. We have a much nicer one now which asks players to each lock in their devices in turn before starting a match.

Our UI is still in progress and will be the last thing to be polished, since it tends to leapfrog with our UX as we develop newer and better ways of doing things. We love using audio to embellish things, so we also added support for positional audio in the GUI which helps add some more audio color to menus and also makes sense of some of the chaos when we have two players menuing away at once.

Last but not least, we implemented our credits screen and inserted all of your names into it! If you fire up the demo and immediately go hunting for yourself in the credits, we won’t tell. It’s actually pretty awesome to be able to run the game and see for ourselves just how many people showed up to support our work. Seriously, it’s amazing and we can’t wait for you to see too.

Nuts and Bolts

While we’ve been polishing the surface of our demo, we’ve also still been working on the scaffolding to help us support that effort. One fun innovation this milestone was creating a soak test with a stand-alone setup that you could run to have two CPU opponents duke it out infinitely. Fred became the best customer of this tool, since it simulated almost every permutation of two ships fighting, and he was able to run a stress test for Simple’s predict/rollback technology with it where it constantly advances forward and rewinds backward over and over, checking for desynchronization (which would point at a problem in Simple he would need to fix).

Beyond just uncovering novel issues in Simple which Fred was able to address and also validating that things were behaving as intended, the soak testing also uncovered issues in the designer-side implementation of certain ships. It wasn’t exactly like having a real human QA team banging on the game, but it sure was helpful to have the digital equivalent of infinite monkeys with typewriters trying to do stuff. It wasn’t much work to set up, and it’s paid off a lot.

Even deeper below the sea, we upgraded our Godot version—mostly to make our eventual Switch release easier. Upgrades always come with a little bit of pain as the earth moves a bit around under our feet, that little bit of pain now usually gets us some real gains later. We also took a pass on a long-overdue task of getting our warning/error count down to zero. We’re used to ignoring all kinds of messages during development because we don’t care too much, and we know things are going to be changing anyway. Why fix an error from a feature which is going to be reworked anyway? Once we moved into playtest mode, though, we wanted to make sure the error output was actually a useful metric for us, otherwise we’d just be likely to ignore new errors in the sea of existing ones. That was a fun bit of housekeeping (Not joking! It’s gratifying to make a number go from 200 to 0!) that’s made our build and QA processes even better.

Speaking of builds, I (Dan) have been making all the builds we release to playtesters, and I am incredibly lazy. We have some pretty slick build scripts that handle the making of a build, but they didn’t do anything to help actually distribute the build (i.e. push it to GOG or Steam). Since we’re making builds pretty frequently and across six different platforms, I got tired of the several clicks, typing, brain-waste, and possibility for human error involved in getting a build from my machine out to playtesters. The Mac build process hadn’t been set up to actually distribute from Mac, either, requiring an even more tedious copying process! No more: we have some nice, new, even more automated distribution handling after builds are made. In addition to automating the distribution, builds also now contain version information in them which Fred and I both can use to help track issues introduced or removed between builds.

Boxed for Retail

Beyond just getting our technical ducks in a row, there’s oodles of work getting ready to actually release and distribute our demo on GOG and Steam! Since the demo and its features are quite distinct from the final game, we definitely needed it to have its own store presence. With that comes a full suite of requirements for marketing assets.

Among the requirements are text to describe the demo, screenshots that we like, a whole new trailer, tons of different specifically shaped pieces of art to match GOG and Steam storefronts, and of course an actual name. We’d had a few possible names kicked around, but nothing quite forces your hand like actually needing to prepare a release with art and a logo!

Beyond just naming our game, we wanted a new “hero image” to help serve as the digital box art for the game and be used in all those pieces of storefront art. We were extremely lucky to be able to get back in touch with Caleb Worcester who had helped as one of our very early concept artists and made the hero image you’ve been seeing for a while on the Children of Infinity store pages. We hope you love the new image, and we’ll be releasing it in a few aspect ratios for everyone who backed as part of our wallpaper set.

We have said it before in this post, and even said it earlier when we described why we were making a demo, but the demo is going to be our biggest splash we get to make since the Kickstarter ran and before the actual release of the game. It’s our chance to stir up attention for potential players, to get people to join our community, to let people get a taste of the fun we have in store, and to get excited about what we’re doing.

While it’s great to complete a checklist of baseline requirements for the game, we also want to go above and beyond and not waste the opportunity we’re afforded by having a playable demo. We can’t share anything yet, but we’re working on plans for how we can boost our own signal and showcase our demo. One thing is for sure: all of you here playing it and telling others about it will be critical to our success. We’re grateful to have you supporting us along the way!

Finishing Touches

Besides the marketing efforts, what’s left before we can actually release the demo? There is a list of stuff we wish we could get done, and our job is to sort everything between the polar ends of things we can’t live without and things we wish we could have. We have to fix placeholder art and text, address game-breaking bugs, and stop any remaining crashes. On the other end, there are things we wish we could do but that aren’t required, like input rebinding, a better CPU opponent, or a tutorial to help new players get their bearings.

There’s not much more to it than deciding what we absolutely must have and how much stuff we can forgo. Once we’re satisfied with our playtesting results and what’s “in the box,” it’ll be ready to go. By that token, just because we release the demo also does not mean it won’t continue to receive beneficial changes from our continuing work on Children of Infinity. Most of the things we wish we could do are slated for the full game already. When we get key rebinding implemented, as an example, we could make a new build of the demo which inherits that support.

That’s all going to be at our discretion, since the main goal of the Demo is to just ensure people have fun. Would players have more fun if they had key rebinding? Probably! Would they have no fun unless they can rebind their keys? Probably not! These are the kinds of pragmatic project management decisions we make, as unglamorous as it is to accept all the constraints that come with a seven-day week and a fixed budget. But it’s helpful to be able to cast things aside and focus on what matters.

There’s even room for a happy middle ground if you know what you wish you could have but can’t. As an example, we wish there was a more complete tutorial, but there’s no way we can pull it off in time for the demo. We do wish new players will have a space to play and understand Melee without being totally overwhelmed, and acknowledging the desire as a separate artifact from what we think ought to be done—just like we do with our playtesters’ feedback—pointed the way to other opportunities.

What we were able to pull off was a clever re-use of our own Melee setup we use for ship development and testing purposes to make a very simple “Practice Mode”. In that mode, the player bypasses the entire roster setup menu and is just plopped down into Melee, piloting a single ship of their choice. They can switch ships at any time without penalty, and they aren’t even thrown against a CPU opponent unless they opt to add one through the menus. We also expose a setting to disable the CPU’s weapons. All that needed to be done was expose a few of our own internal dev tools to the player, since we had already built those features for our own use! This was an example of taking something we already had that wasn’t exactly the right fit but still would satisfy at least some of the need.

At the time of this writing, there are only a few placeholder pieces which we would like to see tidied up. We have only three big ones: we have an extremely placeholder-y “end of match” UI; our “ship description” UI where players can read about what a ship does in-game is missing final text and other things in many places; and what we call our “network lobby” screen where players gather for a network game is entirely placeholder UI.

Beyond that, we have a few missing UI widgets like our menu framing elements and text presentation/colors which have just been done slapdash while we worked on the UX. Now that we’re certain about our desired UX, we can put the finishing coat of paint on with the UI art. The rest will be guided by playtest and QA efforts! 

What Lies Beyond [the Demo]

Demo this, demo that! How about Children of Infinity, the other half or more of the game? We know many of you are here just waiting for that, and we appreciate the wait. The good news is that everything we wrote about above, perhaps with the exception of the unique store page assets, is all work that was required for Children of Infinity anyway. Beyond those features being necessary anyway, we have otherwise been staying the course and sticking to our plan.

Our narrative lead, Mallory, just wrapped up her full time work with us this month and bid us adieu. We are sad to see her go, but that also means we hit a positive benchmark: our writing is finished enough that she can leave! While the gameplay team was over here pushing Melee to completion, our narrative group was continuing to write. The remaining work for them is going to be polishing minor elements in conversations as well as doing prep for VO recordings. Mallory will still be around to work with the voice artists.

As we approach the release of the demo and prepare to send it into the wild, we’ll be shifting back to working entirely on the Adventure mode. While we’ve continued to work on the writing portion of the Adventure, other elements like Planetside and HyperSpace have gone untouched for quite some time. Now that we have most of the writing stood up, we’ll be working on all the gameplay that supports the Adventure and get back to actually playing through the story with a full game instead of simply playing through the interactive sections with text-only tools. In some cases, this may impact minor choices in the writing, and we’ve scheduled around that as well. We’re very sure of the opening of the game, but there is some more work to do on the very end of the game which may inform how we present the story that we’ve written. We’ll only know when we get there.

The good news is that almost all of our work to bring Melee up to speed has a positive effect in getting the Adventure mode more finished. That said, some of the work is really just specific to the Adventure mode, like how HyperSpace is working and tuned. We’re looking forward to actually completing Melee so we can go back to just building around it too and getting deep into the rhythm of taking everything to the same completed state Melee is at. Like Melee, we’ll be planning out some playtesting as well.

Children of Finity

We know your question because we have the same one. Where is the game? When is the game?! When can we all play it? We’ll answer that in two parts.

Our best answer is entirely in these updates. We know this has been taking longer than you or we may have expected, and we want to get it in your hands too. The list of things that came up as surprise or novel challenges just for this game is a long one, possibly longer than anything Fred or I have ever worked on. If you’re reading this update, you may have been following our journey for a long time. It has been quite the journey for us, too, and we’ve shared all the successes, progress, and bumps with you too.

We have taken great joy in sharing that journey openly with everyone and we continue to find new ways to do it. We’re finally back to doing some of our dev streams, and we slipped the word to our Patreon supporters that we were making our project tracking tool completely open to everyone at https://open.codecks.io/freestars.

We can only tell you what we know, which is that the demo is imminent and we’re excited for you to play it. We’re thrilled to have that massive chunk of work under our belts. We’re looking forward to finishing up all the parts we need for our Adventure experience.

We are a small team with extremely limited resources, and we have to choose our strategy and focus at all times very cautiously. A couple years ago I shared with the team my new favorite word for the project: streamlining. This year, I revised my favorite word to a new one: pragmatism.

Streamlining was good, but we needed something better. I continually encourage everyone to be pragmatic about the approach to things. It’s a humble, unloved, kind of ugly-sounding word in the English language, which is why I like it. I have also realized on this project just how much I take some of my own pragmatism for granted or how much I have learned to be practical out of necessity! Many games I’ve worked on have someone (the producer) whose full-time job is to remind people to be practical. I took that responsibility on this project, but I couldn’t make it my full-time job, and we have had so many unforeseen and novel challenges crop up.

So we’re here in 2026 on the practical track. This meant pivoting to getting Melee in fully ready shape and out in the wild before we finished the Adventure mode. Once that’s done, we can start seeing what’s left to truly complete the Adventure mode. We have no release date, but we know we will be doing PC platforms first, then Switch, and only then tackling PS5 and Xbox Series (possibly in tandem with localizations).

Any of that is subject to change because, in an abundance of pragmatism, we have to fund our own work and survival. Could an opportunity arise which would change our course and help us get things done more quickly? Absolutely! What would that look like? Simply: if we received investment or someone could take on some of our work. As of now, we’re self-publishing and funded entirely by ourselves, Kickstarter, and Patreon. We like that, but it also means all the work has to be done by us.

The last time we actually showed our work to anyone with the intent of seeking support was actually our Kickstarter! I took some time to meet with people at GDC this year and was helpfully reminded that it might be good to showcase our much more complete work to see if there are potential partners who could help us. When you are used to taking care of everything yourself out of necessity, it’s easy to be blind to other possibilities!

As some examples: dedicated QA support would make our own development more predictable, and if someone were to take on the localization or porting efforts, it means we could get those done more quickly. Of course there is also marketing support, which is one critical way to ensure our own success and ability to just focus on making the game great.

Dev in the Time of Automata

We’re not done until we’re done, and we mean that in every sense of the word. We’re not giving up, and we’re not just working hard on making the best game we can, but frankly we’re fighting for it. We want our game to be successful and deliver on all of our hopes and dreams. Most of all, we want all of the players out there to enjoy it.

The second part of why the game isn’t ready as soon as we wanted is outside of these updates and requires looking at the world around us.

At this moment in time, getting anything done on our game or otherwise has truly felt like something we’re fighting for instead of “just doing work,” never mind being collectively excited about it (heaven forbid!). Never in all my years of life have I seen so many people so downtrodden. Never have I seen so many people who feel like they truly don’t matter or that no one cares about them. It has impacted everyone’s work and wellbeing, and our game is only made possible through the work of a lot of people we care about.

I’ve alluded to this frequently in our previous updates, but I need to be more direct now: it’s been a rough time to be creative, happy, and proud. In my role on this project, I want to support the team and all of you in feeling those things. I am a relentless (but not blind) optimist, but I have to concede that there are systems of despair so much larger than myself or anything our project can contain or shelter people from.

How do you project manage around armed warfare, oppression, pandemics, and the disruption to peoples’ general well-being? I don’t know how to represent that in my spreadsheets and best estimations. What do you do if everyone is really struggling? We couldn’t see that coming, much less fathom it. LLMs are just the latest of the deep challenges we have been continually failing to surmount as a collective society, so it would be wrong to say they bear the entire burden for the psychological harm being inflicted right now (never mind the other forms of harm too). We have a system which has allowed it to thrive in such a disastrous way driven by the most ghoulish and unconscionable people imaginable, and we should ask why we let that happen. That said, it has suddenly cast a harsh light on how much we continue to reward the complete disregard for humanity in favor of pure greed. And peoples’ minds are going through some unsettling things while feeling unsafe.

Our game and our team is here as a representation of how much we cherish our humanity. We are proud to work with people and celebrate their individuality, their creativity, and, most important of all, their value. It has been very, very hard to keep people aware of that during this project. I take my duty to this game very seriously, and it’s heartbreaking when I see people I’m collaborating with struggling. I know they can succeed and just how much they matter—to the game, to me, and just simply as humans in the world. But there is a toxic din that we’re all collectively tuned into, like a scratchy AM radio that we can’t turn off. It’s undeniable that we are having a shared experience of being completely devalued and feeling helpless.

It’s a lot of extra effort just to speak over that goddanged radio everyone has on. We’re making the game while metaphorical and literal bombs are going off all around us. I don’t say this to shirk blame, but to simply express exasperation and sadness and let you know we’re feeling it too. It hurts me to see my colleagues and our project impacted. We always ended these posts with words trying to speak to everyone’s best self instead of feeling like we need to be unhappy. Now we just need to remind you that we know so you don’t feel alone. And we’ll still get through it.

To put a final, clear pin in it: “AI” sucks. No AI is used in the creation of this game. I have never willingly talked with a chatbot. AI and its slop can see itself out the door and never come back. If AI is just a tool, then it is a tool for hollowing out your own soul. It is Elric’s Stormbringer: it takes while it supposedly gives, and there is nothing left of you afterward. If AI is just a way of getting things done, then maybe we need to examine why we’re doing these things and what purpose they serve in the first place. We need to understand the disingenuous language being pushed in the name of profit and profit alone.

Most of all, we want to remind you that you are irreplaceable. Because you are reading this, you have agency, you have a mind, and you have value. You can care for others and are deserving of care. Now more than ever, we need your humanity, even if it feels like the world doesn’t acknowledge it right now.

Our game is made by a team of wonderful people who all pour their humanity into the game. We are more than the work we do together, but that work is made up of the infinite, ineffable aspects of our humanity. We’re game lovers, parents, trans people, pet foster homes, artists, musicians, loving partners, tired sometimes, neighbors, obsessive nerds, community members, tellers of bad jokes, and everything you might imagine, and we love being here.

We believe it’s not just the work we do that makes us have value. We don’t think people are meant to be reduced to their output like a machine. We believe it’s being who we are. Whoever you are, you have value too and you make the world better just by being in it. We are excited to prepare Battles in the Beyond and Children of Infinity for release to bring some of our deeply-needed, human-made joy to you.

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