BrokenBlog

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.

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.

Update 3: Visit the home of Doomed Online here.

Update 2: There’s a bigger, badder, version up now.

Yes, that’s THE Doom. This uses the original Doom shareware wad file and gets all content from it at runtime. There’s no preloader, so be patient, it’s 1.7 MB. Use the arrow keys to move.

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

There’s no sprites yet (enemies, barrels, that sort of thing) and you can walk through walls too. There’s also a mysterious bug that erects unnecessary walls in the outer areas of the map, but altogether it’s still pretty fast and stable right now. There’s some rudimentary sound support too, although for some reason it sounds scratchy at the end of a sound right now. Press the spacebar to hear.

It took some trial and error to get this far, since making a fast rendering system is so important. I tried using the same method for drawing bitmaps as Papervision at first, and while it was very fast, it also looked terrible. Papervision’s technique doesn’t seem to work well in an FPS environment because the wall textures skewed as you walk along them. I tried again with another method that used Flash’s draw method heavily, but it was far too slow and hard to work with. I was about to trash the whole thing, but I tried a more basic system, roughly resembling how environments were drawn in the original Doom where each pixel is drawn one-by-one. It seemed like it was still too slow, but after a few key optimizations to the drawing routine it ended up being very fast. I honestly wasn’t expecting that, but it’s actually playable now on a decent computer.

I don’t know exactly where I’m going with this, but I’m pretty sure it’s worth it. The only thing I can’t do is the music, the format is roughly the same as midi, and as far as I can’t tell it can’t be preloaded. Everything else Doom is capable of is possible. This whole thing was developed entirely using Flex 2 and the Flex 3 beta with Eclipse on Ubuntu Linux. In other words, with only free tools, right down to the OS.

Update: Apparently nobody knows my name. I think that’s kinda cool, but it’s actually Max.

FZip has been updated, it has a couple nifty changes.

• Apollo/Air has built-in deflate support (ironic, isn’t it?), so if you make an Air app, you don’t need to “prepare” the zip file like before. This means FZip can open any zip file from within Air.
• There’s better support for foreign language filenames. Unicode is now the default, but that can be easily changed.
• There’s a new class, FZipLibrary, which is an (optional) processor that makes it easier to convert incoming files into other formats (images, swf files, etc).

The Air support is the most significant change, but if you’re putting the zip online you’ll have to run it through fzip-prepare.py first.