What I find surprising, though, is how many of my technically adept colleagues seem to be disgusted (or at least perturbed) at the disappearance of the ClickWheel.

Don’t get me wrong: The ClickWheel was a marvellous idea and worked really well… five years ago. It was a solution to the problem of providing a sleek touch based scrolling interface in the days before cheap multi-touch screens. This was also the time when the big iPods needed to fit a mechanical hard disk in the back – so there was this area on the face that needed to be filled with something eye-catching. Yes, the ClickWheel was great- I’ll continue to use one until my 30GB iPod Video decides to die.

But it’s 2010 now. We have solid state drives that can cram tons of information into a really tiny space. We have multi-touch interfaces that are just really beautiful and slick to use. Let’s enjoy the memories we shared with the ClickWheel as we lay it to rest and look forward to new innovations to come. Live in the now.

Oh, no, no, no, my friend! Surely you know that I’m running Micros~1 Outlook as my office mail client?

You see: Outlook knows what’s good for you, and apparently, security certificates are not. Indeed, Outlook will not allow me to access this file, or even give me the option of “Don’t worry, I know what I’m doing.”

[Here's a fun fact: The certificate was *sent* *using* *Outlook*. So, Outlook will happily send files that it deems to be unsafe, but the poor sap on the other end won't get to use it.]

Now, I tend to place a degree of value on others’ time. So it pains me to have to reply to someone saying “Hi, Outlook won’t let me open your attachment. Can you jump through hoops X, Y, Z to get it to me?”

Outlook used to simply be a poor email client. Now it has become actively counterproductive.

void VerifyListener() {…}.verifyText(VerifyEvent e)
Sent when the text is about to be modified.

A verify event occurs after the user has done something to modify the text (typically typed a key), but before the text is modified. The doit field in the verify event indicates whether or not to modify the text.

Wait, what?

What we basically want is a simple predicate function that returns true if the Contents of a Text Field are still valid after a change. What SWT gives us is this awkward event model where we have to modify the event that has just been generated. (In my opinion, events should be immutable, since they represent a historical occurence.) Next SWT will have a peek in the event to see how to proceed.

SWT is full of weird bagbiters like this.

For large applications it’s a major pain – much time spent compiling, starting up the program anew and returning it to the state you need in order to test your latest fix. Even for a fairly trivial change or a bit of experimentation, this is a huge timesink.

And yet there is an alternative approach – incremental compilation, à la Lisp. When the Lisp environment hits a bug it pauses. It shows you the location of the bug, it gives you a full stack trace at the time of breakage. You can inspect just about everything. Here’s the kicker: you can fix the code while the debugger is waiting. Then you can load that fixed code right back into the running program and continue on your merry way.

Let me repeat that last bit: You compile only the code that needed fixed and load it into the running program. The running program then continues using the new code. No stopping, compiling, running, getting back to where you were, debugging.

This is special. It’s not even that new. Lot’s of hip, young, dynamic languages are attempting to copy it. Let’s now, in 2010, make an attempt to catch up to the technology of 50 years ago. We owe the founding hackers that much, right?

1) When you reach an exceptional condition, the correct response in debug mode is to freeze the program and allow the developer a chance to inspect the current state. Stack, Heap, location, all that good stuff.

Throwing your arms in the air, screaming bloody murder and throwing away all the useful information when an error occurs is not useful. It turns debugging java into a game of “How close can you get to an error, without actually reaching the error.”

If you reach the error you lose the game, along with any useful data that might help you fix it.

2) You only seem to allow me to put breakpoints on lines on code. This implies that I already know where an error is. If I did, I’d probably fix it.

Why can’t you let me break on more useful things like when a particular variable has a particular value. This is similar to the previous point where I don’t want the program to drop everything and run away before I can look into it.

3) In 2010, the best way to debug a Java program is to pepper it with Print statements. This is sad.

Hopefully this is only temporary.

It can be used to compute the fibonacci sequence:

It’s simplicity is elegant, but, frightfully inefficient. In fact, the recursive definition of fibonacci is often used as an example of an inefficient method. Let’s look at why it’s poor. When fibonacci is called for a value of n there are two possible paths the program can take:

1. If n <= 1 give back the value of n
2. otherwise return the sum of the previous two numbers in the sequence

So, if n is 0 or 1 then the value is simply 0 or 1 respectively. This is the base case of the function. In other words, from this piece of concrete knowledge, we can derive the remaining values. If n is any value higher than 1, then we need to actually compute what it is. Notice that this case requires fibonacci to be called another two times.

This imposes significant overhead on the machine. In addition to this, the results of these two function calls must be added together. That means we need to hold onto some space in memory to store the results. Simplistically, we refer to the number of significant function calls as the time complexity of the program, and the amount of memory required as the space complexity. Fibonacci sure is expensive.

Anyway, this got me to thinking. What is the main problem with fibonacci? It’s the fact that it must repeat a lot of its calculations. If we want to find the value of Fib(5), we must call Fib(4) and Fib(3). But wait: To find the value of Fib(4) we must call Fib(3). Hence, we do the same operation twice. What if we could tell the program to remember a value once it had been found? Wouldn’t this speed things up? Can this be done without sacrificing the simplicity of a recursive method?

Here’s a modified, partial fibonacci function:

This one is a little more involved, but don’t panic: It still does the same thing, in much the same way. It has an extra trick though: Before it attempts to compute the value of n, it check to see if it already has a value. It looks in a structure called a hash table (any type of lookup table should do). Think of this like a telephone directory. If you know someone’s name, you can look it up in a phone directory and it will tell you their number. In our hash table, if you know a value of n, you can look it up and find its fibonacci value. Of course, some fibonacci values won’t be listed just yet. If there is no value in the table, we continue with our normal process: If n <= 2 then return 1. If n is greater than 2 then we find it’s value by adding the previous 2 fibonacci numbers. Now we have one more change to make: Having just found this new value of Fib(n) we store it in the hashtable. This means we won’t have to do the hard work of finding it again later – It’s already there!

Now, this act of remembering our previous work means that we must use a bit more memory, but the gain is a remarkable improvement in speed. Today, memory is pretty cheap, so this is not a bad thing. Look at the method we used. We start with a function that must call itself with a smaller value in order to discover a new value. When we discover a new value, we store it in a table so that we can quickly find it later.

This could most likely be generalised for any function that follows this pattern. There’s another blog post for when I get time to look into that aspect of it. If this post was about the optimisation, the next will be about abstracting that into a common pattern.

I hope this was of some interest. It was just a little thing I thought about this afternoon then decided to try it out. After I tried it I thought it might make a quick, informal blog entry.

Update: It seems that I have inadvertently stumbled across the definition of memoization which was conceived in 1968! It’s fun to try something out and then learn about a formal definition of the same principle. The act of developing an example gives it more meaning. (Further reading: http://en.wikipedia.org/wiki/Memoization).

I’ve been thinking recently (and informally) about a schism in game design that seems to be developing. I think in part it’s due to the seeming rise in popularity of Role Playing elements within games. When I say Role Playing elements I’m talking specifically about the idea of the player assuming the role of a protagonist from an early stage and gradually building that character; resulting in, for example, more powerful options during play, unlocked equipment, more locations or simply to make the character look better. This typically happens when a player has accumulated enough experience points to ascend to a new level of play. Experience points are typically accumulated by applying the skills previously unlocked. This idea has started to become more pervasive even in games not commonly associated with character building. Examples include puzzle games (Puzzle Quest, Puzzle Pirates), First Person Shooters (Borderlands, Call of Duty), Racing Games (Forza, Need for Speed) and of course those games which are naturally Role Playing Games (Dragon Age, Mass Effect, Oblivion, Fallout 3, Pokémon, …and many more). (Note: Shameless list of some of my favourite games.) For me, this additional mechanic adds a new dimension to the game: Narrative. I like stories and I like characters.

The observation I wish to describe is the contrast between two different ways of presenting this narrative information to the player. I don’t wish to claim that one method is more correct than the other. Although I think that there are merits and danger for each that should be considered. It is these points I wish to briefly outline. Also: I’m not an expert in this area but I do enjoy games.

Introduction to RPG mechanics

Originally, I included this section in the description for Case 1. As it grew, I decided it merited it’s own section. Note: Some games will use different ideas; this is only intended as an example. I’ll describe a simplified Dungeons and Dragons style method.

In traditional tabletop games (using pen & paper, or boards) mathematical functions were devised as a way to roughly model expected outcomes of conflict/encounter. The idea was to avoid leaving everything to pure chance (dice rolls), but instead to modify the outcome of a dice roll based on the characters abilities. for example, A strong character will deal more damage, however, the range of damage is still affected by stamina and the type of armour the opponent is wearing. The dice roll itself merely introduces the idea of something going wrong, e.g. “Your character slips when swinging his weapon and only manages to graze your opponents forearm.”

It is not limited to performing moves in battle. Some characters in the game will have the ability to lie or persuade to gather information. These outcomes will also be based on the characters skill. Modified by the second person’s skills at detecting lies or flattery, and a chance dice roll. For example, “You attempt to impersonate a foreign diplomat to gain information…” “…however, the guard is not fooled by your accent.”

As your character gains experience, your chances of successfully exploiting a skill increase. On the tabletop, there was no computer to perform these calculations for you, so all of the functions where exposed to the players.

Case 1: “The D&D Method”

Yes: I’m bad at naming but it fits with the introductory example. In this case the player is given the raw numbers: “You will do 5 points of damage per hit. Your foe has 8 points remaining.” This is demonstrated in the Pokémon series, Neverwinter Nights and Eve Online for example. This hails back to the tabletop method.

The benefits of having all the raw information are arguably that you can make strategic decisions by testing the mathematics in advance and your plans can be optimised by carefully adjusting the variables. The drawbacks, perhaps, are that the intended purpose of the functions – to provide a model for realism – are not achieved. i.e. The game is reduced to nothing more than balancing equations.

Case 2: “The Once-upon-a-time Method”

The titles get worse, but what I’m getting at here is that in this case, a lot of the raw information is hidden behind a façade which is more abstract or opaque. This tends to present in games which are more about advancing a plot than performing the precise strategic operations. Abstraction may ranges from cosmetic change (Displaying bars and graphics in place of numbers on screen) to making the game logic fuzzy (“Character is big and strong”, instead of “Character has weight 55 and strength of 60″). City of Heroes by default will show simplified hints about the underlying attributes while Mass Effect 2 gives the impression that knowing the exact power of every attack is not significant for the player.

The benefits here are that you can find ways to hide the games computations from the player and present them with only the experience of the characters and story progression. The player has enough information to decide how the character will develop and move from event to event but without micro-managing individual attributes. The drawback is in giving less control to the player.

Thoughts/Conclusions

Already? Well, this wasn’t intended to be a thoroughly detailed examination or case study. It was just putting down some thoughts into a post. At least my host will know I’m still alive.

If I have one concrete opinion, it’s that a computer game has the wonderful advantage of having a calculator sitting underneath it. To this end, the mathematics of the games progression shouldn’t come at the expense of immersion into the game’s world. Of course, in some games, the math is central to the objective and shouldn’t be compromised. However, for any functionality that can be delegated to the computer, the designer should attempt to make the presentation as natural for the player as possible.

The key challenge is finding the right balance between giving the player absolute control of the numbers and presenting the player with an abstraction of the information that is compelling as a story.

• GLUT C++ Project – Initializes GLUT and creates a scene containing a cube which can be rotated using the keyboard arrow keys. toggle an axis widget using ‘w’, toggle fullscreen using ‘o’ and exit using ESC. The FPS is displayed in the titlebar.
• WxWidgets C++ Project – Initializes a WxWidgets based app with an empty frame.

Nethack with Status Colors and Menu Colors

Unfortunately, because the two patches I’m applying have resulting conflicts- it meant manually applying the patches to the source code in some cases (also: I’m lazy). I, therefore, don’t have an elegant method of actually applying the two patches that I can pass on. What I am doing instead is providing two things: The complete refined archive of the patched Nethack source which should be ready-to-compile on OS 10.6; And also the .diff file produced from a vanilla copy of the source and my own patched version. I will also provide my new updated nethackrc file. (ok… 3 things )

Here’s some details about the setup this provides:

1. The Status Colors patch is applied. This is a configurable patch allowing you to color code status effects – hunger, blindness, HP, Gold, AC, etc. It’s very, very cool!
2. Menucolors patch applied. This is a configurable patch that let’s you apply colors to popup menus. e.g. inventory items can be red for cursed, green for blessed, etc. Again, this patch is very neat!
3. The initial configuration for getting Nethack to build on mac has been taken care of.

So Here are the links to get everything up and running. I should say at this point that this stuff works on my machine and YMMV. If something is broken and you want my to take a look at it just leave a comment of send an email – I’ll try to fix it if I have time. You may also want to dig through the changes in the patch.

1. nethack-3.4.3-patched.zip
2. nh343-_menustatus_orig.diff
3. .nethackrc

I hope this is useful for someone who wants a nice shiny setup of Nethack on Snow Leopard.