Wiicade Releases Wiimote/Flash API!

The fine people at wiicade have created an API for Flash that will allow programmers to test for ANY button press on the Wiimote!   The A,B,+,-,1,2, and the direction pad are all available, as well as the pointer from the Wiimote.   To test this API, I took one of my unposted Work In Progress games (code named “Base Shooter”) and retrofitted it to test for all buttons (except the direction pad) to shoot a bullet.   This is just a simple test, but it seems that it might be a very large step in the right direction for homebrew, indie, midnight, etc. developers who want to program simple games for Wii Consumption.  Base Shooter is really rough, but playable.   

The bad news about this is that, even though it uses the wiicade API, it can’t be played outside of Wiicade.com because their API has been specifically designed to work with their servers.   However, they patterned their API after information found here: http://www.quasimondo.com/archives/000638.php#000638 which means, with  little work, this could be used any where…

Atari Haiku: Asteroids 2600

Asteroids 2600

Looking for computers
I see you under the glass
Evil Asteroids

Your brown box taunts me
Sixty-Six variations
Well worth the money

Asteroids float up
Nothing like the arcade game
Asteroids float down

A wave of nausea
Thigh stings from the pain of a
Hole burnt in pocket

Yet, I still play it
Home is not like the arcade
But I can reset

The beat transcends all
Hypnotic flashing space rocks
I give into it


OK, so I was at Target on Friday looking for cheap games in the marked-down section (red price-tags!) and I found a copy of “Big Mutha Trickers 2” for $2.49. Since I have a weakness for trucking games, and $2.49 is my ‘buy it now’ price-point, I had to get it. I know it’s a bad game but so what? I wanted to try for myself. I also picked-up a copy of “Little Miss Sunshine” for my sister-in-law for her birthday.

When I went to check-out the cashier scanned “Little Miss sunshine” with no event, and then scanned “Big Mutha Truckers 2.’  Immediately an alarm went off on her register and she requested my I.D., which I gladly gave her. Since “Big Mutha a Truckers 2” is rated “M”, I figured this was their new way to stop selling “M” rated games to the under age kids.   I’m not against that.  There are tons of great games for kids to play that don’t contain mature content.

However, when I left the store, I checked my bag and noticed that “Little Miss Sunshine” is rated “R”…and then I got upset. So it is conceivable that a kid could go to Target and buy the entire “Saw” series, every “80’s” teen sex comedy, and any movie with content that borders just this-side of criminal, BUT, they would only be carded if they supplemented this purchase with an “M” rated game?

Look, I’m all-for ratings and keeping kids from mature content, but when kids can buy movies with some of the most gratuitous sex and torture scenes ever filmed, yet get stopped only when it happens to be a video game that contains : ‘Language, Mature Humor, Suggestive Themes (according the it’s ‘Big Mutha Truckers 2’ ESRB rating), something seems very  wrong to me.  R-Rated movies have gone places and contain content that would make the virtual participants in the “Hot Coffee” mini-game blush and turn away from the screen in horror, yet, seemingly, according to Target anyway, they are O.K. for kids.

Furthermore, The cashier could not simply look at my I.D. she had to physically swipe it through her register so the sale could be made. I don’t even think they do that for alcohol!   In the Target pharmacy, you merely have to request pseudofed from behind the counter.  So from that perspective (if I’m correct), a 13 year-old kid drinking a 6-pack of Miller beer, watching a ‘Porky’s II’/’Hostel’ double feature while mixing a batch of crystal meth in his basement, is actually less threatening to Target than the same kid getting a-hold of a bargain copy of “Big Mutha Truckers 2.”

The Asteroids Evolution to Retro Blaster

My first video game true love was Asteroids. I think the game must have satisfied some internal, mental need to keep things cleaned up. The Sisyphusian nature of this electronic task was enough to make me pour quarter after quarter into the machine in an attempt to just earn one extra ship at 10,000 points. I was never very good at the game, but I would always have a go at the machine if I found it in an arcade, laundromat, grocery store, or liquor store. It’s funny that as kids we thought nothing of spending copious amounts of time in a liquor store playing video games, buying packs of Star Wars cards, and guzzling Bubble Up and Root Beer. We would even tell our parents that we were going to the liquor store. Now-a-days we probably would have been put in a youth home for just stepping into a liquor store at age 11. Back then, the local liquor store was the hub of teen and pre-teen activity. We weren’t there for the alcohol (I guess some kids must have been, but we weren’t). It was our local carnival with games, candy, soda, adventure.

Anyway, after Asteroids, I poured quarters into Asteroids Deluxe, Space Duel, and to some extent Sinistar and Blasteroids. I remember going to a Savon Drug store and purchasing Asteroids for the 2600 and playing it non-stop for weeks on end. I also had a version for the Atari 800. It was similar to the 2600 version but with slightly better sounds, visuals and game play. Asteroids for the Atari 7800 was an absolutely awesome version that few have played. Probably my favorite classic version was a game called Megaroids. It a demo game that came with Megamax C for the Atari ST. A version was also created for the PC and Amiga. It was the a great version of the arcade game and a nearly perfect adaptation with more colors. When the PC arrived to prominence, I was one of the first on the block to buy Micorsoft Windows Arcade with Asteroids included, and of course I found a definitive version on Mame. The later Harbro Atari games for the PC and Consoles was decent, and I own a copy for both PC, and Playstation, but it never held my interest as much as the original incarnations.

I have wanted to make an Asteroids game of own every since I borrowed graph paper from my dad in 1979 and started to plot out the worlds of wonder in my 9 year old head. My first attempt was on the Atari 800 in Basic and it was a complete failure. The lack of suitable math skills for object rotation and vectors left me with a pretty putrid piece of pre-novice game programming. I left Asteroids type games behind and created puzzle and classic board games for years until STOS on the Atari ST enabled me to think about trying my hand at action games once again. I was in college at the time and besides producing yet another fully realized Yhatzee style game (Zambool Atari ST), I never found the time back then to delve deeply enough into the inter workings and create a good Asteroids clone.

After many false starts with a number of programming languages (Java, Dark basic, Game Creator, Game Maker, C++), I finally decided to throw the gauntlet at Flash and see with I could come up with. With help from books By Jobe Makar, and other game programming masters, the first game I came up with was a semi-polished version called Zeno Fighter. It is currently in the Work In Progress section of the site and I might go back some time and finish it off. properly. This one uses Steve’s Particle engine for explosions, and I copied the Asteroids “Jaws” music straight from the MAME version of the game. I was attempting to do CIRCLE math collision detection on the blobs (rocks), and if you try this WIP, you will see that sometimes the shots go through the edges.

I moved from this version to a more ambitious version called Pixel War. In this game I threw out all of the Asteroids vector graphics and decided to create pixel art for all of the game elements. I also wanted many more things on the screen to shoot at, weapon upgrades, and other enhancements. In creating this game I discovered the need for many new OOP building blocks for my games. These include objects to handle basic sprite properties, depth mangers and clean up routines, in game text display classes, and more. All of this code and animation started to slow the game down. Because of this, I dropped development of this game and started some basic animated sprite reel bitmap caching routines. The basic idea behind this was to cache every frame of animation for a sprite in a bitmap object and flip through them like cell animation in an interval. The interval is controlled by the game loop and this gives the programmer great control over the display of each individual frame of animation for an object.

Retro Blaster is the game that sprouted from this. It will be available on the site shortly.

My First Breakout-Style Game

Creating Brickbasher (just added a few days ago, but programmed in 2004) was one of my first eye-opening experiences programming small garage games. I have been a fan of Breakout style games since the age of 8 (read about the story here) when I first sampled the classic Atari 2600 version. What seemed like a relatively easy game to create became an exercise in frustration and a very humbling experience.

To start programming the game, I looked back and read a bit about how Brad Stewart, programmer of the Atari 2600 version created his masterpiece. The most notable thing I read was that Mr. Stewart divided the paddle into eight sections, so when the ball hit one of those sections, it would be sent in the proper direction. This seemed easy enough for me. In Flash, I created 8 separate hit areas on the paddle. Whenever the ball would hit one of them it would recalculate a new direction and update the ball to move in the direction. Easy huh? But I soon realized that there were not just “8” directions in which the ball could be moving. I also needed to calculate from which direction the ball hit the paddle. For instance, if the ball hits the left-most edge coming in from the left, it should send the ball back off to the left. However, if the ball hits the left most edge coming in from the right, it should have the same effect. However, with my simplified system, this did not always happen. coming in from the right and hitting the left-most section sometimes sent the ball back to the right, which looks and plays weird.

I also made another mistake programming this game that was much more costly. In 2004, Flash MX with Actionscript 1 was not a fully object-oriented language. However, I tried to treat it like one and thought I would be all fancy and program this game using design patterns. The Singleton and Subscriber models seemed like they would work very well with a game. Singleton is a pattern that makes sure you only have one object of a certain type created while you program is running. Subscriber uses a messaging model and has objects publish/subscribe to events of each other. Singleton worked fine, and I would still use it in any project where it was required. However, Subscriber was a disaster, at least how I implemented it. First of all, the messaging was slow. Much slower than just having my main game loop call functions of objects in an array. Secondly, I made the mistake of having each individual object run on it’s own interval. For instance, every brick on the screen checks for a hit with the ball on every frame. Stupid, stupid, stupid.

When I went back in 2006 to re-skin the game for Brick Basher Under Attack: No Way Out I was devastated that I had created such inefficient and ugly code. I started to re-write the whole mess, and I’m still in the process of doing that for the forthcoming “Brickbasher 2.0”. However I learned some very important lessons from the experience. First, nothing is “easy”, not matter what you think. Secondly, the latest and greatest programming “fads” do not necessarily make fast running, good games. I’m sure I will always make mistakes while trying create new games, but the real mistake would be not learning from them. That is why I posted these two games. They are not perfect, but they are part of an evolution. This site is not just about the games, but also about the process of making them. I will never be able to learn from my mistakes unless I can acknowledge having made them in the first place.


Atari Haiku: Baptism By Pixel

Baptism By Pixel


The back of the store


Right of the housewares


Next to the fire door

Heavy Sixer with Combat!

Two wide-eyed kids


Thumbs on the buttons

CX-40s in our palms

Hands and eyes in-sync


“This f-ing rules man!”

“cool-ass games on a TV!”

“Much better than Pong!”


Tanks, bi-planes and jets

Bouncing shots, racking-up scores

We play while mom shops


“This aint no arcade”

Yells the TV salesman in

The C&R suit


He says “That’s it boys”

He then hits the power switch

“Not get outta here!”


We skulk away

From the TV section, but

We will be back soon

Balloon Pop!

So, if you have looked at our Work In Progress page you will notice that we have a lot of half-finished games and ideas that we plan to someday come back to.   To be honest, the list on that page really only scratches the surface.  I probably have 2 dozen more games to add on that page.  I plan to to start adding more as soon as possible, but there are so many that it cuts into my time to develop and finish ideas.

One of the games on that page is simply named Balloon .   It can’t recall exactly why I started to make it, but I’m sure it was for some type of game related to a girl’s toy in 2001.   At the time it seemed like a no-brainer:  who doesn’t like the the satisfying feeling of popping balloons?  (my wife, it turns out, but that’s another story)   However, after getting the rudimentary code finished that would allow the balloons to be randomly created and a mouse roll-over to pop them, I quit.   I still like the concept thouugh,  I think it will work especially well for Nintendo Wii focused browser games.

So, my first step was to take a look at the balloon.fla file to see what I was thinking 6 years ago.   Apparently, I was not thinking of much because the Flash 5 Actionscript programming was terrible.  Code on all sorts of layers, embedded in movie clips, embedded ON movie clips.   I decided to salvage the graphics only, and move on.    I have begun a new version named Balloon Pop based on the Fireworks Blast engine.    It is mostly object oriented at uses Actionscript 2.0 code, and has some physics and trig routines already built-in, which will help speed development.

The first real decison I have to make is how to handle the controls.  For a Web Flash Game, shooting ballons Pooyan style seems fun, but the for the Wii, this might pose a problem.  You can’t click the button fast enough (at least in my tests) to make a playable game that requires fast mouse clicks.    I might have to re-too la Wii version that relies on roll-over.  Hmm…


Nintendo Wii Flash Development

So we are just starting to experiment with Flash games designed specifically for the nintendo Wii.  I started this process on Dec. 24th, the day the Wii opera Browser was downloadable. That day I got the first version of Fireworks Blast ready to work on the Wii.  

Thge first thing I discovered was that the Wii Flash player is slow.  It only runs Flash 7 and below, which is fine for a Beta, but makes playing most modern Flash games very difficult.

The next thing I noticed is that the (A) button response on the Wii is not like a mouse click in any way.  The (A) button simply does not register every click.   It seems like the button needs to be completely pressed and then depressed before it will register a second click.  This means that most fast action games where the player fires rapidly are out too…for now

The 3rd observation I made is that the resolution displayed must be optimized to give your games the best look possible.  After searching a bit on the Internet, I found that the people at Wiinintendo.com had found out that the best possible rosultion for Wii Games is 608×456.  However, 640 x 480 is supposed to scale properly as well.   I’m not sure if this is the same for 16×9 presentation.  I will have to research that.

That’s it for now.  We are just starting this section, but we hope to optimize as many games for Wii play as possible.



Haiku: Breakout 2600

Breakout 2600


Hypnotic death notes

Each block wails an 8-bit tone

Blinks out then silence


Burrow A Hole Through

Your color-banded shield

Watch ball go ape-crap


Difficulty B

Paddle too tiny. Back to

Difficulty A


One last little block

Yes! I cleared level two

What? No Level Three?

A different approach to path finding.

I spent the last week working on jStar. After researching and working with a* for the last few days, I came to the conclusion that while very powerful, it was slow and overkill for my arcade-adventure, shoot the robots game. Also, since the player is constantly moving, the recalculations using the recursive path finding approach was killing my frame rate. I will explore more on this later, but I basically threw every thing I was working on to the side and set out to create my own path finding routine.

I started with these constraints:

1. I don’t need 360 degree movement, my enemy robots only need to move up, down, right left. For this reason, even 8-way a*. is a little too much power for my use.
2. Actual collision detection between the enemy robots and the walls is time consuming and difficult. If I can eliminate the need, it would speed up the routine significantly.
3. The robots can be intelligent, but they don’t need to be smart, remember, they are robots.
4. The grid squares for the robot movement must be large enough to hold an entire enemy robot. That would mean completely changing both my grid and my sprites. I thought maybe a complete over-head perspective would suit this fine.
5. I would need to create a specific, invisible path that the robots can walk on, eliminating the need to a* like calculation, and collision detection between robots and walls.
6. The path should be drawn so there are always 2 tiles that the robot can move to from the current tile.

I took these new constraints to the computer and sat down to write some pseudo code. Here is what I cam up with:

If Robot Not Moving then
	check to see what CURRENT TILE the robot is in
	check the tile UP, DOWN, RIGHT, LEFT tiles from CURRENT TILE
	if a tile is on pre-determined ROBOT PATH , push it to movement stack (this should always result in 2 tiles)
	Compare the two tile by taking the absolute value of the different between the x and y positions of the tile
	and the x and y positions of the player.
	Which ever produces a lower number will be the CRITICAL path on the pre-determined movement path.
	set Robot Moving Boolean to True
	Add the the delta to the movement x,y for the robot for the next frame
	Before moving the robot, check to see if it was made it completely inside the destination path square
	if so, stop the robot set Robot Moving Boolean to false
end if

That’s basically all there is to it. You can test this completely new and very basic looking overhead version by clicking the link below.
Use the arrow keys to move the green circle with the “P”. The Red Circle with the “E” on it is the enemy and he will attempt chase you on the path.
See jStar in action

Obviously, there are a few things are left out. The first one is the robot’s ability to fire a missile at the player when within range. The second is collision detection between the robot and the player. Lastly, if I want to use the “berserk-like” perspective I have already put hours into designing, I will have to modify this engine. Those are my next steps.

This site is protected by Comment SPAM Wiper.