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.

Comments

Karl said…
Thanks for the honest review. I too have trouble with the coding style of Emanuele.
Antipirina said…
It may be similar as when you like a sitcom, and then you go to watch the movie. You expect a lot more and at the end it's like a long chapter of the serie.
zedia.net said…
I agree about his tutorials being very basic and the code not being that good. That's mostly the reason why I have no intention of buying his book.
Orion said…
Great review.

Your point about game books focussing too much on certain games and not about solving particular gaming solutions is excellent. That's why I think Keith Peters' Making Things Move is the best game programming book, even though it doesn't really teach any complete game specifically.

I also appreciate your appeal for naming convention standards. I teach ActionScript and tend to be a stickler for naming. My only issue with your conventions is the use of underscores. I still tend to use the old underscore suffixes such as _mc _txt etc. for instance names...

They don't give the automatice code hints they used to in the Flash IDE anymore, but I still find them useful to differentiate the type and/or purpose of objects. So you could have a few objects working together for one solution with similar naming.

For example: myInfo_xml, myInfo_str, myInfo_txt, myInfo_mc....

Do you think this is still acceptable? If not, how would you do it?
Iain said…
I personally don't think this is a good idea - for one thing, it doesn't match the coding conventions of ActionScript3 language itself or the Flex style guide (definitely worth a read). But also, it's just unnecessary as modern code editors like FlashDevelop, Flash CS5, FlashBuilder etc already know about the type from what comes after the colon.

For your examples, I would try to describe more about the function of the variables rather than the types. So:

"myInfo_xml" could be changed to "info" or "infoData" or even just "infoXML"

"myInfo_str" could be changed to "info" or "infoMessage" or something like "productInformation" if you know that much detail

I always name my textFields as "somethingField", so "myInfo_txt" would become "infoField"

For "myInfo_mc", you would want to think more about the function of the movieclip - is it a container? A panel? An animation? So I would chnage it to something like "infoPanel", "infoContainer", "informationPanel" or "infoAnimation" etc
Orion said…
Thanks for the thorough response Iain. I will try to phase out my old underscore suffix habit.

Do you think this was established by Macromedia way back primarily for the code hints? It's usage in code samples and books was quite extensive years/versions ago.

And are you recommending getting rid of it mostly because it is a weird AS thing and isn't used in other languages?

I don't think I've seen it used in other languages, but would be curious to know if it did exist elsewhere.
Anonymous said…
I agree with a you, book like this needs much more higher level + more examples. When I compare it with others books like legendary Mastering Delphi, I feel that this book is ony one small chapter in whole book. Sorry..