StarWright 0.8.0 - User Interface Revamp

Yesterday I released StarWright 0.8.0. The main focus of this release was to greatly improve the user interface (or "user experience" to use the trendy modern term) for designing and constructing ships. This is the culmination of the U.I. work that started with 0.7.1 (the ship "info card" in the corner) and 0.7.2 (the separate repair and crew management U.I.s), which I will also talk about in this post.

Let's back way up first, and talk about the original U.I. for constructing ships: At the beginning of time (StarWright's lifetime, anyway), designing starships was done using a user interface that was completely separate from the gameplay:

You'd hop into the "Builder" and design your ship on a grid. When you were happy with your design and wanted to test it, you'd press the "Save & Test" button, which would switch you to a testing game environment where you could spawn enemy ships to test your ship's combat prowess against.

And then I watched a talk by Bret Victor in which he persuasively argued that user interfaces are hampered when the user makes a choice but the feedback from the user interface about that choice is delayed. I realized that StarWright (called "ShipBuilder" at the time) suffered from the same delay in that the player didn't see the effects of their design changes until they actually hit the "Save & Test" button. This was unlike most other "construction" games such as SimCity in which you can immediately see how placing a building effects things like power, water, and roads. And so I decided to merge the ship editor and gameplay environment into a new environment that I called the "Sandbox":

In this new environment you could add a part to your ship (like a cannon) and very quickly see how that new part interacts with the simulation of your ship as a whole (crew running over to operate it) and any problems that it has (crew can't get any ammo to it). (I wrote about this change more extensively in a blog post from way back in 2012.)

This was a really big improvement! Being able to watch a ship operate as it was designed really made learning the rules of the ship simulation much more intuitive, and players felt like they were making much more informed (and successful) ship design decisions.

Now let's fast forward again by a few years (I had a job, okay?) to late 2015, as I was beginning to ramp development on StarWright back up to full speed. Up to this point, there was no real challenge or economy in the game; it was just a free-form sandbox mode where you could build whatever you want. And while creative/sandbox modes in these kinds of games are great (yes, I plan on keeping the "Creative Mode" forever and ever), my ultimate vision for the game was that the player would start with a small ship, earn money by going on missions and defeating enemy ships, and expand their own ship over time.

But this caused a couple of conflicts with how ships were built:

• Adding parts to ships needed to cost money, but the player shouldn't be forced to waste money when they accidentally place a part in the wrong location or if they change their mind halfway through an in-progress design.
• It needed to be easy and convenient for the player to restore a partially-destroyed ship back to its intended design.

My solution to these two problems was to introduce the "Blueprint" mode, which separated a ship's design (i.e., its blueprints) from its current physical condition:

I talk more about the Blueprint mode in another blog post, but to summarize how it solved these two problems:

• Players would make modifications to the ship's blueprints instead of the ship itself. The player could freely modify the blueprints without being charged any money. Once the player was satisfied with their design, they pressed the big "MAKE IT SO" button on the right, and -- voila! -- their ship was updated to match their blueprint design and the appropriate amount of money was subtracted from their funds. (If you're thinking, "But Walt, wasn't being able to immediately see the results of design changes a good thing? Why get rid of that?", then my only response to you is, I wish you were there to remind me of that in Nov. 2015!)
• While a ship could take damage and have parts of it completely destroyed, its blueprints would remain unaffected. If the player wanted to repair their ship back to its intended design, they could just open up the Blueprints mode and click "MAKE IT SO" again.

The first problem I realized that blueprints had was with repairing: While it was definitely A Good Thing that players were able to easily repair their ship back to its original state, I quickly discovered that players (including me) would often do the following:

1. Fight and defeat an enemy, taking some damage and earning some bounty money.
2. Open up the Blueprint mode and design some awesome additions for their ship.
3. Realize they can't afford their new awesome design, and so decide to go earn another bounty.
4. Want to repair their ship, but realize they can't without undoing all their glorious design work!
5. Get really angry.

And so I decided to add a "Repair" option. When this option was selected, pressing the "MAKE IT SO" button, instead of making your ship's physical condition match its blueprints, would make your ship match how it was the last time you pressed that button.

And this is how it's worked for the past few months. All problems solved?

Of course not:

• I realized (again) that players were having a harder time designing their ships because they weren't getting immediate feedback from the game simulation on their design changes. Somehow, in my excitement to make Bounty Mode work, I had forgotten that immediate feedback was A Really Good Thing.
• The "Repair" option next to the "MAKE IT SO" button was both confusing and limiting. Confusing because it was a very important feature that was buried as an option inside the Blueprint mode user interface despite having, literally, nothing to do with blueprints. And limiting because it was an all-or-nothing choice; there was no option to selectively repair only certain parts of your ship.

And so I embarked on my weeks-long journey to fix these two problems...

First up, I decided to dedicate a separate user interface to repairing ships; a U.I. which would be accessed by its own "Repair" button sitting co-equally right next to the "Build" button.

And so I started to work on-- screeeech, halt! ... Nevermind. Instead, I decided to first implement another U.I. feature that I'd been wanting for a while. Even though that feature wasn't really necessary to solve the above problems, its code would be very intertwined with the code for solving the above problems, and it'd take less time to implement it before solving those problems than after. This feature was the Ship Hub:

The general idea behind the Ship Hub was that it'd be the place on the screen where the player would go to interact with their ship in any way. The dark rectangular card shows a silhouette icon of the ship, it's name, and some other basic information. (And the '...' button exposes some lesser-used options that used to be in the super-awkward alt-right-click menu.) Above the informational card would be all the buttons to access various ship features, such as the ship design U.I. and, eventually, repairs and crew. The Ship Hub was released in version 0.7.1.

With the Ship Hub completed and out-of-the-way, I did, finally, implement the new repairing U.I.:

The "Repair Mode" is accessed by clicking the green wrench icon next to the Build button.

The cool thing about Repair Mode is that it shows you exactly which parts are damaged or destroyed with a red wrench icon for damaged parts or a red overlay for missing destroyed parts. Clicking on a damaged or missing part will repair that specific part. Or you can simply click the big "REPAIR ALL" button to fix everything at once!

I'm pretty happy with this new Repair Mode user interface. It's much more easily accessed and prominently displayed, and it is also much more flexible since you can, optionally, pick individual parts to be repaired. Repair Mode was released in version 0.7.2.

Also released in 0.7.2 was a little U.I. for managing your ship's crew:

This shows you your current number of crew relative to the number of crew your ship can carry. And it has three buttons for adjusting the number of crew: The first button adds one crew, the second button fills your ship up to its maximum crew capacity (or as many crew as you can afford to hire), and the third button fires one crew. That's it!

This also wasn't strictly necessary for solving those two big problems, but it was easy to implement and is nice to have. Eventually I plan on having individual crew members with different ranks and abilities, and this user interface will be fleshed out to manage them.

0.7.3 and 0.7.4 were interim bugfix released that I put out while I was working on revamping the user interface for designing ships.

With repairing ships handled via a completely separate interface, I realized that the only major design impediment to letting the player directly add and remove parts from their ship was the risk of them wasting money by making accidental mistakes or backtracking on their design. And then I realized that the only reason this was actually a problem was that removing a part didn't refund the full cost of adding that part in the first place (it refunded 75%). And so I made the decision to refund the player the full original cost when removing a part, and now the player can undo any design change they make without having wasted any money. (I had originally added the 25% "deconstruction" tax as a way to incentivize picking a design and sticking with it, but I think being able to directly modify your ship and freely experiment is worth getting rid of the tax.)

And so with that last design hurdle out-of-the-way, I split ship designing into two separate modes: Direct Edit mode and Blueprint mode...

Blueprint mode

Blueprint mode isn't much changed from how it worked these past few months: You can freely make modifications to your ship's blueprints without regard for cost, and then when you're happy with them, you press the "MAKE IT SO" button. In fact, Blueprint mode has gotten even better, because now it will let you temporarily place blueprints in illegal locations as you plan things out, so long as you fix any problems before clicking "MAKE IT SO".

Direct Edit mode

Direct Edit mode on the other hand is brand new. In this mode you directly add and remove parts to and from your ship, being charged or refunded as you go. (And behind-the-scenes, the blueprints will be kept up-to-date with your changes as well.) It's somewhat more restrictive than Blueprint mode in that you can't make any change that would put your ship into an illegal configuration. But on the flip side, you can see the immediate effects or problems of any changes you make, such as whether crew can access a room or whether a laser cannon has power.

Both modes are accessed by clicking the "Build" button in the lower-left above the ship information card. The Direct Edit mode will be shown by default (although if you prefer Blueprint mode, you can make it the default in the settings), and you can then switch to Blueprint mode by clicking the blue blueprints button that expands out from the build button.

There are some restrictions to when you can use Direct Edit mode that don't apply to Blueprint mode. In particular, you can't use Direct Edit mode during combat or while in debt. In addition, if your ship has any destroyed parts, those parts must be repaired before entering Direct Edit. And if you've made any modifications in blueprint mode, those modifications must be either committed or discarded before returning to Direct Edit mode. (If you open the ship designer and Direct Edit mode is unavailable for any reason, Blueprint mode will be shown instead.) These restrictions are necessary to make sure that you can't make any changes in Direct Edit mode that would break either the Blueprint or Repair modes.

I also took the opportunity to improve the design experience of both Direct Edit and Blueprint modes in some nice ways:

• While in either Direct Edit or Blueprint modes, the background is dimmed and a build grid is displayed underneath your ship. This should make it easier to eyeball distances and also make it more obvious when you're in design mode instead of being able to control your ship.
• The cost (or refund) of making any changes to your ship is shown underneath the mouse cursor.
• The logic that determines where to automatically add doors between parts has been greatly improved, especially when the "Overwrite Existing Parts" option is turned on (as it is now by default). It will no longer remove any doors that didn't actually need to be removed, and it's much smarter and more aggressive about adding doors as new parts are placed. This is the kind of improvement that, if it works well, you won't notice it at all!
• Adding a Crew's Quarters or Crew's Bunk in Direct Edit mode will, by default, automatically hire crew to go along with it.
• And lots of other little improvements that you can read about in the version history.

As always, thanks for playing! And please post whatever feedback you have!

StarWright 0.5.0 - Sounds!

I'm a bit ashamed to say this, but until today no version of StarWright has ever had even a single sound effect. Well it took me a lot longer than I anticipated, but sounds are finally here! (Or should I say hear?) I just released StarWright 0.5.0 which you can download, play, and hear right now!

I had told myself for the longest time that sounds were a lower priority than getting in core gameplay features. I guess that might be true to an extent, but now that I'm playing the game with sounds, I'm really regretting not adding audio months ago, because the game feels much better with sound effects. (And also some accompanying screen-shake effects, which really help to give the sounds some added punch.)

Sound Design

Sounds in StarWright can be grouped broadly into two categories: User interface sounds and gameplay sounds. User interface sounds are easy because they never vary in volume or pitch and always get played whenever the user interacts with the interface. Gameplay sounds on the other hand are much trickier to design and implement because whether they're played, their volume, and sometimes even their pitch depend on what's happening in the gameplay.

Designing gameplay sounds for any game is hard, but StarWright has proven to be by far the hardest sound design challenge I've yet tackled. There are two primary reasons for this challenge:

First, unlike most games where the area that the player can see is relatively constant, in StarWright the scale of the player's view can change dramatically as the player zooms in and out; the player's view can scale from a dozen meters across to a kilometer across or more in a second. What the player hears when zoomed in at 10 meters (the loading of ammo and beeps of controls and charging of lasers) is not what the player should hear at 100 meters (the muted, distant reverb of cannons and thrusters) nor what the player should hear at 1000 meters (the almost-empty yet strangely-beautiful resonance of space).

Many of the more-detailed gameplay sounds (such as beeping controls, loading ammo, and charging weapons) are only audible when zoomed-in near the 10-meter scale; they quickly fade out as the player zooms away. But the louder sounds (such as firing cannons, projectile impacts, and explosions) can be hard at the 100-meter scale as well. However, I wanted these louder sounds to sound more muted and distant when the player is zoomed out, and so each of these sounds is actually authored as two separate sounds; one containing higher-frequency elements that fade out quickly as the player zooms out, and one containing lower-frequency elements that fade out much more slowly. Eventually though, near the 1000-meter scale, no gameplay sounds are audible and the only sound left is the eerie sound of space itself. (Yes, I know space IRL has no sound, but in StarWright it does!)

Sounds don't just fade out as the player zooms out; they also fade out as their point-of-origin moves farther away from the center of the player's view. This works like most games in that more distant sounds are quieter (an enemy shooting you from ten meters away is a lot louder than one shooting at you from a hundred), with the added wrinkle that the distance that a sound can travel increases as the player zooms out the camera. This may seem unnatural, but if the distance didn't scale then the player would either (when zoomed in) be able to hear loudly a lot of sounds from objects they can't see or (when zoomed out) not hear sounds from objects that they can see.

The effect of fading sounds as the player zooms out while simultaneously increasing their audible distance leads to a nice "level of detail" -- that is, when zoomed in, the player hears a relatively small number of higher-pitched, high-details sounds; whereas when zoomed out, the player hears a large number of more muted, less-detailed sounds.

The other big challenge to designing sounds for StarWright is the sheer number of objects that can make sounds. While a typical side-scroller or action game might have a few dozen sound-emitting objects (on screen or near the player) at once, StarWright can have hundreds or even thousands since every weapon, thruster, projectile, explosion, and crew member could be making a sound. And the problem with so many sounds at once (aside from being computationally expensive) is that when they all combine together, too many sounds will start to be like gray noise and the individual details will get lost in the chaos; that's neither pleasant to listen to nor useful information for the player.

My solution is conceptually simple enough: limit the number of gameplay sounds of any single type that can be played at once; the theory being that there should be enough simultaneous sounds that the player won't notice when some don't play while also not having so many sounds that they just create unrecognizable noise.

Gameplay sounds in StarWright can be subdivided into two general groups: One-shot sounds and continuous sounds. One-shot sounds are those that are tied to a particular event happening in the game (such as a cannon firing or a battery being delivered) and are over within a few seconds. Continuous sounds loop indefinitely for as long as some state is true (such as while the control room is powered). The ways in which each of these two groups of sounds is limited differs significantly:

For one-shot sounds, there is a simple limit to the number of sounds of any particular type (such as the sound of the regular cannon firing) that can be played simultaneously. (Usually around 3-5 simultaneous sounds, which seems to be about the point at which players will stop noticing when some don't play.) When a one-shot sound is about to be played, the game checks how many other sounds of the same type are playing, and if the maximum number is already reached, it simply doesn't play the sound.

Continuous sounds are a bit more complicated. Any particular type of continuous sound is typically limited to only 1 playing at once. But unlike one-shot sounds, once the limit is reached, any additional continuous sounds will increase the volume of the currently-playing sound. For example, two thruster rumble sounds playing at 0.5 volume will get combined into one thruster rumble sound playing at 1.0 volume.

Sound Implementation

One of the biggest reasons that it took me so long to release 0.5.0 is that I almost completely rewrote my audio-playing code.

StarWright is based on the same codebase that I originally created for my game Tanky-Tank almost a decade ago. At the time, the best API for playing sounds on Windows was DirectSound. However, in the many years since, DirectSound has been obsoleted by the much-more-modern and well-maintained XAudio2 (and on newer systems, DirectSound is actually emulated on top of XAudio2).

When I started working on sounds for StarWright, I started with my old DirectSound-based code, but I quickly ran into some nasty race conditions that would cause crashes in the above-discussed sound-limiting code. These race conditions were going to be very difficult if not impossible to work around, and so I chose to spend a few days rewriting all of my audio code to use XAudio2 instead of DirectSound.

This rewrite went relatively smoothly, except that I found a few bugs in SharpDX, the C#-language DirectX wrapper I use. I spent at least a day tracking down and then fixing those bugs in SharpDX. (But on the bright side, I had my first-ever GitHub pull request accepted to fix those bugs!)

Screen Shake!

The greatest lesson I've learned in my years as a game developer is that every game is made better by adding screen shake!

While this may be a bit of an exaggeration, it's true enough for StarWright.

You may notice while playing that a lot of explosions and firing sounds are accompanied by a subtle (or not-so-subtle) screen shake effect. They started as kind of a silly experiment but they really added a great sense of weight and power to the louder, more explosion-y sounds. When you get hit by a Large Cannon, it feels quite impactful, and a lot of that has to do with the accompanying screen shake.

Screen shakes work a lot like sounds in the sense that they get weaker as the player zooms out or as the origin gets farther from the center of the screen. (And yes, that distance-to-center is scaled by the zoom, just like sounds.) But unlike sounds, there is only one type of screen shake, and so the magnitudes of all the currently-in-effect screen shakes get added together to determine the final amount by which the screen is actually shaking.

StarWright - The Sandbox

Wow, it's been over two months since I last posted about StarWright! But I have been working on the game. In fact, I've been working on a very important change that should make the game much more accessible, understandable, and fun.

A few months ago I watched a talk by Bret Victor called "Inventing on Principle". In it, he talks about and demonstrates a few of his software programs he's created. A common principle of all the programs he shows is that they provide immediate feedback. For example, he demonstrates a scripting program in which he has created a prototype for a platform game. The left side of the screen contains a running game simulation, and the right side of the screen contains the game's programming code. Unlike most old-school programming languages (in which the author writes the code, compiles the code, and tests the code as three separate steps), as Bret modifies the scripting code, his changes immediately effect the game running on the left, so that as he modifies, for example, the gravity in his game world, he instantly sees the character fall faster or slower (or even upwards!) as he adjusts the gravity value.


Bret Victor - Inventing on Principle from CUSEC on Vimeo.

The key here is that all his changes have an immediate effect on how the game is played. This greatly speeds the design process, because every time you change a value, you can immediately see the result. And just as importantly, it makes, in his case, the scripting process much more intuitive, because our human brains are much better at connecting a cause with its effect if the effect happens immediately after the cause, instead of, say, a few minutes later.

I found his talk very inspirational because it made me realize that the "ship designer" user interface that I had created was born from an "old-school programmer" mindset. In the previous version of the ship designer, the player first "designed" a ship, then saved the ship, and then tested it in a separate simulation environment. The problem was, of course, that you couldn't tell what effect a design modification would have until you manually switch to the testing environment. The solution, I believe, is to combine the design interface with the testing environment, so that the player designs their ships directly in the testing environment and can see the immediate impact of, for example, adding that extra thruster.

Merging these two environments together was certainly not trivial. Allowing ships to be updated instantly in a live environment was a challenge, and keeping the nice U.I. features of the designer, such as undo/redo, was a bigger one.

I've dubbed this new merged design/testing environment "The Sandbox". Here are a couple screenshots of what it looks like currently:

Upon first glance, the top screenshot does look quite similar to the old designer interface, which has a similar menu bar at the top and a similar "parts toolbox" (albeit with more parts) on the left. But there are a lot of very nice additions to the old interface:

• The "Build" and "Play" buttons underneath the menu bar allow you to toggle between the build/design mode (which allows you to modify any ship in the sandbox) and the play/control mode (which allows you to control any ship in the sandbox as if you were playing a real game).
• There can be any number of ships in the sandbox, and every ship is a live simulation. Added a couple thrusters to your ship and want to see how it flies? Just switch to Play mode and fly it around! Not quite happy with the result? Switch back to Build mode and add another couple thrusters.
• Any previously-saved ship design can be added into the sandbox by loading it from the Ship menu.
• To create a new ship design, you plop down a new "grid" anywhere you want, in which you can start placing parts for your ship.
• To modify an existing ship, simply go into Build mode, select the part you want, mouse over the existing ship, and click where you want the part to go.
• You can pause or resume the game simulation at any time using the control in the upper right. It's often easier to modify ships while paused. Unpause and the simulation will instantly resume with your new edits.

It's not perfect -- for example, I'm not thrilled with the hard separation between Build and Play modes -- but it's a huge step forward, and the technology behind this could allow me one day to expand the sandbox into a full-blown live level editor.