StarWright 0.7.0 - Ion Beams!

Today I released StarWright 0.7.0!

This latest major release adds the 'Ion Beam Emitter' weapon:

The Ion Beam shoots an extremely powerful (and power-hungry) beam of ion energy that will quickly rip holes in enemy ships. It is currently the most powerful weapon in the game in terms of how much damage it can do every second, and it's particularly effective at sawing ships into pieces.

But as powerful as the Ion Beam is, it does have some key weaknesses:

1. Unlike the other weapons currently in the game, the Ion Beam Emitter is so heavy that it can't be mounted on a turret and thus must be fixed directly to the ship's hull. This means that the ion beam can only shoot in a straight line (as determined by which way the ship is facing), and thus is very difficult to aim with any precision.
2. Firing the ion beam uses a lot of power very fast. If you want to keep the ion beam active for more than a few seconds, you'll need a lot of power being constantly delivered to it.
3. Unlike the other weapons, the Ion Beam Emitter is very weakly armored, making it a potential Achilles' heel through which enemy fire can reach the inside of your ship.
4. While the Ion Beam Emitter is only two spaces wide, it is four spaces deep, three of which cannot be traveled by crew. This may force you to re-think your ship's layout and cause issues with ammo and power delivery to other systems.

Please feel free to download the game and post your feedback!

StarWright 0.6.0 - Shields!

Today I released StarWright 0.6.0, which (in addition to a handful of other improvements) features the game's first active defensive system: the Shield Generator!

Until today, the only defensive additions you could make to your ship were the lowly armor tiles. Armor tiles are useful for protecting the innards of your ship from enemy fire (and especially from penetrating cannon rounds), but, since weapons and thrusters have to be placed on the exterior of your ship, armor was a limited use in protecting those kinds of systems.

The Shield Generator changes that, providing protection for your ship's exterior, but at a hefty cost in credits and power. As you can see in the above screenshot, the shield generator (the purple room next to the big cannon) projects a curved force field in a 90-degree arc in front of your ship. This force field blocks all incoming enemy fire attempting to pass through the arc, while allowing your own shots to pass through unimpeded.

Of course, as powerful as the shield generator is, it's not without some serious drawbacks to prevent it from being imbalanced:

• The shield only protects against shots passing through its limited 90-degree arc, meaning that, without extra shield generators, you could be flanked from the side where the shield won't protect you.

• While the shield blocks incoming weapons fire, it does not actually prevent enemy ships themselves from passing through. So if an enemy ship gets close enough that its weapons fire from within the shield's arc, then the shield will do nothing to protect you.

• Shields use a lot of power while operating. Not only is there a substantial per-second power drain just to keep the shield operating, the shield also loses power quickly as it absorbs enemy fire. And once a shield generator runs out of power, its protective force field will shutdown until the generator can be fully re-powered, leaving a sizable window of opportunity for the enemy to destroy the shield generator or the other systems it was protecting. Keeping a single shield generator powered during an an enemy attack can require many crew working hard to carry power from a nearby reactor or power storage.

• The shield generator itself is very weak and is easily destroyed once its force field shuts down. This leaves a potential weak point in the perimeter of your ship through which enemy rounds can penetrate and damage your internal systems.

One mechanic not yet implemented that I'm considering adding is heat buildup. The potential reason for this mechanic is that it's theoretically possible for a ship to have so many shields and enough crew and power to keep them active that you'll never be able to bust through; and if your ship also has impenetrable shields, that could cause a stalemate. A potential solution to this kind of stalemate is to, as the shield takes enemy fire, have it build up more and more heat until, eventually, the shield generator either deactivates or maybe even explodes.

I have not added this heat-buildup mechanic because I don't want to make the rules for shield generators unnecessarily complex and less intuitive unless I'm absolutely sure that they're needed. If you find that you're getting into these kinds of stalemates while playing, then please let me know!

As always, I encourage you to download StarWright and post your feedback!

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 0.4.0 - Laser Blasters!

Today I released version 0.4.0 of StarWright. The big feature of this release is a new weapon: the Small Laser Blaster!

The Small Laser Blaster is an energy weapon that fires pulses of raw energy. Unlike the cannons, the laser blaster draws its power from plasma batteries instead of using ammo that has to be manufactured elsewhere. Compared to the cannons, the laser blaster deals less damage but has a higher rate of fire and is considerably more accurate. Its rounds also cannot penetrate inside enemy ships, unlike the cannons, making it more effective at destroying perimeter systems than interior systems.

Related to the addition of laser blasters, the player now starts with a new class of ship, which I dubbed the Model-1. The Model-1 is a bit smaller than the previous starting-ship, and instead of having two Regular Cannons it has two Small Laser Blasters. I made this change to reduce the number of game mechanics that the player has to learn and understand at the beginning of the game; laser blasters use no ammo, and so the player only has to understand the power mechanic instead of both the power and ammo mechanics. Also, because laser blasters are more accurate than the cannons, new players will be frustrated less by missed shots.

I have also made some major balance & pacing adjustments in this release. First of all, the damage dealt by all weapons has been greatly increased (cannons do more than twice as much damage); a change I made to increase the pace of combat, which I felt was feeling sluggish. Also, the thrusters and the Ammo Factory both use power much more rapidly, which, combined with the power-consuming new laser blasters, makes balancing power usage and providing sufficient reactors & power supplies much more important.

Go ahead and download it now! I welcome all of your feedback!

StarWright 0.3.0 - New Art!

Which much relief, I've finally released version 0.3.0 of StarWright! (Which you can download here.) This release contains a handful of balance changes and, much more exciting, completely revamped art for the ship interiors.

The new art is much more detailed and attractive than the old "art" (which was really just quick "programmer art" sketches). Most of it is even animated! While I don't consider this art to be "final" and I intend to eventually have it replaced by a professional artist, I think it's good enough for (what is currently) a free game. Even so, I welcome your feedback on it if you have any!

Here's a (rather rough) gameplay video featuring the new art:

And a handful of screenshots as well:

StarWright 0.2.0 series

Since I last posted, I have released not one, not two, but nine new builds of StarWright!

Most of these updates have been to fix bugs that people have found. (Indeed, the game is feeling *much* more stable than 0.1.0 did; there are, literally, no known bugs right now.)

One of those nine new builds was 0.2.0, which includes not just bug fixes but also a handful of other improvements. Here's a summary of the juiciest bits:

• When a part is destroyed, it no longer spawns one structure piece occupying the entire area of the destroyed part. It now spawns one structure piece per tile, each of which can be destroyed individually. This looks better than stretching the structure graphic over the entire area of the original part, and it feels less weird as well. It also paves the way for some future features I want to add that relate to being able to watch a ship build to your specifications rather than it updating instantly.

• Probably the biggest usability issue of the previous versions was that, in order to target a specific part of an enemy ship, you had to hold the alt key while right-clicking on the part you wanted to target. This was not intuitive, and the only way you could figure it out was either accidentally or reading the online bullet points that substitute for not having a manual. So now you no longer have to hold the 'alt' key to target a specific part. Simply right-click to target an enemy ship, and then right-click again on a specific part to target that part.

• In order to destroy an enemy ship in the regular Bounty mode, you now only have to destroy its Reactor instead of both the Reactor and Control Room. I think that it was confusing having to destroy both, and players have told me that they find the reactor a more naturally explosive target. Plus, only having to destroy the reactor makes taking out the control room first a more interesting decision.

There's tons more changes and fixes, almost all of which I list in the patch notes.

I'll leave you with this screenshot of one of my favorite ships I've made:

StarWright 0.1.0 - Bounties & Blueprints!

At long last (more than a year and a half!) I finally have a brand-new version of StarWright available for you to download and (hopefully!) enjoy, and it's a doozy of an update: StarWright 0.1.0. I consider this the first "non-prototype" version of the game, since it now has some amount of actual challenge and progression.

The changelog lists most of the improvements since the last prototype version, but I'll outline here the biggest new features...

The first big feature is what I call Bounty Mode. Just start up the game and hit the New Game button. You'll start the game with a small ship just like this one:

You start the game with 5000 credits, which if you want you can immediately use to make some upgrades to your ship, though you won't be able to afford much more than a cannon and another couple crew.

In order to earn more credits, you'll need to fight and defeat enemy ships. They're listed under the BOUNTIES in the top-right along with the reward for defeating each ship, and there will also be an arrow pointing in the direction of any enemy ship off-screen. Many of the bounties you may see will be too difficult to defeat without upgrading your ship first.

Once you defeat an enemy ship (specifically, by destroying its Control Room and Reactor), you'll earn a substantial credit reward, which you should use to repair any damage to your ship and, if you have any credits left over, make further improvements to your ship such as adding more cannons, thrusters, and crew.

In order to make upgrades to your ship (or even repair it), you'll utilize the other big feature: Blueprints. Click on the "Blueprints" button in the bottom-left corner, and you'll be presented with a U.I. that looks something like this:

(This screenshot is from much later in the game after the playing has already upgraded their ship many times.)

When this U.I. is displayed, you're not actually modifying your ship itself; you're modifying its blueprints. The cool thing about blueprints is that you can edit and tweak them as much as you want at no cost, only paying the required credits once you're actually happy with your design and want to commit to it. And the other cool thing about blueprints is that, if your ship takes damage and has parts of it destroyed, the blueprints are unaffected, making it easy to restore your ship to its intended design.

When you're satisfied with your design and want to commit to it, simply press the MAKE IT SO button in the bottom right. As long as you have enough credits, your ship will be updated to match the blueprints, and the required funds will be deducted from your account.

Once you've upgraded your ship, you can fly off and attempt to defeat one of the enemy bounties:

Simply right-click on the enemy ship to attack it. Hold the alt key and right-click on a specific part of an enemy ship to concentrate fire on that specific part. (I recommend usually taking out the weapons and ammo supplies first, unless its Control Room or Reactor is especially vulnerable.)

The enemy ships will try their best to shoot you from their best side and will occasionally maneuver to hit you from another position. If you disarm them, then they'll try to run away, so you may want to consider taking out their engines or Control Room to prevent that.

And lastly, we have to say a sad goodbye to an old feature that I have decided to remove to make developing the rest of the game easier.... Goodbye, multiplayer. :(  I removed multiplayer because its presence was making the game's code far more complicated than it otherwise would be and was greatly slowing down the development of the primary singleplayer mode of play. It's possible that some sort of multiplayer "my ship versus your ship" mode will return in the future, but for now I've decided to remove multiplayer from StarWright.

Please feel free to download the game. I welcome all of your feedback!