StarWright - Doors, Doors, Doors

Recently I finished an artistic revamp to StarWright's visuals. One of the most important improvements is the addition of a separate layer of walls that is rendered above the crew on the ship. This gave the feeling of actually viewing a cross-sectional floor plan of the ship, which was sorely missing in earlier versions. But the one big oddity with that revamp was that the crew could still walk between the walls, which was definitely weird.

Now, finally, ships in StarWright have walls that crew can't move through, and of course by necessity, doors in the walls!

The player may place those white double-sliding doors in any legal wall locations (some are blocked). Once a wall has a door in it, crew may freely move through the wall. As in a lot of space fiction (Star Trek in particular), when a crew member walks up to a door, the door will automatically slide open to let them through.

From a technical standpoint, implementing doors and walls was much trickier than you might initially suspect, for a handful of reasons:

• The pathfinding system was previously unaware of the presence of walls between rooms, and making it "wall-aware" required a significant retrofit.
• The pathfinding system previously assumed that the entire ship was contiguous -- that is, it assumed that it was possible to get from any location of the ship to any other location of the ship. Additional fixes were required to remove this assumption.
• I didn't want to have to update every wall sprite with every possible door location, because that would have added many times as many wall sprites. Instead, I had to devise a way for the doors to "replace" the particular section of wall that they occupy, but no other parts of the wall. To do this, I render a rectangle representing the door sprites to a special off-screen "stencil" buffer. Then when I render the walls themselves, ever pixel of the wall gets checked against that stencil buffer to make sure there's no door at that pixel.
• Every door sprite has animations to open and close as crew walk through. Unfortunately, doing potentially hundreds of simultaneous sprite animations on the CPU can be slow, so instead I devised a special vertex shader to handle the sprite animation on the GPU. When an animation is triggered, such as the door is opened or closed, the CPU sends the vertex shader the information it needs to render the door animation, and then the CPU never has to worry about the animation again until a new animation is triggered.

StarWright Logo

I made a logo for StarWright using the in-game ship editor, mostly just to show off how flexible the ship editor is.

StarWright - Better Art

I've been working for a while to revamp most of the ship art in StarWright. While I'm certainly no great artist, or even a good one, this new art is definitely much better than before, primarily because it gives the sense that you're looking into a cross-section of a ship as the people run around inside. This was a feeling that was missing from the old art, and the game is much better for having that feeling.

A key part of the new art is having clearly visible walls that separate the various rooms. There are no doors yet, but when crew walk from room to room they walk underneath the walls, which gives a much better sense that they're inside the ship.

The new art is not just aesthetic, though. It serves some practical purposes too. The lighting color lets you know at-a-glance what kinds of systems you're looking at, even when zoomed out (red for weapons, orange for thrusters, tan for hallways and crew). The presence or not of colored lighting also indicates whether that room is operational (a dark gray cannon tells you that it doesn't have any crew operating it). And the number of ammo bullets loaded into a cannon tells you how many bullets that cannon needs to fire.

StarWright - Micro Commands

"Micro commands" are special commands for power players that allow players to micromanage the behavior of their ship's crew and systems. The only current use for micro commands is to command your ship's weapons to focus-fire on a specific part of an enemy ship.

A micro command to focus-fire on an enemy ship's part is issued by holding the alt key and right-clicking on the enemy part. Additional micro commands can be queued up by holding shift in addition to alt while right-clicking.

StarWright - Better Commands

Players have for a while now been able to give both move commands and attack commands to ships, but until now haven't been able to queue up multiple commands or tweak commands already-given. These two new features really help make commands more flexible and useful.

Queuing up multiple commands to be executed in sequence is easy. Simply give the first command and then hold the shift key while giving each additional command. It looks like this:

Adjusting an already-queued command is also pretty easy. While holding shift, rotator and mover widgets will be displayed. Simply click and drag on one of the four arrows to rotate the ship, or click and drag the center widget to move the ship.

This also of course works for attack commands too. Clicking and dragging the center widget will adjust the distance and direction of attack. Clicking and dragging one of the four arrows allows you to choose what flank your ship will fire from, which was previously not able to be manually set.

StarWright - A Slicker Sandbox

A few posts ago I talked about the new "modeless sandbox" user interface. It was nice because it didn't require the player to manually switch modes between building ships and playing the game. Unfortunately, as I pointed out at the time, having on the screen at the same time the full U.I. for everything you might want to do made the screen feel quite crowded, and it has become apparent to me that, unless I reorganize the user interface for the sandbox, it will only continue to become more and more crowded.

What I'm presenting here is what I think is a visually clean, usable compromise between not having modes and not having everything on the screen at once.

You could certainly argue that what I've done here has simply re-introduced distinct modes (and added 2 more), and from a strict word-definition standpoint you'd be right. (You could also rightly say that I never really eliminated modes entirely in the first place. You'd be right there too.)

But the new mode interface is different from the old mode interface in presentation, organization, and efficiency. I steal shamelessly from games like Sim City and software like Photoshop that organize tools into a handful of high-level categories and then show the individual tools in the category once the player opens the category. So in a sense, these new modes feel just like tools in Sim City or photoshop. And this re-categorization really allowed me to minimize the amount of U.I. on the screen during normal play, which keeps the game from feeling claustrophobic.

In the screenshot below there are four buttons stacked vertically on the left, each activating a single "category" or "mode". The first button, highlighted below, is the default mode. It's called the Command Tool, but it serves exactly the same purpose as the Play mode did previously -- when selected, you can click on and command ships like normal. As the default tool, clicking the right mouse button while using any other tool will return you to the command tool. This is an important feature borrowed from the modeless sandbox version, because it eliminates half the nuisance of switching modes.

In this next screenshot, the Build Tool is selected. While selected, a sub-menu is displayed from which the specific desired part can be selected. While the Build Tool is selected, it works just like the old Build mode from the original sandbox U.I.

Here I show a brand new tool, the Ships Tool. In prior versions of the sandbox, if you wanted to add a previously-designed ship into the sandbox, you had to open the Ship menu, click the Load button, and then select the ship from a dialog. In this new version, all of the previously-saved ships are put into the Ships Tool. Simply select the Ships Tool, select the ship you want to add, and click where you want it to go.

And lastly we have the Doodads Tool. Right now the only objects it contains are the asteroids, but eventually it could contain other objects such as worm holes, salvageable resources, or gas fields.

StarWright - Multiplayer! (and saved games too!)

WOW, it has been a very long time since I last posted about StarWright! To a great extent my new job has been keeping me quite busy, but also I've been working on the biggest new feature yet...

Multiplayer.

Adding multiplayer play to StarWright has been a huge task, as anyone who has ever added multiplayer networking to a previously-singleplayer game can tell you. Every core mechanic of the game, from damage and destruction to crew pathfinding to command and control, had to be overhauled to be multiplayer-capable. Add to this the creation of a custom UDP communications protocol and a programming library for "remote procedure call", both of which are critical to the multiplayer capabilities of StarWright.

To make matters even more difficult, my belief is that ever single mode of play in StarWright should be multiplayer-capable. That even includes the sandbox mode, which is the only real way to play the game right now. Making the sandbox multiplayer-capable as well meant that all the systems related to designing ships, such as adding and removing ships, adding and removing parts, and undo/redo, had to work over the network as well.

Oh yeah, I also want other players to be able to drop in and out of the game whenever they want. No pre-game lobbies, except for certain kinds of competitive matches. The host just starts a game, checks a box allowing other players to join, and then other players can hop right in. This means that the host computer must be able to send the entire current state of the game whenever a new player joins, which is its own big system unto itself.

On the bright side, sending the state of the game to another player essentially amounts to creating a save file of the game and sending it to the other player. So even though drop-in-anytime was a big feature to implement, I basically got a save-game feature almost for free. The code that handles networked state sending is about 95% shared with the code that handles game saving, even though networked state sending and game saving write the data to different formats (networked state sending uses a compact binary format to reduce bandwidth usage, while game saving uses a custom text format which is more tolerant of game version changes). This is thanks to a robust multi-format serialization library that I developed for my game engine, Halfling.