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.