GameDevBlog

Test Driven Development, Several Years Later - or, I'm a Big Liar

Martin's comment on an old post reminded me that I really ought to come clean. I said in that post that I was going to stick with TDD despite its unclear benefits. I didn't. Our Bejeweled Blitz: Live contract came along, and the other programers weren't into TDD - I put some tests on a few bits here and there but that was pretty much it.

So I was pretty much broken, and with sixty second shooter I didn't even bother. I just wanted to get that game done as fast as possible and was willing to do a half assed job. (BTW, I slaughtered a sacred cow there: it's generally true in our industry that polish is king and that a great, late game will do better than a game that's on time but not-fully-baked. But Farmville shows it's at least possible to ship a half-baked game and make it better afterwards.)

With both those games, by the way, I'm pretty pleased with the non-bugginess. It's hard to really tell with sixty second shooter since I didn't hire a QA team or anything, but one interesting way to tell your game doesn't have a lot of bugs is if everybody is reporting the same ones. It's a much smaller game than Schizoid or Bejeweled Blitz, but the bugs-per-capita seem great.

What I chalk that up to is not TDD but being a better programmer. Maybe not quite as sharp (Guys my age start losing their edge at chess, etc, and having kids and cats wake you up in the middle of the night almost every night doesn't help) but I'm almost religiously not cacheing state in my code these days and there's just a lot less room for bugs to creep in.

Django templates are infuriating

In App Engine anyway - at least partly because the Django docs online are for the latest version of Django but that's not what App Engine comes with. 

Cue a whole lot of head banging and "why isn't this working?"

Note to self: do as little as possible with the template system; format things with python instead.

Progress

The "money shot":

The gotchas with Google In App Payments: you can't buy from yourself, so you need to make one account for the seller and another account for the buyer. And it's hard to test locally without opening up your computer to the world, but it's easy to write a batch file to deploy an app engine test app (the name of the app has to match the directory it's in, so my batch file copies the whole app folder and then copies over the yaml before deploying) and read the postback-verify logging from the dash.

I decided to do monetization with Google and friends with Facebook ... I can always add G+ later when they make it available. The problem there is managing the data. It would be nice to have one record per player. What if you log in with facebook, set a high score for friend-leaderboard-purposes, then log out, then log in with Google, and set a high score on the global leaderboard, and then log in with both? Wouldn't it be nice to combine those two records? I'm not sure if I'll have solved that in Version 1.1.

My plans for Version 1.1:

- friends leaderboards

- buy energy

- respond to the latest batch of feedback

Can I get it done by Monday? Seems like it's in striking distance.

Crap! Didn't read the API closely enough

Remember my plan to monetize through Facebook?

Didn't read the docs closely enough: "Web Sites integrating Facebook (Connect) ... can not use Facebook Credits."

I wonder why not? Why leave that money on the table? Anybody know?

So ...

What am I going to do now?

I can only do friends leaderboards through facebook.

I can only sell in-game energy through Google.

Hmm ...

Server Costs

Well, this sucks:

Guess when Google AppEngine changed their pricing model?

If I leave things as they are, it'll run out every night and still cost me $15 a month. Pretty sucky for everyone. So far I've made a whopping $10 from donations so I'm in the hole.

What's hitting now isn't actually bandwidth anymore - now it's datastore reads. The leaderboard. I don't know if the size of the database has anything to do with it or if it's just number-of-reads. Well, I'll do what we did with Bejeweled Blitz for XBLA - only read the leaderboard if you get a new high score. 

In the meantime, if you want to help me cover my costs, donate!

 

Killing Multiple Birds

Out of blind brand loyalty I'd been hoping to use Google+'s circles for the friends leaderboards - because, hey, I used Google tech for everything else, so why not go Google all the way down?

Well, they're not letting anybody else in on the Google+ API right now, but they're very open about Chrome Web Store apps using other technology, as long as it's open. So. Facebook it is.

Unfortunately, that means pulling everything else from Facebook in as well - authorization and monetization. On the bright side, that means I'm solving a few problems at once:  Jare's problem with it using your nickname in the leaderboards; monetization; and friend leaderboards all together.

On the dark side, it means everyone who's signed in using Google's authorization will have to register again once I switch.

So, in my Facebook tech exploration, the most useful factoid I've discovered so far is that when you're testing it on your local machine, you can use http://127.0.0.1:8080 (or whatever port you happen to be on) as your website URL and it works. Whew. I really didn't want to have to deploy the app for every change or test.

CSS for native client / webgl / html5 games

I'd been having some trouble displaying text in sixty second shooter. There's some stuff Google's working on that's still in development that worked well but I don't want to rely on it. A couple versions of Chrome ago, using browser text on top of the native client stuff seemed to hash my framerate - but either it was my imagination or they fixed it. Browser text is pretty decent now, particularly if your game isn't CPU bound - you can check it out by playing the game with the about:flags framerate counter enabled and turning the "browser text" option on and off.

But searching websites for how to arrange text left me with no clue how to make it look "videogamey" - but eventually, with some advice from Gregg Tavares and others, I found what I was looking for, and here it is.

For a lot of this, jsfiddle.net was awesome for just mucking around with a decent iteration loop. 

You can check this all out in the field, by the way, by going to the game sixtysecondshootertest.appspot.com and choosing 'view source' - (you can also see how I did the game's audio.)

I'm a rank amateur at this stuff, so if you know better ways, I'd love to hear them.

Web Fonts

Web fonts are cool. My wife picked out 'Comfortaa' for sixty second shooter. It does seem to add a second or two to the load time, which is a problem, but I'll work that out someday - the game really needs a loading bar.

Overlaying Text

I just wanted to overlay text on top of the game area, for a start. Could HTML even do that? I wondered. The old HTML I knew was only good for arranging witihin a single layer. Overlap wasn't its thing.

Eventually I tracked down the "position: absolute;" style in CSS. It's just what I needed - there's even a z-index if I want to control the order things are displayed, though I didn't seem to need it. It feels good just knowing its there.

For example, to put the player's score and whatever other useful in-game information in the upper-left hand corner...

Controlling Visibility

Here's another little tidbit: when I wanted to hide an element with javascript, the first thing a Google search told me was to set its style.display to 'None'.  One problem with that is it bashes whatever information was in the style.display before, whether it was 'inline' or '-webkit-box' or what. A better answer, with Chrome anyway, is to use 'style.visibility', setting it either to 'visible' or 'hidden'. This also keeps the element in the flow - other widgets won't move when it disappears. To wit.

Creating Elements On The Fly

I wanted the points you earned for shooting badguys to pop up when you hit them - the way to do that was to use the CreateElement javascript function. At first I kept track of them in a dictionary, but then discovered I could use the setAttribute() and getElementsByClassName() functions which allowed me to attach data to them and track them. Sorry, no jsfiddle for this one, check the game code.

Sometimes these would stick off the screen, and ugly scroll bars would pop in. Using overflow: hidden on them wouldn't fix it - so I used overflow: hidden on the entire page. Which will mess people up with screensizes smaller than 1024x768, but according to my stat reporting nobody's running that small ... so far.

Resizing The Game To Fit The Window

And that was all I needed, up until I wanted the game to resize with the window. Up until now I'd been doing everything in absolute pixels.

First, resizing the window is pretty easy: use the javascript onresize. (With native client, when you resize the embedded native client element, it calls DidChangeView on the instance. From there I resized my post-processing buffers as necessary.)

The hard part was putting text in the right place - particularly centered text. One way is to use absolute: position, left: 50%, text-align: center, width: arbitrarypx, margin-left: -onehalfarbitrarypx. (Resize that window to see it in action.)

But some of my text, I didn't just want to center it absolutely - I wanted it centered in the middle of the larger, left-hand pane. And it had all sorts of tabley stuff and radio button lists and doodads inside it. This was the biggest pain. This was where I broke out the new flex box stuff which is differently supported in different browsers ... on the bright side, since I'm only supporting Chrome, I only had to use -webkit-box. On the dark side, I discovered interesting things like it's hard to combine flex box with absolute position - look what happens (Chrome/webkit only) if you flex box a list at the bottom of the screen. (My solution for the lower nav bar was to use display: inline and lots of padding-right - they don't spread out exactly the way I wanted but whatev.)

For the box-centered-in-a-pane, I ended up faking it with padding. There's got to be a better way:

A Book

I learned almost everything I know about CSS from CSS: The Missing Manual... and a lot of Googling.

 

Google Analytics is cool

Google Analytics is something Erik Erwitt set up for me that I knew nothing about.  

Just realized it let me find out this:

All of the machines I have access to happen to be running at least 1600 width resolution - the game looks good with them.  Little did I know a quarter of the visitors don't run that wide, and aren't seeing the logo / instructions / leaderboards off the bottom of the screen.

Okay, escalating the priority of screen resizing.

Antialiasing with Native Client

I could just as easily call this article "how to antialias with OpenGL ES" - I was fairly surprised to find that there was no out-of-the-box support for antialiasing in ES. It took me back to the early Playstation 2 days, before people figured out how to antialias cheaply there, and the early slew of games for it that had that jaggy Babylon 5 look.

Fullscreen antialiasing - where we render to a frame buffer twice the width and height of the screen and then downsample, killed the framerate.

It was suggested that I use FXAA. Unfortunately, FXAA seems to require sRGB color space, which isn't supported out-of-the-box with ES either. 

I thought to myself, man, this must be a solved problem, with all those iOS developers out there. So I googled a bit, and discovered that they fake it - either by putting alpha into the mesh or the texture.

Well, turns out I'm not even using textures in sixty second shooter (for the most part), so it was fairly trivial for me to put white textures in with alpha'd out edges for a lot of my meshes. And, on my machines, anyway, the cost was nothing - I guess becuase one texture lookup was free since I was also doing a color calculation in the fragment shader. So, win!  Looks like AA with no cost to framerate.  

Before:

After:

In other news, sixty second shooter hit 200 installs today, and I've gotten a few "conversions" - people actually signing in! If it maintains that conversion rate once Chrome 15 launches, I'll call it a success.

Features vs Framerate

Something I've been deliberating lately - I've done console development for so long I've never had to worry about different performance characteristics on different machines.

One nice thing about web development is I can keep track of statistics about the games that are being played and what framerate they're seeing.  Good news - seems like most people so far are playing with better machines than my laptop. (Though that may be an early adopter thing.)

So, for them, I'd like to turn on some of the cooler features I've worked on - in particular post-process glow and blur. On my machine, it makes things run just a little too slow - when most of your frames are <33ms but once or twice a second you get a 66ms zinger it's worse than running at a consistent 50ms.

So...assuming I don't come up with any genius optimizations...people with machines like mine should have post-processing turned off.  Or play in a smaller window.  It would be really nice if the game could detect that and adapt appropriately - "Am I running below 30?  Turn these features off!" - but what would that look like to the player?  Some players would be playing along with the effects on, and then they'd get a bad frame or series of frames in some gnarly stretch of game, and then suddenly the effects would turn off.  It would look like it broke, like a bug...

Games back in the early days of hardware acceleration used to do things like that, but I think these days PC games have mostly moved away from that - these days they make a best guess and stick with it and let you adjust settings if you want.

So, for now, I guess that's what I'm going to do - I'll run with the full suite of effects and let the players turn them off if they want better framerate. But that's putting a lot of responsibility in the hands of the player - they'll probably have a better time if they turn off the glow and play at 60, but will they realize that?

So, I don't know. What do you guys think?