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.

StarWright - Self Destruct!

Starships blowing themselves up in slow motion is pretty cool.

Guild Wars 2: The Advantage of Pay-Once Games

http://www.rockpapershotgun.com/2012/08/31/wot-i-think-guild-wars-2/

‎"The absence of a monthly subscription seems to empower ArenaNet to concentrate on making the game as enjoyable as possible for however long each player chooses to invest."

This is the advantage of traditional pay-once games -- the developer's primary objective is to create a great experience for the player so that they'll pay for the game and tell their friends.

Whereas the primary objective of subscription and free-to-play games is retaining players for long periods of time so that they keep paying more and more small fees. Such games often prey upon frail human psychology and, while addictive, are often less fun, less interesting, and less enlightening experiences.

I'm not saying that the two objectives are mutually incompatible, but it *is* very challenging to create subscription and f2p games with both longevity and per-minute gameplay that is as fun, interesting, and enlightening as pay-once games.

We're still failing more than we're succeeding in the f2p space, but games like League of Legends, World of Tanks, and Team Fortress 2 show that it can definitely be done.

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.

The Conservative<->Liberal Programming Spectrum

Well-known programming blogger Steve Yegge just posted a long but interesting article about the spectrum of programming philosophies ranging from "conservative" to "liberal". Conservative programmers are typically risk/change-averse (often for good reason) and very performance-conscious, while liberal programmers typically favor flexible systems, concise/elegant expressions, and rapid iteration.

I'm definitely a "liberal" programmer (I don't think anyone would ever call me a risk-averse programmer), but I do favor some traditionally-conservative programming practices, though for decidedly liberal reasons. For example:

• I strongly favor static typing over dynamic typing, but I don't believe that static typing is really any "safer" than dynamic typing. The unquestionable advantage of static typing (which the article admits) is that the programming tools are far, far better. And great tools make me a faster programmer.
• I like compile-time checking and static analysis not so much because it makes my code safer (it probably doesn't), but because the more problems (or potential problems) that can be brought to my attention before even running my program, the more time I save.
• I like strong encapsulation, again not because it makes code safer, but because strong encapsulation *usually* simplifies mental models of programs, meaning its easier and quicker to think about the program as a whole. Plus breaking down problems into small, discrete, self-encapsulated parts is just a good problem-solving technique.

Google Fiber

http://fiber.google.com

Google's plan here is brilliant, ambitious, and simple.

Google understands that they can never win against Apple or Microsoft in either hardware or end-user software, so they're playing to their own great strength: online services.

Google really wants to move everyday computing entirely online, where they have the clear upper-hand. But modern broadband simply isn't fast enough to pull that off, and current ISPs have little incentive to make their current services any faster.

So Google has decided to attack the very heart of their problem, and become an ISP itself, providing internet 100x faster at essentially the same price. They're almost certainly taking a huge financial loss with this endeavor, but to them it's an investment. Google might very well become the dominant ISP in the USA, but they probably don't care as long as they spur other ISPs to upgrade their own services.

If Google can make gigabit internet ubiquitous, then they will make the home-and-office hardware and software industries, which are largely dominated by Apple and Microsoft, mostly irrelevant. Our desktops, laptops, and eventually even smartphones will become simple dumb terminals through which we access a plethora of online services, of which the dominant provider will be Google. (And possibly also Facebook.)

I find the prospect of this happening very exciting, and it would probably be the most important development in personal computing since the personal computer. I do however worry that Google, a company which I currently love, could become a big monopoly and use their power to stifle competition. That would be bad for everyone.

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.

WAY wins "Game of the Year" at Games For Change!

WAY has just won the award for "Game of the Year" at the Games For Change festival! We also won for "Most Innovative Game" and were nominated for "Best Gameplay". I'm incredibly proud of my whole team.

Source: http://www.gamesforchange.org/press_releases/games-for-change-awards-culminate-9th-annual-games-for-change-festival-in-nyc/

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.

WAY is a double-nominee at Games For Change!

My game WAY is a double-nominee at the Games For Change festival. We're up for "Most Innovative Game" and "Best Gameplay". Oh, and apparently all nominees are also up for "Game of the Year".

I'm crossing my fingers! Future Walt is amazed that crossing his fingers actually worked and plans to do more finger-crossing in the future's future.

Source: http://www.gamesforchange.org/2012/05/2012-games-for-change-awards-nominees-announced/

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.

WAY Statistics

About a week ago we had an explosion of people playing WAY. We typically had less than a thousand people play in a day, but suddenly that number jumped to over 61,000!

Here's a longer per-week graph:

Also, here's a graph of how many players complete each level:

Our overall completion rate is about 25%, with over half of our players dropping out in the very first level. The average play time is down to 15 minutes from 25 minutes, which I suspect means that we're getting a lot of repeat players.

WAY Fan Art

This is the first fan art that anyone has ever made for any of my games. :-D

Praise for WAY

People have been saying a lot of nice things about WAY lately, so we took some time and compiled a page full of those nice things. That was definitely a feel-good exercise. :-D

Video Game Predictions

Just for the sake of being wrong in a couple years, here are my predictions for the next generation of consoles and videogames in general:

1. The Wii-U will be modestly successful, thanks to the first truly great console MMORPG, which could only exist on Wii-U because of its touch screen's support of sophisticated user interfaces.
2. The next XBox will be released by holiday 2013:
• It will be packaged with a new version of Kinect (duh), which will impress even the most jaded gamers. The games for the new Kinect won't totally suck.
• It will not have an optical drive or any other form of high-capacity removable media.
• All games will be directly downloaded.
• The basic model will have at least a 1TB hard drive.
3. The next Playstation will be released by holiday 2014:
• It *will* come with a Blu-Ray drive... or maybe that will be optional.
• Like the XBox, the basic model will have at least a 1TB hard drive.
• All retail games will be available as direct download. They will still be available for purchase at retail, at least until #4 happens.
4. By the end of 2014, GameStop will be bankrupt.
5. Since "shelf-space" is no longer limited, the $60 price-point for all mainstream videogames will end and we will see prices of console games anywhere between $5-$100 depending on quality, reputation, amount of content, development cost, etc... As a consequence, we will see a broader range of games, the cheaper ones being more experimental and daring. The line between indie and mainstream will be blurred.
6. Since the middleman retail stores have been removed from the equation, developers and publishers will see a bigger share of revenue, allowing the budgets of AAAA games to grow even larger. AAAA games will be even more polished and epic and derivative than they are today.
7. Despite the continued and growing success of social and mobile games, console and AAA games aren't going anywhere and will continue to rake in more and more money.
8. The PS Vita will be the last handheld console, because my phone and iPod touch work just as well (if not better) than dedicated gaming handhelds.
9. There will absolutely be another console generation, probably 2016-2017. The internet is simply not designed to be low-latency and thus OnLive or similar tech will not be viable for core gaming even by then.
10. Big publishers will open their own digital stores for PC, selling their titles exclusively through their own stores. Smaller studios and indies will stick with Steam. It will suck for us consumers, and for Valve, but at least they've finally announced Half Life 3 for 2016 (delayed to 2018, but it will blow you socks off).
11. By 2020 EA will finally realize that nobody wants to play Dragon Age on Facebook. Yes, Facebook will still dominate the social internet.

WAY wins "Best Student Game" at IGF!

Yesterday WAY won the award for "Best Student Game" at the Independent Games Festival! I'm pretty deliriously happy and oh so proud of my whole team.

The IGF is the largest and most competitive videogames festival in the world. We were selected as the top student game from 295 different entries by a distinguished panel of judges, both professional and academic. This is the first win for Carnegie Mellon University, and we're sure it won't be the last. :-)

We are all incredibly humbled and couldn't have made WAY without the support of our many friends, family, and teachers. Thank you so much!!

Source: http://igf.com/2012/03/fourteenth_annual_independent_.html

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:

WAY nominated for "Best Student Game" and "Nuovo" at IGF

Hurrah, WAY has been nominated for both "Best Student Game" and the "Nuovo" award at the Independent Games Festival! Wish us luck!

Future Walt says: Thanks for all the luck, guys! It worked! We won!!

Source: http://igf.com/2012/01/2012_independent_games_festiva_3.html

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 JSON-like proprietary text format. Text is better than binary because it's far more tolerant of changes. This is as far as the old version went.
2. Compress the text using GZIP. Since the text 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!