Greetings, Captain! There’ve been some exciting developments since your last visit. Please be sure the walkway to the lavatory is clear and the trash compactor is empty before continuing. Fill, put on, and gaze in your shot, reading, and looking glasses, respectively.

If you’re short on time, here’s the highlights we don’t want you to miss:

• We released our combat demo for all platforms on Steam and GOG!!! Go play it! If you enjoyed the demo, please leave a review. It is a huge help.
• We reopened our BackerKit’s physical rewards for late pledges which any digital or new backer can switch to. We are going to be locking down and disabling all new, late pledges on November 30th, 2026. If you would like to change the platform (Steam, GOG, or a console) you will receive your game key on, you will still be able to change that until the end of the year. Steam and GOG versions will be released first.
• We are working on a schedule for the game’s release targeting June 2027. This isn’t a hard and fast release date. More on that below!

Now, if you have a bit more time to spare, it’s time for the full milestone update! We’ll be walking through how we got the melee demo out the door, including feedback received, follow-up patches, and what we’ve learned so far. We’ll also be covering all the work ahead for finishing the full game and planning its release. And finally, we’ll leave you with some insight into where we are as a team along with some ruminations about how we started our mission compared to where we find ourselves today.

We know it’s been a bit of an extra wait since the last milestone update, but we have been busy. There’s going to be even more to cover this time because of the wait, so without further ado, LAUNCH FIGHTERS!

Releasing the Combat Demo

Y’all. We did it!! We successfully released our demo on Steam and GOG, and it was awesome. It was so exciting that we had to take a moment to write about how awesome it felt on our Patreon. We took the time to write about how exciting it was to have finally put it out in part because it took a ton of work. At the time of writing this update, nearly ten thousand people installed and played the demo! Now that things have calmed down and we’re not fighting a thousand fires all at once, we’ll take some time to reveal what that was like. It is a lot to cover, so we won’t go into every detail, but we do hope you’ll enjoy the peek behind the curtain!

We covered our first pass of playtest endeavors in our last milestone update, which was largely focused on just getting a quality play experience once players actually got into the game. We tuned ships, fixed a ton of bugs, and did other work which was only evident when our legions of players were able to get into multiplayer and bang on the game a lot with one another.

Looking back at when we published our last update (June 10th, 2026), it is actually a legitimate struggle to comprehend just how much work has gone into the demo since. Seriously! This is an imperfect metric, as any software developer could tell you, but in April and May of this year, there were about 125 commits (that is, 125 discrete changes submitted to version control) per month for the Melee part of Children of Infinity. From June until September, we did about double that: 250 commits per month.

Breaking our work up into a few areas we’ll dive into, it was largely:

• Ship polish work, ranging from simple number & design changes, to bugfixes, to audiovisual work, to even some significant reworks on ship abilities.
• Developing Cyborg logic for certain ships’ special abilities.
• Finalizing our UI (user interface) and, in some cases, UX (user experience, i.e. how players interact with the UI).
• Adding and polishing accessibility and input features.
• A lot of polish around multiplayer and performance issues.
• Did we mention bug fixes? So many bug fixes.

We actually spent more time doing work on the demo than we expected because there were delays getting it approved on Steam. The upside is that we got to polish more things and include even more playtesters, and we’ll talk more about that later. For now, let’s go behind the scenes on the myriad things that actually went into the running demo!

Ships and Ships and Ships

By the time we started playtesting, we thought all of our ships were playable. That sounds like an obvious statement, but just because we think they’re playable doesn’t mean a random person can have fun playing them. We covered a lot of the nitty gritty for how we tackled ship changes and feedback in our last update, and this milestone had us continuing to address those items based on playtesting. There are only a few ships that have seen significant changes since the initial playtest spree.

There was a design intent with new ships to be a a bit more intentionally odder and unusual than with our returning vessels from The Ur-Quan Masters (UQM), which have a lot of very straightforward abilities and tend to be pretty pick-up-and-play (apart from a handful of the low-point-cost oddballs like the Umgah Drone). Perusing remarks players were making, I (Dan) saw one player calling the new ships “gimmicky,” which we took as a positive sign! I believe one of our playtesters described them as “requiring set-up” which is another good way of describing the target. This was fun to see, but we’ll save more thoughts on player feedback for later.

We still wanted most ships to feel like they were pick-up-and-play with at least their primary weapon. Press the button and an immediately understandable thing happens that will probably damage your opponent—in most cases, a missile or laser shooting forward. Pretty simple, right? Even stranger ships like the Umgah Drone from UQM follow the same logic (press button, deploy antimatter cone). The goal is that even a player who has no idea what’s going on at all can learn something just by mashing the ol’ reliable primary fire button.

We have three ships which abide by that simple formula but also include some non-obvious nuance in how to push the button. One of those tricky ships was the Skald, a ship with a spinning barrel that controls the rate of fire. The faster the barrel spins, the faster it shoots. If you run out of energy while firing, the barrel overheats and requires your energy to recharge fully before you can fire again. It plays a bit like a crazier off/on version of the Druuge.

The problem was that the ship actually has three inputs. You could fire its standard ammo, fire its special ammo, or just spin the barrel. The optimal play involves spinning the barrel up, which uses much less energy than firing, and then only firing when the barrel is at top speed. You’d have to learn just how to release the firing keys before overheating for the best possible salvo. Since we wanted players to have an easy time spinning the barrel, the key inputs were as follows:

• Primary fire: hold to shoot standard ammo and spin barrel up
• Secondary fire: hold to spin barrel
• Primary + Secondary fire together: hold to shoot special ammo and spin barrel up

In practice, it just became really hard to control which ammo you were using! If you wanted to do the “simplest” thing, winding up the barrel and then firing your standard ammo, it felt a bit like playing Dance Dance Revolution with your fingers as you made sure not to press both keys at the same time after you finished winding the barrel up. An attempt at flipping the logic around so chorded keys were standard ammo made it easier to control, but also was confusing because the “special” weapon was now the default primary button. The struggle was confirmed with some playtesting, so the inputs were changed to use the approach we added for the Prowler, which is to distinguish between a key hold and a key tap:

• Primary fire: hold to shoot standard ammo and spin barrel up
• Secondary fire: hold to shoot special ammo and spin barrel up
• Secondary (tapped): Tap to switch the barrel on or off.

We’ve observed that players picking up on the tap/hold distinction isn’t always guaranteed, but once a player learned it, the flow was much easier. Tap special to spin the barrel, and then you’re just thinking about selecting ammo. No more funky chorded keys. The other advantage is that a few ships use the tap vs. hold scheme, so if a player learns how that works once, they can apply that knowledge to all ships that have it. 

One of our other oddball-firing ships is the Acrobat, which has three separate barrels that take a very long time to reload but can fire one after the other, letting you potentially get three good hits in before needing to reload. The intent of the ship was that it would pick the “best” barrel to fire when multiple barrels were available for use, ensuring the player could score hits if possible, but that scoring those hits would require a lot of skill. The problem was players couldn’t figure out how it worked and were constantly missing shots. The fixes under the hood were twofold. First, the logic for calculating the best barrel was completely flawed! Second, the lack of a visual indicator coupled with the bad logic made it too hard for most players to ever master.

Fixing the barrel picking logic did most of the work, but actually adding the visual indicator immediately made players at least think they could be more successful with it, since they could now more easily parse what was happening. The ship was still a little too weak and defenseless, so we also experimented with a few more “high skill” buffs before settling on a temporary directionally-specific shield. The theme of the ship is all about doing things with directions, and we’re happy with the end result. We were seeing more of what we wanted: players struggle to do well with the ship on any early attempts, but with some practice they can learn to be a menace.

Taking some lessons from the Acrobat, we applied some of the same logic to our weirdest-firing ship of them all, the Clipper. The Clipper has a tricky, delayed firing mechanic where you can charge up a salvo of shots which fire after a significant delay. The problem was that the delay was telegraphed through some subtle visual cues and audio—too subtle, it turns out. For a long time we weren’t sure if players would learn to intuit the required timing, even though like the Acrobat, the Clipper was supposed to be strong with some practice.

Observing players play, it was clearly too unwieldy. We addressed it in two ways! The first was by giving it a much more direct, optional weapon: a very short range shrapnel cannon that would let you do damage immediately if you happened to be very close. It uses the same tap vs. hold mechanic described above. Beyond that, the timed firing mechanic became much easier to comprehend by giving the ship a very loud and obvious visual cue for when it was about to fire, which also doubled as an aiming assistant. It had an interesting side-effect, too: the extremely bright graphic helps the player controlling the Clipper to know and aim, but it is equally helpful to their opponent! We’re pretty happy with the net result.

Beyond these major fixes, there were tons of tuning, polish, and balance changes to address ship behaviors and interactions (not to mention the oodles of genuine bugs). This got easier and easier as we got more playtesters joining. At our last milestone update, we only had about a dozen folks playing regularly. Before we released the demo, there were around 150 players who at least played it for a bit and were able to provide some feedback, data, or bug reports.

Our Cyborg still has much more work left to take it to completion for the adventure mode, but we did tons of polish on it this milestone. There was a lot of work just getting the Cyborg pilots able to control their own ships, especially for the new ships with unusual abilities. The more exotic the ship was, the harder it would be to create logic for how it should be used successfully. If we changed a ship’s abilities, as described above, then we would have to redo the Cyborg logic.

Speaking of—the general Cyborg logic which all ships use was vastly improved. At the moment, there are a few ships that the Cyborg doesn’t understand how to use optimally. There are at least a couple, like the Vaculo, that the Cyborg flies in a way that is just confusing for everyone involved. It certainly has no understanding of special match-up behaviors, like an Ur-Quan Dreadnought not wanting to launch fighters against an Earthling Cruiser.

One critical feature added was just exposing and designing a Cyborg skill level. Expert players will still be running circles around our best Cyborg opponents in the current demo, but we were much more concerned with new or novice players not having someone they could have fun playing against. We added three different difficulty levels and put the most effort into tuning the novice Cyborg to be actually beatable and fun for a new player.

An amazing, challenging Cyborg player for really skilled players which is fun to play against without being unbeatably godlike is actually a tremendous amount of work, and not something we’re even going to attempt. We want a nice sparring partner and a Cyborg good enough for the Adventure mode to be fun, but that’s about it. We can certainly make a challenging Cyborg which is no fun to play against which aims and shields perfectly, but you really don’t want that either. Technically, that’s what our first pass implementation of the Cyborg did. It was a great proof of concept that was awful to play against!

User Interface

If you check our previous update’s images against the released demo, you can see just how much UI had been remade. It’s really hard to overstate this because it was every UI element! The UX—how players interact with it—is recognizable in a skeletal form in some cases, especially in certain layouts. The visual styles for the old UI, which is still being used in Adventure mode at the moment, were built around all of the Adventure mode experience and visual trimmings. Once we got into building the complete Melee experience, from launching the game to networking to preparing your loadouts, it became quickly obvious that we needed some different visual metaphors and styles to handle the menus that happen before getting into gameplay.

Our previous UI was designed for use directly on the “tactile screens” we use throughout our in-game GUIs as framing elements. The problems with using these screen backdrops for dense menus is that they not only eat up a lot of space but are completely inflexible in how they’re laid out. 

This example from the fleet configuration screen shows just how difficult it would be to fill space we needed for other things, like the menu title and button prompts. The screen backdrops in this image were also just hacked together, and if we wanted to keep using the motif, we’d need to make final art for them, which is more complicated because they’re all pre-rendered 3D assets. The scope would get scary pretty fast—never mind the fact that, in my own words to the concept artist who I worked on the new UI with, “They’re not exactly making anything better.” It’s just a lot of pointless visual distraction on a very information-dense screen.

And this is just one layout! We needed many other layouts, and we also needed to be flexible because sometimes we wouldn’t even have much of a frame when we wanted to use the whole screen and weren’t focused on a 2-up motif during the fleet config screen, like in the settings menu.

Developing the additional style was actually a fairly rapid timeline from prototyping to completion compared to how we did our previous UI elements, which were built before some of the UX was implemented. This time, since we knew what we wanted out of our UX, it was much faster to iterate on the visual skin until we got something we liked. Anyone who’s looked at our Star Map will immediately recognize some of the visual motifs in the final result, and you can see some of the process and work behind the scenes in the previous Patreon-exclusive post we shared.

UX and Menu Inputs

Beyond the aesthetics for the menus, we implemented a whole host of new UX for them and did tons of work on input—that is, how players actually control the game and its menus. A little bit of inside baseball (even more inside than usual!) for a moment: our entire menu UX is effectively built from scratch even though Godot provides mechanisms for letting players interact with buttons and other widgets with a mouse, keyboard, or controller. There are reasons we might want to manipulate some of the default behaviors because we have opinions about how things ought to work instead of settling for the out-of-the-box way, but the main reason is that Godot (and perhaps other middleware engines?) has no concept of multiple players on multiple menus at once. In fact, Godot doesn’t have a logical system of what, exactly a “menu” is at all, never mind a submenu. It just has some ideas about interactions like focus, which is highlighting a button before you press it, and things which can react to interactions like clicks with a mouse.

None of that will cut it for our local multiplayer setup! If you play the demo with another player, you’ll see that you can each interact with your own menus and submenus at the exact same time, like in the fleet config or melee ship picking screens. This wouldn’t be possible without us keeping track of each players’ own focus and menu stack. In the full game, there are cases where both players can try to drive the same menu at the same time. Playing Melee in single player against the Cyborg? You still need to be able to control the “other player’s” menus so you can set up their fleet! All of our menus need to be multiplayer-sensitive, and the handling for singleplayer, local multiplayer, and online multiplayer can be subtly different.

We have many permutations of these kinds of input interactions just in the demo. We have screens where all devices control the same menu since there’s no concept of players yet, like the title screen. We have game screens where there are two menus but one viewport (game play area), like the actual Melee match. In local multiplayer, either player can still control the singular shared pause menu, but each player can only control their own ship select screen. It gets complicated very quickly, but it was really fun to bring it to life and I had some unique experience under my belt having solved the exact same challenges on Skylanders for its local co-op play. I have a special fondness for these kinds of systemic challenges, and I honestly think it’s magical when you can make something that just works without players having to think much about it.

At a high level, the way our whole input scheme works under the hood is that each player, viewport, and menu can have a device associated with them. In single player, you’ll never think about this. You can pick up a keyboard or press buttons on a controller, and all of them will let you control the game. In local multiplayer, things get fancier! Players opt in to using a particular device (keyboard or controller) through a specific lock-in flow, and at that point we know who’s using what device. Players each have their own menus, which may or may not be associated with a viewport or a given menu. In Melee, there’s only one viewport, but in the Adventure mode, players can be experiencing totally different gameplay or menus since they will be playing in splitscreen.

It was a lot of effort but a lot of fun to get everything functioning as intended for the demo, and there’s still a few areas we would still like to tidy up in the future. Critically: it works, and the base implementation will also serve us for the full game. There were some unique challenges and weaknesses, too. The biggest challenges were the mouse and text input, neither of which is great right now but are caught in the unenviable position of not being too necessary.

Mouse and Text Input

When we started, we had never intended the mouse to be used at all since the mouse isn’t used during gameplay. The problem is that a mouse is a useful thing, and we actually started needing things which would support a mouse once we got to player text input—things like typing in an IP address for LAN play, or our in-game issue report function. Once we needed to thoughtfully support the notion of text entry, supporting a mouse was, perhaps counterintuitively, just a simple add-on to the text input requirements.

The reason is because different menu elements can change what a player’s inputs will do. Normally in the menus, pressing the left arrow on your keyboard will change the focus to a different element or possibly adjust something like a volume slider. Since text entry fields have a unique behavior which is not going to change the focus of something but may just move your cursor around, we suddenly needed a way of short-circuiting our usual left-means-go-left behavior and enter a sub-focus state on the text field indicating that you’re entering text now. Strangely, that sort of multiple-possible-states tracking is exactly what the mouse needed to get working. Beyond that, not having a mouse to help control text entry was quite the bummer, especially if you were typing in long messages or flipping between multiple text entry fields by trying to connect via IP.

Both the mouse and the text entry fields had to have custom implementations because of the aforementioned challenges. We can’t use the Godot focus internals because it’s not quite smart enough to handle multiple players. The mouse and text entry are a little bit of a special case, though, especially since we don’t expect multiple mice or keyboards. If player one is using a controller and brings up a text entry field, but player two is playing on the keyboard… what happens? Nothing good, that’s what! In the demo, our treatment of this scenario is simply to hijack the keyboard input any time a text entry field is up and prevent two text entry fields from ever being up at the same time. There’s a big kludge in there that lets the text-inputting player “borrow” the keyboard while they type.

Now imagine playing local co-op during Adventure while one player wants to change the captain name while the other player is in the middle of using the keyboard for melee. We can’t just steal the keyboard away while someone else is piloting with it! There’s still some design work to do for this one beyond the work we already did to just make a text entry field that worked at all. Never mind a keyboard scheme which would let two players play at the same time, which we are not doing in spite of its presence in UQM and will explain why later.

A similar challenge arises with the mouse. If each player is assigned a device, and they can only navigate by pressing controller buttons and keyboard keys, we can “confine” them to the menu where they belong. What happens when you use the mouse? Shouldn’t the mouse be able to manipulate buttons anywhere on the screen if the players want it to? Probably! The problem is that this idea of an input device which can be used by both players isn’t part of our whole metaphor, and we don’t want to let the mouse suddenly change who might be controlling a menu. The solution for the demo was to just never let player 2 use the mouse, which isn’t great if they’re the one trying to play with the keyboard, but is functional for our UX.

There are other mouse challenges we didn’t get to, either. Our UX is entirely designed and intended for a keyboard or controller. Our menus use implicit “close” actions (e.g. the Escape key or the controller’s cancel button) instead of a discrete, clickable close button. You cannot navigate the menus solely with a mouse right now because you can’t close a menu with it. The visuals for “hover” (mouse cursor on top of something before you click it) are totally placeholder. What we call the “tree and leaf” metaphor for menus like the Settings menu where you can navigate into submenus was made with keyboard and controllers in mind, and a whole different, custom bit of logic is written for the mouse which actually just spoofs input a controller would do based on what you’re clicking. It’s a pretty big hack!

We Can’t Do Everything and You Can’t Either

Like many features in software, the moment you crack a door an inch wide, suddenly it feels weird if the door doesn’t open all the way. What about your scroll wheel? What about being able to click things you’d never highlight with a controller, like a scroll bar on a scrolling menu? Now players will want to be able to highlight text. Now we have to think about supporting the mouse “hover” state because the mouse provides no control for “focus this, but don’t click it”. One player complained about not having Ctrl+C and Ctrl+V support in a text entry field. Having a mouse builds a whole suite of expectations that things ought to act in mouse-y ways for people used to mice, but we don’t just get all of that for free because we’re not an entire operating system and we have a lot of unique local multiplayer needs. Windows isn’t designed to be used with a controller, either!

When thinking about creating a good user experience in these kinds of technical scenarios where I can imagine many possibilities, I sometimes just look at what other games have done. Is there a game that has handled this well in some intuitive way that has lessons I can learn? Actually… no! I truly couldn’t find one after running piles of my own games. I won’t bore you all to tears writing about the many games I scoured, but I’m afraid we are a bit too much of a unicorn at this point. The closest comparison is Baldur’s Gate 3, but they show an entirely different UI depending on whether or not you’re playing on controller or keyboard, and even though they have local split screen multiplayer, you can only play it with controllers! Think about that, we’re solving issues even Baldur’s Gate 3 didn’t. We are so clever. Either that, or the developers were smart enough to know it’s not worth the time and energy. Good thing we put all our points in CHA instead.

The same was true of “tree and leaf” menus. Either games are made for controllers and then a keyboard just acts like a controller (often these are console ports coming to PC), or they are made with the assumption you’re using a mouse because it’s a game that uses a mouse. I don’t think our tree and leaf menus are totally right at the moment, especially since they could use some more visual clarity, but there are many subtle interpretations of how these ought to be controlled if you look through other games! They are broadly different if the player is expected to have a mouse or not, though.

All that said, what will be the eventual fate of the mouse for the full game? Probably close to what it is now, with some clean-up to at least make it a little less miserable. This is one of those product and scope decisions. We could spend a month making the most amazing mouse experience in the world, but what does that have to do with piloting ships, playing the story, or doing anything else? Not a lot! The controller and keyboard are always going to be the optimal experience, just like using Windows or a web browser with a mouse is always going to be easier than trying to use it without one even though they have specific accessibility features to ensure it can still be done.

But We Did Some Cool Stuff

With those travails aside, there is a lot of really neat interface functionality we added in preparing for the demo release, all of which will carry over to the full game. Having a lot of playtesters trying to do things helped us identify areas where players needed more guidance, from simple rewording of text, to specially built UIs, to actually creating clearer visual cues for players. 

We enhanced our “Practice Mode” feature with write-ups of all the ship powers and their controls, which were previously only laid out in an external manual we provided to players. Players can see the explanation for a ship’s controls when playing in Practice Mode or in the Fleet Config screen when picking a new ship.

We also put in a lot of polish on our button prompts—those humble little doodads that sit on the bottom of the screen telling you what to press. In single player, the prompts will adapt to the last touched device since players don’t have to lock in any devices there. In local multiplayer, they’ll show glyphs for the assigned device. In the lock-in screen where players are assigning devices, we show all possible buttons. We support playing with Xbox, PS4, PS5, Switch, and Steam controllers and have custom glyphs for all of them, so the button you see should match the controller you’re using. And we can always add more if we need to support additional controllers.

We added the long-planned-for input remapping screens and UX. Players can finally free themselves from the tyranny of default bindings! Controller input was designed to be as pick-up-and-play as possible, so there was no discrete thrust button and ships simply decided to thrust when facing close enough to the direction the player was pressing. For experts or people wanting more control, we added a discrete thrust button in addition to being able to turn off automatic thrusting altogether.

Truly, we’d be here all day just listing off every single thing that wound up in the demo, and it probably wouldn’t be interesting to read about it unless we did some thoughtful writing about what it was like to do it and why we did what we did. We’re not going to torture ourselves or you like that, so the above are just some highlights. And this was just in preparation for the release. We’ve still got to cover how it went and what we learned!

Before we move on, the last thing to note is that getting the game through the hurdles on Steam was such a saga that we shared the entire story with our supporters on Patreon. It was initially an exclusive, but we’ve made it free to read as of now. If you would like to read a horrible story about being trapped in a Gilliam-esque bureaucratic hell where we were treated like an insignificant speck in a machine (and if you don’t feel like you get enough of that in your daily life), we encourage you to check it out. If not, the short version is that we had to delay the release of the demo by several weeks. We got some additional polish time in, but the experience was very stressful, and it prevented us from trying to lock in any plans around marketing our release since we couldn’t even set a release date.

Call and Response

On September 8th, after oodles of Steam-driven delays, we released our demo to the whole wide world! We don’t have a PR team or anyone doing marketing besides my own labors at this time, but we did create press releases and send early access keys to several online publications. In that same week, though, there was Nintendo Direct, some Apple announcements, and BlizzCon.

We really can’t compete with any of that as far as games and tech journalism is concerned, so it was unfortunate that our demo’s release was effectively buried under mountains of articles talking about more important news like the textures on Link’s hat, two thousand dollar phones, and in-game cosmetics. In response to this, I wrote and actually filmed a comedic script for a Druuge Direct stunt video, but I was too swamped to actually get around to editing and publishing it. Maybe later. We did get a very special piece our own writer Lee Hutchinson was able to do for Ars Technica and some nice coverage from GamingOnLinux too!

As unfortunate as all of our bad timing was, the demo is not our make-or-break marketing moment—it’s just one piece of our arsenal, and much of what we want to share here is about the view from inside the fishbowl, so to speak, and what we did in response to what we saw.

Getting Feedback

Speaking from experience, I know most creative colleagues don’t handle raw community feedback well without previously having had a lot of coaching through its, er, rawness. First and foremost, I took a moment to speak to some of our various contributors whose work was finally on full display in the demo. For many of them, this is their first professional game work ever! This can be one of the most terrifying things for many, and I would say about 10% of the people I’ve worked with in games are actually prepared and happy to handle it. I reached out to them and gave them some mentoring.

The message varied from person to person, but this roughly what I shared with people:

• Most players’ “job” is to be highly critical. Even if they’re excited they will be complaining. It’s because they care.
• You can listen to players, but you don’t owe them anything and you definitely don’t need to explain anything. It’s not your responsibility! (It’s Dan’s!)
• “I love the community, but If I spent time listening to what players were saying, I’d never get anything done” — our own Mallory Littleton
• Most importantly: you are not obliged to be there! About 90% of developers I’ve worked with function better just doing what they do best, not being in a community space for their own work. Please see yourself out if needed and don’t feel bad for doing it.

My preference in all aspects of life is that everyone just listens to me because I’m always right about everything. Sadly, that hasn’t happened yet. Even my birds ignore me! I can’t stop people from looking at Discord, the Steam forums, Reddit, or other community spaces. They can’t not look. It’s a door they can hear commotion behind, and they’re curious. I can tell people “this is awesome and you did a great job” one hundred times (and I do), but they will still find the negativity. It takes discipline and practice to be aware of and cultivate “the teflon mind”, and our default is to instead slough off the most overwhelmingly good things while honing in on the one thing that makes them feel like they failed. It’s a survival trait for humanity.

A rare type of person takes to this naturally. For the rest of us mere mortals, there’s a whole set of muscles one needs to train to participate in a community when your work is its focus. It takes understanding to know there are personalities and environments involved in how people give feedback. A minority of people online can come across as or even be mean. They get a lot of attention by doing it, too! Negativity gets more attention from our sticky minds. The wizened elders among us have ancient parables like “don’t feed the trolls,” because people love playing games, especially social ones.

I wanted to share the details of this process because it’s not always the kind of thing that gets talked about. It’s a very vulnerable thing for people to put themselves out there or feel like you’re obliged to do it because you’re part of a project. I’m very proud of everyone who’s worked with us because one can actually stop themselves from moving forward because of the fear of these things—never mind the fear of succeeding, which is a whole other thing we’ve talked about before. But we don’t.

So with all that said about me trying to coach our team on what to do, what do I do? I read every single thing. If you wrote it on our subreddit, Steam forums, Kickstarter, our Discord, with the in-game feedback report, or anywhere else I monitor, I read it! It’s part of my job. I am grateful for every single thing players have written. Yes, even the mean things! Even the harsh criticism! Even the off-topic absurdities! This is part of what we are creating, along with our community. The corollary to players feeling like it’s their job to criticize is also a much simpler, human aspect: if they didn’t care, they wouldn’t say anything.

In these situations, I’ve learned to be mindful of all the things I don’t know! Especially online, you are missing so much context since you only know the words someone types. You didn’t even watch the player play, which is the most educational feedback especially if it’s in-person.

You had no idea what players were experiencing or doing that caused them to say what they said! Someone could have had two kids running around vying for their attention. Someone could have had bad audio hardware and none of the sounds came out right. Someone could have been absolutely flailing and not even playing as you intended for a reason you’d never think of. Their room could be too dark or bright. It might have been raining outside. They may have been having a bad or good day. All the context you might pick up on from observing and interacting with a person in their own play environment is lost.

Knowing all of that, you still have to enter these spaces with your eyes wide open. You can’t put your ego into the situation because players aren’t speaking to that part of it. They’re there because they care about something or want to express how they feel. It has nothing to do with you. I get mad at games too. I get annoyed when I encounter frustrating things that I feel shouldn’t be frustrating. That’s normal!

Last but not least, there is something I always use which sounds like some kind of new-agey joke, but is truly valuable. Knowing when you need to step away. That can be five deep breaths, it can be going for a walk, or it can be simply saying “enough of that for today” and shelving it for later. I’m human, too, and I can also have my own (valid!) emotional responses because I care deeply about our work.

We don’t have enough bandwidth to truly curate our community anywhere except our Discord, but in that space we really do try to be present and let players know we’re listening and participating. It’s actually quite amazing how differently people will behave and talk if they know they’re actually in the presence of other human beings who treat them with respect and empathy. Sometimes just reminding folks of that is all you need to do, and it’s worth remembering that people won’t approach every space with that in mind.

All of that is no small thing! Like all emotional labor, it is hard to measure and can very easily be discounted, but it’s the filter through which everything goes.

[Players Helping | Helping Players] Find the Problems

Players are simply fantastic at spotting issues and we rely on them for that. However, just because they’re great problem-finders doesn’t mean they are able to identify solutions. Only we have the complete context on the full project, the intent versus the execution, and the chain of dependencies that is leading to their negative experience. A player can tell you a lake at the bottom of a mountain is dry and should have water, but the fix might be unblocking a river upstream or ensuring there is adequate rainfall as opposed to just rushing to dump buckets of water into the lake.

We benefit tremendously from feedback. It’s just not always for the reasons you might think!

Take the case of mouse input above, where we know something isn’t great but release it anyway. If players give feedback that it isn’t good, that’s a kind of sick and twisted—but very helpful—bit of validation! Players are noticing it, so that means players are trying to use the feature we put in and having a bad time, so they agree with us that it’s not ideal and it may be worth our time to improve. We don’t expect players to come up with solutions for us, though.

The inverse would also be true: players not saying anything about something that we think sucks can often confirm that it’s not such a big deal. Hey, they’re not even noticing it, so we shouldn’t work on it much more. This is a huge boon to how we prioritize our work.

We want to build and support a community around our game, so simply providing an outlet for players also says something about who we are and what we’re making. Our public bug-reporting setup in Discord includes ways for players to participate together and discuss, creating even more of the community we want. Players can find that others may be experiencing similar (or different!) issues and come up with new insights together. They have fun being able to trace their feedback through our systems.

Feedback we don’t act on still provides information. Is one player asking for something, or ten players? What are they saying about it? If players are asking for something, even if we don’t ever do it, it points out something that players are interested in. That’s valuable insight about the kinds of things we can do, especially when you compare it to things players don’t ask for at all! It can help us distinguish the difference between “someone said something” and “overall sentiment.”

We can develop insights. Twenty unrelated reports around players’ frustration in different points paints pictures of what kinds of underlying systems are either fun or frustrating in general. This also helps us develop plans for marketing and communicating about our game! Oversimplifying a bit, let’s assume players give unilaterally positive (or no) feedback around certain areas and negative feedback in others. This can tell us we should be hyping up the parts getting a positive reception since those seem to be resonating with players.

All that said, feedback we can’t or won’t act on today could also be something we can do at another time. Circumstances can change, and more games may even be made. Players’ yearnings for things which can’t be part of this game can spark all new ideas for future things!

Last but not least, our north star has always been to make the process of making our game fun for players. Part of the fun we want to provide with this open feedback and even this discussion about feedback right now is education. We think you’ll enjoy learning about and participating in it, and we want you to know what it’s like on the inside!

And Here Comes the Feedback

Going from a hundred playtesters to thousands of players felt a bit like going from the initial upward section of a rollercoaster at the beginning to the first big drop on the Giant Dipper. We intentionally provided several ways to get feedback, including an in-game reporting system and a dedicated Discord set-up along with a publicly-viewable tracker. The rate at which these systems picked up in speed and types of reports were shocking, going from a few edge-case bugs our seasoned playtesters were finding to hundreds of people catching every sharp edge, finding things unique to their hardware setup, and coming in with all kinds of different knowledge and expectations.

We learned a lot very quickly and found ways to improve on all fronts, but we only learned what was lacking once everything went into service for our droves of players. We made better reporting, improved how we filtered and sorted it, and we learned how to actually help certain players through technical issues we couldn’t fix for them.

Priority 0: Tech Problems First

Technical issues were the top priority. Seeing reports come about problems people were experiencing was of course disappointing, but we needed corroborating reports to know if it was just one person, a swath of people, a particular hardware configuration, or any combination of the above. With the flood of reports now happening, we were able to identify a handful of common problems which we had to address in different ways:

• Players were seeing one-time hitches as a result of shader compilation when certain graphics were displayed for the first time.
• Players had hardware or software which did not support Vulkan, so the game was running in an unsupported-by-us OpenGL fallback mode.
• Mac users were experiencing occasional crashes during gameplay.
• Mac users occasionally saw some game artwork rendered as black, unlit meshes.
• Several players were not seeing 3D objects rendering at all.

For the first two issues, we had enough information to proceed. Disabling the OpenGL fallback was a simple enough change we made in Godot, so now users would at least see an error if their setup was unsupported as opposed to playing the game in a broken state.

The shader compilation issue was a longer journey which we’ll cover in brief. If you are extremely interested in the technical nitty-gritty of how Godot and shaders work, you can read their own technical documentation. The high-level laypersons’ version is this: shaders are tiny programs that your graphics cards run, and we write them in a universal language. Those programs are translated to your specific device’s native language as needed when there’s a new graphics instruction. Each computer’s unique graphics card and driver combination will result in the need for that preparation step, so there’s no way the work can be done before the program launches (though certain pre-fab devices like the Steam Deck can because they are all the same). When you run the demo, you’ll see a loading screen, which is us attempting to put your device through its paces and prepare all of the assets so the game won’t hitch as it encounters a one-time “untranslated passage” in the shader code.

This is especially bad in the case of our game, where assets are shown on screen for the first time in the heat of battle—as opposed to while loading in a large level which has a static backdrop. On top of that, because the gameplay is running on a separate loop from the display behavior, the hitch would happen in the worst possible time and produce the worst possible results. A player or the Cyborg would select a new ship, and the moment battle started their screen would freeze up for perhaps a full second or two, depending on their hardware. Often the player was playing online or against a Cyborg opponent, so their opponent would continue to be able to play during the freeze. That was bad!

We had a solution in place on launch, but the problem is that the solution wasn’t comprehensive enough! It covered some of the shader code used by certain ships and their powers, but many were not actually handled. This slipped through simply because we thought we had solved the problem correctly. Especially since all of us (developers and playtesters) had already been playing for a while and had gone through the steps where we might notice this issue. It turned out the problem was quite severe, and it could be even more severe depending on hardware, platform, and even if you were playing on Steam or not.

I have about eight different test devices I run our builds on with different CPU, GPU, and OS combinations. I have intentionally awful, below-spec devices. I have things which match our intended minimum or recommended specs. The challenge with this issue is that shader compilation by definition creates cached data for reuse. Our failure was that we weren’t actually, truly purging all the cached data while testing solutions. As a result, we saw false positives indicating things were going correctly. The first step was identifying all the permutations of cache file locations, which differed across every combination of hardware and software. Nvidia, AMD, and Intel GPUs store files in different places. Windows, Mac, and Linux are all different. Even Steam sneakily stores some cache files as a way of helping other players potentially skip shader compilation steps, making GOG builds behave differently than Steam builds.

Once we understood all the steps to take to reproduce the issue and validate whether or not we were seeing success, the problem became solvable. We created a new shader preparation process, which did require a lot of under-the-hood reworking of our solution, but it was incredibly satisfying to see that we could finally measure our work correctly and actually know with a high degree of confidence that we were actually fixing the issue. We were able to provide a patch on September 25th.

It was longer than we wanted to wait and it was painful knowing it was impacting the all-important first impressions of our game to have every player hitting a really bad-feeling hitch. At the same time, we had to weigh it against other issues which were persistent and wouldn’t even go away. A one-time-per-ship issue is bad, especially if it will turn off players from continuing to play, but a constant issue that never goes away for a player who wants to play a lot is arguably worse.

AMD and Intel GPU Issues

For the latter three issues mentioned above, we actually needed the data players were submitting to us. First up was the non-rendering 3D art issue. Our in-game issue reporting system sends over some logging information from a player’s play session, which includes a few minor details about their device but other diagnostic messages which can help us understand what the player was doing when they encounter issues. After compiling several reports from people who were seeing this issue, we were able to spot a pattern. All the users not seeing ships were using AMD graphics cards. Some searching online turned up this known issue with AMD cards using certain drivers. On my own test devices, I was able to verify this behavior by installing a known bad driver.

Wonderful! Great news! Now what do we do about it? This is a case where we actually cannot do anything but help players help themselves. If players are having problems, we hope they find resources we provide or that they can dig up on the internet, but otherwise what else can we do? We could create some bizarre system that detects and warns if you have a bad driver, but that’s a lot of work for a very niche group of players, and it would be quite risky in case it fails in any way. Players might get stuck with a warning pop-up which introduces its own new issues, or it could be a false positive, or the detection mechanism would degrade the experience for all players because it introduces additional validation before running.

Like many PC gaming issues, the solution is ultimately up to players to figure out. We included instructions in every one of our patch notes posted on Steam/GOG/Reddit/Discord, and we added an in-game updates menu where players can read notes from them. We still get some of these issue reports trickling in, but we just hope players can find the solutions! Update your drivers! The answer is always “update your drivers,” and even in our one-on-one tech support, the first thing to do is ask if someone has updated their drivers.

That itself was a whole other learning experience. Many players came to our Discord or emailed us asking for help when they encountered issues. In working with some of them, I was honestly surprised by some of the things I learned. Most shocking were the number of people who said their system was up to date, and when I asked what graphics driver they were on, they said it was the one provided by Windows Update. I have been playing PC games for so long, it has never occurred to me that someone would do anything but visit a manufacturer’s (graphics, laptop) site to get the drivers.

This was a good lesson in not making assumptions, but also part of a fascinating look into who was showing up to play our game. Some of our players told me they hadn’t launched a game in several years. We had people who weren’t even big on playing games picking up and playing our demo! That is honestly very cool and feels quite unique, and it’s almost flattering that some people in our community are coming from that background.

More frustrating was a persistent unfixed Intel GPU bug with Vulkan where the game would frequently just crash. No amount of driver updating would help players with this! For better or worse, I was able to reproduce this on one of my test devices pretty easily. Searching through Godot’s own issue reports, it appears to be a well-documented driver issue on Windows with Intel GPUs. Since it is specific to Windows, our solution was to release a patch which allows players to run using Direct3D using a command-line argument.

As you can see, there’s a difference between tech support and actually fixing bugs in the build. One of our mistakes in the launch build was in the in-game issue report, which included some text that I believe was making players shy away from entering their email address since it was worded in a way which made it sound like the email address was optional and it might be public information. It is true that the email address is optional, but if someone is having an issue and doesn’t provide it, we quite literally have no way of following up with that individual in the case of a tech support problem! A critical change we patched in was simply rewording that text as well as improving our in-game logging information to help us help players troubleshoot things. Anecdotally, the change in text wording increased the frequency of issue reports with email addresses attached to them.

Mac Issues

Now on to the Mac. On release, it was clear that there was an occasional Mac-specific crash which we had not been able to see or reproduce on our own. That said, since the Mac represents the smallest fraction of the gaming devices out in the wild, we also were not necessarily laser-focused on porting issues beyond ensuring it works and plays correctly on our own. Even among our large playtesting cohort, we only had a couple Mac users. It was hard to isolate Mac-specific issues because of the limited playtesting, the high cost of additional test devices (we only have two between Fred and myself), and the general focus of development on non-platform-specific issues. Beyond all of that, this is also our first release ever targeting the Mac.

Once the demo was released into the wild, we got many more Mac users coming in and providing issue reports! If we can’t reproduce an issue, it’s very tricky for us to fix an issue, but with the data we got, we were able to narrow down what might be going on. Fred was able to isolate the problem under the hood by running our soak test, where Cyborg ships battle each other forever. One of our very engaged and helpful public playtesters was also able to reliably reproduce the issue, so we were able to get some critical extra validation in our otherwise Mac-starved environment. There is still one graphical engine issue specific to the Mac which we have not been able to dig into, but we have to play the numbers game for now and just accept that there’s something odd on the Mac we still need to address. This is made extra tricky because it is not specific to our game and looks more like a Godot engine or Mac driver issue.

Seeing the vast number of Mac players on the demo was a surprise, albeit very helpful for getting us the data we needed to fix the critical crash issue. We have some theories possibly related to the above assumptions about the amount of lapsed gamers trying our game, since Macs are not necessarily known for being a good gaming platform. We do appear to have an unusually high number of people playing on Mac compared to what the overall data about percentage of Macs out there playing games on Steam would tell you. Fewer than 2% of Steam devices are Macs, our community has way more people trying to play on Mac than that! You are so special!

Priority 1: Play Issues

Beyond critical issues like crashes, stutters, and graphics bugs, there were a handful of reports that pointed to some bugs and—in some cases—some missing features that we should prioritize. We’ve already covered a few important ones which would affect human behavior, but the others can be seen simply checking our update notes at the time of writing for Version 6484, Version 6506, and Version 6528.

There are many things we didn’t get to finish in time for the demo, but player feedback highlighted how important some were. A big one was adding more options for controller inputs, which we initially skipped because we ran out of time even though we had wanted to provide them. Our initial implementation of the low-crew klaxon audio was good in spirit, but after getting fresh eyes (ears?) on it, we knew we had to make some design changes to how and when it played.

Other things that we didn’t get in but wished we could were touched on by feedback, but some were not. A more comprehensive results screen was on the wishlist, and players identified that as a want as well. We wanted a simple “how do I even play this game?” tutorial to help totally new players. We wanted a so-called “message of the day” system which could pop up information for players in the case of an update or news, too.

Letting the game run in Cyborg vs. Cyborg mode, a common request from players, is already done and we use it internally. The tricky part is exposing it to players and having the rest of the game make sense of the fact that there are no human players around. There were many, many more things we just didn’t have time for. This includes a lot of polish work we had to skip, especially for ship VFX and UI animations.

Case Studies in Challenging Feedback

We wanted to share a few case studies in feedback that has been challenging to address! In all of these cases, we knew we’d be hearing it at least from someone, if not a handful of people. Like we mentioned above, hearing the specific feedback about these things and just how many people say things is instructive in how we might address them. In some cases, we won’t even be addressing them with any functional changes in the game and it is simply guidance for how we might communicate with players. In others, it’ll be a little bit of a lateral decision: we can’t fix the thing players don’t like, so what can we do to make them like it more?

Melee is a Square Screen

The gameplay of Melee takes place on a screen and in a playfield which must be a square. This is a challenging thing to explain to players even when an explanation is attempted since players get hung up on the “shape” of space with the wrapping edges, but my usual explanation is as such: melee must be a square screen because if it was, say, a wide rectangle, you could travel toward a point faster by moving vertically than horizontally.

So is anyone complaining about Melee being square? Of course not! Players are, as expected, unhappy that the HUD takes up so much room in the game. Whether players like it or not—and some of them are certainly put off by it—the HUD was made to take that space because we have to take the space on the edges somehow, or else the view screen of Melee wouldn’t be square.

It is our goal to recreate and modernize the Melee experience, and it’s not really Melee without the wrapping space. In the old days when you had a 4:3 monitor, which was already more square than our widescreen standards, a square space really would take up more of the screen proportionally. Now monitors are wider, and we are essentially trying to make the best out of what can feel like an anachronism—if players even pick up on it!

All that said, it’s not like we would want to insert a screen with words or audio explaining our UI. Games don’t explain their own design decisions. That’s reserved for novella-length blog posts like this one! Players only know and think about what they see, and our job is to make that delightful. Throughout the game, which also contains other play area screen sizes, we decided on a visual aesthetic which leaned into our retro roots. We made “tactile” looking screens, mimicking physical objects and screens inside the cockpit of a spaceship.

In testing, we’ve noticed that players will immediately have a negative gut reaction to the melee HUD because it is very loud and obtrusive. On past projects, we’d often say that some games or parts of the games don’t do well in screenshots. In general, it has been a visual design trend to make HUD elements as unobtrusive as possible (cue discussions from 15+ years ago about immersion). Games started making health meters transient elements which hid when you weren’t damaged, making them transparent, or doing away with any HUD indicators altogether. The first thing every marketer asks for with the games I’ve worked on is a way to turn off the HUD just for screenshots. This is not a new phenomenon! HUDs are just deemed bad when the game is not in motion. “Show players the game!” is the conventional wisdom—but what if the game is also the HUD?

It was a conscious design to make the HUD more substantial in our game for a simple reason. Our game is a role-playing game, but you never get to see yourself. You are the HUD, truly! We wanted to provide the feel that you were sitting in a captain’s chair and existing somewhere in the game even though you are always controlling some avatar like a ship in melee, the lander, or a cursor in comms screens.

So back to the negative feedback to our HUD. What do we want to do, especially having seen the player feedback? We need to give the player a better value proposition! We’re taking away some of their screen space, but they’re reacting to the feeling that they’re not getting something fun in return. Part of this is in the aesthetics, which are both simultaneously too obtrusive while being a little too uninteresting. Part of this is in the lack of novel fun there is to enjoy in these spaces, with no animation whatsoever and fairly functional graphics for Crew and Energy. Part of this is that Melee is a bad case for the chunky HUD screens, since players only see one view. During the Adventure mode, players will see far more types of screens and a lot of different animations.

We’ve gotten some valuable insight in player responses for this and will be seeing how we want to address it going forward as well as how players may respond to any changes.

Two Players at One Keyboard

At the time of writing, our currently most-upvoted feedback request, which has had several duplicate reports asking for the same thing, is to have two players able to play PvP at one keyboard. Players of the classic UQM experience likely remember doing this back in the day! For those players, this likely feels just as odd an omission as if we had decided to take out the Fighters from the Ur-Quan Dreadnought.

The challenge is that two players at one keyboard is a niche feature buried in a niche feature. Before we even get to the keyboard, local and online multiplayer in a single game is an increasingly rare thing in games, period, especially outside of competitive fighting games or others intending for you to play with another person (e.g. It Takes Two). On top of that, more and more players are playing with controllers on their PCs now than ever, and that is usually the go-to input method for any local multiplayer. It is increasingly common for games to require controllers for local multiplayer to work at all. Hi again, Baldur’s Gate 3! The assignment of one logical device to one logical player just makes too much sense from an implementation perspective.

Part of our job is to make some very honest assumptions by being gamers ourselves and looking at what other games are doing. Other games don’t implement this feature. Seriously, besides some game jam games and some niche web games, what modern games support this alongside the much-more critical features of key rebinding and controller support? I’d dare to postulate that if a player has never played UQM, they would never even think that a game would or should support this. It’s physically uncomfortable, and players don’t play local multiplayer games that way. They play them with controllers. Why would we provide a weird way of doing something players wouldn’t expect when a perfectly good, arguably better way of doing it is available?

This is all subjective, so let’s just talk about the objective aspects. We already discussed the challenges involved with other niche ways of playing like the mouse and the Mac. The work on this feature would serve a fraction of a fraction of a fraction of the player base compared to those. We would have to overcome the following challenges:

• Key assignments must be available for two players, and we would have to have arbitration logic to make sure players wouldn’t double-bind keys.
• Both players can navigate the UI at the same time, so we would have to invent entirely new UI conventions. The arrow keys, reasonable defaults for navigating a UI, couldn’t just move the cursor anymore, since we’d have two keyboard-driven cursors.
• Key jamming isn’t fun and is still a problem on most keyboards. Players unaware of this would have a bad time.
• We would have to invent UX to let players opt to play with Keyboard + Same Keyboard instead of the current flow which is any device + any other device.

Beyond that, there are semi-subjective considerations. The default bindings for the keyboard were designed using both logical conventions from game input and my own body as a reference for what was comfortable. Playing with two hands cramped on one side of the keyboard is not comfortable unless you have a much tinier torso than I do. I am sure some players are that much smaller than me, but at least many adult torsos are much closer to my size. If our assumptions are wrong, that’s not a problem: players can always rebind keys. To support two players on one keyboard, we’d have to make the default single player keyboard experience worse by cramping things to one side, or do something similarly distasteful like making three whole sets of keyboard bindings: playing solo, player 1 split-keyboard, and player 2 split-keyboard.

In short, this is a ton of work for something that has a very limited payoff and is actually, in some views, a regressive feature. At a minimum, it would be a ton of work for very limited payoff, which would just be a bad decision. Just like all feedback, we still record it as a task we almost certainly won’t do in our tracker with some of my own technical notes on how it would be done if we or some intrepid modder wanted to tackle it.

SFX and Audio

We were quite unsurprised to hear (har, har) that players had all kinds of feedback about the audio in the demo, running the gamut from “where are the old sounds?” to “the audio is bad,” which may have just been code for the former. We’ll be talking about this one with a combination of discussing our design process, sharing some insights on audio today compared to audio in 1992, and wrapping it up with where we think we’ll be going.

First things first, when we set out to make all our ship sounds, the core design pillars were as follows:

• Sounds are part of the character of ships. They should prioritize expressing that character more than “what is literally, physically happening.”
• Humor and absurdity are important aspects of character.
• Melee is loud and chaotic, and will only get louder and more chaotic with more than 1v1 combat. We should embrace this.
• There are a number of iconic sounds from UQM that should be preserved as being part of the ships’ identity.

While most of these are high-level high-brow hand-wavey things, we approached the last one more objectively! We cordoned off a few ship sounds which were critical to preserve because they had quite unique sounds that stood out or were part of key characters’ expression. Our list included the Ur-Quan’s sounds, the Spathi’s BUTT missile, all of the vocal-oriented sounds (Pkunk doing insults, Orz Space Marine “Go!”, etc.) as some examples. Others were just less aurally iconic to us or didn’t make sense in the game’s higher resolution context. Just like we changed many visuals, like making the Syreen crew in space not just a glowing pixel because that would be silly, we took the same approach with our sounds.

This was the intent and the execution, though we are also dealing with a game which has many iconic sounds and characters depending on who you ask. The challenge is that what we feel is precious may not be what players feel is precious. I am sure someone’s least favorite sound from UQM is someone else’s favorite sound. For the record, my least favorite is the “ship bumps into asteroid” sound that I can only assume was a foley recording of a dog snorting a tortilla chip into tin foil. But I’m sure someone out there really misses that sound. On top of that, we still had lots of new ships to make with their own personalities!

The goal was, in aggregate, to create enough familiar things that it felt like you were still in the same universe you remembered while also improving on others we wanted to improve upon. There were some clear trends on certain sounds which players felt were missed, but there were plenty of oddball outliers. As discussed above, feedback we don’t get is informative here. (As an anecdotal example, we haven’t noticed a complaint about the new Supox missile sound.)

Internally, some of our special sounds went through many passes before we settled on something we liked. Many of the original UQM sounds were actually used as foundational pieces as part of the mix even though layers had been added. The Ur-Quan blaster went through probably five or six iterations, alone, trying to get the vibrating phaser sound to be a predominant part of the mix.

After the first passes of sounds were done, we went through what we called a “Fun and Joy” pass. Our sound designer Jason’s own work, and much audio design work these days, tends to be focused on transient sounds which create action that passes through the scene. This is a little different from what we are trying to do for our game, which is to prioritize a lot of character and distinction over layers of aural texture.

Many of our ships were initially leaning toward the more functional aspects of their abilities and felt too literal. A good example of a ship I encouraged Jason to crank up the “fun and joy” factor on was the Alaki Acrobat, whose initial audio was accurate but not as playful as we wanted. The initial, creative prompt was “a squeaky toy hammer and sounds like that little fake kids’ toy vacuum full of colored balls,” and it was just a matter of re-centering back on that.

To criticize our own work and where we think we came up short, we didn’t have enough time for more “fun and joy” passes, and even though the mixing is pretty good in the demo, it still could benefit from more effort. We have a lot of clarity in the mix, but it can feel a little more dampened sometimes. On top of that, we are missing some impact VFX, which doesn’t help make the impact audio sound good or meaningful since there are no visual cues. There are certainly some missing impact audio, and we didn’t get any audio volume modulation for levels of impact (i.e. bigger collisions are louder than smaller collisions).

There are a lot of new things games do with audio, in general, and we’re doing some new things too! In UQM, all sounds play at full volume all the time, so shooting your weapons across and off the screen will always sound the same. We’d venture a guess that players are reacting to the sounds feeling “weaker” just because that would be a unique creative decision, akin to intentionally making pixel art (but maybe more unusual). There would be nothing wrong with going that way, but it would be a stylistic choice—and it’s not what we’re doing.

In Children of Infinity, we attenuate sounds based on whether or not things are on screen, so weapons off screen will fade in volume compared to ones on screen. We didn’t get to experiment with volume based on camera zoom (the larger on screen something is, the louder it gets), but it’s something we wanted to test. We have positional audio, which will pan sounds from left to right depending on its screen position. It creates a sense of space and awareness, especially when things get busy. We also have a lot more sounds for all of our ships and weapons, including looping audio for missiles.

We know UQM players will be the hardest to satisfy. They have had years to have something trapped in amber. The Yehat shield should absolutely sound like the Yehat shield in their head. Those UQM sounds truly are the audio version of pixel art: low fidelity, crunchy, and crusty. Like pixel art, for some players they are the definition of joy and more fun than anything newer! Those players are not wrong, either. It is simply a matter of taste. Beyond the creative challenge, it would feel really, really wrong, in our opinion, to create audio that sounded like that to match with the visual aesthetic we have going on.

I have a 20+ page, unfinished and unpublished blog post I started a couple years ago about what it means to have fans of your work. A critical section of it is simply titled “My Favorite Part Isn’t Your Favorite Part.” What makes UQM UQM, and what parts are important to keep for a sequel? We’ve asked ourselves this question throughout this project and everyone is seeing our answers. The good and bad news is there is no singular right answer. We simply will not be able to please everyone, and it’s okay to accept that. There are players who think we are making foolish decisions, and, amusingly, there will be players who think if we listened to those other players, then that would be a foolish decision.

Why didn’t we reuse all the old UQM sounds, exactly as authored? Simple: we think you’d hate it if we did that even if you had the context of the old sounds. We wanted to make something that captured the same spirit while also paving the way for new ships, new ideas, and, dare we say, something that might even be better. If you accept that something else is the best it is ever going to be, then why would you bother trying to do better? We like the wrapping, square playfield of Melee and think it’s part of its character, so we kept that. The audio? We have fresh ideas to try.

One of the many navigational challenges for anyone making any kind of work but especially one that is related to established work is finding yourself in the uncanny valley of similarity. If we try something new, players can’t readily compare it to the old one since it’s just a different interpretation. If we try to ape the old one, it may be even more likely to trigger a response for someone which is that the new one is just a worse version of the old one. This goes beyond just audio, but our work on the demo’s audio and the player response and discussion around it is a great highlight of the challenge.

At the end of the day, the way to navigate all of the responses to these things is to ask the simpler question: is it fun, and is it more fun than an alternative? Is the audio or any other part of the game tracking against our pillars, which were established as how we wanted to go about creating our sequel, and are we happy with the result?

We have probably shared this same hypothetical absurdity before, so apologies for sharing it again: would you rather have a game that’s 100% “faithful” (whatever that subjective statement means) but is 0% fun, or 100% fun that is 0% faithful? The answer is obviously in the middle, but if we had to pick and make any trade-offs, we’d rather it be fun.

What’s Left for the Demo

We released our demo and did a handful of fast-follow patches to address issues. At this point, we don’t intend to put more work into the Demo unless there are critical issues we can get traction on, like the Mac-specific rendering issue being fixed by a Godot change or us being able to look into it.

Even as we improve Melee for the full game, any new release is always a challenge and a risk. Moving from “release something” mode back to “develop something” mode means we’re breaking a lot of things and have an eye toward making progress, not bolting things in place. We may have broken something in the demo because of our work on the full game already! A whole additional QA cycle for the demo is a costly distraction unless we truly have something new and big to add. 

As we get closer to the full release of the game, we may have reasons to update the demo! Since the adventure mode and full game contain Melee, work we do to enhance that may be able to split off into our demo for an update. We may opt to release multi-ship combat as part of an enhanced demo, as an example, but we wouldn’t look to do it until we’re preparing the full game’s release and are back in the position of trying to bugfix and lock things down across the board. A single release is a lot of work, never mind six of them: Steam/GOG on Windows, Mac, and Linux. We have to acknowledge our limitations and ask ourselves if the demo would functionally be doing any more favors for us if we put in certain effort. Of course players might want all kinds of things, but it doesn’t exactly pay the bills.

Right now, we’re very happy with the demo. It’s hit all the marks we want it to. We’re able to collect feedback and will continue to do so. It’s a permanent installation for people to discover our game. Players might even still be having fun playing it in the coming months too! We are even able to show it to other people who might be willing to work with us on QA and marketing, our respective Achilles heels right now. More work on the demo won’t enhance the likelihood of success for our game at this point, so we are done for now.

Return to Adventure

After we were able to wrap up all of our work on the demo and its attendant patches, we were able to return to the adventure mode. Technically, we finished our work on the demo a couple weeks before its actual release and were dragged back into a few rounds of demo hotfixes as described above. Luckily, the demo fixes all benefit the adventure mode and full game, so it was work that would need to be handled one way or another.

Having focused entirely on the demo release for a few months, we had unintentionally broken a handful of things in the adventure mode. Besides the unintentional breakages, there was a lot of bit rot to address since we hadn’t even been looking at or running parts of the adventure mode. A handful of work was just accounting for everything, leaving no stone unturned, and making quick fixes or flagging problem areas. The last time we worked on Adventure, we didn’t have a lot of features especially in UI and UX land, and things were built using outdated ideas. As an example, there was a split-screen HUD and gameplay but no notion of letting two players drive menus simultaneously like we added to the melee demo.

As part of the no-stone-unturned effort, we set about accounting for every single missing or unfinished thing we needed to complete the game. Combining the list with what we had learned from the realities of working on the demo, we felt much better equipped to do some estimation exercises to figure out just how much time and effort would be needed. We organized a massive feature breakdown with detailed scope for each item, trying to actually balance how much effort we thought things would take against how much time we wanted to take on them.

After breaking everything into small parts with estimates associated with them, we assembled them into month-by-month feature lists, ensuring the amount of work in each month was balanced out. Below was the result, with some items redacted for your own spoiler-free experience.

There is a lot to cover in this seemingly innocent chart! Some will come a bit later when we talk about release timing, but the first is just getting into things in that rightmost column, which are features we’ve moved to post-launch (or post 1.0 launch). Yes, we are cutting back on things for launch, and while it seems painful in the abstract, we think everyone will be happier about the results.

Let’s talk about making tough decisions, starting with reality, the most difficult and inelastic thing we deal with. There is a finite amount of resources (time, money, people) for any endeavor, and we have to decide how much “love”—the net result of those things—any part of our work will get. Like our discussion of two players on one keyboard above, there is a pretty poor cost-benefit analysis for many things we could do, so those decisions become very easy to make. Some get a little harder and more nuanced, but cuts are actually one of the easier things to do from a practical perspective because the question is simple: would an “okay” version of something be better for the game than none of that thing at all? If the answer is no, it’s better not to have it at all.

We have constantly been making these decisions in big and small ways throughout our work—we just try to limit them after we’ve already committed to building things, especially if we’ve done time-consuming work like creation of assets. The one we feel the worst about in this case are the Interior experiences with Floyd. We have a pretty fun implementation of these, many assets ready, and we really love Floyd as a character! We also made these an actual Kickstarter goal which people pledged for, so pushing this out as a post-release feature feels like an extra disappointment that is not lost on us. There is a lot of polish work to do, though, and we don’t feel like we’d do Floyd justice given our current timeline.

Because these segments were designed to be interactive forms of “reports from planet surface,” it’s not a dramatic change to remove them. Players will see a report describing what happened, which can be its own delight, and the surrounding gameplay and story will still function. Moving this to a post-release experience gets rid of a ton of pressure and lets us focus on the core parts of the game being excellent.

The Alien Auction House (AAH) is in a similar boat except we have even less made for it. We’ve got a cool if unproven design, but it’s simple to take it out and just provide a purely functional way for players to do what the AAH was doing: convert trade goods to currency and vice versa. The Mark 2 transit sequence, where players would defend the Mark 2 in certain scenarios, is actually quite a bit further along than anything and easier to complete. Since it’s easy to pull out without changing the overall play experience, it’s a wiser decision to put it to the side for now.

Unlike flying in HyperSpace, piloting the lander on Planetside, or fighting in Melee, all of these experiences were limited in duration and—in the case of Interiors and Mark 2 Transit Sequences—quantity. There are hundreds of planets, but only a handful of Interiors. We’d rather make the hundreds of planets great since players will be spending more time there. For other things which are more limited in quantity, like conversations, we want those to shine as jewels in the experience. If we had infinite resources, everything would be infinitely great, but also the game would never come out. Even with infinite resources, we would want to release something. We’re just pushing some things out so we can release the game, especially with our very finite resources.

Beyond those, we’ve been saying for a while that we’ve been planning plenty of work as post-launch already. Console ports and localization will not be part of the initial release. We can think of these decisions as putting more items in that pile.

For those of you out there wondering when the game is coming, this should be good news: it means it’s coming sooner. It’s good news for us too. We’ll talk more about that shortly, with a brief interlude on wrapping up our Kickstarter and BackerKit endeavors.

Kickstarter & BackerKit Updates

To coincide with the release of the demo, we reopened late physical pledges on BackerKit to celebrate! We still only have a limited quantity of all of the items, but our “good problem to have” scenario where we ran out because everyone decided to back late has luckily not come to pass. That said, we are going to be shutting off all BackerKit late pledges—physical or otherwise—on November 30th, 2026.

This means all of our digital pre-orders who haven’t been charged yet will be charged on that date. This would be late pledges and folks who just pledged for a regular digital copy of the game. If backers would like to change the platform they receive their key on, they will still be able to do so up until the end of the year. If you’d like to change your platform, just contact us through BackerKit. Come January, everything will be locked down to prepare for launch unless there is some other pre-ordering mechanism before we release.

We have said many times that we aren’t a merchandise store. We run a pledge-taking setup, and our BackerKit has been built around that. We understand why backers and others would want a merch store, though, but we’re just simply not set up for that right now. Once we finish ensuring all of our Kickstarter and BackerKit folks are settled, we have some thoughts on how we can use our remaining physical goodies as part of the game’s launch and our marketing push when we get there.

We have ideas on how we could run a merch store operation, but please keep in mind all of this has been a one-man operation. That person is one of two people still working full-time on the game. It’s certainly not free labor, and running the shipping and handling part of the operation has only gotten harder.

International shipping is painful and even more expensive than ever, and it took us several attempts to get certain packages to their destinations. Some packages were returned and we still need to follow up on them or have had trouble getting in touch with the backers we’re trying to send them to. Our packaging supplier went out of business, and though we mostly have what we need, we had to find replacements for some items. The new supplier costs twice as much, though, and we can’t imagine it getting any cheaper given the way things have been doing.

That said, it’s really fun and satisfying for me to get the goodies out and interact with backers! In our last update about the increased cost of international shipping, I joked that local pick-up would be free… and someone actually took me up on it! I got to meet up with one of our backers who made a pit stop near my home where I was able to deliver his Collector’s Complete Edition in person.

All that said, I have to be mindful of my own limits and all my other responsibilities to our project. It is a great boon to have the continued income from BackerKit and our physical rewards, but all the time spent there takes away from time spent elsewhere.

When is the Game Coming?

So, we did all this scoping work, made some cuts and decisions, and have a schedule we’re working off of. When is the game coming out? The short answer is that the schedule says we will be able to release in June 2027. That is the honest answer. It’s what the schedule shows, and having worked off of it for a month so far, we are on track.

The longer answer is that it’s just a schedule. We are not a project with a lot of support systems. If anything goes awry for anyone, it delays our work, and the remaining work is resting on the shoulders of very few at this point. Prioritizing the completion of the demo possibly unlocks some support systems since it showcases our work very nicely, but that is speculative and we aren’t banking on it. If things change and we think we can make a much more successful release by adding a few months to the end of it, we may still do that.

It feels like a long way away, but, speaking as someone whose job has been working on this game for the past five years, it feels very soon! 

What is Taking so Long?

We’ve been at this for five years and it’s still not done? Trust me, reader, no matter how much you may want us to leap across the finish line and pop the champagne, we want it even more. Measuring the time from before the Kickstarter and pre-production period is a little tricky, since there were so many things in flight at once and not much had quite settled into place while we didn’t have a defined team, scope, or budget. Critically for our project, I hadn’t settled into place yet. I was not in the role I am now until late in 2023 when I took on the responsibility of seeing us through production.

Let’s talk a bit about that role and do a brief retrospective on how it played out. Until we successfully funded our Kickstarter, we were running a skeleton crew with a couple volunteers and a very limited budget—just enough to get a few artists to help make assets for the Kickstarter so we had something exciting to show. After the Kickstarter, we had the budget to keep those artists and get a handful of contractors to help us. We’ve noted before that we barely cleared the voice over milestone. We’re very happy to be making a game with VO, but from a fiscal perspective, it would have been much nicer to miss the goal by a little and have a buffer for the smaller number of features we wanted to commit to instead!

After the Kickstarter, our team became a larger handful of contractors along with a few remaining volunteers. I knew I couldn’t take responsibility for all of the production work myself, so we were sure to get someone who could manage the most critical aspect: the story. Mallory, our narrative lead, was responsible for managing all of our writers (thank goodness!). The rest fell to me, and about half of my time and/or energy was spent coordinating and managing all of the work everyone was doing, especially on the asset side. I’ve been fortunate to have plenty of management and project management experience, but it was still a lot.

This project was especially challenging because we had people working in all kinds of different capacities, including volunteers who needed a lot of guidance, and most of our artists were not full-time. There was a lot of overhead involved in keeping folks fully equipped to move forward when everyone worked asynchronously, sometimes for just a few hours a week; artists were just creating art while actually integrating things fell to me. To make complicated schedules work, I was meeting with two of our artists long after I finished my usual working hours at 10pm twice a week. I could only talk with our sound designer in the wee hours too, usually on Sunday nights.

The strategy was to treat our budget as the limited resource it was and try to get through as many things Fred and I couldn’t handle—assets, writing and story needs, and some specific engineering tasks (tech art, tooling, localization, and VO needs)—as quickly as possible. We couldn’t afford to keep people full-time for very long, so I had to do much more hands-on production and coordination than I was doing before. The reason we had to stop our regular development streams is because this would eat so much of my precious time.

There were also more logistical challenges than usual because of certain development non-negotiables. The game must be free from restrictions and the content in the game has to be modding-friendly, so we had to develop our own solutions to some things like 2D animation for our comms portraits instead of using certain off-the-shelf things which would have made development easier but future distribution harder.

In short: I am responsible for many critical roles, but the production work had to be the priority since our collaborators wouldn’t be around forever. The budgeting of this overhead time was the biggest misprediction on our project, which was hard to see coming until I was actually going through the motions. We had a few financial budgeting surprises which caught us off guard only after wrapping the Kickstarter, so we had to be even more careful and limited with our spending than what we had intended. Never mind the increased costs of all of our physical manufacturing and shipping that came with the absolutely brilliant (/s) changes in America’s trade policies.

Beyond all of that, it’s reasonable to say that the last couple years have been universally, uniquely painful for people, and my own perspective is that it spilled over into our project. My years of experience told me that doing a few proven steps would produce a desired outcome. It did not. During this project, things have taken more steps than ever had been needed before. People, collectively, went through more stress than I had ever seen before. The emotional burden weighing people down was heavy. Finding security—never mind enthusiasm—in a society that feels like it is going from a pile of tinder to a full on blaze is hard. 

This is not an assignment of blame! This is an observation of the struggle even beyond the walls of this project, and it’s just how bad people have been having it for the past few years. I thought our project would be inspirational and help give people something to be excited about to overcome the dread! It certainly has been to me and many of our team, and I feel a deep sense of purpose through our commitment to what we’re creating: for ourselves, for our community, and for the world. But people are uneasy right now and it creates dysfunction and dissonance. They feel helpless and they are wondering to themselves if they even matter. It’s hard, and people had a very difficult time coming through.

Why is this Happening To Us?

Anyone who’s ever managed a project and people before will tell you that you’re not simply managing deadlines, scope, work, or priorities. You’re managing emotions, personalities, and people’s doubts and fears. People seem to have a lot more of those latter two now because they have a lot less breathing room.

Watching the general horrors of 2024 unfold as wealth inequality, corruption, and government crisis (to put it lightly) took hold made me think people would not be able to tolerate it. There would be a strike, there would be a righting of the ship, regardless of how catastrophically our own government had been failing us. People cannot continue under a forced march driven by fear for long. I was so terribly wrong. There was a different reality which I didn’t foresee,  and this is my view from the eye of the hurricane.

I live in San Francisco which has always been a bubble of sorts. It’s often a net positive bubble, creating its own culture and diversity with communities of all kinds of different people and ideas! It is quite different from the next county over, Marin, where I grew up. Sometimes it’s a very weird bubble, though. San Francisco has been the masthead of Silicon Valley; part of a petri dish for incubating venture-capital driven insanity. Remember blockchain? Remember NFTs? Remember play-to-earn games? Even Theranos is having a renewed moment in the spotlight now. Somehow we constantly produce snake oil salesmen who have got a bridge to sell you. Their booms and busts go, and we move on, but the message is always the same: “You don’t want to miss out on this thing that will change the world!” Dang, did I miss out on DRM in my food? Are all my apes gone?

This time the insanity has taken full hold and the cancer has finally metastasized. Between the national and global changes inspiring fear and business interests finding their strike-while-the-iron-is-hot moment to capitalize on the fear, we have collectively lost our minds. Because I live here, I know many people in the industry. I am a stone’s throw from a software developer at all times. Many of my friends and acquaintances are developers. My partner, herself, is a software engineer. Many work for companies you’ve likely heard of or even do business with.

You think these software companies devouring our resources and our humanity are making us feel bad? You should see how the people who work for them feel. I have never seen so many intelligent people become so stressed out, depressed, and lifeless. The light has gone out from their eyes. They carry on, dragging their feet through this unspeakable misery. It’s like watching a hungry person eating delicious food without reacting to the feeling of satiety or the flavor. The only way they are carrying on is through dissociation. They look and feel helpless. The stories they tell from their workplaces make it clear: everyone has lost their fucking minds. And everyone is too afraid and alone to stop it. It’s true: alone you are helpless.

So on the one hand, I was correct: people cannot carry on like this. Where I was fatally wrong was how people would react. This was articulated well by someone else, whose words I will borrow and expand upon. Instead of fighting back, people are slowly just ceasing to function. Our capitalist machinery of human production will not organize and rise up, it will just slowly break down.

Like the hoses in a car will eventually wear out with use, causing things to just not work as well until the car simply won’t drive anymore, the same is happening for us. People will stop responding to emails, people won’t call you back, you won’t be able to get help from a support person. Never mind people smiling or waving at you while they do it as they appreciate the interaction. All the “little” things people do as part of our collective endeavor to work together are degrading. People are struggling to answer these questions we could so easily take for granted. Why respond to that email? Why pick up the phone? Why do my job?

Everyone would do these little things before simply because they’re people. People like working together and helping each other. People will respond to people, even if those people are annoying sometimes. People know they matter and have value. Or… they did. Now people are questioning if they do matter; if they have purpose. What is their purpose? Does anyone care about them? Or are they just a function of their labor? And are they a tool? A replaceable part?

Look, I wasn’t born yesterday, and exploitation of labor is not a new phenomenon, nor is the creation of different forms of it. The targets, blast radius, and willingness—no, celebration—to hop on the bandwagon is novel this time, especially as it impacts the ongoing knowledge-building and collaborative efforts of humankind. The voices we listen to have been concentrated through unimaginable wealth inequality. From my vantage point of growing up and living for years in the blood-pumping heart of a technology-leader generating factory, the shift in messaging and attitude in the last ten years is palpable.

Ten years ago, even some of our more suspect, locally-grown tech companies at least had the decency to put on an air of hope and optimism while they talked out of both sides of their mouths. Their messaging was about how you could change the world for the better, make something no one has seen before, and you—yes, even you—could be an innovator and learn to do anything. Was this all part of platform capitalism and other modern forms of market capture? Certainly a lot of it was! It wore many guises and had nefarious threads woven through it, but we could still look to find encouraging messages.

It was good, even if just for the sake of PR, to be positive. The messaging was still full of humanity and there were plenty of people who truly were interested in the dreams and hopes. I, myself, picked up doing stuff with computers when I was a wee child because it sparked my imagination for creativity and possibilities. If you’re reading this, you were likely drawn to technology in your own way too. I’ve received stories from backers who became interested in science through UQM or went on to their own software development careers. So many of us were inspired by the wonders of technology and the dreams they instilled in us!

This has been extinguished now. It is replaced by cynicism and fear. The oft-derided billboards and bus stop ads in my city signal messages of dehumanization, shame, and hostility. “Win the talent war.” “Stop hiring humans.” “More agents.” Their artwork and words are often quite literally stolen from internet memes. In an infuriatingly tone-deaf (or tone-aware, you decide) choice, it’s usually a woman representing the subservient AI.

The message is loud and clear, born of previous hype-machinery language used for things like NFTs: “Don’t get left behind.” You have to be on the cutting edge of AI! (Or else what?) Media outlets often refer to the current paradigm as the AI “race.” (What’s the prize and who’s the judge?) AI is scary and you should be scared! (According to whom?) We have to build AI “literacy!” (Who’s writing the books?) Don’t even get me started on the audacity of someone to define the word “intelligence.”

Fear moves money, though, and all of this is a language of fear, not hope. We don’t hear about imagining possibilities except from ten rich people obsessed with actualizing their hope for their future born of their own resentment and insecurity. We don’t hear about the importance and value of people. We are talked to like creatures in a corn maze who have to escape before the combine runs through the field. The machine is coming and you do not want to be the first one to fall. Maybe if you get out of the maze you’ll survive. But start running, no matter what. Pump those legs.

This is terrible. This should not be happening, and yet it is. People should be organizing and stamping their feet down, refusing to move because no one, especially such a small number of people, can force us to do anything. And yet we can’t. Between the trauma of the Covid pandemic and now this, people seem deeply depressed, and our faith in one another to have each others’ backs seems frayed. I’m not a historian but there are odd parallels between now and the years after the Great Influenza epidemic, specifically in the concentration of wealth and the social instability and inequality which followed. A shock like this seems to cause long-lasting tremors in our social structures.

I have spoken before many times about how Pistol Shrimp refuses to use so-called “generative AI” and cannot support it or use it in good faith for so many reasons. This is the ultimate reason. Even if we can solve the myriad environmental, legal, and other concerns—even if we are not exhausting our other finite resources, which technology can probably solve given enough time—look at what happens.

We are exhausting the most important, precious, and irreplaceable things of all: people. The human spirit, curiosity, and empathy are being drained away.

What Are We Going to Do About It?

What are we going to do about it? We are not going to let any of this stop us. We are still here, and just like we finished and released our demo, we are going to finish and release Children of Infinity. It’s going to be really fun and we can’t wait for all of you to play it. Games, themselves, have conditioned us to never lose hope and never give up. If you like musical theater, you should go see Hadestown if you haven’t already, as it’s full of myriad songs and stories that touch on painfully relevant themes of the day: exploitation of labor, environmentalism, and the value of humanity. I think about its hopeful protagonist, Orpheus, and to borrow a line describing him: we want you to see how the world could be in spite of the way that it is.

As mentioned above, we started Pistol Shrimp with a mission: to make the process of making games better. We wanted our process to be fun, inclusive, and educational. We didn’t want to be miserable, to crunch, to be swung about by profit-greedy corporate rationale, or to make decisions which devalue our community of players. How are we doing? Seriously, that’s a real question! Let us know in the comments.

From our perspective, this has been an extremely challenging time, but we’ve been doing our best to abide by our values. Are we avoiding crunching? Unfortunately, no. There are too many pressures at the moment, and there has been a lot of overtime put in at times, especially during the demo release. As for the rest, we think we’ve been doing well. Cribbing directly from our post celebrating the demo release: we released a serverless, not-game-as-a-service, DRM-free multiplayer game in 2026. That is directly in line with our values, which include valuing people: our players.

While the games industry is beset by ever-increasing layoffs, funding disruption, and companies peddling workflows to put an end to creativity, we are not doing any of that because we think it’s the wrong direction. I’ve seen the future through my friends’ eyes as shared above, and we think it’s wrong. The future isn’t fated, though; and, we may not have a heavy finger to put on the scale, but we are still pressing down hard. I’ve probably said these exact same words before, but we hope it’s painfully obvious after reading the above that this is important now more than ever. We look forward to a time when it’s less important to be pushing so hard from our side and when we have more allies helping to fight the good fight.

We have been very open with you throughout our development, from our process, to our insights on the world we live in, to my own personal life because they’re all part of the development of our game. We might be “Pistol Shrimp,” but we’re made of people, our game is a human creation, and we experience human things. I’d like to share another one of those with you.

One of my birds, Mozart, unfortunately passed away in September. He had been ill for a few months dealing with a somewhat mysterious respiratory problem which required daily treatment with a nebulizer along with many visits to the vet. It was a stressful lead-up to his passing. Mozart was a wonderful bird who I started fostered along with his pal, Rocket, in early 2022. He and Rocket got along so well with my other two birds I had at the time, Topal and Buhar, that I decided to adopt. Rocket and Mozart were absolutely inseparable.

Mozart, despite his name, was not much for making music, but Rocket would serenade him with songs constantly. Mozart had developed a plucking habit before I met him and could not fly without his missing feathers, so I would need to shuttle him around a lot. If I picked Mozart up, Rocket would follow. Mozart’s favorite place to sit was my hand, where he’d get his daily, morning scratches, or my lap. I work standing up, so Mozart learned to pick up on the cues that I was done working for the day and would plaintively call to be brought over to my lap to get some cuddle time in. Mozart will be missed by all of us, but most of all by his loving mate, Rocket.

If you bring up the credits in the demo, you will see a section we have dedicated to our feathery and furry friends we have lost along our journey. They haven’t put in a lick of design or a line of code, but they have been part of our development because they are part of who we are. Okay, Rocket has walked on the keyboard many times when I was out of the room, so there might be some of his typing in there. Everyone who shows us what it means to love and be loved back is a part of each of our lives.

Likewise, you are part of our development. Your names are in the credits too, and you deserve it. What would be the point of making this game if not to let people play it? Games are about human connection, and this is our expression of our humanity for you to not just enjoy, but also to remind you of your own humanity. We’re glad you are here too.

One thing you, dear reader, can do which will help us tremendously is simply to leave a Steam review for the Demo if you enjoyed it.

A special thank you again to our generous Patreon supporters who continue to help fund our work despite getting almost nothing in return. Every single contribution helps so much, and while Patreon is its own platform with fees, we hope you know that your funds go to support our work and our mission. You could spend your money on many things and support many other people, but it is a statement of your own values that you feel we matter. Thank you.

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