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.