Stuart Hacking

One of the things I love about the Wii is the Virtual Console. It lets me play a lot of the games I grew up with without the need to sacrifice several power sockets, or swap out all the RF connectors when I want to switch console. So over the weekend I played a bit of Mario World and Zelda: Link to the Past. Awesome!

But then I downloaded Super Castlevania IV and tried to play it… “Mode not supported.”

“Uh, oh!” I guess it doesn’t like my TV, or perhaps the connector – even though I’m already using the Nintendo Composite cable. Surely the console should do the necessary work to send the correct signal?

I looked online and found a fix – but here’s the strange thing: The fix isn’t something like “Try using an old Co-ax cable,” or, “Change the Wii’s ratio to 4:3.” The actual fix is much better:

Start the game and wait for the ‘Mode not supported’ message.
Press the Wii’s home button.
Open the game’s Operation Manual.
Press the following keys together: “Z-A-2″
A chime will sound if you entered it correctly.
The game will now display on your HDTV.

…

Really?… I mean, that’s awesome! It worked, but this felt more like putting in a cheat code than solving a hardware issue. If you decide in the end that you don’t really like ‘being able to see the game’ you can go back in and disable the fix with the combo ‘Z-A-1′.

Self Console, fix, Gaming, HD, retro, TV, wii

Today I read some really crufty code. The whole application is a mess of String conversions. This is because every class in the model only contains String members. Regardless of whether the data is a number, a boolean, a currency value or a date. *Everything* is a String. This makes it very hard to visually (or programmatically) parse what is happening in a piece of logical code because:

1) A lot of methods take Strings as Arguments.
2) The compiler can’t do any useful type checking. Everything is a String.
3) Things like dates and currencies can have multiple representations. Strings provide no abstraction.
4) Logic is shrouded in conversion and other housekeeping.

I don’t which moron had the bright idea of storing everything as a String. They’ve probably been promoted to principle engineer or technologist now and don’t have to deal with the stink they created a decade ago.

Of course, bad code exists. Sometimes it’s a kludge to get round a language limitation, or maybe it’s a speed hack.

This is just depressingly bad design. There was never a time when Java only supported Strings. I won’t even accept serialisation as an excuse because a) Java has been doing that for years and b) If it’s done manually then it should be done once, not peppered thoughout the business logic.

It feels as though someone read a bunch of Design Pattern books, rushed through an example implementation as quickly as possible, and released it as a polished framework.

And people just accept it like it’s no big deal. Worse, some people seem to consider it flexible design.

Uncategorized Rant, Software

At a certain point on the Bureaucratic scale, you may start using Outlook for more than simply the exchange of messages: Tasks/Todo lists, Appointments/Calendar, Notes.

Too bad Outlook isn’t very good at anything it does.

Here are a couple of things I’d like to say Outlook provides to make life easier (I use Outlook 2003, not by choice):

• I flag messages and categorize them quite often. One would imagine that when a message  is flagged that it becomes a ToDo item and is added to the task list. If a flagged email has a follow up date, shouldn’t it appear in the calendar? I guess integration of different services was never a primary goal.
• I’d like folders to be able to tell me the number of flagged emails. Currently they only show total or unread (but not both). I often use folders to store actionable bulk mail. It would be nice to see how many tasks I’ve woken up to.
• When you flag email in a personal folder it does not show up un the ‘Follow Up’ search folder. I guess this is just a bug?

Self email, integration, Rant, Software

Apple have unveiled the shiny new iPod Nano range and they are sexy! Half the size of the previous model and sporting the same screen technology as the touch devices. Wonderful!

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.

Self Apple, clickwheel, ipod, music, progress, screen, touch

An important person in the company (all praise the company!) has just attempted to send me an updated security certificate by email.

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.

Self email, Rant, Software

Have a look at this documentation for a VerifyEvent in SWT:

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.

Programming Programming, Rant

The more I go through this cycle the more it amazes me that this is the development paradigm that won out. That back in the golden era people sat down and decided that this was the model of the future.

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 clincher: 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?

Self lisp, Programming, Rant

The latest update seems to have screwed up some plug-ins. Most notably the collapsible archives and source code highlighting.

Hopefully this is only temporary.

Self, Uncategorized blogging, error, update

Just some stuff I thought about today. Here’s a fibonacci function expressed in Lisp:

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).

Programming Computers, Emacs, hack, lisp, memoization, Programming

It’s not a great title but none of the other drafts I came up with were any better…

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”

These titles are getting 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

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.

Self fun, games, Math