Posted on March 1, 2007
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…
Posted on February 26, 2007
Looking for computers
I see you under the glass
Your brown box taunts me
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
Posted on February 15, 2007
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.
Posted on February 13, 2007
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.
Posted on February 12, 2007
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
Posted on February 7, 2007
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…
Posted on February 3, 2007
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.
Posted on February 1, 2007
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
Paddle too tiny. Back to
One last little block
Yes! I cleared level two
What? No Level Three?
Posted on January 20, 2007
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:
<strong> 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 Else 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 </strong>
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.