Read on for our October in-depth dev update!
Functionality
Mining ore and melting ice is now fully complete. Mining ships mine ore by default, but you can also tell them to melt ice or defend the fleet. Ore mining rates are now tied to the quality of ore at a given destination. A mining ship must now actively be mining to collect ore. And mine ore and melt ice actions now only appear when ore or ice are present at a given destination.
To round this out we added full functionality to the Irenic gatherer, a shield-carrying mining ship. This ship cannot use its shield while mining ore; it uses its shield to mine. However, a gatherer cannot melt water. We added some special cases to shields to accommodate the mine command, and exceptions were added so it could not melt ice.
I also created a unique animation for the shield when it was being used to mine, and that was added in place of the mining laser beam firing.
Heru added code to differentiate between the Repair and Fix actions. Fix is a Rover action used by their relatively underpowered warships; they can quickly repair a disabled ship (most of the time) but they cannot repair armor. Ships that are capable of the Repair action on the other hand do fix armor but take much longer.
We improved the way water riots were handled by making sure they were not triggered until after you completed any crew transfers or evacuation actions.
Quite a few events in the game only trigger if certain conditions are met. Commonly, ships of a certain type of faction trigger an event. Heru added functionality to ensure that these events only triggered if you had a ship from the given faction, and not just crew from that faction.
We have a general rule that ships in a formation should always try to stay in formation. There is an exception; if you give an order to an individual warship, it will break formation, do the action, and then return to formation. But when it comes to mining ships in formation, we decided the mining ship should try to mine but not break formation to do so. This means the player has to make sure the mining ship is positioned in the formation close enough to mine. Previously a mining ship would always drop formation and fall far behind the fleet, which wasn’t very fair or reasonable.
Heru made the Harvester fighters destructible, so when they are shot they explode in a very satisfying array of parts.
I began adding opacity layers behind text labels to improve their readability per the UI spec.
I designed an icon to designate a plan and added it to the trade dialog to help differentiate a plan from a single item.
I also added some code that made plans cost more than individual weapons. Right now they cost double, although that amount may change in alpha or beta.
We widened the effect of the intimidate faction leader power to cause all ships in an untriggered event to jump away instead of just a single ship. This covers off a case where the player could selectively intimidate powerful ships in an event before starting it with very little consequence.
Optimizing is the process of identifying places in your game code that slow the game down and replacing that code with something faster. Well, last month Heru finished out one phase of our code optimization which was to replace a certain type of highly inefficient code used throughout the game, a leftover from the prototype code before Heru came aboard. The type of code occurred in 54 different places in the game code, so this was no small undertaking. Although we’re not done optimizing, we’re both happy to say that part is finished.
We also cleaned up some unused parts of code that helped to speed the initial game loading time up considerably. I’ve also been going through the code and removing unused bits.
One of the most important concepts about XO is that ships have different abilities. So making sure the player is aware of those abilities is pretty important! One way we do that is through the ship detail panel. This panel pops up whenever you hover a ship in your fleet list. It displays things like weapons and crew carried, ship damage and ship special abilities. This panel was fine tuned and abilities for the fixer, barge, refinery, tanker, auxiliary and all mining ships were added. The only thing remaining on the ship info panel is to add the ship camera view and finish a better visualization of weapon range, damage and rate of fire, but that comes post-alpha.
I created an animation for the Jury Rig faction leader power and added it to the game.
I also made some adjustments to ship collision boxes.
Heru added the main menu and options menus and some of their attendant functionality. We have a partially working new game button, but a bit more functionality is yet needed there to fully restart a game.
We had to make some tweaks to how music was being handled so that we could properly turn it on and off from the options menu. And when we added functionality to turn sound effects on and off from the options menu we discovered that we need to do some more work than expected on sound effects. Unfortunately we’re not done there but will turn back to that in coming days.
Now if you send a non-warship scouting and it encounters unfriendly warships or Harvesters, it won’t come back. We added a summary screen to notify the player if that happens. I think this was the last piece of scouting functionality remaining!
Unfortunately Heru had to put in an unexpectedly large amount of time getting the button assignment and controller input working properly. The way buttons had been implemented weren’t up to snuff for working with multiple input devices, so all of those buttons had to be individually refactored. There’s regrettably some more work that will be required there as well.
On the plus side, we now have quick keyboard keys for things like selecting formations, zooming the camera to the next selected ship, quickly cycling between ships, and things like that.
I’ve also been preparing the final list of sound effects we need completed and am almost ready to hand that off to our sound experts at SkewSound.
Bug fixing
We put a fair amount of effort into testing and debugging mining ore and melting ice last month. It all seems to be working as designed now.
We had a case where ore was being mined on a planet with no ore available, and that’s been put to bed.
We also had the opposite case where on habitable worlds ore wasn’t being mined even though it was present, which is now working.
At one point you could try to mine with a Rover fixer — which is not a mining ship. You can still fit a mining laser as a (fairly bad) weapon to the fixer, but you can no longer attempt to mine with it.
We had an issue where the Corp extractor wasn’t mining ore or melting ice which Heru cleared up.
There was an issue where right clicking on an auxiliary was throwing an error which is now resolved.
All ships that should be able to melt ice can do so now.
We did a bit of fine tuning with the gatherer, a shield-equipped mining vessel. First, it would display an ‘abort mining’ action when it wasn’t mining ore. It was also displaying a ‘mine ore’ action when it was mining ore. This was traced to the shield on/off action and both cases are fixed.
Next it was having issues maintaining its direction when mining ore and turning erratically, but that’s been smoothed out now.
Our new rule for formation mining behavior wasn’t working in all cases with the gatherer, so that was adjusted to work properly.
In certain cases the gatherer did not gather ore when it was mining, but that is now working perfectly too.
Lastly with the gatherer, Heru corrected it to properly gather ore from a fixed range instead of a variable range.
There was a case where explosions were not being triggered at the proper place which has been addressed.
I made sure that the game over window appears on all screens.
I also adjusted the pause dialog to appear on all screens.
We had a couple of things that looked like bugs surface when testing events. It turns out we had cases where “faction:” was being used and some where we used “factions:.” While semantically this was correct, it made debugging events unnecessarily challenging. So Heru made a change to our YAML event format to standardize on the word “factions” wherever it was used. Consistency is often the better choice.
Unity is a great tool but can be a little quirky. Sometimes when we make changes to user interface elements in Unity it has an effect on other elements, too. A couple of times last month one or more of our UI elements would disappear, and need to be adjusted as a result.
Similarly, weapon prices vanished briefly due to some adjustments on that dialog.
We also briefly lost the ability to left click select ships in your fleet using the fleet info list.
Sometimes if you had a mission running you wouldn’t be able to start another event. That’s been fixed.
I think I’ve said this before, but you start the game off with no weapons on your battleship. This helps the player understand very early how trade, caches and equipping weapons work. Up until now we’ve been starting the game with at least one weapon on the battleship for testing, but now that we’re getting closer to being finished I’ve removed it to test the early game events. Well, it turned out that if you equipped a weapon after starting, you couldn’t fire it except in self defense! So Heru added functionality to cover that situation.
Heru corrected an issue where abandoning ship would give you a Pact lifeboat no matter what kind of ship you abandoned.
Related to lifeboats, there was a case where you couldn’t perform actions on lilfeboats that has since been resolved.
Lastly, a small issue where the battleship was losing it’s white ‘selected’ color was corrected.
User Interface and Modeling
I spent quite a lot of time working in different resolutions to ensure the game looked as good as possible from 1024×768 all the way up to 2560×1440 (our preferred resolution). First I looked at the placement of dialog windows and various user interface elements and fine-tuned their placement. This went much faster than expected, and I’m fairly pleased with the results. One result of this was that plans had to be reduced from 5 to 4.
The second pass took much more time, and required me to carefully test each icon at various resolutions to ensure consistent display. While I enjoyed doing this quite a lot, I didn’t expect this phase to take as long as it did.
In the third pass I increased the size of the mouse pointer, adjusted some tooltip icons, and changed sizes for ship icons used in different places in the UI from the trade menu to the starmap. I also adjusted font thickness and made some tweaks to the sharpness, color and brightness of specific UI elements.
At this point I’m very happy with the results – here’s a before/after at the lowest supported resolution of 1024×768:
Going over the icons gave me a chance to fix several minor z-fighting issues along the way, too.
Since Heru worked so much on the controller side of things it gave me an opportunity to finally model out the controller button tooltips.
I also created the UI for adjusting controller sensitivity.
I finalized the ship info detail views, making sure that text size, line placement and other details were consistent across all of the different ships. I also adjusted the text on all of the tabs to (hopefully) explain what each ship can do.
Finalizing the ship info detail views also made me rethink how we were displaying faction leader info. I was worried about fitting all the info in, particularly in lower resolutions, and also concerned about consistency. So I updated the UI for the faction leader – it now puts their info in a popout just like weapon information does. That still needs to be implemented.
One of the things we have remaining to do is the dialog for ship scanning. Looking at it with fresh eyes, I didn’t think it was giving the player enough information. I spent a few minutes working within the existing design but it just wasn’t working. Since it hadn’t been started it was a good opportunity for me to refactor the design. The new design features a much larger dynamic view of the ship being scanned and a clearer display of the ship’s stats, weaponry and abilities. I’m much happier with it.
Since Heru was working on our input mapping dialog, I mocked up the UI for that. This went through several revisions as I worked to simplify and improve that very important part of the game.
A lot of my time last month was invested into creating clothing and accessories for the 3d character busts in our game. It was a fun and very interesting challenge to create a unique look for each of the five factions in the game and also come up with quite a few interchangeable parts for each faction that: still felt appropriate for each faction, would also render well in our shader, and would look great at resolutions as low as 1024×768. I’m still working on finals, but each faction now has multiple different models for each of three different accessory types that are randomly mixed and matched. I’ve also begun to increase the number of character busts in the game; we already have a diverse range of ethnicities with a 50/50 gender split but I will be adding even more variety. This will probably be implemented in November.
After playing XO a great deal my current thinking on faction relationships is that that they should go as low as -3 and as high as +2, with hostile starting at -1 and friendly at 1, neutral being only zero. Reflecting this I worked up an improvement to the relationship state UI to show multiple levels of relationship state, in other words, when a faction is hostile, really hostile, or ultra hostile, and mostly friendly or ultra friendly. There’s no difference between them except how far you have to go in order to swing that faction to neutral.
Heru and I agreed to make some adjustments to ordering ships, and I created the UI for that. More details in next month’s update!
I made a minor adjustment to some ship’s origins to fine tune where their trail appears and how they look when hovered in the game.
At long last I traced down an extremely annoying bug where a character’s name would be squashed into the width of one letter. It turns out the culprit was an automatic name generator we had in place. I never wanted the name generator in the first place because it’s too random and doesn’t fit with the idea of different factions, so I ripped it out. Problem gone. We needed to hook up the character names many of you backers submitted anyway, I’ll just be adding a big list of names appropriate to each of the factions instead. I’ve made pretty good headway on that list already.
Events, Narrative, and Balancing
At this point we’re up to 365 events in the game. I expect that to grow to around 400 for alpha, but with such a healthy number of events already in the game I’ve kept my new event creation pace quite low compared to prior months.
Most of my event focus in October was on the opening days of the game. I’ve been creating two types of new events – those that occur before the Harvesters are revealed to the player and the real exodus begins, and the faction-specific events that reveal them. The former events are all about conveying a sense of chaos and impending doom while grounding the player in the basics of the game. The latter events attempt to show the futility of fighting the Harvesters and demonstrating other aspects of how they work.
I’d say I’m about a quarter of the way done with both of those above types of events. I need quite a bit more variety in the opening events, and I only have ‘Harvester intro’ events for the Pact, Rover and Irenic so far. Right now the balance isn’t right, but I’m happy with the pacing and flow of the early events that I do have.
I added a new Harvester tag to my event creation script to speed my work in those events.
I always put quite a lot of time into testing specific events, trying to break them and working through all of their options. Sometimes this gives me ideas how to make a particular event better, or tweak the dialog a bit.
An event called The Fleeing is a good example of that – I added a destination trigger and some other narrative to help explain how the game works using narrative.
Almost all of the balancing work done last month was at the event level in the game. I spent my time making sure that certain events don’t occur too soon, and the right kinds of events are happening early in the game.
I adjusted up some of the rewards and increased the frequency of trade and cache events in the beginning of the game.
I tweaked ore mining and ice melting rates on the upper and lower boundaries of ore and water quality, and decreased fuel use on weapons a bit.
And of course I wrote last month’s update and took screenshots. That takes at least two full days.
In summary we added a substantial amount to the game last month but it ended up taking much longer to implement adding controller code and doing input management than I would have liked. Unanticipated issues with music/sound effects also took longer than they should have.
Having said all that, hopefully you can see that we are really getting there! Thank you so much for you understanding, patience and positive comments. They mean a lot to us.