I sort of did something similar for my Darts app for the iPhone, specifically for defining the throw model for the "AI" player.
I found it easiest to simulate millions of random dart throws parameterized by throw angle and velocity. I record the slot on the board (1-20, Bull) hit given the launch angles and force of the throw. I let this "simulation" run until I had 50 samples per board slot.
The simulation is run once ahead of time. The simulation results are bundled with the app.
When it becomes the AI's turn, it picks a slot to aim at based on the game variation and state of the game. Currently, it chooses rather poorly in Cricket.
Then it picks a random sample from the sample pool recorded from the aforementioned simulation. Based on the user-chosen competence level, it adds a small, random amount of error to the angle and velocity associated with the selected sample. Finally, the dart is launched using the calculated angles and force.
While the app is Objective C, the offline simulation was written in Python. The whole thing was a blast to write.
What is your take on CouchDB? After some initial investigation, I've all but written off CouchDB for anything moderately write-heavy due to its single writer at a time design. I'm by no means an expert on that however. Please tell me what I'm missing about CouchDB.
I tested various NoSQL solutions including CouchDB for my research work. It was the most pleasurable to work with, but by far the slowest. Bulk inserts weren't an option for me, so I had to insert each document one at a time. Insertion time averaged at ~2.5 seconds(!) These documents were very small, and the insert operations were single-threaded, so the write lock wasn't an issue. Compare this with ~150 microseconds on the datastore I implemented instead, or (from what I remember) even better performance on Tokyo Tyrant.
I used CouchDBX on a MacBook laptop with no adjusted settings. Something must have been off, but after reading so many articles talking about how alpha the product was and hitting these insane performance limitations, I wasn't willing to venture any further in experimenting with it.
CouchDB is conceptually promising (especially when combined with HTML5 - that's an awesome solution waiting to happen) but its performance is crippling IMO. I can't wait until the team starts focusing on performance tuning. Perhaps then we'll see a very practical and useful datastore.
Yep, Damien's patch greatly improved CouchDB's write throughput for the case where you've got a pool of processes trying to write to the same DB simultaneously.
I disagree. I would only even consider using a schemaless DB in a case where I need high performance logging of unstructured data. We use it at work as a hot cache and as first line click & impression tracking.
I wouldn't be remotely impressed that it could serve a blog. It would be meaningless to me.
This reminds me of a funny Cracked skit about the 1979 game developer's conference wherein the birth of Frogger was reenacted. "Ok ok you are a truck driver and you try to run over frogs crossing the road". "No, no, you ARE the frog!" "Whoooa"
I found it easiest to simulate millions of random dart throws parameterized by throw angle and velocity. I record the slot on the board (1-20, Bull) hit given the launch angles and force of the throw. I let this "simulation" run until I had 50 samples per board slot.
The simulation is run once ahead of time. The simulation results are bundled with the app.
When it becomes the AI's turn, it picks a slot to aim at based on the game variation and state of the game. Currently, it chooses rather poorly in Cricket.
Then it picks a random sample from the sample pool recorded from the aforementioned simulation. Based on the user-chosen competence level, it adds a small, random amount of error to the angle and velocity associated with the selected sample. Finally, the dart is launched using the calculated angles and force.
While the app is Objective C, the offline simulation was written in Python. The whole thing was a blast to write.
Here's an old video of gameplay:
http://vimeo.com/2010432
Skip ahead to around 1:10 to see the AI take its turn.