Some funny program I made as an experiment - it makes the data pointer travel inside the box and turn right if it meets any obstacle. Of course you can add obstacles in real-time with the Poke operation.
Maybe this could be made into some kind of game, but I definitely do not have so much spare time.

Nokia phones have the silly snake game. So perhaps you can make it like that.

No way, someone should make a full-featured Blackjack: split, doubledown, surrender, insurance, etc.

As I have some ideas for Challenger 2.0, but it is likely I will not have any time to work on it soon, I'm going to write them down here, so they can wait for better times.

What I'd like to have is to get a kind of Core Wars, so Challenger 2.0 would allow unlimited multithreading - there would be a new instruction 'f', splitting any thread into two, the second one traveling perpendicularly. Each thread would have its own accumulator, DP and SP, but they all would share the same plane. So that they would be able to compete, communicate, and perhaps even interact in other interesting ways. Any thread reaching an exception state would simply vanish.

As for the interpreter implementation, it would be optimized for more large-scale operation. The plane would be divided into large blocks, each one connected to four neighbours (just like the segments in Challenger 1.0), or with zero pointers when at the edge of allocated rectangular space. When plane needs to be expanded, the new row of blocks would be allocated and linked to the blocks on the current edge (again, like with segments in Challenger 1.0). Interpreter would start with just one block allocated.
Internally, each block would consist of pointers to segments - each segment being a rectangular part of plane, like 100x100 cells. When some part of plane was not initialized yet, the pointer would still be zero, and the segment would get allocated only when needed. One block would be 100x100 segments, and since pointer to segment and cell would have the same size, the block data and segment data would be of the same size as well (well, it's not really important, but nice anyway).

Large scale would be necessary to try to simulate some evolutionary behaviors. Perhaps some randomization features would be needed to add, too (though I'm not really sure about this one, see the article about Tierran Mutants linked earlier in this thread).

Tomasz Grysztar, there is a bug in your interpreter: pop edi after .program_initialized is excess as it actually pops an lpvAddress argument for VirtualFree, and thus changes ControllerDialogProc return address. It works in XP by accident, but in 9x it reboots/hangs an OS.

Thanks, I updated it.

ok, it was the cause of the reboot i had when i tryed it... then, it's time to retest it.