2) Do small, quick projects to build confidence. Write a calculator to compute Bayesian probabilities, or an alarm clock. Start small! Once you’re comfortable with that, pick a simple game (Checkers, TicTacToe), break it down in to “issues”, and slowly work on finishing each one. Just focus on “draw a board” first, then “allow player to place marks”, then “alternate between two players”, and finally “check for victory”. If you’re feeling comfortable after all of that, feel free to write an AI to play the game, or pick a more complex game like Chess or Go and implement that.
This is a lot of how I built up my own skills. I also downloaded open source video games and went through their source code to see how they implemented it. For some games, you’ll learn what not to do. For others, you’ll see some fairly advanced techniques illustrated. Quality varies :)
For #3, after I’d done #2 for a while, I started offering patches to open source games, as well as joining a development team for one that was incomplete. I’m not real sure exactly how you’d go about finding an interesting project; I usually just happen upon them because I want to fix a bug in LessWrong source, or a friend had discovered a new board game and the only computer version isn’t finished yet, etc. :)
#1 Is probably helped dramatically by addressing the others. Small, manageable chunks help me when I’m running in to this. Having a specific “to do” list that I can go through methodically is also wonderful. “Program TicTacToe” makes me anxious, but “draw a tic tac toe grid” is something I could do in my sleep. As an added bonus, I get to check things off a list, which is a guilty pleasure of mine ^_^
I personally use GoogleCode for storing everything. It’s got nice built-in SVN support and issue tracking, which works wonderfully for me. If you’re not yet used to using SVN for source control, it’s a great way to learn :)
2) Do small, quick projects to build confidence. Write a calculator to compute Bayesian probabilities, or an alarm clock. Start small! Once you’re comfortable with that, pick a simple game (Checkers, TicTacToe), break it down in to “issues”, and slowly work on finishing each one. Just focus on “draw a board” first, then “allow player to place marks”, then “alternate between two players”, and finally “check for victory”. If you’re feeling comfortable after all of that, feel free to write an AI to play the game, or pick a more complex game like Chess or Go and implement that.
This is a lot of how I built up my own skills. I also downloaded open source video games and went through their source code to see how they implemented it. For some games, you’ll learn what not to do. For others, you’ll see some fairly advanced techniques illustrated. Quality varies :)
For #3, after I’d done #2 for a while, I started offering patches to open source games, as well as joining a development team for one that was incomplete. I’m not real sure exactly how you’d go about finding an interesting project; I usually just happen upon them because I want to fix a bug in LessWrong source, or a friend had discovered a new board game and the only computer version isn’t finished yet, etc. :)
#1 Is probably helped dramatically by addressing the others. Small, manageable chunks help me when I’m running in to this. Having a specific “to do” list that I can go through methodically is also wonderful. “Program TicTacToe” makes me anxious, but “draw a tic tac toe grid” is something I could do in my sleep. As an added bonus, I get to check things off a list, which is a guilty pleasure of mine ^_^
I personally use GoogleCode for storing everything. It’s got nice built-in SVN support and issue tracking, which works wonderfully for me. If you’re not yet used to using SVN for source control, it’s a great way to learn :)