Happy holidays and merry Christmas to all you fine rebels! I hope you’re having a wonderful break and that 2018 is an amazing year for you. 🙂 Spry Fox is pretty much shut down right now, so I took advantage of the peace and quiet to write this summary of all the major changes we made before going into hibernation. My for the length of this post; it’s been awhile since our last one and the notables have piled up. Let’s go through them categorically:
Quests!
Our new, enhanced quest system is pretty far along now. We’ve added more definable requirements, so quests can be more selective about when you get them (automatically) or can accept them (when we have quest givers). And we’ve added more configurable goals and parameters, so we can make more interesting quests soon. (Class progression quests, for example!) Also added more possible reward types. And lots of other details that I don’t want to bore you with! TLDR: we don’t have the budget to build a quest system as rich as you might expect to find in a game like World of Warcraft — and I’m not sure we’d want to even if we did — but this is getting us a few steps closer to that and farther from the dead-simple system that has defined SBA up till now. Feels a bit like growing up.
Alternate class controls!
If you’ve been following our weekly livestream, then you know that we decided to experiment with adding mouse/keyboard and twin-stick gamepad controls to see if they’d work in the SBA universe, with the hope (assuming the experiment was successful) that we could add a bunch new player classes to the game that use these controls! Think helicopters, flying humanoid mech units, etc. The long story short is that it has gone surprisingly well. 🙂 The new controls don’t feel as OP as we feared they would (and to the extent they are, we can easily compensate by lowering player DPS or health a bit.) More importantly, the controls feel good and aren’t seeming like they’ll be too expensive to support (i.e. they don’t cause headaches for our auditing system.) This is all pretty exciting to us! Our plan is to convert the Walker and Paladin into classes that use these new controls and see how that feels, and if it feels good, we won’t convert any other classes, we’ll just make some new ones!
New PVS system!
We’ve been working on optimizing one of the core networking foundations. We’ve rebuilt a data structure that manages which entities each game client is allowed to see (an entity is a movable thing, like an enemy unit, or a building). We have thousands of entities running at any given time, but only dozens are actually onscreen or close-to-onscreen for a particular client. Those are the Potentially Visible Set.
Steambirds has many criteria for determining whether an entity is Potentially Visible or not. For example, most enemy visibility is based on a fixed radius per client (how far you can see) combined with a per-enemy radius (how big the enemy is). Most enemies have a small radius, but we’ve extended the radius for big encounters, like Meowza. Another example: when an enemy drops loot for you, each specific item is soulbound, and therefore only visible to your client. Your loot’s information is completely hidden from other clients.
One big performance problem the old system faced was that it compared every enemy to every player, every frame. That scales nonlinearly — if you have twice as much stuff it’ll take four times as long. The new system uses a spatial database to limit this complexity, and at the scale we’re targeting, it’s more than 10x faster at generating the per-client PVS lists.
Another optimization we’re able to do now is to proactively send full unit fields to the client when units become visible. In the old system, it would send partial fields for every unit every frame, using a type of delta encoding, forcing the client to request the full fields from the server for units that it hadn’t seen before, which added a full latency roundtrip. Plus, it was throwing away a bunch of bandwidth because the client would usually receive several different updates for the unit while waiting for the full fields, and it would have to ignore them. Now the server sends the full fields right when the client needs them. The visible result is that if you’re flying quickly, you should see less pop-in of enemy units on the edge of the screen.
Lastly, due to the way the new system works, it’s now possible to batch and throttle more aspects of entity management than ever before. We used to send a lot of tiny individual messages, and now those are packed up into big lists. We can choose to send the entire list if the bandwidth quota is available, or we can choose to break it up into smaller lists to respect a limited bandwidth (or to make a huge event more manageable), though this will come at the cost of reduced fidelity at the client for a subset of units. We even do extremely cheap compression to squeeze a few more list items into each message.
In sum, we’ve rethought the PVS system, making it significantly more efficient, and more powerful, to accomodate our future needs. This should net some real performance wins and/or let us allow a substantially greater number of players into a single server if we choose.
And last but not least, content updates!
- Improvements to Jinn: Made the shielded states more coherent, improvements to existing attacks, minions no longer self-destruct, updated scripts to make it run a little smoother
- Improvements to Ambassador: New phase 3 that focuses more on micro-dodging, added warning to respawn so it’s less punishing
- Minor changes to Kai: Guided bombs are stronger, homing stars during vulnerable state come out more frequently from boss
- Added elemental weakness/strength to Kai, Jinn, Rei, etc.
- Extended vulnerability states to make certain bosses less punishing on smaller groups of players (per Zem’s request)
- Added names to a lot of boss minions
- Added names and descriptions to the Merlin’s bullet wipe items (“Wiper”)
- New T10 arena dungeon in the works!
- Changes for blog: new art for the noble estates and the imperial city