I have been working on Wagic for more than 2 years now, and it’s become quite big for a homebrew game. In terms of gameplay and features of course, but also in terms of source code. I use a small application named CLOC to count the number of lines of code in Wagic, and I was amazed at how the source code for Wagic keeps on getting bigger with time.
Wagic now has 70’000 lines of code.
As a comparison, a “standard” Custom Firmware for the PSP has around 25’000 lines of code.
Out of curiosity, I ran CLOC on several open source projects of the PSP community and here are the results:
Lines of Code
3rd gen Equiv.
70’000 (including 40’000 for JGE)
DSON PSP (DS Emulator)
37’000 (including 28’000 from the PC emulator)
CFW 3.10 OE
Battlegrounds 3D 0.4 (tank game in 3D)
PSP Mancala (Mancala Game)
(3rd gen equiv. Is CLOC’s attempt at comparing projects written in various languages. It assumes for example that one line of assembly code does way less than one line of C, itself doing less than one line of C++)
What does this show? Well, pretty much nothing, except that the number of lines of code in a project are not directly related to its popularity 😛
A “standard” homebrew game with basic features, that is still more than a “proof of concept” will have between 2’000 and 10’000 lines of C/C++ code (I didn’t try any LUA game).
A basic rule of thumb is that a programmer alone can maintain around 20’000 lines of code. The number of lines of code in a program give no specific indication on the quality of the code itself, but there are two obvious things: Maintenance and bugs increase with the number of lines of code. I’m not saying that Wagic has 15 times more bugs than Battleground 3, but that it is highly probable that Wagic has 2 times more bugs than when it had only 35’000 lines of code.
Well, if we want a project to grow bigger, add more features, at some point we have to increase the code size. What are the solutions to deal with it?
Version control. I can’t imagine a project with more than 10’000 lines of code that is not version controlled. We use SVN for Wagic, there’s a free service provided by google code for that. So far it’s great. Other projects use their own SVN servers (such as the PSP SDK at ps2dev). Other solutions such as Git exist. I don’t think any software project can expect to grow without at least a basic version control system
Bugs tracking. I used to write down every single bug on a piece of paper. This works half well when you’re alone on the project, assuming it’s always the same piece of paper. Let me withdraw that: it doesn’t work. You end up forgetting things. Inputting the bugs in a system that will help you keep records is a great idea. I’m happy we progressively shifted to that in the Wagic project. Google code offers this service as well. There are alternatives such as mantis,…
Automated tests. I gave up the idea of having human beings test every single feature in Wagic after the second release I think. There is no way you can get people test thousands of cards in an acceptable amount of time. Depending on the project, automated testing can be hard to implement. Unit tests are fairly easy to implement in languages such as Java, but I haven’t taken the time yet to implement unit tests in Wagic. Wagic does regression tests, which is basically a way of making sure that a new feature does not break old ones. We have lots of progress to do in this area
Reduce the quantity of source code. One other thing I haven’t taken the time to do seriously yet. The best solution to reduce maintenance is of course to reduce the size of stuff to maintain. Wagic has lots of dead code, or code that could be optimized/refactored. We try to do some cleanup regularly, for example by removing hardcoded cards, and instead softcode them (which also improves the parser, that’s a good thing). Often, cleaning up the card codes doesn’t reduce the total amount of code though. But it allows us to code 50 cards when it was only possible to code 1 initially.
These are the four things we use on a daily basis to work on Wagic, and that proved efficient over the months to increase the quality of the game. It is far from perfect of course. We are experimenting with other things (such as a wiki) to improve documentation and communication between devs…we’ll see how it goes.
We are constantly looking for guest bloggers at wololo.net. If you like to write, and have a strong interest in the console hacking scene, contact me either with a comment here, or in a PM on /talk!