Dino Run

May 5th, 2008

I love the guys at pixeljam, they’re what’s right with the Flash game world.

They have a new game, and it even has multiplayer. Dino Run. Nothing quite like it I assure you, its well made but simple, and fits very well into the ADD world of Flash games. I’ve been a beta tester for the game and its pretty fun.

Adobe has started something called the Open Screen Project. They’re going to do 4 things as part of this.

  • Removing restrictions on use of the SWF and FLV/F4V specifications
  • Publishing the device porting layer APIs for Adobe Flash Player
  • Publishing the Adobe Flash® Castâ„¢ protocol and the AMF protocol for robust data services
  • Removing licensing fees – making next major releases of Adobe Flash Player and Adobe AIR for devices free

This is the way the winds are blowing anyway, but regardless it’s a great step forward. The most important thing I see is that the Flash specifications no longer require the reader to not make a Flash Player based on them, allowing the proliferation of open-source alternatives. Since the offical player can also be freely ported to different environments as well, it looks like Flash is, and will remain, the standard.

I read this post on what not to do with private properties. It’s for Java, but applies to Flash as well. Apparently declaring a property is the “amateur” way to do it. This is how I would do it.

public class Person {
private var _age:int;
public function Person(age:int) {
_age = age;
}
public function birthday():void {
_age++;
}
}

According to this fellow, that’s bad practice. You should always use accessors! Why write short concise code when you can write three times as much? Instead of age, use getAge() and setAge() because apparently its a lot better to write setAge(getAge()+1), rather than write age++.

Flash’s accessors would allow you to write age++, but this is still the most disturbingly defensive code I’ve ever seen. It’s a private property! A class is supposed to be able to manage its own properties. It’s other classes you’re supposed to mistrust, not your own. If a class has become so big it requires this kind of nonsense that’s a pretty good sign it should be split up into smaller classes.

In my opinion his only valid complaint is that its easier to make breakpoints. Fortunatly most of the comments for that article disagree with his opinion.

The serial you get works on the Linux version, which is currently in alpha. Get your serial here. Thanks to Colin Moock for pointing it out.

Starfield Stackers Demo

March 22nd, 2008

A while back Andrew Dickman and I tried making games together as an artist/programmer duo.

This is easily the best thing I think we came up with because it’s the most fun to look at and play in its incomplete state. I wrote some decent AI for the game, which I’ve never actually beaten on the hardest difficulty. The gameplay is basically identical to Puyo Puyo, otherwise known as Dr. Robotnik’s Mean Bean Machine and Kirby’s Avalanche.

Use the arrow keys to move, and the spacebar to “spin” the blobs. Chain together 4+ blobs of the same color to clear them and any nearby black blobs. You send more black blobs to your enemy the bigger the chain, and way more than that if you pull off combos.

This game is so incomplete you can’t switch between modes in the game, so you’ll have to pick the type of game you want to play from here.

Yoshi's Island Flash Demo

February 29th, 2008

When it comes to 2D platformers, there is no better than Yoshi’s Island. It’s innovative, loaded with levels, and just plain fun to play. When I was younger, I went so far as to get 100’s on every level, including the bonus levels.

I was experimenting with tile engines in Flash and I figured it would be very hard, but possible to pull off Yoshi’s Island in Flash. These days, that’s almost easy, but this demo was on the far edge of what Flash 6 was capable of on my old computer. It was reasonable in brief horizontal levels, but slowed way down when in levels involving both axes. I decided to drop it, but I have a special place in my heart for this project, since this is probably the best chunk of code I ever wrote for Flash 6. Ah well. I still gained a lot of experience from it.

Here’s the demo Use the arrow keys to move and Z to jump. Press Z again in mid-air to get Yoshi to float.

You’ll need to view this post in a browser with Javascript and Flash 6 in order to see it.

Flash Plays Quake?

October 9th, 2007

I’m surprised I’m finding about this now, but during Adobe MAX Chicago Adobe talked about the (possible) use of other languages in Flash, including C/C++. What’s worse is they had a killer example of the technology. Quake.

It’s located here. Towards the end of the second video.

It is in fact Quake, not Quake II, unless I’m going crazy. I honestly have no idea quite how they pulled it off. Sure having a C/C++ compiler for Flash and a nice 3D api would help, but it’s got sound and everything. The only way I got sound to work in my Doom port was by converting them (the hard way) to Sound instances, but sound in Quake is streaming. Fullscreen in Flash 9 uses DirectX now, are they using the DirectX with the 3D api in fullscreen too? Are we able to stream sound, rather than convert it? I can’t quite understand how they did it. I guess we’ll have to wait and see.

Presenting Doomed Online

September 16th, 2007

I finally got around to open-sourcing my Flash Doom port. It’s under the GNU General Public License (v2), and hosted by Google Code. You can see the current trunk here. If you checkout the source code (more details here), compile src/DoomTest.as or you can try working with my build.xml.

I actually wanted to name it ActionDoom, but turns out there’s already something called that. Since I refuse to mess with a guy called Scuba Steve, I went with Doomed Online instead.

Update: I added a demo to the page.

Update 2: I have temporarily suspended the project, since it’d be better to just port it from C anyway.

More Doom

August 27th, 2007

Update: Visit the home of Doomed Online here.

So I’ve decided to open-source the Doom port I’ve been working on. It’s really a far larger task then I think I have time for and I’m pretty sure that I’ll have to turn to the actual Doom’s source code at some point. Things like the enemy AI are a complete mystery to me, although the rest I’ve been able to get away with so far. I’m not quite finished doing it myself yet, but once I clean up the code some more I’ll release it for public consumption. Not sure what license to put it under though, the GPL would probably be fine.

This leads to my main problem. What should I name the project? Anybody have a good idea? I’m trying to think of something interesting.

Anyway, I’ve got a new demo ready. It’s set in a different level (E1M5). There’s sprites now although most of them are dummy enemies. I figured out the lighting – at least I think I did – so everything is much more bleak and Doom-like. There’s animated flats, walls, and sprites now, as well as some lighting effects. There’s wall collisions, head-bobbing, texture mapping is much better, no more mysterious walls, sound has been fixed (press the spacebar), and the engine is actually significantly faster too.

Use the arrow keys to move. You can pass through doors and other non-impassable walls. Like before, it’s 1.7MB and there’s no preloader. The game is “after the break”, as they say.

Read the rest of this entry »

PaletteMap is fast

August 13th, 2007

This is one of the tricks to my Doom engine. Doom has a 256 color palette, and all colors in the game come from this palette. When an index is found for a pixel, instead of converting it to an rgb value using the palette, write it directly to the image itself. In other words, the last 8 bits (the “blue” section) of every color on the bitmapData should have an index, rather than an actual blue value.

bitmapData.setPixel(x, y, index);

After all processing is complete, you can use paletteMap to convert these indexes for you. PaletteMap uses the value of each byte of an image color (four total) to come up with a new color. See the documentation for paletteMap for more details. Provide an array that converts indexes to rgb values for blue and Flash will do the work for you. If you pass arrays full of zeros for red, green, and alpha, then these values of the associated bytes will have no effect on the resulting color.

bitmapData.paletteMap(bitmapData, bitmapData.rect, new Point(0,0), _blank, _blank, _index2rgb, _blank);

PaletteMap is very fast, which is why this offers a nice improvement in speed. Passing null to a section instead of an array makes it slightly slower on my computer, so that should probably be avoided.