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.

StarWright - Self Destruct!

Starships blowing themselves up in slow motion is pretty cool.

StarWright - Weapon Ammunition

As in the original prototype, weapons now require ammunition in order to fire. Each weapon can store a small amount of ammunition for itself, but once it runs out, additional ammunition must be delivered by the ship's crew. Individual crew hand-carry ammo bullets from a nearby ammo supply to the weapon.

Notice how in the above screenshot, some of the crew are carrying ammo to the weapons.

The purpose of this mechanic is to further emphasis the importance and role of the crew on the ship, and to make designing a ship for maximum crew efficiency a priority. If the closest ammo supply is too far from the weapon, then the weapon won't be able to fire as often. It will also be important to prevent narrow corridors from getting congested with too much foot traffic. Wider corridors and/or more ammo supplies may help if foot traffic becomes an issue.

StarWright - Attacking

For a very long time it has been possible to command a ship to move to a particular destination by right-clicking into empty space, but there has been no way to command a ship to approach and attack another ship. That has now changed!

This screenshot probably requires a bit of explanation:

• In their simplest form, attack commands are very simple to use and work almost exactly like move commands. Simply left-click on one of your own ships, and then right-click on an enemy ship to command your own ship to fly to the enemy ship and attack it. The computer will automatically determine the ideal distance from the enemy ship as well as the ideal flank to attack from (that is, whether to fire from the bow, stern, port, or starboard sides of your ship). A red circle will display the distance from the enemy ship, and a red ghost of your ship will show you exactly where your ship will station itself relative to the enemy ship.
• As an advanced "power player" feature, it is also possible to right-click on an enemy ship and then, without releasing the right mouse button, drag away from the enemy ship. Doing so allows you to adjust both the attack distance and the direction to attack from. Thin red lines show which weapons can hit the enemy ship. The screenshot above shows an in-progress right-click-and-drag away from an enemy ship.

It is currently not possible to manually adjust which flank your ship will fire from. This feature is hopefully coming soon.

StarWright - Modeless Sandbox

This is just a quick update to show off a refinement I made to the sandbox user interface.

If you remember from my previous blog post about the sandbox, I lamented the separation between the two separate Build and Play modes -- one mode for modifying ships, the other for playing the game. As simple and as easy as it was to toggle between the two modes, it was still annoying to have to toggle between them, and the separation discouraged making very quick design iterations.

My refinement is to eliminate those two distinct modes and instead display the toolboxes for ship parts and asteroids on the screen at all times by default. (They can be hidden by clicking the X and re-shown from the Panels menu.) Ordinarily, if you have no part or asteroid selected, then you can select and command ships like normal. If you want to modify a ship, simply select your desired part on the left and add it to your ship. Likewise if you want to have fun with an asteroid, select it from the toolbox on the right. Once you're done either building ships or placing asteroids, simply right-click to get rid of whatever you had selected and you'll be able to command your ships again, just like normal.

The elimination of the two distinct modes is definitely less annoying and more intuitive too. The few people who I've had playtest the game seem to agree. My only real lament now is that the presence of both toolboxes on the left and right can crowd the screen. It's not too bad on large monitors, and you can hide either or both of them if you want, so it's not a big deal, but I still wish the user interface was less crowded.

I also recently made another important refinement to the sandbox, which is the elimination of "ship grids". Previously, in order to build a new ship, you first had to place an empty "grid" into space, and only then could you put parts and rooms on the grid. In this latest version I streamline the process by allowing you to place a part directly into empty space, without requiring a grid first. To further extend your new ship, simply select a new part and when the mouse cursor is near the ship, the selected part will snap into position.

StarWright - Crew

Starships now have crew on board. As in the most recent version of the original prototype, the crew on a ship are fully automated. Crew currently only have one job, which is to staff the ship's weapons and control room. In the future they will also have other tasks to perform, such as delivering ammunition and making repairs.

In order for a ship to have crew, you need to provide living quarters for them. In the current version of the game, there are two such rooms: A small "bunk" which provides space for 2 crew, and a larger "quarters" which provides space for 6 crew.

StarWright - Fun with Asteroids

I'm in the middle of adding a crew simulation to the game, but I took a break to add asteroids to the existing game. Asteroids aren't very useful except for target practice.

When in Play mode, the toolbox on the left, which ordinarily shows the ship parts available, now shows a few different sizes of asteroids that can be placed into the sandbox. Each asteroid has a randomly-generated shape.

StarWright - CPU Profiling

When programming video games, it's very important to understand how much time your computer's processor is spending in various parts of the game's code. In order to better understand StarWright's code, I added a CPU profiler to my game engine to display graphically how much time is being spent in each section of code.

Here's what that profiler looks like: (Click to see full-size version.)

Each row of text represents a single section of code that is being measured. A section of code may also have a number of "sub-sections", which are indented in the above picture.

The colored bars indicate the "slices" of the game frame that are spent in each code section. You can think of the left edge of the profiler as representing the beginning of the frame, the right edge as representing the end of the frame, and the colored bars as representing the time within the frame that is spent on a specific task.

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.

StarWright - Ship Combat

Combat is of course a major part of StarWright, and I've just finished the major ship-versus-ship combat systems. The mechanics of combat work essentially the same as in the original prototype. Weapon turrets automatically track and fire upon nearby enemy ships. Damaged is handled on a part-by-part or room-by-room basis, where individual parts or rooms can be individually destroyed. Additionally, if the only parts joining two sections of the ship are destroyed, then the ship will be split in two and become effectively two distinct ships.

As in the original prototype, cannons are able to penetrate deeply inside enemy ships, damaging critical systems deep within the ship. The current defense against cannons is to add parts with a high "penetration resistance" such as armor tiles or cannons themselves. While there currently aren't many systems inside ships worth protecting, I plan in the future to have many such systems, such as ammo supplies, power generators, shield generators, engineering bays, etc...

Here's a screenshot showing two "Enterprise"-like starships attempting to assault a heavily-armed space station:

StarWright - In-Game Ship Controls

The original Starship Builder prototype suffered from some terrible user interface choices. It's not that they were stupid, but that they were a product of tacking on lots of features and not being sure about how I wanted the game to play. Now that I have a better sense of what the game will be, I can greatly improve the user interface.

This past week I've been working on the in-game controls for commanding ships. Since I see no need to reinvent the wheel, I've modeled the controls after typical real-time strategy games like StarCraft and, especially, Company of Heroes. Like most RTS games, you can left-click on a ship you own to select it, or drag a box around several ships to select all of them. When you have ships selected, you can right-click somewhere in empty space to order your ships to move there. I've stolen a feature from Company of Heroes, whereby if you right-click and drag you can easily reorient which way your ships are pointing.

The green circle in this screenshot indicates that the starship is selected. The green "ghost" indicates the destination to which the ship has been commanded. The thick green line indicates the path from the ship to its destination.

As in the original prototype, once you have commanded a ship to move to a location, an algorithm will determine the optimal "activation level" for each thruster on your ship. This algorithm I was able to lift virtually unchanged from the original prototype.

StarWright - Steganography

Probably only programmers will appreciate this, but I did something I think is pretty neat today...

For StarWright, my super-awesome spaceship building game I'm making, I added more awesome to how spaceship designs are saved to files. Take a look at this PNG image:



If you download the file to your computer -- and of course have the latest version of StarWright -- you can simply load that PNG straight into the game and it will be fully playable and customizable. I'm hoping this will make ships easier and more fun to share, and it has the added bonus that I don't need to generate an in-game preview of the ship.

There's no fancy image-analysis going on. I'm simply embedding the ship data into the least significant bit of each of the red, green, and blue color channels of each pixel in the PNG (which is 32bpp ARGB). That's 3 bits per pixel, which means a 512x512 image can store about 98KB of data, which is more than enough for the largest ship I currently allow. Since only 1 very-insignificant bit is used per color channel, it's very difficult to see any visual difference. This is a kind of "Steganography" (hiding one message inside another), and Spore and the upcoming game Monaco use the same technique for creatures and custom levels.

The basic process in StarWright works like this:

1. Save the ship layout to a proprietary data format.
2. Compress the data using GZIP. Since the data is highly repetitive, I get about a 20:1 compression ratio.
3. Take a 512x512 screenshot of the ship at 32bpp.
4. Embed the compressed data into the least significant red, green, and blue bit of each pixel in the screenshot. I could use the alpha channel as well but that'd probably be more visually noticeable.
5. Save as PNG! Done!

There are some drawbacks to this method, but nothing really major:

• Save files are much larger than plain compressed text files. But the largest ship I have is still only 116KB on disk.
• Any alterations to the PNG file will almost certainly corrupt the embedded data.
• Theoretically the ship data may not fit in the image, but I can always increase the image size or use more bits per pixel. At first I was using 1024x1024 at 6bpp which was way more than I needed.
• Supposedly embedding already-compressed data inside a PNG will reduce the PNG compression, but I've seen virtually no file size increase vs screenshots without embedded data.

Okay, I'm done nerding out now. ;-)

StarWright - A New Beginning

Well, I'm starting over from scratch.

For a while now I've been working on a game prototype called Starship Builder. In short, it's a "build-your-own starship simulator" in which players design their own starships by placing rooms and parts onto a grid. Players can challenge other players in multiplayer matches to see who can design the best starship. Eventually, players will be able to explore galaxies with the starships that they create. You can read more about the game on my website.

I think that the existing prototype shows a lot of promise (usually when I show it to fellow gamers, the response I get is, "When can I buy this?"). But as high as its cool-factor is, the prototype as it exists right now is deeply flawed, both in terms of design (the user interface is very confusing and too detail-oriented) and programming (the game is being held back by choice of game engine).

So I'm starting over. For now, I'm calling this new version StarWright.

Beginning again from the ground will help me hit reset on the game's design. I will take what I learned from the prototype (the premise is fun and interesting, but the U.I. is terrible, micromanagement is tedious, and player-control of multiple ships is desirable) and build a much more fun game that is much easier to play.

But probably more importantly, starting over afresh will let me correct some major technical issues with the current prototype, most of which stem from the use of the Unity3D game engine. While Unity was I think a good choice for proving out the basic concepts of the game, it has proven to be unable to scale up to the complexity that the game demands. Unity requires that ever piece of code be attached to a game object, and it does not provide control over the main game loop or the precise order in which objects are updated or rendered. Working around those limitations was cumbersome, inefficient, and a lot of work. By switching to my own game engine (dubbed Halfling, it was originally created to power my games Tetrik and Tanky-Tank), I now have full control over the game's code, which will allow me to make a more sophisticated and much more optimized game.

I'm just getting started, but here's a sneak peak at the new ship designer interface:

There's not much to the game yet -- only three parts you can use, and no way to test your ship, fly around, or fight other ships. But I have high hopes for this new version. Throwing off the shackles of the old design and game engine already feels like breathing in a cool breeze atop a mountain. It's liberating.

Now that I'm taking the project more seriously and hope to sell a finished game one day, I probably won't be posting regular playable builds of the game -- just screenshots and maybe an occasional video. That will also save me the hassle of having to make a new build for every blog post I make!