« September 2011 | Main | November 2011 »
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.
| | |
| |
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.
| | |
| |
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:
Tomo's still world champion - one of the anonymous players came close to beating him last week, but not quite.
| | |
| |
The combination of it being my anniversary weekend and doing a fairly large change - a macrogame of sorts! - means, well, things aren't quite ready to deploy. And I'm starting to fade and the wife wants to watch TV together. Tomorrow I'll have something.
| | |
| |
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!
| | |
| |
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.
| | |
| |
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."
| | |
| |
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:
Enjoy! (Here's a screenshot with blur off:)
| | |
| |
I was pretty sure death was too punishing so far in sixty second shooter. That was one of Tomo's pieces of feedback - it breaks up the action for three seconds, lowers your multiplier, and eliminates all the enemies (giving you no points for it) meaning you respawn into a target-poor environment in which it's hard to build chains.
Probably people will just restart the game at that point, I thought.
On the other hand, if death isn't punishing enough, going through the 'next level' portals becomes an easy choice. Always go - ideally, I'd like players to judge their own skill level and hang out on the level they feel they can handle.
And I've been recording the number of deaths in the high score database, and turns out the top scores often have one or two deaths.
So - seems okay for now. I am going to shorten the time of the death cycle, because it does break up the action, but keep the multipler change and enemy evacuation as is...
| | |
| |
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?
| | |
| |
Recent Comments