jQuery Game Development Essentials: Learn how to make fun and addictive multi-platform games using jQuery with this book and ebook.

Making games has this amazing advantage that you immediately see the result of the code you just wrote move before your eyes. This is the reason why everything you learn in this book will directly be applied to some practical examples. In this chapter, we will write a small game together inspired by the classic Frogger. In the following chapters, we will then make a platformer and a role playing game (RPG).

I really encourage you to write your own version of the games presented here and modify the code provided to see the effects it has. There is no better way of learning than to get your hands dirty!

The game we will implement now is inspired by Frogger. In this old school arcade game, you played the role of a frog trying to cross the screen by jumping on logs and avoiding cars.

In our version, the player is a developer who has to cross the network cable by jumping packets and then cross the browser "road" by avoiding bugs. To sum up, the game specifications are as follows:

Throughout this book, we will use DOM elements to render game elements. Another popular solution would be to use the Canvas element. There are plus and minus points for both technologies and there are a few effects that are simply not possible to produce with only DOM elements.

However, for the beginner, the DOM offers the advantage of being easier to debug, to work on almost all existing browsers (yes, even on Internet Explorer 6), and in most cases to offer reasonable speed for games. The DOM also abstracts the dirty business of having to target individual pixels and tracking which part of the screen has to be redrawn.

Even though Internet Explorer supports most of the features we will see in this book, I would not recommend creating a game that supports it. Indeed, its market share is negligible nowadays (http://www.ie6countdown.com/) and you will encounter some performance issues.

Now from some game terminology, sprites are the moving part of a game. They may be animated...

The framework part of the game is done. Now we want to implement the graphics and game logic. We can divide the game's code into two parts, one that will be executed only once at the beginning, and one that will be called periodically. We will call the first one the initialization.

This part should be executed as soon as the images are done loading; this is the reason why we will pass it as the end callback for the startPreloading function. This means that at the very beginning we need to add all the images that we will use to the preload list. Then once the user launches the game (for example, by clicking an image with the ID startButton) we will call the preloader.

The following code uses the standard jQuery way to execute a function once the page is ready. I won't give you the complete code here because some of it is quite repetitive, but I will give at least one example of each of the actions performed here and you can always look at the complete source code if you...

The main loop will typically contain a finite state machine (FSM). An FSM is defined by a series of states and the list of transitions from one state to another. The FSM for a simple game where the player would have to click three boxes that appear one after the other would look like the following diagram:

When you implement an FSM, you really need to consider two things: how the game should behave in each state, and what conditions make the game transition to a new state. The advantage of FSMs is that they provide a formal way to organize your game logic. It will make it easier to read your code and you can add/or change your logic at a later time if you need it. I would recommend you to first draw the FSM for your game and keep it somewhere to help you debug your game.

For our Frogger game there are 10 states. The initial state is START and the two final states are GAMEOVER and WON. Here is a description of what happens exactly in each state:

We will use some sort of collision detection, but a very simple version that is designed only for this situation. In the later chapters, we will see more general solutions, but this isn't necessary here.

There are six spots where collision detection matters in this game; the three lines of packets in the first part, and the three lines of bugs in the second part. Both represent the exact same situation. There is a succession of elements separated by some empty space. The distance between each element is constant along with its size. We don't need to know on which packet the player has jumped or which bugs hit the player, what matters is only if the player stands on a packet or if he/she was hit by a bug.

For this reason we will use the modulo technique we used before to reduce the problem complexity. What we will consider is the following situation:

To know if the player touches the element or not we just need to compare its x co-ordinate with the element position.

The following...

We now have a game that completely implements the specification that we defined at the beginning of the chapter. The code is not yet optimized and that will be the subject of our next chapter, but to make a game that is nice to play it would really need more polish. You could add a high-score system, integration with social networks, and sound and touch device compatibility.

We will cover those topics and more in the future chapters. However, there are a lot of things you can do with what you have already learned now to make the game better: you may want to add an animation for when the player dies, a nicer GUI, nicer graphics, the ability to jump back, and more than one level. It's these small things that will make your game stand out and you should really invest a big part of your time to give this professional finish to your game!