About a week ago a friend of mine released his very first indie game – for the iPhone of all platforms. Sounds like a bit of a pain and probably it actually was. The game is basically a bigger and better version of one of his old games. The old one was written in C++ for Win32 (the source is also available over there). Later on he also ported it over to the GBA.
The new version looks and sounds pretty cool. If you're interested check out the video over at the official site. By the way, all models were done with everyone's favorite box modeler Wings3D. And the final audio cutting was done in Audacity. Both tools are mind-boggling awesome for these tasks. Check them out if you haven't yet.
Well, about a week has passed and he only sold a dozen copies so far. In the meantime it was pirated a few thousand times. Ouch. So, if you got $2.99 to burn (and an iPhone to boot) you can make one poor student very happy.

I just finished a tiny web application. And by tiny I do indeed mean tiny. It's a single file and less than 8kb in size (thanks to GZRepack). You can check it over at riddler.kaioa.com.
It allows you to store the hashes of answers to some question in an URL. If someone clicks on that URL he/she is then asked for the solution. If it matches any of the up to 5 hashes the icon and the border turn green and he/she can then start the next round.
With web games you want hits — lot's of hits. A million per month or more if possible. Of course this means lots of traffic. While broadband became faster and cheaper during the last couple of years, traffic is still somewhat expensive. In order to get a nicer cost/income ratio there are apparently two options: reduce the costs and/or increase the income.
As you might have guessed I'm about to tackle the former with brute processing power. If you reduce the file size by 1% every 100th served file is free. With 5% it's every 20th file and with 10% every 10th file. If the price for that are only a few minutes of processing power it looks like a really good deal, doesn't it?

If you're writing a game with ActionScript3 you've basically two options: either use the scene graph or handle it yourself. I.e. extend Sprite, create some Bitmap, attach it to your Sprite, and blit onto its BitmapData via copyPixels.
Skipping the scene graph is certainly more fun. If you wrote some games in other languages, you'll quickly feel at home. Apart from that external main loop it's basically the same deal. Additionally, if your game requires full redraws either way (i.e. dirty rectangles won't help), using copyPixels is the fastest option.
However, if you take a look at BitmapData's documentation you might be in for a big surprise — there is no drawString function. How can you draw some text on top of your entities for quick debugging now?

The last time I looked for something like this I was only able to find horrible implementations. They somewhat worked for the most part, but boy where they ugly. All of them. Well, to tell the truth I gave up pretty quickly. I decided to use a simple 18 lines long version which utilized trace for the output.
And that was fine. However, as I experimented around with Kostas Michalopoulos's Flash mod player I found out that the Debug Standalone Flash Player can be much slower if the bottleneck is on the code-side. It was over 10 times slower. That was a bit of a surprise, given that this kind of thing is free in Java. Of course I wanted to know now how fast my game can actually run in it's current state.
There aren't many calculations right now and there won't be all that many once it's done. Therefore it only runs about 20% faster with a non-debug plugin. But that's still good to know. Now I do at least know that there isn't much of a speed up to expect.
The FPS counter listens to ENTER_FRAME events, because that's the only way to know how many frames are actually displayed. If you render in response to timer events, you may enter that function far more often than new frames are displayed. The enter frame event is the most reliable pulse generator, I'm afraid. Be sure to use the deltas though and cap them in order to avoid warp-through effects and the like.
ActionScript was introduced with the release of Flash 4 back in 1999. In my never-ending naïveté I assumed it should be pretty mature by now. Almost a decade should be enough for that, shouldn't it? Obviously that isn't the case - otherwise there wouldn't anything to rant about. ;)
I started with ActionScript3 (Flash9+) a few weeks ago. It's supposed to be so much better than ActionScript2. There wasn't much of a reason to not use the latest version; given that about 90% of the users use the latest version of Flash. The remaining 10% quickly fade away if you consider things like the lifespan of small web games (a couple of years easily) and the time it takes to get things rolling for real. A quick look at AS2 was actually enough to discard it completely; it's ugly.
Do you remember those days you started programming? Back then all I had was a Commodore 16, one and a half bad books, and BASIC of all things. The really awkward kind with numbers in front. Incrementing by 10 every line in case you need to insert something later on. Drawing a Sinus curve took bloody ages. You could literally see how it was plotted pixel by pixel.
Later at school I had some C lessons. I liked C a lot. It was fast enough to do draw some odd effects in real time and the code looked so much better than C16 BASIC. Well, big deal. But back then it was truly the holy grail for me. I also got introduced to that odd algorithm stuff. Bubble sort. Gasp.
There aren't much details out there about Quake Live (formerly known as Quake Zero) yet. One of the few things that were made public a few months ago was that it won't be written in Java (nor ActionScript... haha... very funny). Some people were really happy about that. Java is slow after all, right? Even Carmack himself said so.
While it's true that Carmack said "Java is really slow"[1], he didn't mean Java in general but J2ME. And he's of course right - J2ME is slow and it really is a platform of pure horror. There are simply too many differences between all those handsets. Different resolutions, color depths, key layouts, features, extensions, glitches, processing speed, memory, and whatever else might get in your way - it gets in your way with J2ME. I salute to the bravery of everyone who's doing that stuff for a living.
Some of you might have seen FontStruct over at Slashdot. It was at the front page yesterday or the day before. The usual thing happened of course - it got slashdotted to death. Fortunately it's back online. It's time to give it a shot.
In a nutshell: FontStruct is a web-based font creation tool. Apart from a few minor issues the Flash-based interface is perfect. It's surprisingly awesome in fact. Well, it's not intended to be used for professional font creation; it doesn't handle kerning or hinting for example. There aren't even any vector tools (all you get is a set of building bricks). But all those things aren't really necessary for less-serious/pixel fonts.
Without net access there wasn't much to do. However, modeling was one of the few things I actually could do. Fortunately I had some recent version of Wings3D installed. A few futile attempts later I got something that looked alright. Semi-satisfied with my low poly (52 polygons, 104 edges, 54 vertices) spaceship I went ahead texturing it with Inkscape.
Since the intended rendering size is rather small there isn't a need for fine details. I also wanted to try some bold semi-futuristic look with a touch of military blandness. Using vectors seemed like the most natural choice. Hard vector edges also fit the flat shaded rendering a lot better.
Before I could start with the texturing I had to do the UV mapping first. UV mapping is a bit annoying in Wings3D, but it's alright for simple models. If you aren't familiar with the term: it's about which part of the texture goes where on the model.