Book Review: Core HTML5 2D Game Programming 50
eldavojohn writes Core HTML5 2D Game Programming details a journey through creating Snail Bait in well defined steps. This simple two dimensional platform game works as a great starting point for anyone interested in making their very first game targeting many desktop and mobile platforms. This incremental process is expertly segmented into logical lessons with the only prerequisite being fluency in JavaScript. One of the most attractive aspects of this book is that the core concepts of this book don't rely on some flavor of the week JavaScript library or framework. Read below for the rest of eldavojohn's review.
First, this book isn't for people who do not recognize HTML5 and JavaScript as a valid development platform for games. I know you're out there, you can stop reading here and move on to the next article. This book isn't for you. If you have no programming experience this book is likely not for you either. This book dives into concepts faster than Geary's last book on game development in Canvas. You should also be familiar with JavaScript if you want to effortlessly start on this book. Throughout the book, Geary utilizes object's JavaScript prototypes to add functions, uses anonymous functions and refers to common programming patterns. | Core HTML5 2D Game Programming | |
| author | David Geary |
| pages | 615 pages |
| publisher | Prentice Hall |
| rating | 9/10 |
| reviewer | eldavojohn |
| ISBN | 9780133564242 |
| summary | An exercise in 2D game development and mechanics in HTML5 and JavaScript. |
It is worth repeating that the implementation in this book does not rely on a framework or library that could change or go defunct. The game runs entirely on code covered in the book accessing W3C standard specifications like requestAnimationFrame(). As long as JavaScript interpreters don't change core things like timing control, this book should be relevant to developers for years to come.
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 first two chapters of the book focus on a set of basic guidelines to follow when doing game development in HTML5 and JavaScript — like keeping certain UI display elements in CSS instead of rendering them as paths or objects in the Canvas. Geary also covers the very absolute simplest concepts of how graphics are going to be displayed and how the background is going to move. He also spends time in Chapter Two showing how to best set up the development environment. It is demonstrated how shortening your cycle of deployment saves you tons of time and the author does a great job on letting you know what tools to use to debug throughout the whole text.
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 chapter tackles the core infrastructure of Snail Bait and discusses at length encapsulation of certain functionalities (instead of globals) in the source code as well as Snail Bait's 2300 line prototype. It bothers me that one file is 2300 lines and I wish there was a better way to do this but as a learning tool, it works even if it is daunting to scroll through. The book adds some helpful pointers about how utterly confusing the "this" keyword can be in JavaScript. Chapter Four really sets the pace for the rest of the book by introducing the use of event listeners and illustrating how the game loop is going to continually be extrapolated.
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.
Overall, Core HTML5 2D Game Programming is a great book for a JavaScript developer looking to dabble in game development. You can purchase Core HTML5 2D Game Programming from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page. If you'd like to see what books we have available from our review library please let us know.
Okay, Bye! (Score:5, Funny)
First, this book isn't for people who do not recognize HTML5 and JavaScript as a valid development platform for games. I know you're out there, you can stop reading here and move on to the next article.
Okay, bye!
Re: (Score:1)
A browser is significantly more capable than ms word even if it began with humble origins. To say that simply because a long time ago a program was not very powerful doesn't mean it isn't powerful at the moment.
You may wish to do more research as to how much more powerful a browser is than a text editor...otherwise people would think your a raving idjit :)
Examples:
http://madebyevan.com/webgl-water/ -fluid dynamics example
http://media.tojicode.com/q3bsp/ - quake in a browser example
http://cycleblob.com/
Re: (Score:1)
A browser is significantly more capable than ms word even if it began with humble origins.
I'm not sure about that, granted this is excel [eeggs.com], although Word has it share of fun and games [eeggs.com] too.
Re: (Score:2)
Right. Don't use a tool for anything more than its first version was ever was intended for. Maybe we should all have green screen terminals that only run Lynx and Pine, or even just having gopher (or no networking at all), displaying only static content, running on an ENIAC-like machine, loading from punched cards...
I'm sorry if some of us find use and value in these modern tools, no matter how humble their beginnings were. I don't develop HTML5 games, but the canvas tag and other similar technologies as th
Native app for a platform other than yours (Score:5, Informative)
An application is handled by my OS.
From a developer's point of view, how should a developer write an application that will run on 14 different operating systems, some with prohibitive initiation fees and annual fees? From a user's point of view, would you rather A. run a web app or B. not run an app at all because it was produced as a native app for a platform other than yours?
It's very difficult if not impossible to use multiple web apps side by side.
Slashdot users defending the window management policies of iPad and Android tablets tell me that most people run all maximized all the time even with native apps. If you prefer floating or tiled window management on a computer, you can always right-click a Firefox tab and choose "Move to New Window."
they slow each other down
Two native applications running on the same desktop computer slow each other down. It's called round-robin scheduling.
If one tab is busy loading a dynamic content menu, the other app is unusable.
Chrome has already fixed this by adopting a process-per-tab model, and Firefox has an ongoing "Electrolysis" effort to bring an option for a process-per-tab model. This lets the operating system use the same scheduler that it uses for native applications.
Re: (Score:3, Insightful)
D key for left
K key for right
J key for jump
Apparently people who program HTML5/JavaScript have some really fucked up keyboards.
Re: (Score:1)
Those are decent keys for someone who keeps their fingers on the Qwerty home row. Blame laptop manufactures for fucking up the arrow key positions and mobile keyboards for forgetting them.
Re: (Score:1)
Those are decent keys for someone who keeps their fingers on the Qwerty home row.
No, they aren't.
This is obvious to anyone that has ever played a computer game.
Re: (Score:1)
what about WASD? or ESDF? Whoever designed this ignored a whole shitload of intuitive precedent (same trend as these UX 'designers' for modern OS's nowadays).
Re: (Score:2)
what about WASD? or ESDF?
Movement with a single hand. Both are fine.
Whoever designed this ignored a whole shitload of intuitive precedent
Do you mean "intuitive" like D for left and K for right? If not, then what are you trying to say?
WASD dates back to at least the early 1980's (Wizardry for instance.) Not using WASD is what ignores "precedent."
Seriously.. 35+ years of WASD. You're ignorance involves missing more than a few decades.
Re: (Score:2)
Re: (Score:2)
/Oblg. The Birth and Death of Javascript
* https://www.destroyallsoftware... [destroyallsoftware.com]
Any language that requires a "use strict"; hack as the first line to turn on better error checking is fucking retarded.
Re: (Score:1)
The Binding of Isaac remains pretty much my favorite game right now.
Also in flash.
Re: (Score:2)
The Binding of Isaac: Rebirth is an order of magnitude better though in my opinion. Bigger, badder, and more polished.
No longer in flash.
Re:LOL. Just miles behind Flash (Score:4, Interesting)
http://hellorun.helloenjoy.com... [helloenjoy.com]
WebGL won't run on my computer, but native will (Score:2)
I tried the examples at threejs.org, and my error console said "Error: WebGL: Refused to create native OpenGL context because of blacklisting." I get a similar error message at get.webgl.org: "Hmm. While your browser seems to support WebGL, it is disabled or unavailable. If possible, please ensure that you are running the latest drivers for your video card." This is using the Intel GMA 3150 driver included with Ubuntu 14.04 LTS, which supports up to OpenGL 1.4, while WebGL is based on OpenGL 2. One thing th
Re: (Score:2)
You do realize that you're on a 10 year old GPU architecture, right?
Which means it was already more than 5 years old when I bought my laptop. But at the time, there wasn't better with a 10" screen.
even cheap smartphone SoCs can support OpenGL (ES) 3.0+ and DirectX 11.
DirectX? How many people have a smartphone that even runs DirectX?
Re: (Score:2)
> while WebGL is based on OpenGL ES 2.0
As in, you must declare a vertex + fragment shader, and roll your own matrix transformations.
Comment removed (Score:4, Insightful)
Re: (Score:2)
I thought flash was proprietary making it ideologically incompatible with the goal of universal data, js/html5 however is directly on target to ensure that if you load the game it loads no matter which platform you load from.
Actually that's something I'm not understanding with most of these comments, why are you all rooting for flash that cannot realistically be utilized by the majority of people vs a universal solution that works most times?
Granted there is a slowdown, however I haven't seen many games (mo
Re: (Score:2)
Re: (Score:3)
Even if the browsers suddenly decide to support another programming language the APIs are VERY unlikely to change, the bindings would probably be the same (or if it is a typed language it would have a ton of method overloading).
And anyway, Javascript is not THAT bad, the main problem is the DOM and guess what, when using canvases you don't interact with the DOM. In fact Coffeescript and Typescript make programming for the web as good as programming on the server with Ruby or Python, support for sourcemaps i
Re: (Score:2)
http://en.wikipedia.org/wiki/U... [wikipedia.org]
Is Canvas really HTML? (Score:1)
I know that Canvas somehow got poked into the standard, but really you are just writing to a bit mapped display and happen to use JavaScript as the language.
Re: (Score:2)
HTML5 eventually became the term used to mix recent javascript and html updates along with all the surrounding things like canvas, webgl and all the other new stuff.
Its not actually refering to the markup language only.
apt name (Score:2)
sounds like "Snail bait" to me.
Pay or wait, or shareware (Score:2)
Is it possible to make money off Flash games?
Is it possible to make money off mobile games? Or web sites? The "pay or wait" pattern that you see in F2P mobile games is not unlike the New York Times paywall, which allows only 10 free article views per month.
Is it possible to make money off native games? Many PC games from the 1990s were distributed as "shareware". The modern equivalent to that would be making the first episode available without charge and then selling the remainder of the game as one big IAP
Re: (Score:2)
I don't see anyone investing or hiring in canvas games.
There are still SWF game portals. I don't see how you couldn't be the first to launch an HTML5 game portal.
The author apparenlty never played a game himself. (Score:2)
Zero credibility.