getify / cloud-sweeper Goto Github PK

the game will probably remain an entirely canvas rendered game, but investigate loading all the SVG artwork as SVG documents (so they can be scripted to, say, change colors on the fly, etc) instead of in <img> elements.

current code only normalizes client/screen coords for touch events, fix for pointer events too.

noticed that when app is pinned to home screen (tested with android 5), upon launching sometimes the orientation lock seems to mess up the detected dimensions, so the welcome screen draws wrongly.

could be that orientation change doesn't fire resize? is there an orientation change event to also listen to perhaps?

we could store every single randomly generated element and all the game moves and then completely reconstruct the game frame by frame. with that, we could have a feature that auto creates a video / highlight reel for your game play.

will help reinforce the impression of the plane flying forward through the sky and not just moving statically up and down.

Okay if I contribute some unit tests? qUnit okay?

will this need the WebAudio api? what do we fall back on if that's not available?

probably have it store the game version with the score, and if the game version has a minor or major change (not just patch), have it reset the best scores to 0

ideas under consideration:

• powerups
  • refill sun meter
  • "air bomb" that clears all clouds/birds
  • bubble to protect the plane (and help clearing clouds)
  • water canon that squirts the clouds for you to clear them away
  • giant vacuum that sucks up clouds, birds, obstacles
• more obstacles
  • multi-bird formations to fly around
  • kites
  • helicopters
  • falling debris
  • tall skyscraper to fly over
  • storm clouds to avoid (lightning, etc)
• missions
  • flying through hoops
  • collecting coins in a time limit
• leaderboard (tracking both cloud score and sun meter %)
• zen/sublime mode
  • relaxation/practice mode
  • only plane and clouds, no score/meter, no birds, no crashing

pretty obvious how amateur my artwork is so far. working with a professional artist to get better artwork, probably in a similar style to angry birds.

observed that scene shaking doesn't always finish (like at end of the retry-entering animation, for example), which leaves the scene offset incorrectly.

figure this out and fix.

some parts of the game are still churning GC... track down places where objects (or arrays or functions) are being created and thrown away and see if they can be reused.

Rather than doing artificial timing like with timers, the game uses framerate (via requestAnimationFrame(..)) for all its timings, with the assumed target of 60fps. Luckily, most good devices seem to be running the game very near that already. But old devices or those without defaulted hardware acceleration (like linux desktops!) are running at or below 45fps routinely, which makes current game play on those devices quite painful.

Note: Obviously, optimizing the game's code more is a good strategy all around. However, this thread assumes all that has already been tackled, and that there may still be environments where the best version of the code still runs slower than desired. In those cases, the game should have some strategy for adjusting itself.

Should the game track its own FPS (beyond dev/debugging, but obviously just not displayed)? Should it adjust itself if it determines that a device is running substantially under (or over?) the target 60fps? Should the game refuse to run if the effective fps is just too far below some reasonable threshold (like 20fps)?

The game could monitor fps and round to nearest 15fps increments (15, 30, 45, 60, etc), and then scale its timings accordingly. Or, if the fps is at or below 45, could scale down to 30 fps artificially, and just drop (aka, not draw) every other frame of its normal timings.

Or, it could detect a fps below some threshold like 50 and suggest the user pick a simple-graphics mode which maybe uses lower quality graphics.

Investigate all these possible strategies (and look for others?) and test them out on old devices (like iphone4 for example).

performance.

I'm not a big fan of the constructor pattern, as most people who follow me know.

But it does seem to help when objects have a predictable shape and are created frequently. NOTE: this has nothing to do with using classes as a design pattern. It's a way to declare the shape of the object in a way that the engine can pre-optimize for.

ex:

// instead of:
var obj = { x: .., y: .., z: .. }

// do:
function makeObj() {
   this.x = ..
   this.y = ..
   this.z = ..
}
var obj = new makeObj();

Test on older androids, older ipones, all available windows devices, tablets, etc.

suspect that the width: 100%; height: 100% CSS (which are overridden with style setting) is messing with some browsers' ability correctly display the <canvas> at its requested size.

May also be the reason why some browsers seem to report improper numbers for width / height so the game cannot properly scale/ratio itself -- thus possibly related to #8.

appcache is widespread but dying. serviceworker is on the rise.

should we use both? neither? etc?

According to Apple's docs, adding the following meta tag will allow full screen support when the user adds the site to the home screen.

<meta name="apple-mobile-web-app-capable" content="yes">

https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html

want: animated svg (an svg with css animation embedded in it) for a progress bar... probably just a simple spinner of some sort. should be in place with an <img> tag by default, with the scene canvas hidden, until game has loaded and is ready to go.

too much stuff in game.js, refactor. Move each of these sets of functions to a module:

• interaction event handling
• debug/tracking
• welcome screen
• game intro (play hint)
• retry

note: leave the stuff for actual game-play in game.js. :)

scaleZ or whatever.

note: this does NOT mean use a build process, just have a manually updated build number constant.

currently, the bird is a singleton of sorts because of how the ticks work (meaning multiple birds couldn't be flapping at different intervals). fix this so we can have as many birds as we want.

"Press & hold to fly up"
Well, yes, OK, I suppose. But... press what?
I see up arrows next to the message, but pressing the up arrow on my keyboard does nothing!
Ah, that's left mouse button? OK.

Might be better to be a bit more explicit... 😄

So, that's a relatively easy clone (yet another one) of Flappy Bird?
Good, why not? And it is well made: very fluid on my quick test on Chrome. Good experiment ground.

This game could easily be ported to Firefox OS TV by adding/updating a few key listeners

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/TVs_connected_devices/TV_remote_control_navigation

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Platform/Keyboard_events_across_browser_elements

I have a Firefox OS TV so I can test things out for you! :)

make sure the game really is using the optimal ratios for all devices. investigate why it seems sometimes that the width/height are reversed in terms of what's reported to window.

For various performance reasons, it is surmised that canvases that are at least 256x256 can be hardware accelerated, so consider modifying the logic that deals with all offscreen canvases to use that as the minimum size (even if we only use a small part of it).

Need to first investigate:

1. what is the real benefit of hardware acceleration for non-visible, offscreen canvases?
2. which platforms/engines this is true for, and if the target dimensions differ in any meaningful way?
3. if you have a 256x256 canvas but you only use a small part of it, do you still get the HA if you're drawImage()ing from it and you only take that small part?

+@petkaantonov