The end is nigh! The end of the wait for the next milestone update, anyway. In this update we’ll cover our finishing touches on the Melee Demo we’ve been doing, give a short retrospective on shipping our Kickstarter rewards, and detail our plans for the forthcoming Melee release.

Before the inevitable walls of text, we have a few headline items we don’t want you to miss:

• All Kickstarter physical rewards for finished surveys should have been shipped. Have questions or need any extra information? Contact us! Want to share pictures of what you’re doing with your goodies? Share it in our Discord or tag pistolshrimpgames on Bluesky!
• No digital rewards (game, digital lorebook, digital starmap, soundtrack) have been provided yet.
• Backed for physical rewards but didn’t finish your survey? Please finish it by May 1st (or June 1st if you actually pledged funds during the Kickstarter) or else you risk your pledge being refunded/canceled. Need help accessing your survey? Contact us!

Tuning Ships

Our approach for tuning and improvements is usually the same: we start with the things that will have big, sweeping broad-stroke impacts, and then we move on to specific, detailed elements, like things which alter certain classes of behaviors or just a single ship.

All our ships have unique character, represented in their abilities and maneuverability—but it’s also expressed in how they fly through space and their physical properties (e.g. mass). We developed and polished a single set of flight characteristics for our last milestone, and the current milestone saw us adding more. We currently have six unique sets of flight characteristics—two for each “weight class” of ship. We have Featherweight, Middleweight, and Heavyweight ships, and then specifics depending on how powerful we want their thrusters and maneuvering ability to feel: Slow or Fast. For example, the Ur-Quan Dreadnought is a Fast Heavyweight, while the Mycon Podship is a Slow Heavyweight. A Pkunk Fury is a Fast Featherweight, on account of the wings.

Your Pkunk Fury shouldn’t knock either the Dreadnought or the Podship around much; on the other hand, if the Dreadnought and Podship bump, they’ll provide a similar bump to one another, but the Dreadnought will regain control faster. We’ll be continuing to tune these six types as we go and watch more people test, and it’s fun to dress our ships with this last bit of gameplay character. The Androsynth Guardian’s comet form presents a unique challenge we haven’t solved yet in the new physics-based world we described in our last update. Since ships now tend to confer more momentum to other ships on contact, the comet has trouble doing its signature rat-a-tat-tat maneuver where it wants to repeatedly ricochet off its opponent. That’s a good example of a fine detail which we’ll act on last, since it’s just about one solitary ship.

For our UQM ships, we already had a template and target to hit, but for our new ships, we have the opportunity to make some different decisions since they’re all new! Is it more appropriate for certain ships to feel like lunkers or to be speedy? It’s not that we don’t have a vision for what we imagine each ship to be, but it’s also something we couldn’t fully realize until now, especially until we put them into an arena with UQM ships to see how they tipped the scales one way or another. (It’s a mass joke, get it?! You just don’t understand the gravity of this situation!)

After doing an initial pass, we found a lot of our new roster felt like an abnormal distribution, with a lot of ships at the extremes. We had a lot of light, dinky ships, and a lot of heavy, slow ships. “Balanced” doesn’t necessarily mean fun, and what’s most important for our Melee is to have a mix of ships which create interesting counters to one another and also give people opportunities to identify with the characters. Making “average” ships is not necessarily our first impulse, but they’re also helpful to create interesting distinctions against the edges of the spectrum. We wound up tuning a few more ships toward the average, and all of a sudden the new ships felt even weirder in their niches! As I said back in the beginning, the goal is to develop a cast of characters, and then we can always tune things later with point costs or numerical adjustments.

And gosh, are there a lot of numbers to play with in Melee!

High Energy

Working our way down from broad strokes, there are a few other efforts that we knew would help us change the overall feel of large swaths of ships. We wanted to address how we handle energy use for continuous powers like lasers and shields which you can start and restart at will. In UQM, the game ran at 24 frames per second, so having abilities able to be toggled on and off every frame had a certain level of impact for very skilled players, while still being relatively slow. Building rules about using big units of energy on their activation makes good sense if that can only happen once every 24th of a second. In COI, we run at 60 frames per second. If you are fast on your fingers, you could turn on—and, more critically, off—your Yehat Terminator’s shield very, very quickly!

This means a few things: the “skill ceiling” for being good at blocking with your shield goes through the roof compared to UQM, but if we deduct energy every frame, we have to be a lot more cautious not to punish players who aren’t great at pushing and releasing keys very fast. Likewise, there’s a distinct line between “repetitive motion stress” and responsive abilities! Our Cyborg pilots, for example, have computer reflexes and will act in the most inhumanly optimal way possible, so it doesn’t make sense to tune for them (we’ll discuss how we are polishing them later in this update). But what about making things fun for humans of different skill levels? For energy use, we’ve applied a mix of a few different ideas where applicable:

• Having minimum times for powers. For example, even if you quickly tap and release the Yehat’s shield, it will still stay activated for 1/24th of a second. This gives players some grace period and ensures they get their energy’s worth. This may have even been exactly how the Terminator worked in UQM, but we just convert it to UQM times instead of our own frame times. This also has benefits in making 60 fps ship combat feel less fast and frantic, which it tends to be.
• Deducting energy only at certain intervals. Using our Yehat example, we could deduct energy constantly while the shield is on, or we could say if you’re activating and deactivating it within a certain period, the bonus activation is ‘free’. This is simply a different kind of twist on the above thought, which preserves the in-game responsiveness without punishing high skill players for being good at pressing buttons quickly even if not everyone can do it.
• Differing the cost of activating from maintaining. For example, it costs 2 energy immediately to start using a ship’s power, but it only ticks down 1/10th of a unit of energy per frame (60th of a second). At a minimum, this punishes/restricts rapid tapping on its own, which isn’t usually useful, but it’s part of the formula, especially combined with one of the above approaches! This has interesting applications for some of the newer ships which do have some weirder “use until you run out of energy” powers, like our TBone ship which spends some time winding up before activating a powerful weapon.

The net result is that with a few new tools, we can make energy use a little more nuanced where it makes sense, depending on how players wind up playing. As UQM and other competitive game players know, even different ships handling these things differently become quirks which are part of how skilled players learn to play. We expect that as players master certain things, we’ll adjust our strategies (or not, because they might turn out to be interesting already), so we’re counting on all of you to help us by playing!

Collision Course

All of the fast-paced physical interactions in Melee rely on being able to create and detect objects that collide with one another. We usually call this collision detection, but you may have heard other terms like hit detection, hitboxes, and so on. In our Simple engine, our ships and their weaponry are mostly built out of primitives: simple shapes like spheres, capsules (a sphere with a cylinder in it), and boxes. Some weapons like lasers are just lines (rays) which stop upon contacting an appropriate surface. In the ancient past, before we had any real graphics representation and could only visualize shapes, the UQM ships were generally faithful-if-creative representations of what they looked like in UQM, made out of collages of boxes and spheres.

They sure looked neat, but that’s not quite the purpose we want collision to serve—collision is just something the engine uses for physics in the most computationally optimal way. The player also never sees the collision representations, since they’re instead looking at actual ship art (which looks even neater!). Our designer, Zach, was tasked with remaking all of our UQM ship shapes using fewer primitives and also replacing boxes with capsules, where appropriate. Did you know a capsule is computationally cheaper than a cylinder? That’s right, you’re over there thinking about rendering bajillions of polygons with your graphics card you’re now paying 300% more for, and we’re still thinking about boxes and spheres. In general, capsules also produce better collisions.

In addition to remaking the UQM ship shapes, our new ship shapes ran the gamut from “very rough” to “non-existent.” Since we were defining the new ships from the art first and focusing on getting that right, we hadn’t necessarily gone back to match up the physics representation with their final visuals. All of the new ships have now received finished collision shapes.

Since Simple is only in its nascent state and we optimize for “good enough to get by” most of the time, we don’t really have any slick tools for laying out collections of shapes in-game. We use Tiled for HyperSpace, but that’s more like laying out a level or play-space than a character/object. For our ships, I had developed a simple process using shapes in Photoshop which could be manually converted into numbers to plug in to Simple. What’s really cool is after I taught it to Zach, he developed an even better process using Illustrator to do the task. We don’t just get to iterate on our results, we get to iterate on our processes! Zach could likely tell a whole story about this, but I wanted to share a few of the diagrams that are produced as interstitial artifacts of the work. 

Polish Begets Polish

Almost at the same nitty gritty level is polishing various ship and object interactions. How do missiles interact with other missiles, generally? What about lasers interacting with missiles? We have a few new types of ship-specific objects and behaviors, but there are broader categories of things like Orz Space Marines, Ur-Quan Fighters, and Crew in Space created by the Syreen, all of which have some similarities but still need their rules for interaction configured.

We worked through a lot of these special cases and built out rules as needed for our different interaction systems. Damage used to just be numerical damage, but now we include information about the damage being done which can be categorical. We have unblockable damage, like hitting the planet or taking damage from an Orz Space Marine intruder, so Shields like those on the Yehat’s and Utwig’s won’t interfere. Likewise, the Yehat’s shield will protect it from damage, but it won’t protect it against something like the Melnorme’s confusion ray.

We re-implemented and tuned the planet’s gravity, which hadn’t been set up for a while, and also configured it to interact with arbitrary objects like Space Marines. Space Marines themselves also take no damage from the planet, which is another rule on top of the unblockable rule above.

For quite some time, most missiles (and lasers) didn’t actually interact with other missiles in COI. We had done the groundwork to make them interact properly, but hadn’t applied it to every single object—never mind tuning their interaction so that a Shofixti Scout can’t shoot down the Ur-Quan Blaster’s shot with a single missile. We’ve set those values appropriately, so now we have appropriately powerful ships able to plow through weaker missiles. This triggered some amusing visual bugs where missiles thought every time they hit something, they ought to explode because that’s how they used to work, making for some extremely explosive-looking melee matches. We fixed this (sadly), but you can see what it used to look like for posterity.

Some interactions are new concepts, and they are sometimes hilariously silly, whether or not we intend them to be. Two of our new ships have deflection abilities where they can actually knock missiles away, and we needed to take a pass to make sure only the right missiles were being deflected (and that they were deflecting correctly). While the word missile probably just makes you think of a projectile, in our game implementation language, a missile is just a thing which does damage. While deflecting some missiles makes sense, it might not make sense to let you deflect the Shofixti Scout’s self-destruct, even though it was pretty funny. Similarly, there were some amusing bugs deflecting things like lingering Kohr-Ah blades where they’d just fly into the deflector’s face instead of being knocked away.

Getting more specific, there’s a new ship which we’ve shown before codenamed the Undying ship, which has a mechanic that lets it collect ‘souls’ of lost crew. Its presence makes all ships create ghosts any time they take damage. This triggered some odd side-effects, since ships like the Ur-Quan and Orz technically lose crew to create Fighters and Space Marines, respectively. Similarly, when a Syreen sucks enemy crew out of the airlock and into space, that ship also loses crew. In all of those cases, it’s not like anyone died, though! We used this damage information to clarify what was actually happening. Along similar lines, we could now have ghosts come out of Ur-Quan Fighters if they did actually die in space, as opposed to ‘die’ when they returned to their mothership. While crew is a numerical abstraction in-engine, we only want the souls of the dead to come out when something with a soul actually dies! This is also empirical evidence that VUX Limpets have no souls, much like players of the VUX Intruder.

There are quite likely more things like these which we’ll learn as we watch more people play. There are so many different types of interactions ships can have that we try to catch in our broad strokes, but the number of totally different match-ups will make new ideas come to mind only when we see it actually play out.

Melee AI

Once again, we worked from general to specific as we continued to program Melee ship AI. As of the last milestone, we still had a handful of problems. There were acute issues: the AI would frequently over-steer, its own thrusting would ruin its attempts to do tight steering, and slow ships that want to keep their distance weren’t great at understanding there’s no hope when they’re up against a faster ship. Then there was the general feel of fighting the AI: it acted too much like an inhuman robot (because it is an inhuman robot).

Addressing the acute issues mostly involved working to develop some better logic for turning and thrusting. Ships pay attention to their turn rate when considering how long it will take them to reach a destination and will know when to stop thrusting to just focus on reorienting themselves. A very fast ship can’t just bully a slow ship which wants to keep its distance into confusion anymore, as the slow ship will prioritize fighting back as the best option.

The general feel of them being a little more “human” is something that will be a longer journey, and as Fred and I have discussed, there’s no simple, one-size-fits all solution. The result will likely be more of an aggregate of small tweaks which collectively create the right feel. One thing we can address pretty directly is making them “behave more like a person would.” Not in the creepy LLM chatbot kind of way, but in the fundamentals of how they behave.

Our ship AI doesn’t “cheat”: all it can do is press the same buttons a person could. It just happens to be unnaturally good at things players have different levels of skill with, like reaction time and ability to aim. One small change which did a lot of good was simply reducing how frequently the AI could press and depress buttons. Sure, the game runs at 60 frames per second, but I don’t think many—or any—humans can press and depress the thrust button 30 times per second. Now ship AI can react to changes in the environment, like trying to change direction, but we have a knob for how quickly they can “change their mind” (e.g. turn left, then stop turning, then turn right). It makes a big difference!

Over time, we’ll be cooking up more things to try, as well as considering how to support AI difficulty settings—which will make an AI weaker or stronger by changing some of those tuning values. It’ll require a lot of little experiments, since an AI that’s imperfect at hitting its shots isn’t necessarily any more enjoyable to fight against if it mechanically creates an unpredictable hail of bullets in a way a human never would, which you now need to dodge! 

On the ship- and mechanic-specific side of AI, we also needed to enhance our AI senses by giving ships the ability to filter different objects. Ship AI had the ability to understand enemies (chase and shoot them!), friends (ignore them!), and the damaging things (avoid them!), but certain mechanics and ships require different behavior. Ships should chase the Syreen crew in space, but they shouldn’t shoot them, unless we’re trying to create a particularly lethal Syreen mind control effect (or punishment for mutiny). Our ghost-creating Undying ship mentioned above wants to pick those ghosts up, but no other ships can interact with the ghosts. Ships might want to shoot down enemy Ur-Quan Fighters, but they certainly don’t want to pursue them.

Lastly, we built a few proofs of concept for ships to understand how their abilities relate to one another, so they could make decisions in cases where they have a few viable strategies. The Mrnmhrm X-Form will use its faster Y-Form if it needs to close the distance with or stay clear of a faster enemy, but it will opt for its X-Form when it would be more lethal at close range. The Ur-Quan Dreadnought might avoid launching fighters against an Earthling Cruiser, unless it feels it could pressure the Cruiser and finish it off.

We could probably do an infinite amount of work on ship AI! But our time is not infinite, so we focus on what we think would make the AI behave in a more human way and what creates fun play experiences, especially when our tweaks can impact all ships at once. At some point, what’s there will be good enough, and other improvements and enhancements will come as we ensure a fun play experience for the Adventure mode. The last bit of work we have for AI, broadly, will just be finding ways for it to be less robotic, and that will be a slower, simmering journey.

Playing and Iterating

How are we creating these lists of things to fix? At this point, it’s by playing the game! Our vision has largely been executed, and we are finally getting to see how it holds up in the real world. Individual ships had all kinds of minor bugs that needed fixing, and we gave those bugs a thorough sweeping in this milestone. Doing this required us to actually have the game in a state that could be played for a while, in a way that we intend players to play.

During development, we are often just working on parts of the game over and over, making sure those parts actually function. Never mind how the player reaches that part, like playing a full Melee match—we need to fix a bug with a missile, or a feature for an AI, and so on. This milestone, we took the time to truly implement all of the flows players could go through, and in a surreal experience akin to watching your theoretical spaceship design actually fly through the sky, we can finally play the game, front to back, for large chunks of time!

These flows included things like setting up multiplayer matches, playing a match, then playing another one, then having someone leave, then having a different play join on the network, then going to play a local multiplayer match instead. All without exiting the program or any of the usual “in development” contortions we just accept and take for granted. We have handling for all of the different state changes players might experience, like being in the middle of your own match but getting an invite from a friend on Steam and hopping into their game.

We can assign different input devices so players can decide to play locally with two controllers, or a controller and keyboard. We’ve got a settings menu where you can change sound and graphics options. The only silly thing we were missing until a couple of days ago was a way to actually exit the game from within the application. (No quitting! Only playing!)

It’s an exceptionally exciting feeling! You want to shout “It’s Aliiiiiiiive!” as you watch mundane things like modal prompts function, guiding you, the creator, merrily through the hoops of playing the game you’ve been working so long on. It’s the symphony finally playing after you’ve been designing a hundred new instruments, planning their melodies, and positioning them in the concert hall.

Beyond being exciting to play (and quite the accomplishment to feel!), it’s also informative. Sitting back and playing for a while actually affords us the opportunity to really feel what the game is like, and also lets us notice things we’re usually hyper-focused on fixing. When the game runs in fits and starts or when there are too many bugs and issues, it’s hard to really feel what’s right or what’s still wrong since your brain is just overloaded by the multitude of wrong things.

This all culminated in a playtest between Dan and Zach where we actually just duked it out for about an hour. With a real Steam build of the game, we played together via network with very little observable latency even though we were playing on different coasts of the United States. We had one “hard” crash, but otherwise were able to play together for a solid fifty minutes. We had a lot of fun and also surfaced a great list of bugs and tuning elements to fix—things which were much easier to find in a human vs. human scenario, compared to the vs-AI scenarios where I (Dan) am testing and iterating.

Was the game finished? No. Were we having fun? We thought so! Critically, we identified several things to tackle which were getting in the way of our fun. We always have lots of work which can be done that we know about, but we learn so much more from playing or watching others play. It helps us see what’s actually going to be most critical for others. After we fixed a handful of bugs, Zach actually ran an informal playtest with a group of his colleagues who are fighting game aficionados. Getting to the point where we can meaningfully do this is a huge accomplishment, and guess what: y’all are next!

Demo Plans and Path to Completion

We have a few different launch stages for our Melee Demo, with requirements for each one. To put it simply:

• Internal Playtesting & QA (Quality Assurance): ← We are here!
• External Playtesting & QA: We have mechanisms for running and observing playtests, getting feedback, collecting bug/crash reports, and tracking when we do changes/fixes.
• Wider Distribution: We pass muster for fundamental QA, and we just want people who are following us to play it, start talking, and have fun with it.
• Release: We have store page assets for GOG and Steam, so the thing is publicly presentable and a piece of marketing material and cause for celebration.

We’re preparing for our next phase, which is external playtesting. We’ll be semi-randomly picking a couple dozen people to become our lab rats and play around with our Melee Demo. In this case, we’re very self-serving: we want people with different types of computers, people in different places, people living with others who will play local melee with them, and so on. A playtest with UQM Melee pros is just as invaluable as getting feedback from someone who doesn’t even play games. This is both a playtest and also quality assurance. We aren’t too worried about minor bugs or unpolished bits, but we are trying to find out if people are able to play, how much fun they’re having, and if anything fundamentally stops them from playing (e.g. crashes, game won’t launch on their unique hardware config, etc.).

After that, we’ll be heading into our wider distribution. The plan right now is to simply give everyone who supports us on Patreon access to the demo in advance of its public release. We’ll want some infrastructure to collect the same kind of information we were looking for with our external playtesting, but at this point it would be more about players having fun than us getting things we need. We’d still be looking for information on critical problems like crashes or show-stopping bugs.

Finally, we have the demo’s release. This has a few extra requirements and also serves some additional purposes. Up until the final game’s release, it will be our biggest “noise-maker” since the Kickstarter! It will be available not just for everyone here who helped us make it happen, but for everyone. There’s a big sliding scale for how much of a splash we want to be able to make (the biggest one possible, duh), but the best possible outcome for our project would be that this isn’t just fun for people to play, but also garners support for and interest in the final game. There’s a minimal bar to clear by having a write-up of what the demo is and a new trailer, and we’d ideally be able to get a lot of new people interested in what we’re doing so they’re excited about Children of Infinity and being part of the Free Stars community in general.

More success and interest now can mean more success for us later, which means our work as we prepare for the full release gets easier. We’re a tiny team and have to balance all of our activities and intents, but we’d love for our work on the demo to help us do some of the lifting for the finished product. It already does, in an internal and technical sense: it proves our technology, it lets people test it out, and the work we put in to finish the demo is work that carries over to the full game anyway. It can do even more, and we’ll be measuring what the right balance of effort is and where opportunities may lie.

Adventure Mode and What’s Under the Hood

Speaking of the rest of the game: our writing team has been continuing to work on it in tandem. We take time to review the writing and iterate upon it, but the other components of the Adventure experience have been left alone while our design focus is on Melee. After this milestone, we’ll be shifting some of that focus to finishing the full game, and once the Melee Demo is fully out the door, we’ll be entirely focused on the Adventure mode.

The Adventure mode benefits not just from the work we’ve done for the Melee Demo around melee and its “window dressing” mentioned above, but also from a lot of under-the-hood technical work. As of now, we’re successfully making builds for seven different target platform configurations: GOG (Windows, Mac, Linux), Steam (Windows, Mac, Linux), and Switch. We’ve fully implemented GOG and Steam networking backends, with their attendant friends lists as easy ways to join games on those platforms. Cross-play between PC versions will be supported, though cross-play between consoles and PCs is at the discretion of first parties (e.g. Nintendo). We cannot promise anything there besides saying we’ll try.

When we prepare for release, we’ll have instructions on how you can play between PC versions. It’s a little bit of extra legwork if you’re playing on the Internet, but we may develop ways to make it easier—or our community will support their own ways of making it easier. Playing between versions on a LAN is very easy. To reiterate: our game is fully DRM free besides what first-parties like Steam require, and there is no backend service we’re required to run for network play. The demo, like the full game, will always be playable. If you want a fully DRM free game, GOG is a great platform for that. The Demo will be available there too!

There are a lot of other little features we’ve added beyond that, which we won’t bore you with too much. We have different menus and screens to handle network states like waiting for the connection to be configured. We’ve gotten a prototype for the game’s credits with all of your names in it. My first pass, proof-of-concept implementation with zero optimization takes about ten seconds just to get to the credits screen because there are so many names!

We have an implementation of shader caching which pays a one-time-only loading time cost in exchange for eliminating stutters during fast-paced gameplay when you really don’t want them. There were also some forays into our own wishlist features like how to change the game fonts or font sizes which we attempted but haven’t yet finished. There is a long list of features we need to do experimental implementations of just to scope, though they’re more for the Adventure mode than Melee.

Even deeper in the real belly of the beast, I took the holiday downtime at the end of 2025 to upgrade and reconfigure our team’s version control server to better support our release efforts. We have a place to store old versions of builds now, for posterity or just for regression testing. While endeavoring to redo ship collision shapes, Zach discovered a problem with how we visualize those shapes which was throwing off all our attempts to make collision right, which Fred was able to fix. There’s a lot of work down in the guts that just helps us work!

Kickstarter Ship-a-thon

We also successfully shipped out nearly 2,000 packages of Kickstarter rewards to all of you! The darkest, deepest depths of our project turned out to be in my (Dan’s) apartment conversion: from an already-extremely-small living space, to an international receiving and shipping center, and finally back to a relatively normal apartment where I can access my kitchen without tripping again. Down the road, I’d love to do an entire retrospective on the shipping process and what we learned, but in the meantime I did want to share a relatively brief glimpse into what it was like and some of the situations that cropped up.

It is difficult to overstate just how much of this process was simply building a “production line” where I could pack things! This place had to exist in my one bedroom apartment, which is also my office where I work on the game, which is also my home where I sleep, which is also a place other people come visit me, which is also the warehouse storing boxes upon boxes of rewards and shipping supplies. And it’s all up (and down) two flights of stairs. If the average weight of our shipment was about 8 ounces, that was about one thousand pounds (or ~450 kilos, for people who use sane units) that I had to move around multiple times in my apartment and eventually back down the stairs. I was quite literally sore from working on this part of our project!

We talked a bit about the prep in our last update, but I really did cannibalize half of my apartment to not just store all of the supplies, but to set up spaces where I could reasonably access things in batches to do the packing. Ignoring procuring all of our manufactured goods, shipping supplies, and setting up my production line, it probably took only a total of perhaps sixty to a hundred hours, in a mix of late evenings and weekends, to actually pack, label, and ship everything! A lot of the work was just in the set-up, and as much as I would have wanted to just set up a dedicated space for packing, I had to make my packing table setup movable because it’s also where I work, where I eat, and where the birds play.

I talked a bit about this on my surprise “packing stream” last year, but the most time consuming aspect was actually everyone’s custom orders with add-ons. I’m very glad we let people have the flexibility to add an extra pin or get some stickers and that many of you were excited to kick in funds, but it also meant I couldn’t just pack all hundreds Collectors’ Complete Editions in one big assembly line, since there were so many unique combinations of items y’all backed for! In all, about fifty percent of the time was spent packing maybe only twenty percent of the orders. With the big pile of Collector’s Complete Editions, I would just pack all of them and have them sitting in boxes, ready to get their shipping labels later. For the unique orders, I had to print shipping labels as I went or else I’d lose track!

As all of humankind knows, printers are the greatest technological scourge on the planet. My very handy thermal label printer made my work far easier than using my laserjet, but of course it didn’t work perfectly. When printing hundreds of labels in a big batch, I noticed it would occasionally skip random labels. I would have to go back in and manually check for skipped/missing pages of purchased shipping labels. This was very error prone and scary, since I wanted to make sure I knew which packages were going out even though there are automated scanning systems at the post office. Not willing to spend the time or even knowing how to diagnose a printer driver, I applied tried and true game development wisdom to printing: I produced a simple script which would use the command line interface of SumatraPDF to print our multi-page PDF label documents a single page at a time. Success! Brute force hacks and open source software saves the day as usual.

Now that I had hundreds of pounds of packages packed, labeled, and ready to go, it was as simple as scheduling a pickup with the postal service, right? Wrong! I scheduled a total of seven pick-ups, and my local post office driver only came three times. I wouldn’t actually know if the driver was coming until the day was over, so I wound up with mountains of packages clogging up the shared lobby in the building where I live. I apologized profusely to my confused but understanding neighbors. Once I got down to smaller numbers of packages, I opted to instead become my own postal carrier as I schlepped them the four blocks down to my post office. If you want something done right, and all that.

The last interesting challenge was simply international shipping. I could write a lot here, but there were a few things which took me by surprise which are at least amusing, sad, or both. First off, since we originally scoped our shipping costs, the price of international shipping has skyrocketed. Part of this is certainly in the hazards of not knowing the final weights of our items until they’re manufactured, but a lot of it is simply that the price of shipping internationally has gone off the charts.

In a future retrospective, we could analyze this data more deeply, but we’ll just hit you with the highlights. We collected $15 USD from international backers from Canada and $20 USD from backers everywhere else in the world. The lowest-priced international package we sent was about $23 USD (Canada and Germany). The highest-priced international packages were two at $80 USD going to Australia because our customs declaration valued the price of the package over $500, which means we have to pay an extra $30 for a fancier shipping tier. The average price of an international package turned out to be about $40 USD. Ouch! The initial 15 or 20 dollar estimate was made with buffer room for possible cost increases, but no one could have predicted how far off the mark we were.

We had a few one-off, very special case errors. A few backers input addresses in non-Romanized characters using Hangul or Kanji, which the automated online shipping systems will happily accept, but are effectively undeliverable and print as useless labels. We had to contact them to get corrected addresses. One backer is in Belarus, and we cannot deliver anything there right now. Several backers contacted me asking for the declared customs value of items in the parcel, which confused me because we have to declare the value just to put on the label on our side. I sent a message to everyone who may have been impacted by that to help them.

Did you know that mail is only classified as a letter if it contains a document, and only a document? I didn’t! Everyone internationally getting the Collector’s Lite with just a card and a patch had to have their envelopes shipped as if they were a parcel/package, even though, for all intents and purposes, it was shippable in a letter. Domestically, it doesn’t matter as long as the container is letter-like in dimensions and weight, so that also took me by surprise. And, yes, now even that humble envelope cost us more than $20 dollars to mail everywhere.

On the domestic front, we have had far fewer problems, at least. Only a few packages were returned as undeliverable, and I have usually been able to resolve that by being in touch and sending things back out. There have been hundreds of emails I’ve answered to help backers, which is a lot of work, but also one of my favorite parts of this process as I get to talk with all of you! Of course it’s also satisfying to hear that you received and like the rewards. I love seeing your pictures and hearing your stories if you share them in our Discord, on Bluesky (tag us!), or even just as comments on Kickstarter or in an email.

I’ve gotten a lot of questions about getting digital rewards like the Lorebook and Starmap out for those who pledged for them. I have some good news on that front! My work setting up all the shipping helpfully pointed me toward a strategy we can use to deliver those items piecemeal through BackerKit. We don’t have an ETA just yet, but we’ll be looking to deliver those things soon, likely some time near when the Demo releases. The soundtrack will be made available later, much closer to the release of the full game.

Last but not least on the reward front, there are about one hundred stragglers who pledged for physical rewards but still need to fill out their surveys! I have been sending automated emails, and I will be trying to annoy you with reminders frequently, but we really need you to finish your surveys or I can’t ship you your rewards. I even phoned one backer because I had their phone number!

After May 1, 2026, we will be cancelling any incomplete pledges who weren’t charged anything during the Kickstarter. After that, we will be hounding the remaining backers until June 1, 2026, when we will be canceling and refunding any pledges people did make during the Kickstarter. We don’t want this to happen to you! You don’t want this to happen to you! Please get in touch! If you accidentally made a duplicate survey/pledge, which we know some folks did, just contact us and we can cancel it for you.

After we have ensured all of our backers have been fulfilled or refunded for their physical rewards, then we can look into possibly selling the remaining extra awards for those who missed out or need more pins to battle against their current ones.

In the Future, Fun is Fun

We’ve cleared a lot of big hurdles and met a lot of big goals! So what’s up next? As we discussed above, a lot of our work will be in reaching back out into the community. With the Lorebook in the wild and the spoiler warnings supplied in some of our community spaces, we’ll be sharing a lot more information freely. We want you to play the demo! We want you to see our game’s progressing development more again, which means looking to do development streams again. It also may mean smaller, more frequent updates instead of these essay-length pieces.

We also always want to ensure we provide resources for our community to rally in places that we can support. Some people have been rightfully put off by some of the tremors around Discord’s move to require age verification. We are too, and we try to keep as much under our own umbrella as we can because we prefer being self-sustaining that way. That said, we do rely on Discord at the moment to reach some of you. If you’re here on Kickstarter, we have a way to reach you! But we’re always looking for other community resources we may want or need to provide. That can include hosting a regular old forum, setting up a wiki our players can use and maintain, or looking for Discord substitutes if the community becomes too unhappy there.

One thing we know we’ll want, which we have mentioned already, is some clear end-user bug reporting and observing mechanism. The first Demo release will likely not be the last Demo release, since we know that we don’t know everything. We’d like people to have a place to go if they have problems, and we’d like our work there to be visible.

Lastly, we know the Melee Demo is just the beginning of our release schedule. We don’t want to provide a release date for the full game since we’re still looking to learn a lot from the demo, but we are very sure of one thing: if you help us make the demo successful and spread the word, it will help us with the finished game. We’re counting on all of you, and we appreciate everyone who is able to lend a hand by playing the demo, reporting issues, or telling friends—and enemies, it is PvP after all—about it!

End Transmission

It’s time to wrap up our first milestone update of the year. We made a huge amount of progress, and there are still more hills to climb. We scaled some big peaks, though! I find it’s too easy to forget our progress when we’re always focused on what’s next, especially right now in our quite disheveled world, when “living in the moment” doesn’t necessarily mean being part of a moment you want to be in.

Part of acknowledging our progress involves the important work of acknowledging our own value and contributions, even if the end result isn’t there yet because it’s not the end. Right now, as an apologetic and aghast American and San Franciscan, I can only say: it’s not the end.

While every bus stop ad and billboard carries the full weight of cynicism that seems to be trending among all of us, while I feel like we’re truly living in a post-COVID world of trauma where the people who felt victimized and hurt are taking it out on the rest of us, while it’s just a normal thing for people to be riding around in robot cars all around me, living in some surreal, Gilded Age 2.0 dystopia—I have to be especially mindful to reach out to the communities who are part of making life worthwhile and change happen.

No matter what happens, I hope you remember you’re not helpless and you are an invaluable part of our project in addition to the other communities that appreciate you. There’s more going on in your world that matters than just what’s going on in “the world.” Take time to find and appreciate those things, and don’t forget about the moments you create for yourself and others.

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