Flash Game Development by Example – Book Review

Tech publishers Packt have sent me a copy of Flash Game Development by Example by Emanuele Feronato, to review. Packt seem like a really awesome publisher – I love the short, punchy format of their books and their twitter account @PacktExplorer is single-handedly bringing the tech publishing industry into the social media age (honestly, they’re definitely worth following). I’m currently also working my way through their book Away 3.6 Essentials by Matthew Casperson, which is excellent and will be getting a full review on this blog shortly. For reasons that will become apparent however, I was able to get this review of Emanuele’s book out a bit more quickly...

Unfortunately, this isn’t really a book that I can recommend. Emanuele Feronato is a legend in the Flash blogging scene, tirelessly giving away tutorial after tutorial, covering everything from Box2D to Flashpunk. These tutorials are great for beginners who don’t know where to start with a new technique or library, or are new to Flash. I think Emanuele does a great service to the Flash community and I hope he doesn't take this review too badly if he reads it. As Emanuele gets a lot of content out very quickly, the quality and style of this code can be quite quick-and-dirty. There’s not a lot of object-oriented code or best practices in evidence. Now this is fine for a free tutorial (what do you expect for free?!), but once you stick a £28 price tag on something, I think it must be held to a higher standard.

While it gets the job done, the code in this book is quite messy and throw-away. I really feel the technical reviewers dropped the ball here. I was a tech reviewer on a book myself last year, and I really came down hard on the authors coding style, getting them to rewrite many of their variable names to be more descriptive and enforce some standard Flash coding conventions. We all write weird looking code sometimes, but I think a book needs to set a better example. Here are some basic style conventions the book should have used, but doesn't:

• Variable and function names are made up of full words (or, very rarely, accepted common abbreviations such as “config” and “init”).

• Variable names are written in “camel case”, starting with a lowercase letter but with the first letter of each new word being capitalised. An example might be a function called findClosestEnemy().

• Classes start with an upper case letter and each word should have its first letter capitalised, e.g. you might have a class called FastEnemyShip. I believe this convention should also be applied to the class names you give Flash symbols when linking them in the library.

• The only place you should use an underscore is at the start of private variable name that is returned by a public getter function. Never in the middle of a variable name.

• Operators such as = and > should have a space either side, so:
  if (x > 50) isDead = true;
  NOT:
  if(x>50)isDead=true;
  This will still compile but it’s a lot harder to read.

Obviously these are only conventions and you can code however you like, but I think that if you are teaching or writing a book you should pay attention to these things. While coding style is only superficial, my next criticism is more fundamental – many the games this book teaches you to make are not the ones you should be learning to make.

So what have we got?

• The match-the-pairs memory card game “concentration” - this was old-hat when I started in Flash games 10 years ago – at this point it’s prehistoric.
  
• Minesweeper is making a resurgence with indie titles like Desktop Dungeons so that’s a decent addition.
• Connect Four is really only fun as a multiplayer game, so that’s not very useful .
• Snake is a very old-school and basic game – too basic to be successful in today’s increasingly sophisticated Flash games scene.
• Tetris is so much of a classic that there are already too many clones out there.
• “Astro-PANIC” is a Space Invaders-like shoot ‘em which is worth knowing how to make.
• Bejewelled and Puzzle Bobble are both classics with potential to go in new directions, so they’re ok to see.
• And BallBalance is a design so unique that it doesn’t really offer any techniques that are worth pursuing in your own games.

In summary then, 4 games out of the 9 are worth learning about. If you need to make one of these games, and you can’t already find a tutorial online, then this book might be worth it, otherwise I’d avoid it.

On a more general note, I really think that a lot of game developers around my age group (e.g. 25 and older) are stuck in the past somewhat with their ideas of what constitutes a computer game. The new generation of players grew up with Pokemon and Xbox Live, and have never played a game that doesn’t save their progress as they go and feature achievements, upgrades, collectables, item shops and other RPG elements. I think that any future Flash gamedev books that come out need to understand this fact and capitalize on it with a focus on implementing modern game design ideas. Also, I notice that most books teaching Flash game programming seem to be broken up into individual games, whereas I think a more logical approach is to break the book up by topic, so each chapter covers a different game programming problem, such as collision detection, saving a game, physics etc. Then when you are stuck on a particular problem, you know where to turn.