Have you ever thought Tetris(R) was evil because it wouldn’t send you that straight “I” brick you needed in order to clear four rows at the same time? Well Tetris(R) probably isn’t evil, but Bastet certainly is. >:-) Bastet stands for “bastard tetris”, and is a simple ncurses-based Tetris(R) clone for Linux. Unlike normal Tetris(R), however, Bastet does not choose your next brick at random. Instead, Bastet uses a special algorithm designed to choose the worst brick possible. As you can imagine, playing Bastet can be a very frustrating experience! — http://fph.altervista.org/prog/bastet.shtml

That is the description of Federico Poloni‘s Tetris clone, Bastet. I first played Bastet over a telnet session to some person’s machine. In November of 2007 I started work porting it from its C code implementation to ActionScript 3.

I ported it for fun and because I didn’t have a Linux system handy on which to play Bastet. This version should not be viewed as a full game, as it isn’t. The controls will suck, it will give you several of the same piece in a row, it may not work at all and it definitely won’t be fun.

I have recovered the source code and made some changes to it. The controls should work a little bit better and it now tells you your score. Also, the debug text is removed.

Here is the result (instructions and more info are below):

Instructions are simple. Arrow keys left and right to move your tetronimo left and right. Up and Space to rotate your tetronimo. Down to move the tetronimo down. Pressing R will restart the game. As I said, simple. Standard Tetris fare.

The catch, though, is that the game looks at your playing field and determines which piece you will probably want most and then … denies it to you. Score keeping is not implemented. The text you see at the top is some of the debug data used for the current piece choice.

It is still under construction, so there may be some issues. I seem to have misplaced the source in the year-plus since I worked on this. I have recovered the source. If you find any glaring problems, I can be reached through my contact page. I don’t promise to fix them, though.

If you’re looking for more great Tyrian artwork, do check out Daniel Cook’s blog, Lost Garden. He has put up most of the artwork for free. Our boss ship came from his free graphics dump in his postmortem of Hard Vacuum. Thanks, Daniel!

My favorite shooter of more recent times is Jets’n'Guns by the Czech indie dev team, Rake in Grass. The difficulty level is perfect, the sound is spot-on and the visuals are amazing. It is a game that I keep coming back to no matter how many times I beat it. Do yourself a favor and check it out.

In June of 2008 my friend, Robert, and I started working on what we called PewPew Shooter. We obviously stepped way into clever-creative land with the name. We weren’t setting out to develop anything revolutionary or never-before-seen in the shooter world. We just wanted a space shooter game.

We worked on it in our down-time off and on for about 3 months. We knew early on that we were eager to get something up and running quickly, so we decided to use Microsoft’s XNA Framework to develop it. We were able to get a working demo going within a matter of days. Here is a video of it after just 3 days of work.

http://www.youtube.com/watch?v=mXWABVYlt4o

Some features of the engine we ended up creating include:

• Geographic Grid Registration
  We had the potential to have a large number of entities on the screen and doing collision detection on all of them was costly. We ended up creating a class that would manage the entities for us that grouped entities by where they were on the screen. This saved us a huge amount in iterating over the enemies when checking for collisions. Instead of comparing a player’s shot projectile to all entities we just compared it to all entities in its own and neighboring grid locations.
• Collision Detection
  We opted to not do sweep tests for our collision detection. Instead we decided to try to design around needing to do too much work for the collision detection. We chose to not have anything move at so great of a speed that an intersection should occur but would be overlooked because the two object might swap places. We ended up simply testing for collisions after moving everything each frame.

  We started out with a simple bounds check but then we started adding shapes that fit the theme of the game better than squares or circles. So we had to check alpha pixels and make sure that the collision wasn’t between two invisible pieces of the objects. This worked fine until we introduced a large meteor object. This meteor was considerably larger than anything we’d put into the game up to that point and we immediately saw a large slow down whenever an object intersected with the rectangle bounds of the meteor.

  At the time the algorithm checked every pixel of object A against every pixel of object B to see if they were above a certain threshold. This ensured that transparent pixels didn’t cause a collision. I reworked the algorithm so that it only checked each pixel of the actual overlapped rectangle of each object. This made the game playable with large meteors and increased framerate overall as most object that were getting collision checked were small projectiles against large ships. The most amount of pixels we’d ever have to check was n * n where n is the number of pixels in the smallest object. This is much better than n * m (m>n) where m is the number of pixels in the larger image. In reality, it averaged out to less than n * n as the smaller object wasn’t always completely overlapped by the larger object.

• Local Multiplayer
  Multiple players wasn’t something that we thought about early in the development but, as it turned out, it didn’t end up being too dificult to add in. We tried to keep a lot of our functions that involved enemies picking targets and entities tracking entities’ movements pretty generic. This worked out well for us when we added a second player because the functions didn’t have to be modified at all and the enemies automatically started firing at random players (which they were doing all along, except there was just one to choose).

  Theoretically we could support an arbitrary amount of players until we hit the max the CPU could process in a frame and the enemies and tracking powerups would work fine. In the end adding multiple players was only a couple hours worth of work. Two players are able to enjoy the game on a single keyboard.

• Particle Engine
  I can’t take credit for the particle engine. But it was a very attractive addition. Our early explosion animation was a little kludgy and didn’t look all that great. Once I got JimJams’ Mercury Particle Engine integrated we were able to have attractive explosions and projectile trails. The addition of the particle engine was a nice visual touch.
• Level Editor
  I took a day to write a level editor supported saving and loading of levels. It wasn’t fancy, but it made the process of creating a level much easier than the previous method, which was editing an xml file by hand. It also allowed us to somewhat visualize the levels as we were creating them. The best solution would have been to build the editor into the engine, but we didn’t take the time to do that.

We both learned a lot working on this project. More importantly, we had an awesome time developing PewPew. In the end we had to stop production as life stuff came up. If I get some free time I’ll try to figure out what licensing obligations I have by using Mercury and try to get the code put up online.

In the meantime, enjoy some pictures. \n\n\n\n\n\n\n\n\n\n

When I was about 12 I learned that my dream of being a fighter pilot wasn’t within my reach. I was, however, lucky enough to get to do that in October of 2008. I can’t make a career of it, but I can do other things that I love. One of those things is making games.

I don’t live a different life as a color blind person. It rarely effects my day-to-day living. Things that it does effect include: I occasionally lose red objects in the lawn and I stop at all non-green flashing signals at night to ensure my safety as the yellow flashers and the red flashers are very hard to tell apart with nothing to compare them against (such as position or walk signals). I give green Sour Patch Kids to my wife when she asks for red. Other than small things like that, I live a pretty normal life.

Games are a love of mine and I enjoy most types. Color vision deficiencies (I won’t bother posting statistics. You can view them yourself at the relevant Wikipedia page) affect a small enough percentage of the population that worrying about afflicted people playing your game seems like an easy thing to dismiss, much to our chagrin.

There are a multitude of games in the wild. I figure it’s safe to say that the majority of them were developed without giving a single moment’s thought to color blind gamers. If I weren’t color blind myself, I might also dismiss it as trifling and unimportant. However, I’m in the unique position of being a gamer that makes games and has an opinion. Okay, maybe I’m not so unique.

First I’d like to point out common problems: (Links are to Jay is Games reviews)

Stained Glass. Match the colored sides of tiles.
Twinoo. Perform math and color manipulations.
Loop. Draw circles around same colored butterflies.

The 3 games linked all have similar problems. They use colors that look nice to the developer, but they are too similar to a color blind person. I am unable to play any of those games without quickly running into issues with the colors chosen. On Loop I run into problems on the second level. It’s a game made for young children and I can’t play it because of the color choices.

Puzzle Bobble is another game that doesn’t get it right.

I believe there are 5 different colored bubbles visible in that screenshot. However, the orange, yellow and green are extremely hard for me to immediately tell apart. Since they are right next to each other, with some effort and time I can tell that the line of bubbles coming off of that red on the left screen are truly different. However, the game isn’t one that considers patience a virtue, and, to be an effective player, I have to make split second decisions. My split second decisions created that line.

In the top-left corner there’s a whole group of similarly colored bubbles that I just kept shooting there thinking that they’d end up popping. What makes this game even more difficult is the fact that the bubble I’m shooting starts with nothing around it to tell me what color it is. With some games that have similar colors right next to each other it’s possible to tell them apart by comparing one to its neighbor(s). This game has a large gap between target and projectile. By the time they’re close enough to do good comparisons the game is already lost. An easy fix is to make the objects have more differentiation without using new colors. Symbols or shapes, perhaps.

PopCap Games created an extremely fun game by the name of Peggle. (I’ve used Peggle Extreme, available for free on Steam, screenshots for this. I assume the other variants employ the same technique.) It’s a pachinko-style arcade game with cute graphics and wonderful gameplay. Orange pegs are the pegs to remove. Green pegs provide a special powerup and purple pegs are worth bonus points. Blue pegs are just filler and provide minimal points.

The developers at PopCap include a color blind mode that can be enabled from the menu. Enabling it removes the lighter highlight around the blue studs to make it easier to tell them apart from the purple studs. They also made the orange pegs a bit better looking and increased the resolution, oddly. The non-color blind oranges look a bit blurry when compared to their brethren. The best thing that PopCap did is introduce shapes to help tell the special pegs apart. The green pegs have triangles and the purple pegs have plus signs.

First, color blind mode off:

Next, color blind mode on:

The first time I played through Peggle I found myself getting frustrated because I was unable to tell the orange and green pegs apart easily. Again, it’s far easier to tell them apart when they’re close to each other, but separated I just couldn’t tell that the green pegs were there and assumed them to be orange. Big thumbs up to the person at PopCap responsible for this change. Thanks!

That brings us to another developer that got it right. Valve recently released their phenomenal zombie apocalypse game Left 4 Dead. You can play 4 player co-op through zombie infested farms, boathouses, hospitals and airports. You can play as a zombie against human survivors in the 8 player versus mode. Basically, the game is a big pile of awesome.

Valve put their usual attention to detail to work during the creation of this game and it shows in both the standard game and in the thought they put into their own color blind mode. It can be enabled from the multiplayer menu.

The color blind mode has three settings. The first setting is off, and doesn’t change anything. The second setting causes the crosshair to turn from a light blue color to a white crosshair with a black border. As you can see in the following screenshot (or not, if you’re not color blind.), without any of the color blind modes enabled the light blue crosshair doesn’t show up well in some situations.

Crosshair example with color blind mode off (“cl_colorblind 0″):

Setting color blind mode to the second (and third) setting allows you to see the crosshair no matter what is behind it, as illustrated in this next image (“cl_colorblind 1″ or “cl_colorblind 2″):

The third mode builds upon the crosshair changes and also changes the colors of the health status HUD and the colors of the survivor outlines. As a survivor you are able to see your own and all other survivors’ health status at the bottom of the HUD. When you are playing as infected you are able to see moving player silhouettes that are also visible through walls. The color of the status bars and the silhouettes indicate the approximate health of the survivors, which allows you to strategically cover or target the weak links. The third setting also changes the smoker’s crosshair from a red circle to a blue-green circle when a survivor is able to be targeted.

First person smoker’s crosshair (“cl_colorblind 0″):

First person smoker’s crosshair (“cl_colorblind 2″):

The default colors for the health status bars and silhouettes aren’t easily visible to color blind people. As an infected I am nearly unable to see a survivor with medium (hp>15<=50) health through brick walls (“cl_colorblind 0″ or “cl_colorblind 1″):

A survivor with low (hp<=15) is, for all intents and purposes, invisible to me through brick walls (“cl_colorblind 0″ or “cl_colorblind 1″):

However, as soon as I set the color blind mode to its third option (accomplished through the console with “cl_colorblind 2″) the survivors pop right out of their blending into the wall. First medium health, then low health:

The low health is especially of note because I am able to immediately discern that the person highlighted such is an excellent weak target. The colors chosen with color blind mode disabled are difficult to discern on their own even when not seen through walls. First, a survivor with medium health outlined, and then a survivor with low health outlined. Both with color blind mode disabled (“cl_colorblind 0″):

Once we enable the third color blind mode I am again able to be useful to my team because I too can pickup on the visual cues. First a survivor with medium health. Then a survivor with low health, both with color blind mode on its third setting (“cl_colorblind 2″):

As a survivor the color difference for low health has a huge impact on my ability to spot the status of myself and my teammates. First, a screenshot of a survivor’s health at 14 with color blind mode on the second setting (which only effects the crosshair) (“cl_colorblind 1″):

The red doesn’t pop out at me and it’s very easy for me to not notice it. Here’s the same shot with color blind mode on the third setting (“cl_colorblind 2″):

With color blind mode on the third setting, the  new color, some blue green variant, is of high enough contrast that it actually draws my eye to it as soon as it changes.

The same goes for bleeding survivors. First, no color blind mode, next, third color blind mode:

I hope that more developers put color blind compatibility modes, or even design to accomodate, as it doesn’t require changing an entire game, into their schedules in the future. I, as one of those “infected”, will very much appreciate it. If you have any comments or know of more games that seem to have put thought into accessibility for color blind gamers, please do share below.

Today I logged my first 1.4 hours of Viper time. Lt. Col. Kevin “Coconut” Grove was the pilot on my first F-16 flight. We started off by doing a full afterburner vertical ascent to 10,000 feet. This pulled about 3.2Gs. The strangest thing about sitting in the cockpit of this aircraft while it is flying is the lack of engine noise. The vertical takeoff was completely silent.

After we got to altitude we meandered up past Sedona to Meteor Crater. I’m going to have to plan a trip (road) there. It looked really neat from the air. We then headed west past Flagstaff and got a short view of the Grand Canyon. We were running into some wind so I opted to cut the Grand Canyon tour short in favor of more time in our airspace.

Once we saw the Grand Canyon to our right he gave me the jet. I banked to point to our airspace and did some S-turns to get used to the controls. Upon arriving in our airspace I did a quick left aileron roll. The stick took some getting used to as it only has about a quarter of an inch of play. Slight movements of the stick translate to huge movements of the jet. After the left roll I did another one to the right. My second was a lot faster than my first. I did some vertical movements and experienced some negative Gs.

As I was in the back seat I didn’t have a traditional HUD. I had an MFD with a HUD display overlaid onto a camera view of straight forward from the aircraft. This was below horizontal from my head position so the majority of my stick time was spent looking at this screen and not out the window.

After my maneuvers he took the jet back and proceeded to do some G checks. He accelerated to about 450 knots and did a 4.5G turn to the left and I practiced my breathing. He again accelerated to about 450 knots and then did a 6.5G turn and I again practiced my breathing. I started to get tunnel vision and he mentioned that I was breathing too quickly. I corrected this and he let off on the stick. After a quick check to make sure that I was fine he accelerated to about 500 knots and threw us into our 9G turn. This was excruciatingly awesome. I did not start to black out or get tunnel vision. I was under intense pressure and acutely aware of the sweat running out from under my helmet and down my forehead. I noticed that my mask must not have been seated right as it started warbling when I was breathing in the 100% oxygen that I turned on to help avoid passing out.

My mind was relieved when he said “There’s 7, 8 and there’s 9″. But it wasn’t over. We still had to come back down from 9Gs. After he leveled us out and I told him that I was fine, great, even, he asked if I wanted to go supersonic.

Supersonic was nothing. An absence of anything unusual. I wasn’t expecting much to happen and I wasn’t disappointed. I watched the Mach speed indicator go up from 0.5 to 1.0 and then back down. I’m sure the people below us noticed, though!

We were running low on fuel so we proceeded to head back home. He let me fly it back into the Luke area and I descended from 12,000 to 3,600 feet at which point he took over and brought us in for a landing. We dearmed our AIM 9M-9 Sidewinder and taxied back in. I disembarked and felt a bit wobbly and very tired.

I changed out of the harness, G-suit and flight suit and drove home where I promptly went to bed.

This was one of the best days of my life.

My ABU Blouse

I had a good run. I was assigned to Detachment 1 Air Combat Command Training Support Squadron at Luke AFB, AZ. I worked there as a Simulation Engineer. I got the chance to go TDY to several states and to work on several cool projects.

Crypto Trainer

In addition to working, I also got a few chances to do other cool things.

Wings of Blue Skydive

F-16 Incentive Ride

I also was able to attend E3 3 times. This was before it went all retarded.

I’ll miss the Air Force. I’ll miss what I was doing. I am, however, not going to cry over it, as I’m moving on to pursue my other dream. I’m going to be a game developer with Sony Online Entertainment working on DC Universe Online. The job is in Austin, Texas and I move on the 16th of October, 2008.