Friday, October 7, 2011
Steve Jobs once said
"Live every day as though it were your last." Absolutely, do not do this. You will be wrong for every day except for one.
Wednesday, September 14, 2011
Some funny code...
I often sigh while reading the source code at me new job. Occasionally, I have a few laughs too. For example:
I'm not sure what it is about exception handling but it seems to be the most frequently mis-understood/mis-used area of programming C#. The lines above are not nearly has bad as:
which I've seen a lot of too, but it's more of a sigh moment than laugh.
catch (Exception exception) { throw new Exception(exception.ToString()); }
I'm not sure what it is about exception handling but it seems to be the most frequently mis-understood/mis-used area of programming C#. The lines above are not nearly has bad as:
catch (Exception exception) { }
which I've seen a lot of too, but it's more of a sigh moment than laugh.
Labels:
c#,
programming
Thursday, August 25, 2011
I ran home after work tonight...
I ran home after work tonight; first time ever. What would spur on such extreme activity? I've been wanting to run/ride more frequently, but it's been difficult to find the motivation. I thought back to a time where I always tried to ride just that little bit harder. Turns out that was when I had a bike computer. It was decided, geekdom is to be my exercise motivator.
Last week I bought the Forerunner 310XT, designed for running and riding. It has a heart rate monitor, cadence monitor, and a GPS for tracking a whole bunch of data.
After installing a bunch of drivers and plugins, I updated the 301XT's firmware and was ready to go... Except first you need to plug in your height, weight and age for energy burning calculations. Then setup the display screens, make sure the HRM is detected, turn on/off auto settings like auto pause (for traffic lights, etc.), auto lap, and auto scroll. It's all very detailed. Thus far, however, I've been very happy with the features and user interface.
I think the exercise plan is going to work. I barely noticed that I was running, too busy looking at BPMs, time/distance, and trying to outrun my virtual partner that was doing 5:45 minute kms. The jerk beat me by 2mins.
My first run is recorded on the Garmin website.
Last week I bought the Forerunner 310XT, designed for running and riding. It has a heart rate monitor, cadence monitor, and a GPS for tracking a whole bunch of data.
After installing a bunch of drivers and plugins, I updated the 301XT's firmware and was ready to go... Except first you need to plug in your height, weight and age for energy burning calculations. Then setup the display screens, make sure the HRM is detected, turn on/off auto settings like auto pause (for traffic lights, etc.), auto lap, and auto scroll. It's all very detailed. Thus far, however, I've been very happy with the features and user interface.
I think the exercise plan is going to work. I barely noticed that I was running, too busy looking at BPMs, time/distance, and trying to outrun my virtual partner that was doing 5:45 minute kms. The jerk beat me by 2mins.
My first run is recorded on the Garmin website.
Labels:
exercise,
Technology
Friday, July 15, 2011
Tools for learning F#
Every few months I try to learn me some more F#. It isn’t easy.
I stumbled across a nice learning tool by Chris Marinos. It works on the premise that you learn by making the unit tests pass (initially, they all fail). It's a nice idea. The only issue is that the testing framework it uses was written in NUnit. I don't use NUnit anymore. With a couple of little changes I switched it to Microsoft's unit testing framework. You can get my version here.
There is also http://www.tryfsharp.org/. It gives a good intro to F# that you can do online (don't need Visual Studio or nothink).
I tried to do some interoperability between C# and F#. When testing an F# console app in a C# test project, my functions didn't return results. I changed my F# console app to a F# library and it worked correctly. (Don't know why C# can't use an F# console app.)
I stumbled across a nice learning tool by Chris Marinos. It works on the premise that you learn by making the unit tests pass (initially, they all fail). It's a nice idea. The only issue is that the testing framework it uses was written in NUnit. I don't use NUnit anymore. With a couple of little changes I switched it to Microsoft's unit testing framework. You can get my version here.
There is also http://www.tryfsharp.org/. It gives a good intro to F# that you can do online (don't need Visual Studio or nothink).
I tried to do some interoperability between C# and F#. When testing an F# console app in a C# test project, my functions didn't return results. I changed my F# console app to a F# library and it worked correctly. (Don't know why C# can't use an F# console app.)
Labels:
c#,
f#,
Visual Studio
Thursday, June 30, 2011
Le Jeu de la Guerre thoughts
During 2005 I tried to make a computer game version of Le Jeu de la Guerre (war game) by Guy Debord. I never finished it. It didn't help that the translation was poor (and still is in the latest English translation. Corrections here and here.)
I stumbled on Kriegspiel again while writing a negamax algorithm to play noughts and crosses. Debord said of Kriegspiel:

Debord need not have feared, I doubt Kriegspiel will ever be accorded much value. It's not a terrible game, but it doesn't offer all that much either.
One concept that Kriegspiel does very well is the lines of support. I've always loved how you need to keep your units supplied from the arsenal and relay units, else they become useless. That idea is evocative and well implemented.
Nevertheless, I think Heller sums up the game nicely: "Between the arithmetic and the boggling geometries, it may, in fact, be reminiscent of a certain dream you had the night before the SAT." (What is it good for? Guy Debord believed his war board game would be his legacy)
Of more interest, however, is trying to determine who Debord was by the rules he defined for Kriegspiel.
Kriegspiel is a perfect information game. In war, there are spies, scouts, propaganda, miscommunication, stealth, radar, etc. I don't see how a perfect information game captures the "essential movements" of warfare. I wonder why he chose it. Did Debord not like leaving anything to chance? Was he always completely honest (wasn't interested in hidden units/movement)?
The terrain is asymmetric, yes, but the opponents face each other as equals. For someone who lived the class war, I find it strange that Debord didn't apply the asymmetry to the players. There has probably never been a battle where opponents faced each other with equal force. Not Bored discuss this lack of asymmetry in Dispensing with Clausewitz, though I don't agree with their defence of Kriegspiel/Debord. As McHugh points out, Debord would have experienced asymmetry in '68, yet it's not there in Kriegspiel. Yes, '68 wasn't a war but it was an armed conflict and even so, there are hundreds of historical examples of asymmetrical conflicts (Battle of Thermopylae, Battle of Rorke's Drift, US vs Vietnamese, US vs Afgans, etc.)
Debord designed Kriegspiel as a zero-sum game. Zero-sum games are great but they often don't reflect the subtly of reality. They are just on/off, binary type games. Zero-sum games are not what I imagine a communist or someone who thinks dialectically would create.
Still, Kriegspiel is an interesting game. I noticed that the two computer implementations of it don't have a computer opponent. One day I might get around to writing one. I wonder what Debord would have thought when a computer plays the game better than he could ever have.
I stumbled on Kriegspiel again while writing a negamax algorithm to play noughts and crosses. Debord said of Kriegspiel:
So I have studied the logic of war. Indeed I succeeded long ago in representing its essential movements on a rather simple game-board… I played this game, and in the often difficult conduct of my life drew a few lessons from it — setting rules for my life, and abiding by them. The surprises vouchsafed by this Kriegspiel of mine seem endless; I rather fear it may turn out to be the only one of my works to which people will venture to accord any value. As to whether I have made good use of its lessons, I shall leave that for others to judge. (Panegyric, 1989)

Debord need not have feared, I doubt Kriegspiel will ever be accorded much value. It's not a terrible game, but it doesn't offer all that much either.
One concept that Kriegspiel does very well is the lines of support. I've always loved how you need to keep your units supplied from the arsenal and relay units, else they become useless. That idea is evocative and well implemented.
Nevertheless, I think Heller sums up the game nicely: "Between the arithmetic and the boggling geometries, it may, in fact, be reminiscent of a certain dream you had the night before the SAT." (What is it good for? Guy Debord believed his war board game would be his legacy)
Of more interest, however, is trying to determine who Debord was by the rules he defined for Kriegspiel.
Kriegspiel is a perfect information game. In war, there are spies, scouts, propaganda, miscommunication, stealth, radar, etc. I don't see how a perfect information game captures the "essential movements" of warfare. I wonder why he chose it. Did Debord not like leaving anything to chance? Was he always completely honest (wasn't interested in hidden units/movement)?
The terrain is asymmetric, yes, but the opponents face each other as equals. For someone who lived the class war, I find it strange that Debord didn't apply the asymmetry to the players. There has probably never been a battle where opponents faced each other with equal force. Not Bored discuss this lack of asymmetry in Dispensing with Clausewitz, though I don't agree with their defence of Kriegspiel/Debord. As McHugh points out, Debord would have experienced asymmetry in '68, yet it's not there in Kriegspiel. Yes, '68 wasn't a war but it was an armed conflict and even so, there are hundreds of historical examples of asymmetrical conflicts (Battle of Thermopylae, Battle of Rorke's Drift, US vs Vietnamese, US vs Afgans, etc.)
Debord designed Kriegspiel as a zero-sum game. Zero-sum games are great but they often don't reflect the subtly of reality. They are just on/off, binary type games. Zero-sum games are not what I imagine a communist or someone who thinks dialectically would create.
Still, Kriegspiel is an interesting game. I noticed that the two computer implementations of it don't have a computer opponent. One day I might get around to writing one. I wonder what Debord would have thought when a computer plays the game better than he could ever have.
Labels:
board games,
Guy Debord
Tuesday, June 28, 2011
Computer Opponent: Noughts & Crosses
The next task on my list for making a strategy game is writing a computer opponent. In the tutorial I describe how I’ve used variations on the minimax algorithm to play noughts and crosses (tic-tac-toe). I chose noughts and crosses because it’s finite (always ends in 5-9 moves) and simple, yet there are thousands of different solutions. Eventually, I plan on using a minimax type algorithm for a game which will use the hex board tutorial I created in Unity earlier.
The C# source code for this project is available here.
The tutorial is available here.
The end result of this project is a console application that plays noughts and crosses with itself. It cycles through games using negamax, alpha-beta pruning and negascout. Every game is, of course, a draw. (You may notice that negascout is slower than alpha-beta pruning. This is because I haven’t ordered the search tree, it’s such a simple game that it isn’t worth it.) There is also a test project that runs a number of tests to make sure that the algorithms are doing what I expect them to do.
The C# source code for this project is available here.
The tutorial is available here.
The end result of this project is a console application that plays noughts and crosses with itself. It cycles through games using negamax, alpha-beta pruning and negascout. Every game is, of course, a draw. (You may notice that negascout is slower than alpha-beta pruning. This is because I haven’t ordered the search tree, it’s such a simple game that it isn’t worth it.) There is also a test project that runs a number of tests to make sure that the algorithms are doing what I expect them to do.
Labels:
c#,
Computer games,
programming,
Visual Studio
Friday, June 17, 2011
Unity, hexagons and path-finding
I’m creating a strategy computer game again. This time I thought I’d write some tutorials as I go. In this tutorial, I bring path-finding on an hexagonal grid together with Unity.
I assume a good knowledge of C# and no knowledge of Unity. If you know how the A* search algorithm works, you’ll probably be able to read all the code without any problems.
You can access the tutorial here.
The source code and Unity project file are available here (7zip).
A Windows binary is available here.
A Mac binary is available here.

I assume a good knowledge of C# and no knowledge of Unity. If you know how the A* search algorithm works, you’ll probably be able to read all the code without any problems.
You can access the tutorial here.
The source code and Unity project file are available here (7zip).
A Windows binary is available here.
A Mac binary is available here.

Screenshot of the result
Labels:
c#,
Computer games,
programming,
Unity
Subscribe to:
Posts (Atom)
