GameDevBlog

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.

 

sixty second shooter update day!

So, last week, Isaac took the title of sixty second shooter world champion away from Tomo. What do you want for a prize?

This week, (before I even managed to get the update in) I seem to be leading the pack, but I'm not eligible for the nonexistent prize. One jvoung already has a pretty solid score, in the 200K range. 

For me, this was another week filled mostly with stuff that was not-working-on-the-game.  

But I did manage to get some window-filling goodness in there.  Ben Guildenstein's been asking for it for weeks and I finally did it.  (You see?  I do, eventually, respond to feedback.)

Turns out that extra 20% screen real estate makes a big difference!

And, sorry Ben, it doesn't automatically go full-screen, but if you full-screen Chrome yourself (that's F11 on Windows) it's pretty sweet.

Or, if your framerate sucks, you can play in a smaller window and get some more performance.

And people with small monitors will be able to see the leaderboard now - it won't be wrapped off the bottom of the screen.

To do it, I had to spend what felt like a stupid amount of time mucking with CSS to more-or-less get the browser text to where I thought it should be.  It makes me miss the days when I only had to support 4:3 and 16:9. I should now probably write an article on CSS for NaCl / webgl / maybe even HTML5 games.

Nearly forgot the link.

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.

sixty second shooter belated update day!

Okay, got most of the bugs I know about worked out, including one with logging in that I don't know how many people got hit by. 

I did a fair amount this week - but it's pretty rough:

• a macrogame: earn and spend energy to give yourself an edge (and, because I haven't yet implemented a "bonus energy of the week" or "bonus energy of the day" system, Tomo starts with nothing. Now's your chance to beat him.)
• worked on bringing some clarity to the game mechanics: little score readouts when you destroy enemies, and it gives strategy tips between games
• new powerups: double-fire and energy coils
• a few tweaks, such as making powerup-collision more forgiving (I may not have gone far enough there)

Let me know what you think.

Tomo's still world champion - one of the anonymous players came close to beating him last week, but not quite.

 

sixty second shooter on the show floor at GDC online

If you can't run sixty second shooter for whatever reason (no webGl, don't want to install Chrome Beta...) and you're going to GDC online the Google developer outreach guys are showing it and other native client games on the show floor. Go check 'em out!

sixty second shooter update day!

Tomo is still the world champion at sixty second shooter.  WILL NOBODY UNSEAT HIM?

I didn't have much time to work on the game this week. Tomo helped me decide that last week I went too far in tightening the game up and lowering variance - this week, things will be more random and building chains is easier than ever, so we should all be able to rack up higher scores. 

Also made some changes to the way leaderboards work - Tomo will only be on the main leaderboard once now, so he won't scare anybody away - and there's a leaderboards page where you can examine high-scores by level.  So if you don't want to compete in the Big Show you can always stay on level one and see how high a score you can get there. 

And I put in some half-assed antialiasing. I'll make it three-quarters-assed this week.

FIGHT!

Over 100 served

sixty second shooter hit over 100 installs in the Chrome Web Store today! - may not sound like much but it's pretty good for an app that isn't "Featured" or "New & Noteworthy."  

sixty second shooter update day!

Today's update should be easier to run than ever - no more setting environment variables or command line parameters, just install Chrome 15 and the game.

And a new tournament begins, with new tweaked mechanics.

The winner last week, sniping Anonymous's score of 800K this morning, was TomoMoriwaki (again) with a whopping 5M points. I should offer some kind of prize for winning the tournament. Except Tomo would always get it.

So one of the biggest changes in this update is I'm fixing an exploit with the Chain Reaction. Tomo will still win, but not by so gosh-darn much. I'm also making the Chain Reaction harder to attain - perfect world, in my mind, is it's like the Blazing Speed from Bejeweled Blitz - something even really good players only see a fraction of the time.

Other changes this version:

• graphical improvements
• glow and blur - that you can disable
• choose between in-game and browser fonts
• new slow-mo powerup
• more powerups active at any one time - should make game less random
• quicker death cycle (as I mentioned last post)
• autofire - your machine gun is always on
• and some other stuff that I'm forgetting

Enjoy!  (Here's a screenshot with blur off:)

 

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?

sixty second shooter mid-week update

A lot of people thought the game didn't work because they couldn't see the text: in particular the text that said "press 'x' to start" - I've made a hacky fix to that, using browser text and CSS absolute positioning so the game is playable without the NACL_ENABLE_PPAPI_DEV flag.  Downside - some people will see the text twice, and there's a framerate hit.

A more permanent solution is on its way.

But until then.