Rugby is played by sissies. Hurling is where the real men go to play. They really should rename it "hematoma ball".
author David Geary
pages 615 pages
publisher Prentice Hall
The reason this book gets a nine is it accomplishes everything it sets out to do and Geary does a great job dividing up task after incremental task of setting sprite sheets and backgrounds into motion. The reason it doesn't get a ten is that I was personally disappointed with the the author devoting little time to physics and their simulations.
The book is laid out to enable its use as two kinds of resources: cover to cover and chapter specific topics. Reading this straight through, there were only a few times where it felt like I was needlessly being reminded of where I had already read about tangential topics. On the plus side if you ever want to see how Snail Bait implemented something like sound, you need only spend time on the chapter devoted to sound sprites. One mild annoyance I had with the text was that the author seems to always refer to Snail Bait as “Snail Bait” which leads to a Ralph Wiggum-like aversion to pronouns or saying “the game” instead occasionally. It might only be me but it can become tiresome to read “Snail Bait” five or six times on the same page.
You can read a sample chapter here that shows how to implement sprite behaviors.
The third chapter delves into draw and rendering graphics in the canvas as well as introducing the reader to the game loop. It spends a good amount of time explaining the use of animation frame control in a browser to keep animations running smoothly. It also begins the auditing of frame rates so that the game can respond to and display things normalized at the rate the user is experiencing them. It also touches on how parallax can be employed to show things closer up moving faster than those further back in the background. This illusion of depth has long been popular and is even finding its way into scrolling on blogs and I wish that Geary would have spent more time on this perhaps in a later chapter but offer the reader more on how to do multiple levels of depth.
The next three chapters cover the use of loading screens, sprites and their behaviors. Snail Bait uses all its graphics from an open source game (Replica Island). But if you were to design your own graphics for your game, these chapters do a great job of showing how to construct sprite sheets and how to use tools to construct metadata in the code so that the sprites are usable by the sprite artists. Using the flyweight pattern, Geary sets the stage for more complex behaviors and actions to come in the following chapters.
The next three chapters cover time, stopwatches and their effects on motions and behaviors within the game. The author starts and works from linear motion to non-linear motion and then using transducer functions to affect the time system. The game now has bouncing coins, a jumping player and Geary does a good job of showing the reader how to emulate behaviors in the code.
Naturally what follows next is collision detection and gravity. The collision detection strategies were adequate but I wish that there was more depth at least referenced in the text. This isn't a simple problem and I did like how Geary referenced back to chapter two’s profile and showed how collision detection performance as you implement and refine and optimize your algorithm. The nice thing about this book is that it often tackles problems with a general solution in the code (runner/sprite collision) and then provides the edge case solutions.
In the fourteenth chapter, the author tackles something that has long been a plague in HTML5 games: sound and music. The author doesn't sugarcoat this citing the long history of problems the vendors have had trying to support this in browsers. There’s a great explanation of how to create and handle “sound sprites” (similar to sprite sheets) so that there is only one download for background music and one download for audio sprites.
Next Geary covers the problem of multiple viewport sizes with a focus on mobile devices. Of course this is one of the biggest issues with mobile gaming today. The chapter is lengthy and deals with the many intricacies of scaling, sizing and touch events. This chapter is long but the highly detailed support of multiple platforms and resolutions is a justified discussion point.
In sixteen, the reader gets a treatment of utilizing sprites and their artists to simulate sparks and smoking holes. The book calls this chapter “particle systems” but I don’t think that’s a very good title as the code isn't actually dealing with things at the particle level. Instead this chapter focuses on using sprites to simulate those behaviors via animation. This is completely necessary on a computation inexpensive platform but it is misleading to call these particle systems.
Now that the game looks and functions appropriately, the book covers UI elements like player scores and player lives. The auditing of these metrics are covered in the code as well as warnings when the game begins to run to slowly. It also covers the ‘edge’ condition of winning in the game and the routine that is followed when the user wins the game.
The next chapter introduces the concept of a developer backdoor so that the reader can manually speed up or slow down the game while playing it or even test special cases of the runner sprite interacting with other elements. It’s a useful trick for debugging and playing around but does devote a lot of time to the specialized UI like the speed slider and other things that won’t (or rather shouldn't) be seen by a common player.
Chapter nineteen really felt out of place and very inadequate on important details. It’s a blind rush through using node.js and socket.io to implement server side high scores. The way it’s implemented would make it trivial for someone to submit a high score of MAX_INT or whatever to the server. The metrics reporting is done in a manner that (in my opinion) breaks from long established logging structure one would be familiar with. While it covers important things to record from your users in order to tweak your game, the inadequacy of discussions about shortcomings makes it feel out of place in this text. It's a topic of great depth and I have no problem with an author touching on something briefly in one chapter — this chapter does lack the warnings and caveats found in other chapters though.
Contrary to the previous chapter, the final chapter is a fast application of the entire book’s principles applied to a new game (Bodega’s Revenge). Geary gives a final run through showing how the lengthy prior discussions quickly translate to a new set of sprite sheets and game rules. If this book is ever expanded, I think it would be great to include additional chapters like this although I would pick a more distinct and popular two dimensional game format like a tower defense game or a bejeweled knockoff.
Link to Original Source
"disenchanted/upset customer"? Clearly, you haven't worked in tech support, or known anyone who has, or read any of the blogs or horror stories, or, really, informed yourself in any way about this. Humans have a bell curve of both "crazy" and "mean", and the tail end of either is not something you'd ever want to come into contact with.
My sympathies are with the Comcast tech support on this one. As bad as Comcast can be, which is at least 300 milli-Hitlers bad, the tail-end of the worst people to call customer support can be worse still. Or just too stupid to be allowed to own a computer.
But Jobs didn't want third party applications on it. There was no App Store. And when prompted about third party apps, Jobs envisioned some kind of web app system. But he didn't want the perfection of the iPhone soiled by third parties.
That is indeed what he said, but I suspect that was just spin. As evidence, I'd point to the yanking of a substantial portion of the OSX team onto iOS development to get those features added. I think he was just putting a positive spin on his not-quite-finished product. "Reality Distortion Field"
Brady Haran is neither, but he puts actual scientists on his YouTube channels, and they talk about honest science (and occasional amusing trivia), with no CGI or celebrity required. No politics, no manufactured quotes, many Nobel prizes.
I'm not a fan of the television series, but do enjoy the books
I enjoyed the first few, but the latest book was rubbish and I've entirely lost interest in the story thanks to the pace of his writing. He doesn't seem to have much in the way of original plot ideas, so it's mostly about character moments, and you have to keep that sort of writing coming for me to stay interested in those characters.
The series, however, I rather enjoy. While it's probably the first series to ever make me say "there is such a thing as too much gratuitous nudity", the pacing is vastly better than the books, the important character moments are all there, and the gaps between seasons aren't so long that I forget who everyone is.
More fundamentally; the only reason to insist solar do baseload is quasi religious.
It's the only thing that can scale, unless fusion ever stops being "just 20 years away". Think of the energy needs of 11 billion people at American consumption levels (~40 TW), which isn't at all a far-fetched projection and of course it won't stop there. Even ground-based Solar hits scaling issues there - it's one thing to shade everything that's already paved, and maybe all the salt flats, but at some point you get significant ecological effects.
Oh, sure, for now, but Solar for now can't be baseload anyhow. Orbital can. It will be a while before panels get cheap enough and enough not reliant on scarce materials to scale. It seems inevitable now, but it's still a ways off. Meanwhile, private space efforts keep making progress. In 50 years, when solar has wide adoption and we're struggling with baseload at night, and in bad climates, I think orbital will be a viable choice vs nuclear or gas.
The only argument for space-based is "it's a way around NIMBY". PG&E did some serious research into it, as there's just no where in Northern California they're allowed to build a new power plant, and demand keeps rising. The main reason the plan failed is still NIMBY: They'd need a 1-block receiving station for the incoming power, and could never get that approved. Fuck California.
It's also useful in Northern latitudes. In Texas, ground-based makes perfect sense: lots of land, far enough south. In Seattle, not so much - even on the 12 clear days each year, you're too far north for much efficiency.
No, I think it is completely unacceptable that we don't have a permanent solution in place. I was just responding to TWX's post - which to my reading implied that the spent fuel requires a lot more attention than it actually does.
The pools aren't necessary forever - 5 to 10 years and then they can be moved to dry casks. Already, over 20% of spent fuel is stored this way. Hardly permanent, as the casks need to be reconditioned/rebuilt every 30-100 years - but not the active process that you describe.
At current rates, with no reprocessing or advances in technology.
... whose jobs are dependant on a federal grant getting renewed.
A recent GAO report said that $106 BILLION was spent by the US government through 2010 on global warming research. If you figure that was through the end of 2010, that was still 4 years ago, so the number is now much larger.
That number absolutely dwarfs even the imagined amount of money that fossil fuel companies have been accused of spending in campaigns against "climate change". I mean it's easily more than 2 orders of magnitude larger.
Even scientists are human, and they are smart enough to know which side of their bread the butter is on.
So it isn't a total waste.