Why he vertically aligns his code (And why you shouldn't)

Over on Terence Eden's blog, the latest post is about vertically aligning code : https://shkspr.mobi/blog/2014/11/why-i-vertically-align-my-code-and-you-should-too

The "bad" example looks like this:

Which is then "fixed" to make it look like this :

Just for comparison, I typed it into my regular text editor:

The point being, because I'm using a well designed syntax highlighting where the numbers (green) contrast with the operators.  If you so choose, you can visually inspect just the green numbers and just as easily spot the outlier.

(Pro-tip: To concentrate on just one color, defocus your eyes slightly by staring "through" the plane of the monitor to engage your eye's cone cells.  With a little practice, you'll find yourself doing this automatically when you want to focus on the structure of the code instead of the details.  For best results, you might need to make the glyphs larger on screen....)

Note too, how the combination of proportional font and camelCase instead of under_scores keep the code density onscreen the same, but the individual glyphs appear larger in-place.

My code editor also uses syntax highlighting to hint the kerning.  So for example, the kerning around the equals sign and the semi-colon are particularly loose to aid in their recognition. Similarly, the single space character (' ')  has a width 50% larger than would be used for normal paragraph text.

But here's the big change that Terence missed, I've sorted all the variable declarations alphabetically to ensure there are no duplicates.  This is a zero-cost policy that can simplify merges and conflict resolution when multiple variables (possibly duplicate) have been added upstream.

Coding Atoms

The bigger problem is the coding atom is the line-of-code.

Lets take another code example from Terence's blog post, this time a function declaration :

extern int SomeDemoCode(int fred,
                        int wilma);

That's an atom right there - you can't split that up without changing its meaning. Watch what happens if I try to add a parameter in an excess white-space environment:

extern int SomeDemoCode(int fred,
+                       int barney,

                        int wilma);

The diff splits our (atomic) function signature across 3 lines, exposing us to problems where a git merge might accidentally succeed, when really we need it to flag a merge conflict.

(For a real world case of how bad automatic merging can be, take a look at the Goto Fail Bug)

Now compare if everything had been on the same line, the diff would look like :

-extern int SomeDemoCode(int fred, int wilma);
+extern int SomeDemoCode(int fred, int barney, int wilma);


TL;DR: Using whitespace to control your code presentation is a hack from the '70s.. get a better editor.

p.s. Some formatting edits have been made to make this post clearer.

Wi-Fi in Schools

A friend of mine asks :


Question : What's the effect on the human body, of 20 children in a classroom, each downloading a 3 minute youtube video over Wi-Fi?

An excellent question!

As with all good science, let's start with an experiment.  I happen to have a 3 minute HD video on my network, so I can time how long it takes to copy across to my laptop:

missingbytes:$ time copy /NetworkDrive/HDVideo.mp4 .
real   0m6.550s
user   0m0.001s
sys    0m0.116s

So a single 3 minute video (3:19 to be precise) will use about 6.5 seconds of Wi-Fi time to copy.

With 20 students, and rounding up a little to account for congestion..

... lets call it 200 seconds of Wi-Fi activity total.

Transmit power

The transmission power for Wi-Fi signals is heavily regulated in the EU, the US and also in New Zealand where I'm performing the test.

The maximum 2.4-GHz transmission power is regulated by law, so lets assume it's 20dBm = 100mW = 0.1W ( source )

As we all learnt when we were in school, a watt is a joule per second, so 200 seconds at 0.1W is 20J.

Now we know that a class room of children downloading a youtube video results in 20 joules of microwave energy being emitted from the Wi-Fi router's antenna.

A brief diversion : Ionizing and Non-Ionizing radiation

Electromagnetic radiation forms a spectrum, from low frequency and radio waves, up through the microwaves, visible light, X-rays and on to gamma rays which have very high frequencies indeed.

Those high frequencies are characterized as ionizing, they're very dangerous to humans and their ability to cause DNA damage and ultimately cancer is well known. This is the reason why we need to be so careful around medical/dental imaging devices, and need to take precautions such as wearing sunscreen and polarized sunglasses when we're outdoors on a sunny day.

It's not necessarily the amount of energy, it's more the frequency that's the problem.  This high frequency ionizing radiation quite literally has the ability to rip electrons off their atoms.  It's these "ions" which go on to cause damage to biological systems.

By contrast, the lower frequency non-ionizing radiation (such as used in Wi-Fi, or FM radio) doesn't have the same ability to affect us in this way.

By itself, non-ionizing radiation can only cause heating in biological systems. Indirectly, it's this heating which slows down or speeds up chemical reactions and/or signalling within the cell, and it's these secondary effects which has the potential to cause problems.

Intuitively, this is why the 1000 watt microwave oven in your kitchen makes food super hot in a few minutes using microwave energy, but it doesn't actually make your food radioactive.  (You'd need an X-Ray oven for that!)

Anyway, lets continue, we've got 20 joules remember?

Absorption

Now we need to make a pretty unrealistic assumption. Suppose that the entirety of those 20 joules of energy was somehow absorbed by one child.  Of course, this can't happen in the real world for two fairly obvious reasons:

• A router transmits energy in all directions.  For all the energy to be absorbed by the child, the router would somehow need to be inside the child.
• Microwave energy interacts only weakly with the human body.  That's one of the great benefits of Wi-Fi, it can pass right through walls and ceilings and straight through you and me.

But just for fun, lets continue on anyway and figure out what would happen if all of those 20 joules were absorbed by one child.

An average 6 year old child weighs about 22 kilograms.  (Of course, my 4 year old son also weighs 22 kilograms, but that's a blogpost for another day!)
The human body is about 65% water, so lets consider 14 kilograms of water.

The specific heat capacity of water is 4.18 J / gK

So we have 20 J / (14,000 g) / (4.18 J / gK) = 0.00034 K = 0.0004 °C
(That's 0.4 millikelvin for all you geeks out there.)

Answers!

So there we have it, even with a wildly exaggerated assumption:

Answer : A classroom of children, all downloading a 3 minute youtube clip over Wi-Fi yields a maximum biological heating due to 2.4GHz microwave radiation of 0.0004 °C.

(0.4 millikelvin is about twice as small as it's possible to measure using a precision thermometer.)

Conclusion

We shouldn't really be too surprised.  Wi-Fi signals are incredibly weak. Consider this, those 20 joules of microwave radiation is the same amount of chemical energy contained in one thousandth of a teaspoon of sugar.

There's no way to prove scientifically that microwave radiation from Wi-Fi is safe in the human body. Science doesn't work that way. You can't prove a negative.

But we can try and make smart choices about tiny risks.


For example, the exposure from a banana is about 0.1 μSv of harmful ionizing radiation because of their high quantities of naturally occurring radioactive potassium.

Yet who thinks twice about giving bananas to kids in schools?

Thoughts, questions or especially corrections?  Please feel free to leave a comment down below!

ScooterBoy Global Launch

Modka Games is very proud to launch ScooterBoy:

ScooterBoy, free on the App Store, for iPhone, iPod touch and iPad

ScooterBoy HD screenshot (click for full res)

Gameplay First

ScooterBoy brings back the classic feel of the arcade, updated with one button touch controls.  Of course you can jump and dodge to avoid obstacles, but in ScooterBoy you also swipe to change lanes, drop-boost to go faster, and there's loads of power ups and pickups to collect too.

"Scooter Boy!"

If you want to climb the high score ladder, you'll need to learn the mushroom's secrets.  Or you can simply relax and explore ScooterBoy's amazing world at your own pace.

Upgrades

Marmot, jumping with the shark.

Upgrade your scooter, choose new characters, hats, wheels and more..

Buy a friend!

Need a little something extra?  Why not buy a Pet from the store?  These cute little helpers will fly along and collect coins and points to boost your score.  You can even flick your pet to reach up even higher.

PhotoBooth

Bizzer in the PhotoBooth with his dragonfly.

Meanwhile, in the PhotoBooth:

1. Choose a background and a frame.
2. Take a photo of your ScooterBoy.
3. Share with your friends.
4. Repeat!

Music

Download link for ScooterBoy

Did I mention the music?  ScooterBoy has nearly an hour of classic recordings from the 50s and 60s

Download, for free!

And the best part, ScooterBoy is free to download, and free to play!

So what are you waiting for?

Download ScooterBoy Now!

Praise the Fire Fighter, Damn the Safety Inspector

There's a sickness eating our industry.  It's a culture of Macho Programming.  In it's simplest form, it's the idea that if we just push harder, longer, stronger, then we will win.  Yet time and time again, experience shows that the way to win is by working smarter.

Side-effects

I was once working on a particular AAA title.  The game was running late.  We were in crunch, and had been for a while.  There was no end in sight.  I came across the following code:⁽¹⁾

bool DetectCollision(Vector3 location, float radius){
  ...
  radius * 1.2f;
  ...
}

So that line of code makes the collisions a bit fatter.  It's what we call a 'Fudge Factor' - we don't know why a problem is occurring, so we fudge the numbers a little until it works.

But take a closer look.  The statement as written has no side-effects.  It doesn't actually modify the value of radius.  When the programmer wrote:

  radius * 1.2f;

they intended to write:

  radius *= 1.2f;

Let's review the facts:

• It's the wrong fix to begin with (fudge factors are generally a bad idea)

• It doesn't actually change the behaviour of the running program

• The programmer didn't verify that their "fix" worked

And we can safely assume that the programmer didn't verify the original bug in the first place.

Compound Fail

It gets worse.  In this late stage of crunch, there were so many easily avoidable bugs coming in to the code, that the production team mandated every changelist required a second programmer to sign off.

That's right, not one, but two programmers, working together, managed to convince each other that this placebo changelist actually improved the game.  Together, they marked the bug as fixed and sent it back to QA, fully confident they had made the game better.

What other trivial mistakes did those programmers make that night?

What a colossal waste of time and resources, simply because those two programmers had inadequate sleep.  The project would have been much better off if those two programmers had just gone home at 18:00.  Or 17:00.  Or even 14:00.

[Edit: I just wanted to add, these are actually two really good programmers! I'd jump at the chance to have them on my team again.  The equation here is crunch + good programmers = too many careless mistakes.]

Praise The Fire Fighter ...

When you're deep in crunch, it's easy to see the heroic efforts, the mountains of caffeinated beverages, the change logs at 4am.  It's easy to point to the person who's working the hardest and say "We all need to be more like that guy."  Because when it's all falling apart, you need to do something.

(Hint: That something we need to do is to get more sleep.)

... Damn the Safety Inspector

And when you're at the beginning of the project, and the Safety Inspector is telling you that what you're building isn't up to code, that the schedules are unrealistic and will lead to crunch, slipped deadlines, hard-to-find bugs and adds unacceptable levels of risk to the project...  Well they're easy to dismiss "We're trying to build something here! Why are you trying to stop us?"

(Hint: The Safety Inspector is probably right.)

Macho Programming

As an industry, we should be working smarter than that. We should be rewarding measurable results and hard evidence, rather than effort and posturing.

To me, Macho Programming, is blundering onward in whichever way you possibly can, without regard to what's best for the project or the team, simply for the appearance of getting something done.

I think we can do better than that.  In the true Agile sense, as a team, we need to make the best decisions based on the best information we have, right now, and move forward in the best direction we can.

Who's with me?




⁽¹⁾ Some details have been changed to preserve anonymity.

ScooterBoy NZ Launch at Digital Nationz

ScooterBoy and Modka Games was lucky enough to be involved with the Homegrown exhibit at the Digital Nationz expo!

The ScooterBoy booth at Digital Nationz

Hands on

Our booth consisted of a large monitor hooked up to a laptop (Display Mirror), playing the actual game.  We had a second laptop with a slideshow, and then lots of glossy printouts of the logo, icon and artwork.

www.scooterboygame.com

We also had two iPads running the game, which we tried to get into the hands of as many players as possible, getting some awesome user feedback.

Oh, and a portable "QR" code with a direct download link for iPhone users!

Attract Mode

For the main screen, we cooked up a special build of ScooterBoy running in "Attract mode" - basically bouncing between the intro comic, level selection, and the game itself, choosing random levels, scooters, characters, pets, music, etc.

I hooked up Momma's AI to the player, so the game would merrily play itself with no human intervention required.

"Attract Mode" turned out to be a super useful feature, it meant we could talk to gamers 1 on 1, while the screen continued to play for the small crowd that gathered.

... in fact "Attract Mode" proved to be so useful, that on the second day of the expo, two other Indies had added the feature to their game!

Big Screen

ScooterBoy also got some time on this awesome 103" panel upstairs in the chill out zone.  It really shows off the amazing HD retina graphics in ScooterBoy!

Telecom Homegrown "BigScreen", running ScooterBoy

Thanks!

Thanks everyone for making an awesome #ScooterBoyGame weekend with @DIGITALNATIONZ

And a special shoutout of thanks to Telecom, Asus, @oldjackgrey, @BenTuhoeKenobi and @sknightly!!

Shameless Plug

And if you're in New Zealand, and own an iPhone, iPad or iPod touch, why not download ScooterBoy and give us a rating! ScooterBoy on NZ App Store

Random

Lately, I've been tuning the "Drop-Rate" of pickups in Scooter Boy.  It's actually a lot like handing out candy at Halloween.

Allow me to use this handy diagram to explain:

Too little Candy	Too much Candy
Not enough candy to go 'round - some people walk away empty handed.	Everyone is all full of sugary goodness, and they don't want any more.

But that's not actually what I wanted to talk about today.

I wanted to talk about Pigeons.

The Pigeon Food Dance

There was a famous set of experiments back in the '30s that revolved around withholding candyfood from pigeons.  In one of these experiments, the amount of time between successive drops was random. It turns out that each of the pigeons developed a (unique) ritualistic food dance. In happy pigeon land, it was the completion of the dance which caused the food to appear.

Now the curious thing was, the time it took for the pigeon to complete the dance was slightly longer than the average time between drops.

So when the pigeon completed the dance, there was a better than 50/50 chance of getting food.  And if not, well repeating the dance a second time would surely do it!

(Have you ever timed how long it takes to reboot your computer when you've got Tech Support on the phone?) 

Random Drop Rates

For most of Scooter Boy's development,  I've been using random drop rates.  Power ups would appear, seemingly at random.  Sometimes you'd get lots, and sometimes you'd go ages without seeing any.

Worse still, changing the drop rate, by changing the percentage of a drop, was very clumsy. You'd double or quadruple the drop rate, play the game, and the results would be... well ... random... There was no way to tell if your change was making the game better.

In short, random drops, just aren't fun!

A Drop Rate Schedule

I'm in the process of changing all those drop-rate percentages into times. 30±10 seconds between drops.  Or 120±60.  It's so much more measurable. And it turns out, it's a lot more fun too.  As a player, it feels like the powerups are rewarding your effort.

So down with Mathematical Randomness! Lets make the game match the player's expectations. Lets put the fun first!

Analytics

If you happen to live in a certain North European Country, in the wee hours of this morning, ScooterBoy went live!!

That's right, you can now download ScooterBoy, for free!!  (with certain geographical restrictions.)

"But why can't I download it??!" I hear you ask.

Well, you see, it works like this :

We want to make the best release possible in the largest market.

 ➡  The best way to do that is to use feedback from real live customers to improve the game.

 ➡  Where best to get those customers? Yes! From a certain Northern European Country!

Analytics

Now our analytics takes over.  How many downloads will we get? How long will players play? Which level and characters do they play the most? How quickly do they earn currency? What's their favorite IAP (In-App Purchase). What does our retention look like? Where does the game crash?

We can turn all these questions into metrics, then apply those metrics to our game.

We will compare our numbers to our expectations, and then see which numbers we want to improve.

What If?

The next step is to play the "What-if" game.  For example, suppose we make the decision we want to increase player retention:

• What if we had more characters?
• What if we had more levels?
• What if the game were harder? easier?
• What if we gave a bonus for playing every day?
• What if we had daily challenges?
• What if we highlight the leaderboard?

Soft Launch

Exciting times for ScooterBoy!  And lots of geek-out points writing queries in SQL to try and turn a mountain of data into usable information.

We can't wait to make ScooterBoy even bigger and release in more markets!

...watch this space...