Thanks to Antti Kupila, I have been given a copy of Emanuele Feronato's book Flash Game Development by Example to read and critique. Emanuele has been blogging about Flash gaming for years, and since I am looking to get into gaming, I was eager to read the book.
So far I have made it only through the first three chapters. I did a preliminary critique of the book on the Amazon product page:
Emanuele Feronato has been blogging ([...]) good tips on Flash gaming and PHP development for a while now. When I learned he had written a book on how to get into game development, I had to try it.
In line with his blog, Feronato's writing is clear and concise, no fluff is added. A good thing is that he assumes the reader has already some knowledge of Flash and AS3. This book does present some basic information if you know nothing of Flash, but the intent of this book is to teach you how to do games, not how to program. This is really a good thing, for there are way too many books that think that all readers have never touched programming of their life.
Feronato does a good job at increasing the difficulty of concepts during each chapter. His introduction to each challenge, by splitting the concept and the coding, guides the reader properly.
As a web developer, jumping into gaming is a good and honest challenge. Oftentimes a web dev tends to create complex systems for data and views. Feronato brings back the joy of programming with simple and logic code structures.
I did get put off by the fact that his instructions make use of the Flash IDE, rather than Flash Builder, FDT or FlashDevelop. In a professional environment, it's quite inefficient to code in the Flash IDE, but I believe it would have taken too many explanations to put in a book about games. All in all, it is quite easy to transpose the instructions into code-only IDEs.
I would also have like some more game-oriented optimization tips (like using multiplications rather than divisions, since it is quicker), for gaming is all about being code-efficient. That said, it is a good buy for those who are serious about getting into Flash gaming.
Critiquing the critique
My grandad used to say: "Only a fool does not change his mind." Whereas I do not think as harshly about the book, I do want to delve deeper into my critique to either correct what I said, or even add to it.
Lobb mentions the coding style of Feronato, which I also noted looks a lot like PHP's style:
We all write weird looking code sometimes, but I think a book needs to set a better example.
I must say that it did not deter me really too much, since I am used to pick up other people's work and fix it. However, now that I think of it, a book must set an example of good coding practices. I have to agree with Lobb on his critique.
Another practice that really should have been present in Feronato's code is tips that make code execute faster.
var array:Array =  may look dirty, but it is way quicker than creating arrays with the
new Array() declaration. His examples do not use many arrays, but I do not see why good habits should not be put forward.
Another tip is to try and use multiplications rather than divisions. Again, the examples do not use calculations that are processor intensive, but it is the best moment to explain to new game developers tips that will help them when they have to handle complex systems in the future.
But those tips are something that I knew already and that could have been used in the first three chapters of the book. Let's see when I get further in the book how it goes.
Both Lobb and Larsen look onto Feronato's code as merely scripts, for it doesn't push OOP concepts. As Feronato's book is really built on iterating his code and moving it forward, as many oftentimes code in real life, it would have been nice for him to explain how to transform hid code into classes etc. The speed at which Feronato moves through concepts means the reader is expected to know how to code. And if so, the reader could also then be expected to know some OOP. Feronato could have used such a premise to then push the use of classes. Unknowingly, I worked exactly how Larsen describes what he sees in his book:
[...] if you know how to code AS3 with OOP and good coding practises, plus being able to extract general ways of doing something from very specific examples [...]
As I mentioned in my Amazon critique, I would have preferred it if the author would have not used the Flash IDE to code, since it's pretty backwards. As I was going through his examples, I actually used FDT to create a proper project structure, with assets, packages and different classes for specific tasks.
I did enjoy Feronato's scripting style to read, but I do now think the book he wrote should have promoted practices that would be useful in professional environments.
Lobb critiques Feronato's choices of games for being out of touch with current trends. He makes an interesting point:
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.
I think that using a lot of pixel sprites in my prototypes casts me in that group. However I must disagree with Lobb here. I am not fan of Flip and Match games, Tetris or other classic puzzlers per se. As good a developer I am, I have never tackled a real game project. Starting from scratch with basic concepts and logics actually helps me learn things properly.
For example, in Minesweeper, the logic of how to use and create a flood fill function is explained. Since I come from a web development, where the UI is usually the most important concern, I would not know what to call such a concept. It is a definite win for me here.
Another example is the Connect Four winning explanations. Feronato explains how a win is made in concepts and how to translate that in code. I know pseudo code is not something new in development, but learning to do it for gaming is, to me and maybe to other non-gaming developers, something refreshing and useful.
Let's take a look at what I was able to create with what I have read so far.
Concentration, a flip and match game
This game is pretty straightforward, we pretty much all know it. Feronato explains in simple terms how to build such a game.
What is missing however is an explanation for the reader on how to reset the game so the player can enjoy more than one game. Actually, the author does not explain how to restart any of the games he describes. That is a big part in gaming, it should be present in his book I believe. It would also have been a great way to show how to use functions. So as you can see from my prototype above, I have added that logic. Once the game is complete, the user can retry to play.
Stats on how the game progresses is also interesting for the player to see. Lobb actually mentions this in his critique, although I had though of adding these stats previous to reading the article.
As a personal touch, I decided to make my game shareable on Facebook's wall so that my friends could try that little prototype in their news stream. I will eventually explain how easy that is, but it is not the point of this blog post. You may try it yourself in sharing the URL http://jansensan.net/experiments/game-dev-concentration/ onto your news stream. Do not just copy the URL into your browser, it redirects to this post.
Once you share the above URL onto your news stream, it will then show like this:
If you ever used YouTube or Vimeo on your news stream, you know the Flash piece will expand when they click on the blue play button.
With those simple additions, people were enjoying a simple prototype and sharing it around.
To be honest, I never understood the Minesweeper game, or rather what is compelling to play it. Or maybe I just hate it because that is the only game that was available on my dad's work computer at the government when I was visiting and he was asking me to wait for him... Anyways, I digress...
Feronato only explains what makes the player lose the game, however he should also have explained what is the win situation. An author cannot take for granted that the reader knows the game that is described.
With this game, Feronato explains some recursion and the concept of the flood fill, which I believe is well worth to learn.
Concerning the use of functions however, the explanations lack. Functions are made to reuse code and, again, restarting a game is the perfect need to reuse code. As you can see from the prototype, you can only play once, which as I mentioned before is not a way to build a complete game.
Maybe I have not read enough tech books, but whenever I stumble upon an example online that uses events, the tutorial not always explains that it is best to remove the event handlers, sometimes even in Adobe's documentation! Many a time did I have to explain or correct other people's code to reduce the demand on memory. Feronato does explain to remove the event handler, I have to give him props for this.
This game is not digital by any means, and recreating it does not make it more fun. However, the logic learning with this game is quite nice. Games like Drop 7 seems to be a game that extrapolates on the concepts defined in Connect Four.
The structure of the code in this game made me cringe. I believe that under no circumstance should a child tell its parent what to do. Sounds logical no? I mean not only about code, just read the previous sentence aloud and you will feel how much sense it makes.
Feronato actually does that here, he write something like
this.parent.parent. It is not technically wrong, since it compiles, but I believe that conceptually it is not right. It makes it so complex for someone else to inherit a project and try to figure out such a logic. Big no-no.
While explaining how to check for the game completion, the author does bring forward the idea that is it not efficient to loop through all possible tiles. Good suggestion on code efficiency here.
So, what now?
I do see that this book has some flaws, but nothing that could not have been corrected or pushed more. I think also however that both Larsen and Lobb have dismissed a couple of things in their critique.
a) The audience. Larsen makes a good point that the code is quick and dirty and that the prototypes are not teaching concepts, but that is exactly what the introduction says:
Who this book is for
- AS3 developers who want to know quick and dirty techniques to create Flash games
- Flash animators who want to learn how to create games from their works with AS3
- Programmers who know languages different than AS3 and want to learn AS3 to make something more interesting and fun than the old "phone book"
- Even if you aren't a programmer, but you love Flash games, you can count on this book: you will be guided step by step with clear examples and the support of the full source code of every game
Now, is that audience right? That's another question, but it is clearly stated.
b) The types of game. Lobb did hit on that and I do what to bring it back. The title of the book clearly states that is for building classic games, mostly puzzlers.
Build 9 classic Flash games and learn game development along the way
Again, the question to raise is, is that a good thing to teach devs? With Stage3d (a.k.a. Molehill), P2P, game controllers on AIR and all sorts of awesome features, Flash can be so much more as a gaming platform.
All in all, I will go on reading the book, for I know I will learn some more things. I agree however that this book does not feel complete, but it feels like a good primer to get into game development. Hey, I may also be wrong, but once a reader knows about some concepts like AI, recursion, etc., it then becomes more possible to search for more precise concepts.