Thursday, January 03, 2008

Tonight I spent 2 hours reading & commenting stevey's blog about code size. Here is my comment to his article :

I Think you should try the "play" programming language. Its semantic is quite rich : the program "Play;" will run a game with all the features of your 500k game.

Ok, I'm just kidding but you have some very valid points : trying to factor (I'm not saying refactor) your code, and reusing instead of duplicating is a mandatory thing.

What I'm not buying is your focus on the "LoC" metric. Your 500k lines of code break eclipse, and this is good thing. For me it means that the way the code is architected, eclipse must load all the code to figure it out (I mean compile / index it) : exactly like if the code was a single 500k line script, where line 500.000 depends on line 1.

Divide to win

Let's think about it for a few seconds, what do you have in a game : the AI, the graphics engine, the physics engine, the audio engine, lots of data file and a "scripting engine" to glue everything together. It is pretty clear that your AI does not care about the colors of the textures on your polygons.

Now, would you consider a technology like OSGi / Eclipse plugins ? You focus on writing the smallest possible piece of code. Everytime you're willing to add a new feature, you ask yourself : "Can I add an extension point here and program my new feature as an external plugin ?".

Now my feature is a separate project Y in my IDE. I create a new project Ytests, that depends on Y, and unit test the code in Y. When Y performs correctly, I package it (right click / export / export as deployable plugin & fragment), push the code to git/svn/you name it, and close the project Y in eclipse.

Another point is, when I start writing a program, do I use plugin / modular technologies from the start ? Can I know in advance that my little project will be successful, and will grow to X lines of codes ?

No comments: