Google I/O 2009 - Writing Real-Time Games for Android

Skip the first 14.5 mins which is mostly introduction and a game demo, but I recommend to watch the rest.

[Concept] Coding Tricks

I was reading an article of Dirty Coding Tricks that game developers use to meet deadlines or simply cut down work needed. Here's a few I found interesting (some of which were comments posted by readers):

"At university there was a team (not related to me, but these guys are the perfect example :P) that made a FPS flash game...

For some bizarre reason, the programmer instead of checking if you was colliding with the wall and not allow you go there, he made the inverse, he checked if there was a wall, and allowed you to move parallel to it...

This sparked a bizarre bug: In crossings, you could not actually cross, only turn to the passage on your left or right.

The deadline was closing, and they had no idea on how to fix it...

Then the team writer fixed the issue! He told the artist to draw a animation of hands touching the walls, and then he wrote in the story that the protagonist was blind and needed to touch the walls to know where he was going.

-Hélder Gomes Filho



Back on Wing Commander 1 we were getting an exception from our EMM386 memory manager when we exited the game. We'd clear the screen and a single line would print out, something like "EMM386 Memory manager error. Blah blah blah." We had to ship ASAP. So I hex edited the error in the memory manager itself to read "Thank you for playing Wing Commander."

- Ken Demarest



I was fresh out of college, still wet behind the ears, and about to enter the beta phase of my first professional game project -- a late-90s PC title. It had been an exciting rollercoaster ride, as projects often are. All the content was in and the game was looking good. There was one problem though: We were way over our memory budget.

Since most memory was taken up by models and textures, we worked with the artists to reduce the memory footprint of the game as much as possible. We scaled down images, decimated models, and compressed textures. Sometimes we did this with the support of the artists, and sometimes over their dead bodies.

We cut megabyte after megabyte, and after a few days of frantic activity, we reached a point where we felt there was nothing else we could do. Unless we cut some major content, there was no way we could free up any more memory. Exhausted, we evaluated our current memory usage. We were still 1.5 MB over the memory limit!

At this point one of the most experienced programmers in the team, one who had survived many years of development in the "good old days," decided to take matters into his own hands. He called me into his office, and we set out upon what I imagined would be another exhausting session of freeing up memory.

Instead, he brought up a source file and pointed to this line:

static char buffer[1024*1024*2];

"See this?" he said. And then deleted it with a single keystroke. Done!

He probably saw the horror in my eyes, so he explained to me that he had put aside those two megabytes of memory early in the development cycle. He knew from experience that it was always impossible to cut content down to memory budgets, and that many projects had come close to failing because of it. So now, as a regular practice, he always put aside a nice block of memory to free up when it's really needed.

He walked out of the office and announced he had reduced the memory footprint to within budget constraints -- he was toasted as the hero of the project.

As horrified as I was back then about such a "barbaric" practice, I have to admit that I'm warming up to it. I haven't gotten into the frame of mind where I can put it to use yet, but I can see how sometimes, when you're up against the wall, having a bit of memory tucked away for a rainy day can really make a difference. Funny how time and experience changes everything.

- Noel Llopis"

[Source: GamaSutra.com]

Code Optimization in Actionscript

3D graphics in Flash are usually handled by the CPU almost no assistance of any fancy 3D acceleration GPU. Thus, framerate is a very important concern.

I found a very useful guide on Code Optimization in Actionscript. For exampled, it states:

"Denormal numbers are floating point numbers that are really small. When such a number occurs the CPU switches into denormal mode and calculations become very slow.

Example

In this example the framerate will jump from approximately 40fps to 1fps. The reason are denormal numbers.


private var _denormals: Vector.;

private function init(): void
{
_denormals = new Vector.( 0xfffff, true );

var n: int = 0xfffff;

while( --n > -1 )
_denormals[ n ] = 1e-256;//very small number!

EnterFrameProvider.connect( enterFrame );
}

private function enterFrame(): void
{
var n: int = 0xfffff;

while( --n > -1 )
_denormals[ n ] *= 0.5;//do some calculations with very small numbers
}


ActionScript Solution

There are a couple of solutions to deal with denormal numbers. Some try to avoid them by adding always a very small value or by adding some white noise. In ActionScript the best and most simple solution is by adding and subtracting an anti-denormal constant.
[edit] Solution

Example

This solution is easy to implement in ActionScript and will result in real zero values.


_denormals[ n ] = _denormals[ n ] * 0.5 + 1e-18 - 1e-18;//avoiding denormals


This is the same example with the fix for denormal numbers. The framerate will now stay at approximately 40fps."