We got a lot done in August, here’s a very full update!
For me the biggest accomplishment in August were fleet events. Fleet events start immediately when you emerge from jump at a new destination. Some fleet events are purely narrative and help set the tone as the chaos unfolds. Some give tips and mini-tutorials in the form of lore or interactions with the ship’s crew. Some bring benefits, and a few bring trouble. But the most exciting ones depend on your relations with other factions. These faction events are the core of our political system and will challenge you with many tests of leadership.
I dove into fleet events right away and already have 45 implemented and tested. In September we are adding more functions that will enable me to create the more complex political events that I’ve been waiting to play literally since I first imagined XO! I’ll talk more on that next month.
So as a result I worked a lot on early narrative and setting the tone in August. I converted the the old starting event to a fleet event, and broke it up into smaller pieces. Then I worked and reworked some of the mini-tutorials.
Heru made the first event trigger automatically when the game begins, which sets the tone perfectly and gives an opportunity for the player to ask questions or quickly skip all that and jump right in.
I also completed lore for all the ships, stations and caches in the game. These will display when you scan a ship, although we won’t have scan functionality ready for a while yet.
I added formationAttack tags to quite a few events, mostly the Attackships events to increase the challenge and immersion.
I’ve been having a lot of fun testing, which is good because I have to do it for hours every day. As I playtest, I often have ideas for adding depth to events. This month was no exception. For example, I came back to an event involving a rescue and added several new conditions, including our first true achievement. Even though we haven’t built out the functionality to support them yet, this one screamed out ‘achievement!’
My philosophy on achievements is that none of them should be easy – I’m staying well clear of freebies. We will have a few obvious ones like survive 50 days or collect all the ships from a faction, but most will be unusual and/or hard.
The pace of event creation is good. Including fleet events, we’re up to 331 events now, and I’ve still got no shortage of ideas. Now that we have so many events, Heru added a search box in our testing tool so we can quickly start an event that we need to test. Another huge time saver.
On the 3D modeling side, I created caches for each of the three remaining factions: Empire, Irenic, and Rover.
I created animations for the upcoming actions sacrifice, launch and recall. I also created an abort animation. I’m also playing with different settings to get animations to pop even more.
But most of what we did in August revolved around killing bugs, covering off overlapping rules and adding functionality for edge cases.
Rule #1 about bugs: if you can’t reproduce it, you can’t fix it. And it can be quite tricky to reliably reproduce bugs. For example, I had an event that wasn’t always throwing an error. It required quite a few steps to get to where the error would occur. Well, eventually I discovered that I wasn’t being consistent with my testing – in this case, sometimes I was adding a ship to a formation and sometimes I was not. The bug required the ship to be part of the formation.
Other times a bug triggers a discussion. Case in point: we fixed an issue where some formations were not performing certain actions when ordered. But this could lead us down an infinite hole because the player could still design formations that make it impossible for certain actions to work in some cases. For example, if you have a formation that has no ships on the top edge, and a ship on the bottom edge and you order a rescue, no ships can be in range for the rescue once the formation reaches its target. So rather than design an elaborate algorithm for adjusting formations, we’re just going to have the formation stay in place and if the command is out of range, that’s a learning moment for the player.
The new skip button on our text boxes was improved – in some cases it was only completing the text that was in process of being displayed. Skip now always jumps ahead to the next player decision or the end of the event.
We had a case where if you told a ship to repair another ship that was moving back to a formation, the repair ship couldn’t catch it. Now when you call for a repair, the target self-issues an abort order which stops it so it can be caught for repairs.
Also with formations, we had an issue where ships were trying to rejoin a formation after their crew had been removed by the Harvesters. Now the spooky ghost ships are no more.
Continuing with formations, Heru fixed a problem where ships were being accidentally dropped from a formation when they were selected using the fleet info panel.
At one point formations would freeze if you launched a nuke from one, but that’s gone now too.
And there was also a situation where you’d select the leader of a formation and that would invisibly select the entire formation. That’s fixed.
A bug with weapons free and formations was appropriately destroyed.
Similar to formations, there was a bug with weapons free and multiple ships where only the lead ship would open fire on a target, but Heru took care of that one.
When a ship is disabled it tumbles slowly towards the planet where it eventually burns up or impacts on the surface. We had a case where ships that were harvested were tumbling but not dropping towards the planet and Heru fixed that, too.
We deprecated the Evac event action for a more flexible and reliable crewCount, so I went through all of our events and replaced that and tested the new action.
I had to fix some triggers in an event called The Vendetta so that it worked in all cases.
Trade and some other event tags weren’t working right when called with the new preTrigger, so Heru fixed those up.
An issue was resolved where multiple protect orders issued in an event weren’t working properly.
Heru also fixed a minor issue where clicking in a dialog box deselected your ship(s). We only want ships to be deselected if the player clicks on another ship or in the tactical viewspace.
Sometimes I report an issue and something else that is done fixes the issue. Such was the case with protecting ships not firing on targets that were very close, so we took that one off the list after testing.
Sometimes a bug is caused by mistakes in the event syntax. We had an event where I accidentally used the wrong condition in a trigger, and it was throwing strange results. Not surprisingly, the problem resolved when the correct condition was used. Oops.
And sometimes I misunderstand the function of a tag. For example, I thought you could use this syntax to keep an event running: [ end: no ] Turns out I should just do nothing and the event keeps running, which is more elegant anyway.
Heru also caught and killed a bug that prevented events from ending when the skip button was used, and another one where farmship events weren’t spawning correctly.
Although I have a script that I use to generate events, I still have to thoroughly test events. Sometimes even then I think we have a bug, when actually the event is doing just what it’s told to do. Case in point: I filed a bug where an event was ending prematurely. The cause: my script had added an endEvent tag automatically, and I glossed right over it when I was debugging the event. This is similar to how you can skip right over duplicate words when proofing a post.
Heru fixed a very old bug where non-warships could get warship commands. I’m very happy to see that one go.
Some work was done cleaning up the Abort order, as it was causing problems when used with formations. It works as expected on formations now.
Similarly, the new Retreat order wasn’t working correctly with formations, so Heru got that working properly.
Setting weapons free on formations of certain sizes also threw an error, but Heru stomped that one out too.
We had an issue where if you attacked a ship in an event that wasn’t started it would throw an error. That no longer happens.
There was a case where formations were mirrored which Heru took care of.
Setting a ship to protect another ship in an event sometimes didn’t work – now it works 100% of the time.
When a dialog box had a lot of text, in a couple of cases the dialog box wasn’t scaling and the text overflowed out of it. That’s no longer an issue. These were minor issues but since I need to take screenshots for Kickstarter updates, I made them a higher priority.
When we made some adjustments to how the Harvester fighters select targets, it inadvertently caused some fighters to unlatch from a ship they had captured, and then of course the Harvester taker wouldn’t be dispatched to grab the crew, either. This was causing some strange swarmlike behavior around ships. So that’s been fixed.
Often times we have to make decisions about overlapping rules. Here are two: we have a rule that if the player tries to shoot a fighter that has already latched on to a ship, the fighter and the latched ship are destroyed. But we also have a rule that says if you give a ship a weapons free command, it will automatically shoot any enemy ship in range. See the overlap? Our solution: since it makes sense that automatic fire should not target latched fighters, Heru added that additional rule.
Here’s another good set of overlapping rules. When a ship (like a repair ship) is disabled, it automatically unlatches. We added this rule in August because you could be repairing your battleship and if the repair ship was disabled, the battleship would be trapped, unable to move. You’d then watch as it slowly drifted into the planet. This was a long, slow, painful ‘game over’ moment that no longer happens.
However, we have another rule that Harvester fighters cannot be disabled, only destroyed. So the new rule caused the Harvester fighters to unlatch their prey when they were destroyed, too! Heru fixed that, and now the fighter and latched ship are destroyed, but if a non-Harvester ship is disabled or destroyed, they unlatch their ship.
We did a lot of work cleaning up scouting. As an example you can no longer send a non-jump capable ship scouting. For a while you could send lifeboats, gunboats, caches – anything.
And you used to be able to send a disabled ship on a scout mission, too, which simply wouldn’t do.
There are a number of rules involving how events are generated, so making sure these lined up with scouting reports required a fair amount of work. Thanks to all that work, scouting reports now always report the right number of events.
There were a few actual bugs with those rules, too. For example, there should never be two simultaneous warship events. In some cases two were generated, but that’s fixed now.
There was a bug that occurred when changing your jump destination after being fully plotted while a mission timer was running, but that’s fixed now.
Another specific bug happened when scouting to a second destination in a specific way, and that one is gone too.
A small area at the top of the starmap screen was unclickable in certain rare cases, and that’s been taken care of.
Now if you try to jump while a ship is scouting you’ll receive a warning – you can jump or wait. If you jump you lose the scout forever.
Another scouting bug had to do with sending two scouts simultaneously to different destinations and coming back with an empty second report; that bug is gone too.
We also had one strange case where after scouting several times, two scouts would go out on a single scouting mission. That one is also gone.
There were some issues with the water riots, too. For example, if you dropped a ship from your fleet that had a crew on it, it used to throw an error.
Another scouting/water riot bug that’s thankfully gone happened if you left the scouting window up until the scout returned.
Another water riot bug happened when you had a certain size fleet and you sent two frigates out to scout ahead. When the second one returned, you’d get a mistaken water riot.
Sometimes our bugs happened when multiple conditions were used. In one event it is possible to juggle crews around quite a lot requiring quite a few conditions to cover off all the cases. All of those work smoothly now.
Although we mostly worked on bugs, edge cases and cleaning up overlapping rules in August, we did add features as well. We finalized the relationship system, which underpins the politics in XO. We now have a large set of rules implemented and tested that cover everything that can cause the factions to be angry with you, and all the ways you can make them happy with you. This was a considerable effort comprising nineteen different tasks – I won’t go into each and every one, but here’s a couple for flavor:
Losing a refugee causes a faction to become angry with you, but losing a warship does not. It’s enough of a penalty to lose a warship!
Rescuing crews not in your fleet gives you a boost to relationship. But if you destroy one of your own ships and rescue that crew, there’s no real effect. This covers off an obvious exploit where a player could boost relations just by disabling and rescuing their own ships.
Heru added the ability to add groups of conditions to triggers, which adds a great deal of depth. He also fixed an issue where factions were being ignored in the crewCount tag.
We had a situation where if a ship was targeted on the opposite side of the playfield for certain actions it would not move, although it would move if you gave a hail order. That’s also been fixed.
Mining ships were giving you ore even when they were set to hold fire, that’s been fixed.
The auxiliary was halting repairs during jump, that’s been fixed so that the aux repairs a ship until done or the player releases the ship.
Some minor rotation issues were fixed, such as the battleship not orienting correctly after jump.
There was a bug that cropped up when an Irenic station was destroyed and a different one that happened when they were attacked, but that’s no longer an issue thanks to Heru.
There were a couple of cases where multiple lasers would fire simultaneously on missiles and fighters; since these only take one shot to destroy, the extra shots were wasted. This no longer happens.
We worked a bit making shields better. We briefly had a bug that happened when fighters impacted shields, but that’s gone now.
Heru fixed a case where the outer shield wasn’t going down when hit on stations fitted with two shields.
We had an issue where enemy ships that were attacked would sometimes run away, which made completing timed events pretty much impossible. Turns out some of the time they were assuming a ‘running’ attack order instead of just standing their ground and fighting. Ships hold their positions now.
Heru also fixed a problem with minefields – in some cases player mines would attack the battleship, which is never a good thing. Of course, I discovered this bug on an epic playthrough after I had amassed a huge fleet, and it wiped out my heavily damaged battleship!
The nuke is a devastating weapon in the game, and it requires an enormous amount of ore to fire. So it was pretty important that it not fire automatically when you issued a weapons free command or gave an attack order. That functionality is now in place. That’s another bug that I discovered accidentally. My fleet was defending against an attack and I heard the telltale nuke launch and watched in horror as several of my ships disappeared in the blast wave!
Also, the nuke command now only shows up when you have enough ore to launch one.
We had a case where if you nuked a Harvester carrier a bug was thrown, but you can nuke them all day long now. And boy is that satisfying.
Proximity destruct basically turns a ship into a nuke that detonates when an enemy gets near it. We had a bug with that for a bit, but it works great now.
Our dialog windows would sometimes display text one letter per line, which made reading pretty impossible. This one was tough to chase down and and correct but in the end Heru persevered and that bug is gone on all of our windows now.
There was a bug that cropped up when you jumped with a specific set of conditions in a certain event, and that one too is gone.
On the balancing side, I changed the resource values used for rewards, penalties and costs in our events to bring them in line with changes I made to costs the month prior, and those are now in place.
I made some adjustments to the shield firing delay to make sure fighters could break through, and reduced the amount of ore that an Irenic gatherer could store.
I asked Heru to change the behavior for how ships responded to a hold fire command. Previously, a ship would remember if a ship had been firing on it, so if you issued a weapons free command after a hold fire, the ship would resume its prior attack. I thought it better to have the ship forget any enemies in case, for example, you persuaded an attacking warship to join your fleet.
I had a friend play the game and I observed some confusion when the player’s crew was talking versus when the player’s character was talking. So I adjusted the position of the character windows to make the difference more clear. We may add some sound differentiation there.
There was a minor issue creating a Windows build of the game that Heru fixed. Another unrelated issue in Windows only made the jump button not work, but only the first time. That’s thankfully gone, too.
I continue to build out functionality in my event script. In August I added logic for the preTrigger, fleetEvent, getShip and shipExists tags. I added a new tag type for tracking the types of fleet events. I fixed a few syntax bugs, and expanded cache/trade events for preTrigger actions, and added the new caches.
I also updated to my event tracking script to include fleet events in the general count. The join to rescue ratio is 3:1 right now which feels about right.
Of course, I wrote the July kickstarter update and did the screenshots, which took about two days.
So as you can see, quite a lot of our bugs got squashed and we still managed to add substantial functionality in August. Going forward Heru is going to dedicate one day per week to bug fixing and focus the rest of his time on adding features. Our pace is good. All of the bug fixing has been quite a test of the robustness of the code, and I’m happy to say that it has held up well, which is a real testament to Heru’s abilities.
It’s really great to see the comments come in supporting our efforts. Thank you for your patience, good ideas, and positive words!