Have you used Perl? Did you enjoy it? You strange bastard. I have a very simple criteria when it comes to programming languages: if I can comprehend the code of something I did a year ago, then it’s a good programming language. I like maintainability and intuitive naming; it’s pretty hard to mistake what int or float means for example. I can return to 6502 Assembly, Pascal, x86 Assembly, C, C++, Ada, Lisp, 68k Assembly, Scheme, BlitzMax, Java, HTML, PHP and a dozen other languages long after I’ve stopped using them, and I still understand decently what I wrote ages ago. But not so with Perl. Perl is the devil’s plaything.

Okay, enough Perl bashing – it’s not really a bad language at all. It’s devilishly efficient at text manipulation and everything else involving regular expressions, for example. But I simply can’t remember Perl syntax; it’s like a black hole in my mind. Everything I pour into it that concerns Perl gets swallowed up. I can look at Perl code I wrote a few years ago and have no idea at all what it’s supposed to do! So I guess Perl is a little like pearls before swine in my case. Perl before Karja could be a new proverb.

Incidentally, did you know that the Japanese have a similar expression? Similar to pearls before swine that is. Neko ni koban apparently means gold coins to a cat. Not that I’d know – I just know what neko means. I think the most advanced Japanese phrase I can put together is watashi no soseji wa ookii desu yo!

Aanyhoo, the reason I started ranting about Perl is this excellent article I found called You Used Perl to Write WHAT? It shows five good reasons for when you should use Perl…and some situations where it’s just not appropriate at all. I don’t agree with everything. Take number 3 of the good reasons for example:

A replacement for shell scripts: One of the worst things about shell scripting—whether in bash, sh or csh—is that the syntax of the scripts themselves is fairly hard to read. By using perl as a scripting language instead of a “traditional” shell, you can use much more C-like syntax without sacrificing functionality.

I may or may not be biased but I find shell scripts infinitely more useful than Perl scripts. For one thing, they are more maintainable. Even though sed and strange syntaxes are black magic, it’s possible for another person to decipher what shell scripts are supposed to do. Unlike Perl, which is made for supernatural gods!

Finally I can end with an amusing anecdote. A friend of mine went to a job interview where they asked him if he’d ever written some Python. “Python… Oh! Yeah, sure – I know that!” So they gave him some code to modify, whereupon he stared blankly for a few seconds before he realized “Damn, it’s Perl I know – not Python! I’ve never seen a line of this before in my life!”

He got the job anyway. He was able to understand Python decently based on the examples, and had made a good impression during the rest of the interview. See what I mean about code readability? Could you understand how to construct a new regular expression after having looked at some Perl code?

Mathematics is not one of my strengths; if I put my mind to it I can get by,  but I lack the discipline to become skilled at it. I’ve read some calculus and algebra and combinatorics and statistics and whatnot, but in general I’ve just taken some courses only to forget everything I’ve learned shortly afterwards. The only maths I use regularly, except for simple arithmetic, is trigonometry. (It’s quite useful for 2D games.)

Logic is a completely different matter though. My job as a software developer at a Large Multi-National Corporation(TM) demands that I keep many of my skills sharp: the ability to juggle many ideas and projects, the ability to deal professionally and courteously with customers, and the ability to drink copious amounts of tea. Oh, and let’s not forget the ability to actually write code. Many non-programmers seem to think that maths is necessary for programmers, but in reality it’s logic that’s in high demand.

Speaking of skills at work, another thing that I tend to do there is solve sudokus. I find great comfort in spending my lunch breaks listening to the ongoing conversations while I solve a sudoku and – if something interesting pops up – add something to the discussion. Solving a sudoku is relaxing; you know that it’s solvable as long as you apply some logic, so you can take your mind off the possibly-unsolvable problems facing you in real life. At one time I did many sudokus per day, but now I limit myself to at most one for the sheer pleasure of it. A friend of mine mentioned that sudokus can be used to measure stress as well: if you find yourself taking too long on a standard sudoku, it might be an indication that you’re too stressed to think straight at the moment. True enough, but I find that if I’m too excited about something it also makes it hard to concentrate on the problem at hand. But then again, I suppose that that could be classed as stress as well, albeit of the positive kind.

Incidentally, speaking of sudokus, did you know that Benjamin Franklin used to amuse himself with mathematical puzzles similar in principle to sudokus when he was not busying himself with inventing just about everything you could imagine? Read the article and be amazed at the 16-by-16 magic square with bent rows that Franklin devised. You know about the magic square, where each line has to add up to 15? This is a magic square where each line has to add up to 2056. And all the coloured areas also have to add up to 2056. I’m just shaking my head at the complexity of the puzzle.

Read the article above to see more puzzles.

At one time I was pondering if I could devise a meta-puzzle game, where each puzzle mechanism would be unique, and one part of the problem would actually be to figure out the rules themselves. I started examining the sudoku to get inspiration, and quickly decided that it’s above my current skill to actually bring that idea to life. The idea is seductively simple: create a formal definition of the sudoku, and then expand that definition to encompass other mathematical puzzles. After you have created a suitable grammar of mathematics puzzles, you simply create a generator for new exciting puzzles. But in reality, this is much too complex for a layman in mathematics.

However, after having read about Franklin’s exploits in the puzzle domain, I wonder if this would have been something he would have enjoyed to create.

Today I browsed a DDJ article called C++ Hash Table Memoization: Simplifying Dynamic Programming, and I was immediately struck by a feeling of “why the hell didn’t I think of this!” If you’re not familiar with Dynamic Programming, here’s a very very brief summary:

When solving a problem you often encounter overlapping subproblems which – if you implement the solution algorithm naively – causes a sub-solution to be calculated many times. The most famous example of this is the Fibonacci sequence: 1, 1, 2, 3, 5, 8 and so on. Here’s an example pseudo code snippet stolen from Wikipedia which calculates a Fibonacci number naively:

function fib(n)
if n = 0 or n = 1
return 1
else
return fib(n + 1) + fib(n + 2)

From the code you’ll note that when trying to calculate, say, fib(5), you’ll calculate fib(3) more than once. Dynamic Programming is basically saying “hey, let’s stop being stupid! If we make sure that the result of fib(3) is only calculated once we’ll save a lot of time!” Quite so. Dynamic Programming may have the most idiotic name ever, but the idea is elegant and very efficient for certain problems.

The Wikipedia article then goes on to mention two DP approaches: top-down, and bottom-up. I’m getting all hot and bothered from mentioning both DP and bottom in the same sentence, but I’ll try to control myself. Bottom-up DP is essentially a way of restructuring the algorithm from a recursive solution to an iterative one, while top-down retains the recursive structure but uses an array for storing the calculated values. As the DDJ article mentions, arrays are most commonly used for storing values…and that’s where the real beaty of the DDJ article’s suggested improvement kicks in.

An array may be inefficient for some problems, so use a hash table instead!

In that short sentence I think I’ve summarized the whole DDJ article; the actual implementation of the proposal is irrelevant, and nothing else is particularly new or exciting. If not for this short addition to what’s already presented on Wikipedia I would’ve claimed that the article was dull and pointless – but now it turned from cow dung into gold! It’s amazing how a small idea can have such an effect. And of course, the fact that it’s such a small idea is what causes the I-Coulda-Thought-of-That reaction that’s oh-so-common.

To end on a high note, here’s a little fib for you:

Left
Right
Top-down
Bottom-up
I don’t give a damn
Just don’t waste any precious RAM

Jamie Fristrom has some opinions on Test-Driven Development after using it for a year, and it seems that they’re mostly negative. It’s quite interesting to compare this with his experiences with TDD after only a few weeks.

Some interesting observations:

After a few weeks:

TDD is forcing me to pay more attention to the code, and I’ve actually found bugs just from studying it.

After a year:

Frankly, I’m disappointed. I was hoping for a bigger, more obvious win.

The number of “false positives” – tests that break because my assumptions changed – greatly outnumbers the number of real bugs really caught.

Also, they say it improves your code quality. Frankly, my code quality is worse, as I frequently expose things I wouldn’t have exposed so I can get them under test more easily – and other abuses.

Quite a different story after a year, and I’m not really sure I agree with his final word. Code quality is subjective of course, but in my experience TDD often results in more clearly defined interfaces. Sure, sometimes one needs to expose methods and functions that could have been strictly internal, but they are often more well-defined and….well…functional, with a clearly defined purpose.

After a few weeks:

TDD seems very well suited to gameplay and AI programming. It’s hard to TDD graphics and sound, but in the virtual world that the graphics and sound are just a representation of it’s a good fit.

After a year:

And we still end up introducing lots of bugs into the code. Partly because we’re not covering everything (not only are we not covering cosmetic features, “is this sprite/menu item/whatever in the right place?”, we’re not covering experiments, “Will it be more fun this way?” even if those experiments end up sticking) and partly because you just can’t cover all the cases of all the functions, and partly because the tests don’t catch multithread problems.

Oooh… To me it seems like the engine/framework code was suitable for TDD, but when it comes to the artistic side things get worse. I agree completely with the latter sentiment: there’s no simple way to test these things using unit tests. I think the reason is hinted in the last part. Multithreading is a problem, but so is user input and everything that concerns subjectivity. They’re haphazard and volatile and other cool words that indicate that they’re inherently problematic because the system complexity increases in orders of magnitudes when you introduce these things.

I agree with his final decision that TDD is not for him; it might be useful for some parts of game development, but the biggest – and most critical – parts cannot be easily tested. At least I know of no simple ways to do so. However, TDD itself isn’t bad. It forces a functional structure; it captures stupid memory leaks and such; but mostly, it’s extremely useful for projects with multiple members.

Jamie mentions the fact that his understanding of the code has increased due to TDD, and this is iiiincredibly useful in some projects. “How did they intend this function to be used? I know – let’s check out the unit test!” Another benefit of TDD comes when you’re working with other people’s code, even if they have no unit tests for you to glance at: if you’re using valgrind or other tools of that crowd you’ll easily detect whenever you’re using a library incorrectly. Trust me, it’s not always obvious what exactly needs to be deallocated…but if you’re running a unit test for a specific function, you’ll know instantly when something was done incorrectly.

On a final note: have you noticed that I’m only mentioning unit tests and their benefits? There’s a simple reason for this: I like unit tests, but I hate TDD itself. Writing the tests first is cumbersome and a waste of time in my view. Maybe I’ll change my ways as I gain more experience, but my current (non-game development*) approach looks more like XP, with rapid iterations:

• Write a quick prototype
• Write unit tests for the most obvious functions
• Add more functionality and refactor if necessary
• Unit test the new functionality
• Repeat refactoring and unit tests until it’s good enough

I’m still undecided whether this means that I’m too unstructured and inexperienced, or if it’s actually a benefit to let code grow like this. Either way, I definitely think that unit tests have benefited in my work.

* The game development iterations look more like this:

• Write a quick prototype
• Sigh and re-write the prototype
• Add some graphics
• Re-design the game and re-write the prototype
• Sigh and re-design the game because the gameplay is dull
• Go back to the original design, modify it, and re-write the prototype
• Repeat for a while until all of the sudden I realize that the prototype is starting to look like a proper game
• Add music and graphics and make a final version
• Test the game
• Scream in frustration when I realize that the game sucks
• Re-design the game, add features, re-write parts, and repeat ad nauseum

I really don’t get one kind of coding mentality. Which one? I’ll tell you which one. The one where people insist that code should be written correctly from the start so that there’s no need for safeguards.

“What?”

Okay, I’ll elaborate a bit further with a theoretical example. Imagine that you have an embedded system of some sort, and a task needs to be kept running. The first thing to do is, of course, to ensure that the application is written properly, doesn’t crash, and handles errors in a proper way. Of course. I’m not against that in any way. But some people are of the opinion that this ought to be enough – that with enough unit testing and good programmers, this will result in an application that will not crash and will always run. In a perfect world I agree that this should suffice…but the fact is that people are stupid now and then and make mistakes.

Personally, I’m of the opinion that if a task is critical you need to write it securely and have a monitoring system that tries to jump start it again in case something happens. One of the most common questions I get when I propose things like that is: “What do you need that for? What could cause the application to crash?” I grind my teeth every time I’m asked that – if I knew what errors people might have made I would look for those potential errors instead! This is to ensure that the unknown factors are taken care of. Of course, a monitoring system can fail as well. But it increases the chance that things won’t crash and burn horribly – it just might work in some cases.

I know, I know: this is technically a bad approach to writing good software. If you have a safety net you might get sloppy in your implementation. Also, the point of not having a safety net might be that you want to find the errors, and the best way of finding them is to have the system crash. You’ll definitely know that something’s wrong then, and you can make a proper solution. But let me tell you a little story; a story about a couple of device drivers.

First there was device driver A. He was a strange beast, written by a team of Americans and then moved to India for further development. Not that that has anything to do with the issue – the Indian people are good developers and the same thing would have happened if another American team had taken over the driver development. The point is that I suspect that there was a distinct lack of understanding in regards to the driver’s internal logic, due to the new team’s relative inexperience with the code. This became very apparently when the driver received new functionality. The new functions were built on top of the old ones, and everything seemed hunky-dory until one day when a customer experienced serious problems.

“The device driver crashes,” said the customer to the friendly people in the middle who used device driver A in their products. “You suck! We will sue your asses and knit little sweaters out of your pubic hair.” This was a very strange threat, but it didn’t sound like fun at all. So the friendly people spent weeks trying to reproduce the problem. After many weeks of hard labour they finally reproduced it, and gave enough information to the device driver developers to fix the problem. Apparently it was caused by some internal states that were introduced; the driver could get locked up in one of these states, since there was no age timer that cleaned up those new states. But all was well, for a solution was found! Yayness!

But then there was device driver B, developed by a completely different team for a different set of products. Some time after the adventure with driver A, driver B started showing strange behaviours as well… Lo and behold – it appears that driver B has a problem that’s not completely dissimilar from driver A’s! The details differ, but the main concept of the problem (new functionality built on top of the old, but no safeguards were added) seems to be the same. If only there had been a general safeguard inside the driver, that examined the internal states and cleaned up strange states; maybe both driver beasts could have lived happily ever after, then! Sure, there would have been an error and this error would have had to be corrected. But the whole product would not have become useless in the meantime, risking potential deals with the customers who experience these errors.

Disclaimer: a safeguard mechanism might not have improved anything in these cases. It might have been completely useless, and provided nothing at all. But I’m firmly convinced that the damage could have been lessened immensely by a functioning safeguard, had it been in place…and that the mere chance of minimizing damage is worth the extra effort.

If you have an interest in agile development, take a look at this article: Pitching Agile to Senior Management. If you don’t care about agile development, have a look at it anyway – it brings up a few interesting points. To sum things up very briefly, the article goes something along these lines:

• Junior managers and up-and-coming engineers want to try agile development methods to increase productivity.
• However, they don’t understand the criteria upon which upper management decisions are made.
• This article explains that senior managers don’t have the same goals as engineers or juniors, and teaches the latter a few economic buzzwords to throw around.
• The end.

Despite appearances and my cynical summary, this is actually interesting! For example, the second page discusses the difference between introducing technological improvements and introducing economically beneficial improvements; this might be pretty obvious but it never hurts to get a nice summary of the different perspectives. Also, the third page has a very very important tip: you don’t always have to get permissions for everything. I seriously don’t know how I’d get anything done if I didn’t have both the initiative to make my own decisions, and the (grudging) acceptance from managers that it’s okay to do things my way. It’s an old cliche that you can’t get denied permission for something that you don’t ask permission for – but it’s also very true. As long as the results are good, no one will hang you for your slightly questionable methods.

Unless you work in bad companies, of course.

I’m a big fan of Dilbert, but I would never accuse my bosses of being pointy-haired. I often critizise their decisions, but I don’t think that they’re incompetent. Rather, as the article suggests, I think that they’re smart people who are making the best decisions they can based on the information they have…and the goals they want to achieve. Sometimes, when I read horror stories on the ‘net, I get the impression that other people either have completely moronic bosses or a complete lack of understanding for why decisions are made. I try not to be one of the latter people, and I’d never be able to work for the former. I don’t want to end up in…oh, the horror of this flawed and unhumorous pun…bad company.

And speaking of bad companies: time to bring up a bad thing about the article above. Take a look at this quote:

A few months ago I was educating a client about agile development and they told me that they weren’t interested in pair programming because of what they felt to be obvious loss of productivity in having two people do the work of one. I pointed out that with pair programming, when you’re doing it right, both pairs are exhausted after five to six hours.

This seems to be a prime example of bad management.

“Lesse, people who produce get tired. Thus, if a person is very exhausted he must be very productive. Let’s aim for exhausted people!“

Can you spot the errors in that line of thought? At a recent meeting I noted that my company doesn’t use the term productivity. The reason was that many people assumed that increased productivity was the same as more effort, so they exchanged produtivity for a different, more positive, term. At the time I was irritated at this obviously ridiculous attempt at giving productivity a more humane name in order to disguise it…but after reading this article I suspect that there really might have been good cause for it.

Finally, if you’re anything like me you might have wondered what Moore’s technology adaptation chasm that was mentioned on the first page of the article is. Wonder no more: I looked it up for you! To sum things up briefly, Moore divided people into Innovators, Early Adopters, Pragmatists and Traditionalists, and noted that there’s a chasm between Early Adopters and Pragmatists; a new technology must cross this chasm before it can become common practice.

Now, wasn’t that fascinating?

God had it wrong. The seven deadly sins aren’t wrath and sloth and whatever is in that list. He forgot a very important one: inefficiency. In fact, it should be made into a commandment:

Thou shalt not create a situation in which other people are waiting for you in order to be able to perform their tasks. This will only unnecessarily drain the company’s resources and make the waitees incredibly cross. So sayeth I.

Say, hypothetically, that a person is entering a new project and has taken upon himself the task to write a library. This project attempts to be agile and contains very little documentation. In fact, it is encouraged to store knowledge in people and not on paper. On Monday he proposes an API to the library in question but receives no response. On Wednesday he offers a more detailed description of the API and brings a few ambiguous situations into light. Still no response. He discusses the functionality verbally with some people, and then offers an even more detailed description of the API the following Monday. This is met by a short e-mail response at last: “Let’s discuss this tomorrow.”

Well.

Hypothetically, what’s wrong with this situation?

First of all, keeping little to no documentation may sound fine in practice, but it will lead to ambiguous interpretations and difficulties for new team members. Secondly, despite this it can function well if feedback is offered speedily; but it will cause unnecessary work due to unclear specifications otherwise. Thirdly, the lack of information in the response makes it totally useless: does the API need corrections; does it need to be re-structured totally; is it passable but needs to be understood by all parts – the e-mail response tells us nothing about that. It becomes the final nail in the coffin: it becomes impossible to perform any more work on the library because there’s no way of knowing if it will be useful or not. Many hours of productive time is lost because of this. The person responsible for the library will most probably rant about the situation on his blog instead of doing anything worthwhile – effectively losing the company money since a useful pastime is not possible to find.

I hate inefficiency. Or rather: I hate waiting for other people. I don’t care how others do their work, but I loathe being unable to do something productive when I want to. It just leads to frustration, cynism and irritation. The library in question could be written in a few days if the desired functionality was known and specified. In a perfect world projects would be agile, but there would be non-ambigous and thorough specifications for everything. A contradiction in terms? Maybe, maybe not: I fully believe that a team can work in an agile manner but still keep information readily available.

However, playing the devil’s advocate I have to blame myself as well. The information is readily available – it’s simply spread out over several people who have lots of other issues to deal with. If I were truly desperate to be productive I would hunt them down and demand instant feedback on my thoughts, and ask them to guide me to the ones who could offer constructive criticism if they weren’t able to give me feedback. Maybe that’s what’s expected and required in a situation like this. Personally, I would prefer it if people could offer these hints by themselves, without any external pressure.

Maybe I should think of that the next time someone is waiting for a response from me.

Final note: I used the term deadlock in the title, but that’s of course not applicable anywhere. This is simply a mutex that’s locked for too long. But I like the power and force of the word deadlock, so I used it anyway. Sue me.

2007. Taste the word. It hints of futuristic worlds and scientific advances unthought of just ten years ago. But at the same time it’s mundane and common – it’s simply the year we live in right now. And was ten years really such a long time ago? That’s what I asked myself when I found an old zip archive called FirstProg.zip. Granted, it’s definitely not a complete colllection of my first programming experiences: I dabbled with game and demo programming on the C-64 and Amiga before this. But some of my earliest PC projects were found in this archive! Let me show you a little bit of what I found. I’ll begin with a vague timeline:

• Pre-1996: I messed with C-64 and Amiga hobby projects of various types, such as an Amiga fighting game called Time Fighters. I actually received some praise for it – it had a much better control scheme than the over-hyped Body Blows. Not that that says much.
• Spring 1996: I bought my neighbour’s 40 MHz 486 PC. This was my first real experience with x86 computers, and I quickly learned the joys of having an incredible amount of RAM to use in Fast Tracker II, compared with the limitations of an Amiga. At first I had all of 4 MB RAM, but I soon upgraded it to a massive 16 MB!
• Autumn 1996: I heard rumours about an assembly programming group at my high school, and soon joined the four other students interested in diving into the mysteries of x86 ASM. Soon after I had gotten a copy of Turbo Assembler I created this:

I intended to do a very straight-forward Space Invaders clone, but due to sloppy coding I forgot to clean up the bullets when they had hit the bottom of the screen – it looked like a big pile of crap after a while. In addition, my horrible green UFOs had been turned sideways due to…erm…inexperience with x86 memory addressing, and almost looked like green bottoms instead. So the project turned into Shit Invaders. Oh yes, and as you can see I was childishly impressed by David Eddings when I tried to think of a handle to use.

I also experimented with Mode X scrolling. (Don’t ask what it is.) Childish humour resulted in the following scrolly effect:

The scroller starts small with the text “PEOPLE HAVE BEEN COMPLAINING ABOUT THE SIZE OF THE FONT IN MY SCROLLIES, SO…” and ends with a massively enlarged “BETTER?!”

I also worked on a platform game that I intended to call Satan Claus:

It may not look much, but there are actually three parallax layers: one background that simply were the gradient blue tones for the sky, one layer with the blue hills, and one layer with the foreground. I’m sure that it might even have looked pretty nice if I’d had a real artist to help me instead of making some crappy graphics myself.

Back to the timeline:

• Spring 1997: By now we were finishing high school and had to present what we had accomplished during our studies of the illustrious assembly language. This was one of the things I ended up showing to the teacher:

A simple demo effect with a generated flag (and its accompanying gradient colour table) and a bitmap manipulated by a sinus table in various ways. Simple enough, but it looked really nice. Go me! I did something that wasn’t just silly!

Of course, I compensated that brief bout of seriousness with making an action game inspired by Smash TV and Robotron, called Mega Brain Splashing:

A curious tidbit: this game sucked incredibly hard, and one of the reasons is that I had never actually played neither Robotron nor Smash TV – I had just read about them in video games magazines and imagined what the gameplay must be like. Curious tidbit number two: the title screen for Shit Invaders also featured a fire effect, but the difference was that by the time I made Mega Brain Splashing I had learned how to make it fast enough in real-time instead of just using a static picture.

More timeline business:

• Autumn 1997: I joined the Swedish military for 10 months of mandatory torture. Interestingly enough this led to a burst of creativity since I was located at the same place as one of the guys I’d been doing assembly programming with! Ka-ching! Touchdown! Together we experimented with many different subjects: 3D graphics, C programming, low-level optimizations of Bresenham algorithms, and so on. By myself, I continued making strange small games and proof of concepts:

I toyed with having enemies move in pre-determined paths, in something that would have been Mega Brain Splashing 2. This time there would have been a two-player mode.

I also started Mega Brain Splashing: The Medieval Interlude. This was going to be a gory action-RPG that combined exploration with lots of blood…and – as can be seen above – stolen graphics from the Exile II game. But most disturbing was probably this little game:

A Star Wars game completely written in assembly! I’ll spare you the text from the scroller, but I’ll note that involved mentions of homo saunas, epic dangers, and another trench run. Oh, and see how quirky it is – “Press Escape to play.” I must have thought that I was very clever and funny indeed. The game itself is quite simple: you pilot an X-Wing that has two shields – one to the left and one to the right. Hitting obstacles removes shield strength. If you shoot targets on the way you get points. And if you reach the end of a “level” you must fire off your proton torpedo at a specific goal. That’s it.

Eventually I was let out of the military and ended up studying computer science; that’s when I went over to the dark side – i.e. Windows programming. Many small games and projects emerged from that transition, one of which was in fact Mega Brain Splashing 3:

Ironically, many people found MBS 3 better than MBS 4 that I created later. There are no technical reasons for it: MBS 3 was in 8 bit colour, I used colour lookup tables to simulate transparencies, it just consisted of a single static map, it had a more basic gameplay, it had no bosses, the weapons weren’t very balanced, it wasn’t compatible with all graphic cards (due to the weird software rendering I used)… All of these things were improved on in MBS 4, but I just might have forgotten to transfer the most crucial part: the fun factor.

It’s often said that ideas are worth nothing, and only the implementation matters. However, this might really be just part of a bidirectional fact: ideas without implementation are useless, but implementations without a good idea results in a loss of this elusive fun factor. Maybe, in creating MBS 4, I concentrated too much on the technical aspects of the game instead of stopping to think: “Is this really fun? Am I basing the game on a good idea? Am I injecting my usual experimental mood and quirkiness into the game? Or am I just trying to improve the technical bits?”

Sorry for the misleading title – this won’t be a deep look into AI models, and neither will it link to any brilliant new papers concerning AI architecture. There will also be no diagrams and no pseudo source code. All you’re getting is a musing on differences between the academic and the commercial world. I’m sure you’ve read countless of articles about that issue already, but I have something new: I have anecdotal evidence to spice things up! Cue the crowd’s cheer.

The time: February 3, noonish.
The place: A stinky bus full of tired and half-drunk travellers going from France to Sweden; at this time the bus happened to be located in Denmark, but that’s highly irrelevant.
The cast: A mix of people who have studied Computer Science but ended up on different routes in life: a PhD student/consultant, a PhD student/biologist, a programmer, and a beer-swilling bastard. I only added the last bit for the amusing alliteration, but I’m sure you can guess whom I’m referring to. The main point is that two chose a rather more academic route than the other two.

I had brought along the latest (or by now old) issue of Game Developer on the journey, as some light reading compared to Michael Moorcock’s Wizardry and Wild Romance: A Study of Epic Fantasy. No, the light reading part wasn’t ironic at all – Moorcock’s book is excellent and he is totally dripping with wit, but the constantly changing writing styles (since he quotes different authors) makes it a non-trivial read for a poor Swede. Either way, in the Game Developer mag there was an article about AI models for games, and one of the more academic persons happened to browse through said article. I’ll make an attempt to describe an exchange of words that occurred around this time:

“So, was there anything worthwhile in the magazine?”
“Nah, not really. Interesting to read about the AI model, though. They’re acting like this is the next big thing in game development research, but it’s really just a simplified version of subsumption architecture. It’s been common knowledge in AI research since the 80s!”

I was pretty sceptical at this reaction. Sure, game developers don’t really keep up with academic research, but there had to be something new! Unfortunately I hadn’t – and still haven’t – read the article, so I can’t say anything for sure. The argument briefly touched the notion of game developers being result-centered and academics focusing on demos and theory rather than practical applications. I advocated this viewpoint, but I was met with arguments that the dude’s PhD work had included active attempts to develop AI models that could be practically used in games, and that he had worked together with industry representatives on this matter.

Then we arrived at the ferry from Denmark to Sweden, and had to get off the bus; so the discussion stopped.

I remain slightly sceptical, though. I have a nagging gut feeling that the viewpoints of a game developer and a person with a more thorough academic background simply are too separate to merge that easily. I’m convinced that said PhD student acheived excellent results that would be practically useful in game development…but I’m also convinced that despite all his efforts, all that it has resulted in is a demo; a proof of concept. An academic proof of concept that can be used for homebrew development, but probably won’t get incorporated into commercial game development projects.

I also have a nagging feeling that the PhD student in question focuses on potential. He sees what his projects can evolve into – he sees the possibilities for evolution that a good, solid theoretical foundation has. But I also suspect that a commercially-inclined game developer would only look at the actual output. If the AI he beheld didn’t produce effects that were wildly superior to existing simpler models, he probably wouldn’t care much for the potential in the project. This might be due to a lack of understanding of the potential, or simply a sound business sense since old-fashioned methods are cheaper and yield good profits either way.

Of course, this is a vague generalization. There are exceptions in both academia and commercial game production, and I have no data to support my claims in any way. All I have is this gut feeling. It would be very interesting to dig up a bunch of academic AI projects and interview professional game developers about their spontaneous opinions on what these projects could be used for.

All names have been omitted from this article to protect the innocent. Me, that is, because Peter would do harmful things to me for paraphrasing his words incorrectly.

Oh, damn!

During lunchtime yesterday I expressed my disgust at some people’s behaviour – it seemed like they were more interested in not getting blamed, rather than ensuring that the end result was a success. I’m the first to admit that I’m (regrettably) not always productive and that I often let personal interests guide myself, but I try to prioritize: the most important thing is to Get the Stuff Done(TM) regardless of who receives the most credit. Or rather: regardless of who receives the less amount of critique. I thought about specifying negative critique, but I think I’ll leave it like that. Of course I hate making errors, but everyone makes them. Seriously. You do too. So it’s not a big thing in the long run.

At this point I have three separate things that I’d like to rant about, and in an attempt to break off from the normal discourse in blogs I’ll sum them up here:

1. The original topic: what happened after I had expressed said disgust? Where was I going with that?
2. Making mistakes is human, but it’s not really like me to make an understanding and helpful comment like that without attempting to apply a twist. Of course I have something else to add.
3. This style of writing: I could easily have written a normal monologue where I slowly shifted between these topics, but instead I chose to make the reader aware of my plans. Why?

For fun (no, that’s not the answer to why; this sentence continues) I’ll number the paragraphs below so that you can skip to your desired topic at a quick glance. Just like these go-to-page-or-chapter-depending-on-what-kind adventure books we all read as toddlers!

1. The response I received to my disgust was a thought-provoking question: “Don’t you think that your point of view is pretty Swedish?” Possibly; and I hadn’t considered that. Many different nationalities were involved with the issue I was discussing – Swedes, French, Dutch, Arabs (sorry – I don’t know the term for people from UAE) and so on – and it just might be the case that I was too critical since my values and expectations are wildly different.

2. To be human is to err. I guess I want to be non-human then. Unhuman. De-humanized. You get the point. I hate making mistakes; I’m getting better at ignoring them, but I still feel slightly panicky when I think of mistakes I made earlier in life. As an extreme example: I nagged my mom into buying me a plastic toy when I was six years old, and when I got home I realized how infantile my nagging had been – the toy wasn’t important enough and didn’t give me pleasure enough to warrant my annoying my mom. The shame of that realization still burns. It’s one thing to say that everyone should own up to their mistakes, but making them - and admitting to it - can be very painful.

3. For fun.

4. Where the hell did 4 come from? Let’s just say that it’s vaguely relevant to point 1 above. I read an article called The Essential Unified Process: New Life for the Unified Process today, and I felt…uninspired by it. Maybe cynical, even. Elaborate processes – even ones that try to simplify and be agile – feel so pointless: it’s just an attempt to rationalize something too large - too complex. Consider point 1 above: processes are often conceived by people of one nationality…and then they’re adopted (and adapted, thankfully) by people of other nationalities. But people have different sets of values. Using a single management process for everyone is like trying to [insert vulgar verb phrase] with [insert suitably humorous noun phrase].

5. I really didn’t want to make yet another numbered point, but symmetry requires it since I felt like making a new paragraph here. After my rant in 4 I guess I ought to conclude that the article was pretty interesting after all. Agility and the Unified Process is a big step forward from stagnant older processes, and if the EUP indeed moves toward being as flexible and extensible as the article describes, it sounds like yet another step in the right direction. Processes can never be perfect due to individual variations, but I guess that they can be better or worse tools for making educated approximations. I’m still not a happy cynic, though. I work differently from my co-workers. Swedes work differently from Finns. Making things agile or test-driven or xtreme or [insert new buzzword] is definitely no solution to the variations.

6. I think I need to cook some dinner before I get even grumpier.

245. It’s pitch black. You were eaten by grue. Go to section 1.