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
Friday, January 13, 2012
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.
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.
Friday, January 6, 2012
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:
There are some drawbacks to this method, but nothing really major:
Okay, I'm done nerding out now. ;-)
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:
- 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.
- Compress the text using GZIP. Since the text is highly repetitive, I get about a 20:1 compression ratio.
- Take a 512x512 screenshot of the ship at 32bpp.
- 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.
- 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. ;-)
Thursday, January 5, 2012
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!
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!
Subscribe to:
Posts (Atom)