Very interesting read, but one of the understated takeaways is that playing a game is data. Playing a game means generating data from data. Lekktor took this principle to the extreme, it took the input of the player as the data by which is decided how to morph the code.

It's crazy, but it's something to think about. The data in the form of the player input counts. Player input was used to measure code coverage, and to some extent, this is why automated bot tests can return you bogus performance profiles. If using Lekktor was taken for granted, what would be necessary to make it not a crazy idea?

The first step could be to introduce unit tests of a different sort. For everything that the game can do, the unit test would make the game do it so Lekktor wouldn't forget about it. If someone finds a feature missing from the final game, then you missed a unit test. Also knowing that Lekktor won't let your code live without a unit test would provoke you into writing said test, which wouldn't be a bad thing at all now would it?

There are some other things to think about too: If a player is unlikely to do something, then we all know it's more likely to be buggy because it's less likely to be tested, but also, things that are less likely deserve less developer time. In turn this allows us to make trade offs. For example, it's seen as quite natural to ignore fixing framerate issues from areas that the player is unlikley to see in favour of fixing the framerate in areas where the player is highly likely to see. Lekktor allows us another view of the code. It can tell us what areas of the code are used little, and from that we can deduce what areas are potentially more dangerous than others.

During development, it's important to have all the optional but not actually used code paths available, but in a final build, not just the debugging code should be eradicated, but also all the code that was only used by the debug code. Lekktor could potentially be that tool, but only after all the crazy is taken out.

http://fgiesen.wordpress.com/2012/04/08/metaprogramming-for-madmen/

DATA-ORIENTED DESIGN The hardware will thank you.

Chinese translation provided by KouZhe / Martin Cole

input is data 04/05/2012:21:07:54