*Lick*

(Note: I understand that communities are not singular. They are composed of multiple individuals. It can still be instructive to observe general sentiments and responses because they all blend into a singular sense, a vibe, a taste.

This is what I taste after licking the indie game developer community for the last few years.)

 

Sweet – Willingness to help other people

I don’t mean just other indie developers. As a group there seems to be a large portion of people willing to dedicate time, effort, and other resources to help others. Whether it’s raising money for specific needs, promoting other people, lending an ear or some motivational words, you can find it all within the community. While this isn’t unique to the indie dev community, I’ve found that it’s pervasive and that’s great.

The obvious examples are from crowdfunding campaigns via Kickstarter, IndieGoGo, GoFundMe, Patreon, et cetera. The less obvious examples are the micro-communities that develop around engines and other resources (e.g. Unity 3D’s user community is very friendly and helpful.)

 

Bitter – Willingness to destroy others

This manifested most recently regarding Flappy Bird, an app that grew extremely popular and apparently made the creator a lot of money – who then turned off that tap because of all the hate and threats he received. In some cases there was also a racial component.

This can also manifest in the Indie vs. AAA mentality. I’ve never seen an AAA dev shit on an indie dev for being indie, but I see the reverse on a daily basis. More to the point very few indie devs will even attempt to defend AAA. A lot of this is passive, tacit agreement.

 

Salty – Friendly rivalry

This may be my own bias at work regarding turn-based strategy games in particular, but I’ve also seen it in platformer devs, space sim/stragey devs, FPS devs, and others. The concept that we can all go far together is stronger than in many other entrepreneurial communities.

There are certainly people who still sabotage for eyeballs. I’m most familiar with Reddit’s Screenshot Saturday posts which recently underwent changes to combat this behavior.

 

Sour – I’m right, you’re wrong

The unwillingness to accept that people doing different stuff, or doing stuff differently, can be okay. This manifests in the more traditional language, engine, tool chain arguments, but also the types of games, production values, aesthetic choices, and design choices. The worst of this seems to come from developers who want challenging and compactly designed games hating on casual or simulation type games.

I am forced to admit I’ve fallen into this category on occasion although I try to rein it in. Being critical of games is good. Saying there is only one supreme type of game (that happens to be the kind you’re making) is just an act of masturbation.

 

Umami – The IDGAF attitude

Despite all the hate, despite all the naysayers, all kinds of stuff still gets made. Why? Presumably because people want it. They clamor for it, and sometimes they end up making it themselves. So no matter if people snort at Skyrim’s combat mechanics, or applaud Super Meat Boy’s controls, or cheer for more voxels or less.

Whether it’s meat and potatoes you’re looking for, or a nice garden salad, you can find it here.

 

Thanks for reading,
Mister Bums

You can contact me at yjseow@worthlessbums.comTwitter, or leave a comment below!

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.

 

Complexity

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 yjseow@worthlessbums.comTwitter, or leave a comment below!