A key element in the law of attraction is faith. If you repeatedly think about something that you would like to have (or have happen), and you have absolute faith in getting it, you will get it, the law says. This technique can be put to use most efficiently by repeatedly thinking about the desired thing as if it would already exist (thereby exercising absolute faith). For example (modern examples for this law seem to be notoriously monetary), instead of saying, “I have faith that I will have a million dollars”, one would rather say, “I have a million dollars”, ideally repeating this several times a day.

By stating the object of our desire as if it were already a reality, we create a strong tension between the current reality (not having whatever we desire) and the desired reality. Our persistent and absolute faith then compels us to take action that will resolve this tension, by moving us towards the reality that we desire. Depending on your believe system you might also say that this action is guided by god, the universe, your subconscious mind, the divine, your muse, inspiration, etc.

If you are a programmer, and you are still reading, congratulations! Because now, let’s think about Test Driven Development, where usually one goes about writing a test first, that is, before the code that would make it pass even exists. So by writing this test, we pretend that the code that will make it pass (or even compile) is already there. Our test talks about the desired object, the code, as if it were already written. In other words, we express absolute faith that the code will eventually be written. In fact, our failing test starts to attract the code that will make it pass.
Now, after we clearly stated what we want, we run our compiler and/or test framework and immediately get in touch with the current reality. The test will fail. Since we have a desire to make it pass, and absolute faith that we can make it pass, the tension between the current reality and our desired reality will compel us to write the code necessary to make the test pass. Every test becomes a mini-fulfillment of a clearly stated desire. That might just be the reason why writing failing tests and making them pass is so satisfying.

Rant Start

So we hear this year our AAA projects will cost 10 million dollars to make and next year they will cost 15 and in 5 years it will be a gazillion. Why? Well hmm, let’s see, the hardware is getting more complex, content creation becomes so much harder, photo realism, content pipelines, episodic content, oh my!

The real reason for exploding costs in game development is incompetent software developers. I am sorry to say. It’s not the big, all encompassing, unrelenting and unchangeable advancement of technology and refinement of consumer taste and expectations, neither is it those “risk averse” publishers who wont finance your creative idea. No, it is simply incompetence. Our skill in devising reliable and flexible software architectures is, to put it mildly, severely lacking. The advanced hardware and those pesky creative designers have created an environment that requires excellence, an environment we can’t possibly keep up with using our current skillz (sic).
Programmers are the least trusted individuals in the industry. Why? Because we are poor and misunderstood individuals? Because we work so hard and are tired all the time and therefore make mistakes every now and then? No. It is because we can’t code for shit. We have no clue about the simplest and oldest principles of software development. We consistently violate well established principles and practices of object oriented programming, while cranking out one class after the other in our “oh we started out with some classes but then it got out of hand uhuhuhu”-piece-of-shit-hacked-together system, which sometimes, but not always, through brute force, individual genius, or sheer luck finds it’s way onto the shelves. And then we go on complaining about those long hours “they” put us through, when in reality, it is our crap code that has us sit there, debugging deep into our utterly untested systems, looking at the same functionality in 10 places and treading to add another line to that one forbidden include file, that will send the time of our next build cycle through the roof. But hey, more time for coffee and bitching about management in the kitchen!

The designer walks up to us and asks us to do a simple thing that would enhance his game, and we tell him that it will take, oh, hmm, days or maybe a week, and we will not be sure how it will affect all the other systems and therefore we can’t say if the game will behave the same as before the change, look out for those side effects, testers! The designer looks at us funny, and we roll our eyes, hidden or otherwise, because how can she possibly understand the intricate goings on in our wonderful and complex software and oh how hard it is to do this cool (and sexy) programming thing but don’t worry, we got it! After all, we are your heroes. Right? Right?? And they keep throwing these change requests at us .. can’t they make up their mind! Do it right the first time, for fucks sake!
We add a feature to your game, but we just can’t tell you if we broke it or not! I mean What. The. Fuck! Dear designers, dear artists, dear producers, we have fooled you. We have stringed you along. We somehow convinced you that this is the way it goes, that software development just IS THAT WAY. No, sorry, we are full of shit. We lied to you. We lied to you because we wanted to hide our own lack of software development competency. And some of us are really good at hiding that behind shiny graphics and oh those mind blowing physics. And we usually do this by crunching our asses off and burning out in our twenties.

So, we need software architecture you say? You mean the thing where you write those small classes with only 3 members or something, uh, and you, like, test them, and, like, your classes have as little responsibility as possible, so you can test them in isolation, and then in the end you plug your well tested small classes together, yielding a well tested and reliable layer of functionality, ready to carry your next layer, which you can build with confidence and the courage to display excellence?
Are you, like, gay or something? Oh and .. you can’t use virtual functions because on the 360 this will cause cache misses and our performance uh uh uh uh. Well fuck cache misses. Tell your programmers to learn how to write tested and reusable software first, and then have them go and profile those 20% of the code that is exercised 80% of the execution time. They might find out how to get past the same 20% of problems they run into over and over again, using 80% of your budget.

So here we are, blaming Walmart and EA and those evil money wielding publishers in general, and oh the risk it is nowadays with all that money involved.
Or, rather, with all those incompetent developers involved. They build you software which will be hard to maintain and hard to change. They build you software of which they will not be able to tell you if it works the same tomorrow or 10 minutes later. They build you software that will drag them back to their desks for 80 hours a week, spending most of their time in their favorite tool, the debugger. They build you software full of non-commitments and guilty conscience. Producers, have a look at those C++ files in the elusive “Code” folder of your multimillion project, and look at the lines beginning with // or /*. You might get a feeling for how your developers feel about their work. Search for “fuck” and “shit” and “crap” or “god”, “OMG” and “sucks”. You will see comments throughout the code saying “oh .. this sucks but I put it here” or “shit! This is sooo bad but for now it is good enough. NEED TO CHANGE LATER”. Or, my favorite one, which I read personally in the source code of a Triple-A title: “I have no shame left”.
That is right. We, your developers, have no shame left. We walk around in your office, our penises tangling, scratching our balls, and providing you with a heap of shit that you are to use for your creative ideas and dreams, and that you are to market to a hopeful crowd of gamers, which is growing more and more frustrated. Please show us the way to the closet where we left our pants and send us back to programming school.

Rant End

The spike

In "Extreme Programming" the term "Spike Solution" basically means venturing out into the untested waters and "hacking" together a piece of code which roughly does what we want, in order to learn about the problem as well as the solution. So I did exactly that. I found a convenient place to implement my picking code in the update loop of the game. The code would shoot a ray from the mouse curser position into the world, and intersect it with the geometry, providing me with the intersection point (if any). As a visual indication, I would render a sphere of some size at the intersection point. If the mouse cursor appears to be always in the center of the sphere, I assume my code is correct.

After a few iterations over the code, and some grappling with high school trigonometry, I arrive at a satisfactory solution. Visually, everything looks correct, the data in the (occasionally invoked) debugger also looks good. Here is an actual screenshot, with a wireframe sphere indicating the point of intersection on the ceiling, close to the viewer:

Now that I have some code which does roughly what I want, it is time to put it under test. After all, I will get tired of staring at my sphere to test my code for correctness whenever I change it.

The failing test

To put my code under test, I first write a failing test. The code I have written so far essentially calculates the end-point for a ray which will be tested for intersections with the game geometry, the start-point being the location of the viewer. In the game, I am interested in that intersection point, to find out what is in the game world at this point, in order to operate on it in a certain manner. In the test, I am really only interested in the end-point of the ray - if this point is correct, I assume the rest of the operation will be fine. My goal here is to use data that a computer can verify (in my case, a vector consisting of three floating point numbers), as opposed to the visual cues I have gotten so far, which need the human eye to judge (approximate) correctness.

So now, having rid myself of any dependency on the game data, which is expensive and time consuming to load, my test simply has some inputs, and an expected output, and will run completely independent of the game.

My inputs are (for completeness sake):

• The screen coordinates of the mouse cursor
• The horizontal and the vertical field of view
• The view matrix
• The eye point (position of the viewer)

My output is another 3D point, the end-point of the ray which is shot in the view-direction, distorted accordingly using the field of view variables. So, I put the code I have "hacked" into the game into a class, and put this class under test. This test lives in a seperate project from the game project, and is run independently (and cheaply). The first version of my test looks like this:

As you can see, I set up some fantasy data, put it through a function in my new "Pickray" class, which is a copy of my spike code, and check if the result is equivalent to another fantasy 3D point (taking a small epsilon into account). Of course the test fails. This, in the words of Kent Beck, is progress. Because now I know exactly what to do next: I need to make this test pass. How do I make it pass? By feeding it the correct pairs of input data and expected output data. Where do I get this data? Why, by exercising the code that I have put into the game, the code which was visually verified to be correct.

Sampling data

So, back in the game code, I add some lines that print the inputs and the expected outputs I am interested in. Since I am really excited at this point, I don't bother much with formatting. The obvious idea of formatting the output so it becomes correct C++ code ready to be pasted directly into my test eludes me at this point. That's ok though, I remembered it early enough later on. At any rate, an early version of the output code looks like this:

This code dumps the current data whenever I move the mouse (and whenever a certain console variable is set to 1). The high precision in the output is necessary to avoid imprecise results in the test - so the more digits after the comma I can grab, the better. I fire up the game, move the cursor around a bit, and I get a lot of "real world" data to choose from. A few copy and paste operations later, and some reformatting, and the fantasy data in my test is now replaced with one set of this real world data. One version of my first passing test looks like this:

This looks pretty good already: I can get the game to output data which I can use in my test, testing the exact code that the game gives me output samples from. By now I am confident enough to replace the "loose" code in the game with the class I have since put under test. I have moved my tested code already to "production". Always a great feeling.

At this point I am ready to refactor my test for using multiple data samples. I add a little infrastructure in the test, enabling me to add an arbitrary amount of samples for testing. My test now looks something like this:

The class PickrayTester takes care of collecting samples and running the tests. Meanwhile, the code in the game that outputs my samples has been changed to produce correct C++ code, nameley a block of code starting with tester.addSample... which I can directly paste into my test, for every data sample I want, and for as much samples I want.

The final thing I want to do is to remove some of the remaining manual tedium. Also, my test starts looking a bit fat, depending on how many data samples I use. So, approaching the inevitable happy end, I change my sample output code in the game to directly write into a cpp file, which is in the same directory as my test. I call it PickraySamples.cpp. This file now solely contains a list of tester.addSample.. blocks. In my test, I replace the inlined sample data with an #include statement that includes the generated file:

At this point I declare my mission to be accomplished - I can now change my picking code with the safety net of an automated test. Obviously, there is more to picking up 3D objects than just shooting a ray into the world. But the automatically asserted correctness of this integral part is already a nice and solid foundation to build on.

I have previously used this framework to run unit tests via a simple text interface. Tests are easily defined using a simple set of macros and automatically enumerated. Now, whenever my modified version of Doom 3 starts up, it will do the same, it will enumerate tests wherever they have been implemented in the code, and I can operate those tests via the in-game console. Have a look:

Now, why did I do this? I will of course also have a seperate program with a lot of unit tests, as I develop my software test by test. However, I will want to write tests that will need the game running in some stage, and part of the beauty of all id Software engines is that they make it extremely easy to hook in any kind of custom code that is readily executable in the game at any time, via custom console commands, thus opening up an extensible command line interface to the running game. And so I not only have the environment in which to run my tests, it also hosts them and provides an interface to them. That, I think, is quite beautiful.

I am not working for Id Software, in case you were wondering. I am using the publicly available tools and source code for modifying the original game.

The "Enum Example"

Let's say you have an enum, and you would like to associate a string with each element, to provide a readable name. A common way to do this is as follows:

The output of this program is:

ID0 -> ID 0
ID1 -> ID 1
ID2 -> ID 2

Now, whenever you add an element to IDs you will have to remember to add an element to idStrings. The compiler wont tell you about your omission, and things could get nasty only very late at runtime. Even more so, if you have code that operates on all members of the enum, you have to add to this code as well, as you would have to in the above example, where we output all the string names on standard output.

X-Macros relieve you of all that. Let's rewrite our code like this:

Let's examine what is happening here. At (1) we define a macro which expands to a set of "X-Macros". In our case, the X-Macro has 2 Parameters. At this point in the code, they are not expanded. Note that this uses the fact that the preprocessor will not expand macros embedded in other macros, before the "parent" macro is expanded. Therefore it does not matter that, at this point, X is not defined to anything. At (2) the whole magic happens. The X-Macro is defined. It will expand to its first parameter (ID0, ID1, ID2) and a colon.
Now, inside the enum definition, we expand GENERATE_IDS. This will now also expand the current definition of our X-Macro, and, voila, an enum is generated. At (3) we do the same thing, only this time, we expand the X-Macro to something else, namely, it's second parameter and a colon, resulting in a list of strings generated by GENERATE_IDS, fitting nicely into our array definition. Note that the definition of X had to be undefined before we could define it again.
Now, whenever we want to add an enum, all we have to do is add a line to the definition of GENERATE_IDS, with the enum value, and the enum string name. There is no need to edit multiple places in the code any longer. The output of the new program will be exactly the same as the first one.

Beyond Enums

While the above example demonstrates a useful technique to avoid code duplication in a particular implementation, X-Macros can be put to use in many different scenarios. I would like to give one more example in this post. Let's say you want to have a class which has many different data members, and the frequency of adding, removing, or changing those members is currently very high. Here is how I would implement such a class using X-Macros: