2018 June Dev Update

Hello everyone! I asked our Kickstarter backers last month if people wanted longer updates and the response was overwhelmingly yes so I’m pleased to add another good long one detailing what we were able to accomplish in June working on XO.

The biggest victory for me was our work on the starmap. Here’s a before and after:


Old starmap
Old starmap
New starmap
New starmap


As you can see the planets look a lot different. That’s because, thanks to Heru, the starmap now uses the same shader as the main tactical view. This is something I’ve been waiting to have done for years. Not only do the planets in the starmap –finally– match the rest of the visuals, but it is so much easier to tell one type from another.

This wasn’t a simple change. It took a few tries before Heru got it right. And it exposed some underlying issues with our shader that needed to be addressed.

A small amount of work needed to be re-done; for example I had to add new collision boxes for all of the planets. We also had to correct some new problems this change introduced, from transparent dialog boxes to overbloomed elements. Heru also made a lot of adjustments to the starmap after the new shader was implemented. For example, the planet preview was duplicating other UI elements on the main screen instead of just being a view of the planet.

It was all worth it. At last I am happy with the way the planets in the starmap look!


Not enough shield for everyone in the fleet...
Not enough shield for everyone in the fleet…


Another big accomplishment last month was the final implementation of shields. Shields now have up to five charges each, and multiple shields can be stacked on a single ship or by overlapping shield coverage. Each hit from a laser takes away one charge regardless of the power of the laser. Harvester fighters are also destroyed when they hit a shield, removing one charge. Missiles are unaffected by shields.  And now, all enemy warships within the shield’s radius take damage periodically.

Shields now properly lose a charge when the shield’s outer radius is impacted, not the shielded ship. When hit, a shield also immediately begins recharging.

A lot of effort went into creating, implementing, testing, balancing and tweaking the shields this month. There are still some small issues remaining but they’re working exactly as I hoped, adding much more depth and utility to the Irenic faction.

Visually I created the final shield dome which sparkles just the way a shield ought to. I also created the UI for displaying shield charges which Heru quickly implemented. Yet to be implemented is the shield collapse animation I made last month.


Shields up
Shields up


I began adding shieldship events to the game, which uncovered an interesting edge case where a ship that was protected before an enemy spawned in would be fired on. Heru slapped that one down quickly.

With the crew functionality he completed in May, Heru added several new event conditions in June: crew and evac, which allow me to add crewing and rescuing as a condition to mission success, failure or as triggers. He also added a new crewCount condition that allows me to specify actions when a certain number of a certain faction crew exists on a particular ship or station. And I also have an addCrew tag that allows me to create new passengers on ships that can carry them.

I wasted no time in creating several crew events with these new tags. And of course we found and fixed numerous small bugs related to the evac and crew functionality.  For example, when I used the shipHealth tag to disable a ship in an event, it wasn’t properly tumbling away into the atmosphere. A similar problem was fixed with disabling and then abandoning a ship.

I also added the new Faction tag to all of our events, which allows me to specify what events spawn based on which faction owns a given destination. So right now if you want to add an Irenic ship to your fleet, you have to be at a destination owned by the Irenic. This gives you a vastly more meaningful choice when deciding where to jump.

I did a lot of work pushing the limits of our event system and trying to make unusual combinations. No spoilers, but this exposed some gaps that Heru filled in.


Multiple shieldships protecting a fleet
Multiple shieldships protecting a fleet


In addition to writing new events, I went back and updated some existing events, sometimes with the new functionality we’ve added, sometimes just to make them better. For example, I added an option to use ore to convince a ship to join the fleet in an event called The Chattel. As I playtest more I’ll be adding and tweaking events like this as I come across opportunities to do so.

My goal for release is at least 300 events (not including fleet events). We are now at 172 events; I’m happy to have passed the halfway mark! I am having so much fun writing these events, and my ideas continue to outpace my ability to write. I also feel that my pace of event creation is good.

On the 3D modeling side, I added the Corp Mining Colony (a type of station) to the game. I created the Empire station.  And using an old model as a source I made a new Rover station. I then animated and added them to the game. Then I added a bunch of unique names for Rover, Empire and Irenic stations.


An Empire station
An Empire station


I simplified the Pact lifeboat model which was a little heavy on polygons, and then created unique lifeboat models for each of the four remaining factions and added them into the game. With the lifeboat functionality now complete I added abandon ship actions to all of our events that had triggers for ships becoming disabled.

Alexander did a great job creating more icons for the new lifeboats and stations in the game. He was also instrumental in helping with the final shield rules.  Did I mention how awesome it is to work on a game with my son?  It doesn’t get better than this.

Since I like the visual effect of pieces flying off of warships so much, I want fighters to blast into little pieces when hit, too. So I made the Harvester fighter destructible, although that functionality has not yet been implemented.

I finalized the mouse pointer for multiple selection and swapped that out for the old blurry one.

I improved the animation for salvaging, and have been spending time slowly making all of our animations better. I hit on a couple of techniques just last week that are promising so far.




I improved the UI for viewing weapon info. I’m excited to see this implemented, as the pure numeric display of weapon data we have right now is pretty awful, but I will have to wait for some time as we are prioritizing functionality over UI improvements.

A good number of bugs were also squashed last month. Heru fixed an issue where ships doing a proximity destruct kept blowing up over and over. He corrected a bug where Rules of Engagement orders and formation position changes were not working with mining laser-equipped ships. And a bug was fixed where repairing ships through a trade event wouldn’t work even though you had the right amount of ore. He also fixed a bug where sending a scout after plotting a course made the jump button re-plot instead of jump.

Another bug was fixed where ROE commands were not applied to all ships when multiple ships were selected. Abandoned ships were still firing weapons even though they didn’t have a crew to operate them, so that’s been fixed too.

Heru added a new event command, killOnJump which stops an event if the player jumps. This corrected an issue we were having with events ending prematurely. I added this to all the appropriate events.

On the combat side of the game, apart from all the work done on shields, Heru adjusted the actions of the mining laser to focus only on repelling fighters and missiles instead of wasting their shots on warships (which have no effect).


Losing the fleet
Losing the fleet


We made a big change to how the Harvester fighters target ships. Previously they had been individually targeting ships. This ensured that no ship was safe, but it often caused fighters to pass right by worthy targets. Now, Harvester fighters retarget on ships that are directly in their path. This has had the desired effect of making where you place your ships in a formation much more important. It may yet require a little more adjustment, but I’m pleased with the result.


Harvester attack
Harvester attack


On the game balancing side, I made adjustments to the cost of resources in trade actions. I added small amounts of ore storage to each Empire warship to buff them a bit.  And now all of your ships always re-enter from jump at the same small area of the playfield – in formation if you have created those, or randomly placed if you have not.  Among other things, this prevented a Harvester carrier from jumping in right on top of your fleet — which is pretty much a game-ending situation.

Based on the playtesting I’ve been doing, I made some small adjustments to the rules for how events should be created; Heru has already begun implementing those this month.

Another part of balancing the game revolves around carefully tracking the mix of events that I write. Now that we have crew events I’m separating narrative events out into what I’m calling join events, which involve a ship joining your fleet, and rescue events which involve you adding crew to your fleet. As of the end of June we have 108 join events and 5 rescue events (the rest are a mix of attack, trade and abandoned ship events).

I continue to make improvements to my scripts that help me create events. In the last month I added functionality to support the Faction tag, killOnJump, addCrew, crew and evac actions. I expanded the functionality for question/results, added several new triggers including location and flexible relationship states, added relationship states to occurIf (which will be critical for the upcoming fleet events), added more flexible mission success/fail tags, added the abandon action, and finally added a new ship id tag for rescue events so that I can track them separately from join events. I also did some minor refactoring of the script to give me some more flexibility, and cleaned up a bit of the code.

I also improved the logic for my event tracking script and added ratio calculations so I can see at a glance the balance between certain types of events. For example there is currently a 9:2 ratio between join and trade events.

Last but not least, creating last month’s mega Kickstarter update took me two days.


Overlapping shields protecting ships
Overlapping shields protecting ships


In the Kickstarter comments I was asked to provide some kind of list of what is remaining until alpha, and I’m about to do that.

DISCLAIMER: keep in mind that there are many smaller tasks that I haven’t included, things may come up that require attention, and this doesn’t include a short list of bugs we still have to address. We may decide to add things from the wishlist, or move things from beta to alpha or vice-versa. We will certainly encounter more bugs. None of this includes marketing tasks. And we have more to do between alpha and beta.

With the above disclaimer in mind, here is the list of major functionality remaining before alpha: we have event spawning rules to complete, then we have plenty of work on ship AI and movement, then adjustments to how we are generating the types of destinations at game start. Then we have fleet events, faction leaders and an initial set of faction leader powers, and a handful of event actions to implement. After that, we need to add saving and restoring the game state and clean up the game over/restart cycle. Then the galactic map needs to display faction information and their correct 3D models. Faction accessories need to be properly assigned to their correct faction. And we have a very, very long list of small but important UI bits to do. We also have optimization and deferred refactoring to speed the game up. During this I will be writing many more events, creating or improving 3D models and animations, testing and balancing.

We are still not going to make estimates of how long it will take until we reach alpha, beta or release. We’re going to continue to work full time until release, and post monthly updates here until we are very close to alpha.  But hopefully this gives a better sense of where we are at and how much more is remaining.

The code is holding up well as we add functionality, the work we have left continues to shrink as does our list of bugs, and our enthusiasm is high!