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.

The Hobbit @ 48 FPS

I saw The Hobbit in 48fps 3D today. The movie itself was enjoyable but too long and not nearly as good as the original movies.

But what I really want to talk about is what it was like to watch a 48fps movie. I'm generally pretty positive about the experience, but not completely:

• The film feels extremely crisp and raw. By that I mean you pick up every detail in the actor's expressions, and you notice every imperfection in the motion of the camera. It feels like a veil has been lifted between you and the actors, and that you're right on set with them. Double the framerate means that your brain can pick out double the details. In many ways it felt a lot like watching live theater.
• It took me about half an hour to stop being conscious of the increased framerate. After that it seemed pretty natural, with some exceptions.
• There were a handful of shots of very simple things that felt oddly *fast*. For example, Bilbo closing a chest or picking up a quill pen, and I wanted to shout at him to slow down. Mostly that was at the beginning, so perhaps I just got used to the speed. I found the timing of some cuts to feel awkward at first, but quickly got used to it.
• I thought that the high framerate made the 3D somewhat easier to watch. I usually feel slightly strained when starting to watch a 3D film, and I did not get that at all.
• I did not feel at all queasy as some people have reported, although I'm not very susceptible to that kind of thing.
• I thought that 48fps made both foreground elements and long shots absolutely stunning. Also I really loved all the silky-smooth, slow-motion battle shots.
• I've heard some people complain that it makes the CG look bad. Personally I didn't think that the CG looked any worse than CG normally does.
• Some people have complained that 48fps makes the sets look like sets, and I found this to be true in many scenes. It seemed to me that this was worst in scenes with a high range of depth -- that is, scenes with both near foreground elements and farther middle-to-background elements. The foreground elements look absolutely terrific, but I hypothesize that the 3D technology just can't give the farther elements enough depth to feel right, and so the combination of insufficient depth combined with very high detail makes the backgrounds feel like sets. I'd be really interested to see how the movie looks at 48fps in 2D, but there's no such version of the film right now.
• 48fps certainly gives a sense of hyper-realism, but I'm not sure that's appropriate for a movie like The Hobbit. I can see it being really spectacular in a movie like The Hurt Locker where you really want a strong feeling of realism, but at times the realism felt out of place in The Hobbit. This was most prevalent in scenes with real sets, such as those in Hobbiton. I wonder whether additional post-processing to make those scenes feel more fantastical would have been appropriate.