My advice would have been to reinvent the wheel. Yeah it might not add to anything useful but there is an off chance it could. The reason why reinventing the wheel is good is that you have direction as to what you should implement. Trying to do something new all the time isn't possible.
I used to build tic tac toe games It was never complete or useful but it helped me learn the tech I was using. Now days creating a blog engine is my new tic tac toe.
One of the coolest programs I ever made was a tic-tac-toe with an AI that learned the optimal strategy by playing itself over and over. I wrote that in the process of learning Lisp, which made writing the program easy, and I got to exercise a lot of the language features.
What was so cool about it was watching it learn, and realizing that unless I programmed it to make random mistakes, it would settle for sub-optimal strategies.
It's simulated annealing specifically when you start with more tolerance for unfavorable random mistakes, then gradually move toward only accepting random variation that improves.
>I believe the AI strategy you describe is known as "simulated annealing".
Not necessarily. You could get much the same effect (the program learning by playing itself over and over) with many Reinforcement Learning algorithms (like TD learning, say).
There are major differences between Value Function (loosely, perceived_state -> perceived_long_term_reward map) based RL algorithms and algorithms that work only in the policy (loosely, the perceived-state -> chosen_action map) space like Simulated Annealing (or Genetic Algorithms). Barto and Sutton (somewhat loosely) use the term "evolutionary algorithms" to distinguish Value Function based algorithms from those that only manipulate policy
Agreed. I find that when you're actually building something, that's when the great ideas come. You start to think of improvements and new approaches that you just can't think of without first getting your hands dirty.
I haven't done this myself (not enough experience) but I saw a similar idea discussed years ago - for an experienced programmer learning a new language, reimplement something you have already written in the new language. Supposedly, the fact that you had written the first application shows that you understand the problem domain, so you can concentrate on the new language.
Yup, just try it, make the board and how to check if someone won or if it's full, figure out how to get input from the user. Then if you like the language move to implementing a simple ai (start with randomly putting pieces ;p).
By then you should know a good chunk (IO, loops, built in data structures ...)
I have never done any graphics at all. All I know is bash and some awk and perl, mostly for text processing. I keep planning to learn more, which is why I read about it a bit, and browse HN, but I have too many other things I want to do too.
o | o | o
----------
x | x | x
----------
o | o | o
That (if HN doesn't mangle it) should be a fully working Tic-Tac-Toe board. You can store it as a string, hashtable, whatever you want. You could label the squares 1-9 for the prompt asking the user where to move.
This is all doable with perl and a command line. Try it out, see what you learn.
My first implementation (in c++) was exactly like that. A 3x3 array that printed out like that. You had to enter 1,1 for the left upper corner (that's how I learned that arrays start at 0 in almost all languages ;p)
I used to build tic tac toe games It was never complete or useful but it helped me learn the tech I was using. Now days creating a blog engine is my new tic tac toe.