A road named NoNameUno

I will have to switch to a new direction, since building multiple kernel sources seems to be a bit of a problem. I'm actually trying to have both openmoko and beagleboard environment simultaniously...

Well, for the application side I'm trying to comeup with a GUI interface that does not have rectangular boundaries for the controls. So for example if I've a bucket of fruits, and I click on banana, it should tell me which banana I picked...

I will get back to android kernel port soon ...

Before I dive into the detail of my application I would like to explain a bit about combinatorial games, and programming challenges involved in them.

Combinatorial games are in general two party or single party games like: Chess, Nim, Hackenbush etc. The beauty of these games are that one party can be the computer and there are already rich bodies of mathematical formulations for them. Also most of them has combinatorial explosions so effecient handling of data structures and algorithms are central to have a decent experience for users. Also some of these games have evaluation processes that quantifies the chances of winning. When an user plays these games, they can not possibly calculate the chances of winning, but for fairly large configurations of these classes of games, computer can detects the chances, a play accordingly.  Moreover the configurations of these games can sometimes be randomly generated, placed on the board for other party ( an user) to play. Easy games, not so easy games, and difficult ones can be placed as an user become more and more familiar with the games and builds intuition.

In my next few blogs, I will try to clarify the process or approach I'm taking to implement some instances of combinatorial games. But it requires some of the following -

• Given a configuration, can I quantify the game value. And chance of winning.
• Does it really matters if the user start first or the computer starts first?
• What, if any chance, of declaring that no matter how hard you try, you gona loose to your opponent (computer).
• What are the fundamental types and data structures we need to use.
• What are the performance problems we are likely to hit when we set out to implement.
• How to represent these to an user - User interface related stuff.
• Finally how much I can carry from one game to another type of game - Reusability.
• How do we classify the hardness of the configuration?
• How do we generate and place those configurations in increasing order of difficulties?