Thinking About Code

(Note: This blog post is mostly for fun. I don’t really intend on drawing any grand, sweeping insight into good or bad code. This is just me tired of squashing bugs and wanting to dig around in what I’ve created. I also promise not to talk about Big O.)


By the numbers

Let’s start with some Steam Marines v0.8.6a script source numbers!

162 script files
1747 script functions
43532 lines of game logic code (non-GUI, non-engine)
8415 lines of comments
4385 blank lines
3488 if statements
638 else statements
456 else if statements
305 switch statements
28 while statements
15 do-while statements

This turns out to be 9860 lines of code with only a single bracket, either { or }, on them. This means that the number of non-GUI game logic not including comments, blank lines, or trivial single bracket lines, is 20,872 lines of physical code. Of those nearly 21k lines 4,930 are control statements, or about 23.6%.

I don’t really know what these numbers imply, nor am I aware of anyone who has done analysis of “good” and “poor” code and gathered relevant statistics (although there probably have been.) But it’s interesting to note that almost a quarter of the relevant lines of code are about flow control. We are here and we want to go there.

This suggests a few more metrics to look into, namely how many functions need to be called and how many source files need to be touched to perform actions or respond to user input.



I was taught to write re-usable code. Make it abstract, make that list of things be able to hold all the things! I’ve mostly abdicated this approach for coding games, at least from an object oriented perspective. But I do love functional programming, and that intrinsically allows for more re-usability. So maybe I haven’t abdicated so much as melded the concept in my brain.

It’d be pretty cool if every action was a single function that contained some straight-line code; no branching, no other function calls, just bam bam bam and we’re done. It’d be pretty easy to debug, too. But probably a nightmare to write with lots of duplicate code.

If we think of the number of functions touched to complete a task being a metric of complexity, functional code is a big help. Sure even functional code adds complexity, but it doesn’t change state which is the biggest help. We know that by themselves functional code didn’t screw something up, although some other code might have taken what they returns and mucked about with it.

Steam Marines is written with Torque 2D, but for the purposes of this post let’s ignore the engine guts and talk about script code execution only. What happens when the player presses the key to move in the left direction? Well, it enters a function conveniently called left in the input.cs file.

It essentially looks like this (minor details left out, but all files touched are included):

left – input.cs
—> globalInputLocked – input.cs
—> clearFireControl – fireControls.cs
—> —> clearTargetIndicators – fireControls.cs
—> engageCharacterActionLock – characterMovement.cs
—> canMoveToMapPosition – characterMovement.cs
—> getTilePositionFromIndices – dungeonGenerator.cs
—> moveUnit – unitMovementHandler.cs
—> —> growAndShrinkUnit – unitMovementHandler.cs
—> setSquadMemberFacing – facingHandler.cs
—> mountSightToUnit – weaponModHandler.cs
—> initializeReadout – readoutHandler.cs

Yowza! That’s a dozen (12) function calls to move a unit in one direction! It also touched eight (8) physical files. Like I said above I don’t know if there’s a good way to measure this stuff, but to me that feels like a lot of files to jump through just to see if basic unit movement is working.

To me the code structure works well this way, though.Code is split into small functions, each with a very specific job, and they are categorized into physical files based on functionality.


Doom 3 GPL Source

Counting just .cpp files in Doom 3‘s GPL’d source code shows that it has:

531 cpp (C++) files
377566 lines of code
115818 lines of comments
89582 blank lines
38829 if statements
5517 else statements
5767 else if statements
693 switch statements
1161 while statements
123 do-while statements

That’s 172,166 lines of physical code with 52,090 control statements, or about 30.3%.

I want to point out that I am in no way suggesting this is an accurate comparison, or that the code quality between Doom 3 and Steam Marines is similar. It’s not a full source comparison; I rather arbitrarily chose to ignore my GUI code, the Torque 2D engine code, and that Doom 3 and Steam Marines are remarkably different games. I also stripped single bracket lines out of my own numbers. Really the only thing going for this comparison is that it was only between .cpp and .cs files since I excluded .c and .h files from Doom 3. It speaks to code structure more than anything else.

But it’s still interesting to look at, eh? Maybe it suggests Steam Marines is way too complicated for it’s own good! To be completely honest I assumed Doom 3‘s OOP structure would have indicated relatively less flow control statements. So maybe this is a metric of nothing!


Now what?

I dunno. Wanna tell me your source stats?

Aside: I’ve churned out approximately 31 lines of physical code a day (that remains in the current dev build) for Steam Marines since starting on it – not including GUI or engine code.

I didn’t include GUI code because there’s not a lot of explicit flow control in that kind of code. Full script (not engine) numbers if you’re curious:

Steam Marines cloc
Steam Marines cloc


Thanks for reading,
Mister Bums

You can contact me at [email protected]Twitter, or leave a comment below!