Its really a shame that most beginning game programming books use C++ or some obsure languages like unheard of flavors of BASIC and ignore the prevelence and ease of use of modern scripting languages. This book is not for beginning programmers, it just introduces these 3 scripting languages and then throws some game code in the back of the chapter for each.

Its really a shame that most beginning game programming books use C++ or some obsure languages like unheard of flavors of BASIC and ignore the prevelence and ease of use of modern scripting languages. This book is not for beginning programmers, it just introduces these 3 scripting languages and then throws some game code in the back of the chapter for each.

First let me preface this by saying that i'm only on page 31 and ALREADY am I compelled to write a review about how bad this book is. however, if I get further into the book to find that by some miracle it actually improves, I will revise this review as appropriate. However, the first 31 pages alone are so bad i had to say something before other people blow their cash on this.



Where to begin? I suppose my biggest problems with the book are:



1) It's like no one edited the book AT ALL:

By only page 31, already i've had to re-read more than a few sentences because of the blatant grammar errors that I simply don't expect when reading a professionally published book, such as



"A strings is basically..." (p31)

"In the1960's software development..." (p13).

"They can be composed numbers, letters..." (p30)



There are numerous others but I can't remember them off hand.



Also, in Chapter 1 as the three languages are introduced, the author produces a diagram for each language's "family tree". Two out of three of these are completely wrong. Figure 1.5 is labeled as "The Python language family tree", yet the diagram itself doesn't contain Python anywhere-- rather, the root of the tree is Lua. Figure 1.6 is labeled "The Lua language family tree", but again, Lua is nowhere to be found; rather, the root of the tree is Ruby.



How can so many errors exist already, less than one TENTH of the way through the book?



2) Numerous technical errors and misconceptions:

With all due respect, I seriously question the author's grasp of even basic subjects so far.



For instance, on page 25, we're told that the # symbol is used for one-line comments in numerous languages, including *C*. As anyone with even a semester of junior college CS classes knows, the # symbol denotes a proprocessor directive in C, not a single-line comment. This would be nitpicking anywhere else, but in the context of a professionally published book, especially one that's already on such shakey ground, this is unnerving.



On page 18, one of Lua's features is described as the ability to be compiled into byte-code, "simulating a virtual machine". "Simulating" a "virtual" machine? In other words, Simulating a simulated machine. You don't simulate VM's-- the whole concept of a VM is a simulation in the first place. It'd be like "simulating" virtual reality. Again, it wouldn't normally be a big deal, but I can't help but wonder how much the author really "gets" this stuff. This becomes less of a joke when you consider genuine newbies reading this stuff, setting them up for real long-term confusion.



There are other examples but those are two I remember off the top of my head.



3) A book clearly aimed at no one:

This book, as I understood it at least, is aimed at game programmers who want to learn how to use scripting languages to either script their games, or implement their games while using native languages like C++ to handle performance-critical elements such as graphics.



Unfortunately, it also seems to be aimed (in certain parts) at newbies and flat-out non-programmers. On the one hand, the author has gone out of his way to explain what CPU is (!), what commenting is (!), and how parentheses are used to denote order of operations in math expressions (!). Not more than a few pages later, however, we get this sentence (typo taken from actual text):



"[Lists] can be composed numbers, letters, or even constructs such as arrays, hashes or even other lists." (p30)



Exactly what type of reader needs to be told what CPU stands for, what a comment is, and what parentheses mean, but has no problem following along when you mention "constructs" such as arrays and hashes?



My point is that the author is continually wasting time with useless explanations of things that would only serve a *brand new* programmer who knows virtually *nothing* about computers or programming in general. Needless to say, that person simply won't learn anything from a book like this, which would clearly only be useful to an intermediate programmer or better (so far at least). So those of us actually trying to learn something have to sit through these absurd sidebars and tangents instead of focusing on what we came for. Of course, if you actually were a total newbie, you wouldn't be able to understand 90% of the content *aside* from these useless sidebars and tangents.



4) Strange organization:

I'm only about 7 pages into Chapter 2, and I'm already about to give up on this book. This chapter is an absolute train wreck and is the total opposite of the approach that would have worked. Believe it or not, the author is attempting to introduce all three languages, Lua, Python and Ruby, *simulatneously*. In some ways this sounds like a decent idea, since it seems like it would allow the reader to directly compare the languages feature-for-feature. Unfortunately, keep in mind that this book is designed to *teach* these languages, not just compare them. Imagine having to learn three separate topics at one time simply because later on, you'll have to chose one of them to go with. I've never read anything so disjointed in my life. Fortunately, I already know a thing or two about two of these languages, so I can keep my head above water, but it's obvious that if I didn't understand any of them I would be totally lost.



This book is begging to be rewritten in a straightforward divide-and-conquer approach. Teach me things in separate, discrete, understandable chunks, and THEN tie them all together and make the necessary comparisons. Throwing them all into a single chapter TOGETHER makes things endlessly confusing for no reason whatsoever.



5) A weird, sketchy writing style overall:

Lastly, and I admit I don't know quite how to categorize this, the author writes in a style that is just bizarre. Overall, it often sounds like I'm reading a conversation between one beginner-level programmer trying to explain programming concepts to another beginner. Ugh:



- "Variables are holders for data any computer or program might need to use or manipulate."



I know what he's trying to say, but this is a REMARKABLY obtuse way of saying it. "Any computer or program"? "Use or manipulate"? Yeesh.



- "Variables are usually given names so that a program can assign values to them and refer to them later symbolically."



"Usually" given names? That's like saying numbers "usually" have values. And the program doesn't "assign values" to those names-- the programmer does. Variables exist *solely* for benefit of a human programmer, not an executing program. Variables and their names (generally) do not persist beyond the compilation stage, and even when they do (as in the case of late binding or debugging), they still exist for the use of the human programmer only, not the "program". Explaining this concept in such a hazy and clearly incorrect manner is poison for a beginner's understanding.



- "Another commonality between Python, Lua and Ruby is using parentheses() to state precedence;"



This may be true, but why phrase it this way? It implies that the parentheses is a specific feature to these three languages. In reality, the only mainstream alternative to parentheses is RPN, which is used virtually nowhere in modern programming languages. Parentheses are a de facto standard among all high-level languages if ever there was one, not a "commonality" between these three languages. He might as well say the same thing about variables, conditional logic, iteration, and what have you.



To sum up, this is a book that doesn't have a clearly defined target audience (by a long shot), is written in a savagely unprofessional and often baffling style, and is riddled with subtle and not-so-subtle mistakes and innappropriate tangents.



The only reason I've written a review so early into the book (page 31!) is that I'm already thinking about returning it, and want to make sure others have some idea of what they're getting into before they buy it. At best, if you're still curious, give this thing a good 30 minutes at least in your local bookstore, and keep an eye out for the things I mentioned.



The Premier Press GameDev series actually does have a lot of good, underrated titles, and gets a bad rap more often than it deserves, but books like this definitely aren't doing it any favors.

First let me preface this by saying that i'm only on page 31 and ALREADY am I compelled to write a review about how bad this book is. however, if I get further into the book to find that by some miracle it actually improves, I will revise this review as appropriate. However, the first 31 pages alone are so bad i had to say something before other people blow their cash on this.

Where to begin? I suppose my biggest problems with the book are:

1) It's like no one edited the book AT ALL:
By only page 31, already i've had to re-read more than a few sentences because of the blatant grammar errors that I simply don't expect when reading a professionally published book, such as

"A strings is basically..." (p31)
"In the1960's software development..." (p13).
"They can be composed numbers, letters..." (p30)

There are numerous others but I can't remember them off hand.

Also, in Chapter 1 as the three languages are introduced, the author produces a diagram for each language's "family tree". Two out of three of these are completely wrong. Figure 1.5 is labeled as "The Python language family tree", yet the diagram itself doesn't contain Python anywhere-- rather, the root of the tree is Lua. Figure 1.6 is labeled "The Lua language family tree", but again, Lua is nowhere to be found; rather, the root of the tree is Ruby.

How can so many errors exist already, less than one TENTH of the way through the book?

2) Numerous technical errors and misconceptions:
With all due respect, I seriously question the author's grasp of even basic subjects so far.

For instance, on page 25, we're told that the # symbol is used for one-line comments in numerous languages, including *C*. As anyone with even a semester of junior college CS classes knows, the # symbol denotes a proprocessor directive in C, not a single-line comment. This would be nitpicking anywhere else, but in the context of a professionally published book, especially one that's already on such shakey ground, this is unnerving.

On page 18, one of Lua's features is described as the ability to be compiled into byte-code, "simulating a virtual machine". "Simulating" a "virtual" machine? In other words, Simulating a simulated machine. You don't simulate VM's-- the whole concept of a VM is a simulation in the first place. It'd be like "simulating" virtual reality. Again, it wouldn't normally be a big deal, but I can't help but wonder how much the author really "gets" this stuff. This becomes less of a joke when you consider genuine newbies reading this stuff, setting them up for real long-term confusion.

There are other examples but those are two I remember off the top of my head.

3) A book clearly aimed at no one:
This book, as I understood it at least, is aimed at game programmers who want to learn how to use scripting languages to either script their games, or implement their games while using native languages like C++ to handle performance-critical elements such as graphics.

Unfortunately, it also seems to be aimed (in certain parts) at newbies and flat-out non-programmers. On the one hand, the author has gone out of his way to explain what CPU is (!), what commenting is (!), and how parentheses are used to denote order of operations in math expressions (!). Not more than a few pages later, however, we get this sentence (typo taken from actual text):

"[Lists] can be composed numbers, letters, or even constructs such as arrays, hashes or even other lists." (p30)

Exactly what type of reader needs to be told what CPU stands for, what a comment is, and what parentheses mean, but has no problem following along when you mention "constructs" such as arrays and hashes?

My point is that the author is continually wasting time with useless explanations of things that would only serve a *brand new* programmer who knows virtually *nothing* about computers or programming in general. Needless to say, that person simply won't learn anything from a book like this, which would clearly only be useful to an intermediate programmer or better (so far at least). So those of us actually trying to learn something have to sit through these absurd sidebars and tangents instead of focusing on what we came for. Of course, if you actually were a total newbie, you wouldn't be able to understand 90% of the content *aside* from these useless sidebars and tangents.

4) Strange organization:
I'm only about 7 pages into Chapter 2, and I'm already about to give up on this book. This chapter is an absolute train wreck and is the total opposite of the approach that would have worked. Believe it or not, the author is attempting to introduce all three languages, Lua, Python and Ruby, *simulatneously*. In some ways this sounds like a decent idea, since it seems like it would allow the reader to directly compare the languages feature-for-feature. Unfortunately, keep in mind that this book is designed to *teach* these languages, not just compare them. Imagine having to learn three separate topics at one time simply because later on, you'll have to chose one of them to go with. I've never read anything so disjointed in my life. Fortunately, I already know a thing or two about two of these languages, so I can keep my head above water, but it's obvious that if I didn't understand any of them I would be totally lost.

This book is begging to be rewritten in a straightforward divide-and-conquer approach. Teach me things in separate, discrete, understandable chunks, and THEN tie them all together and make the necessary comparisons. Throwing them all into a single chapter TOGETHER makes things endlessly confusing for no reason whatsoever.

5) A weird, sketchy writing style overall:
Lastly, and I admit I don't know quite how to categorize this, the author writes in a style that is just bizarre. Overall, it often sounds like I'm reading a conversation between one beginner-level programmer trying to explain programming concepts to another beginner. Ugh:

- "Variables are holders for data any computer or program might need to use or manipulate."

I know what he's trying to say, but this is a REMARKABLY obtuse way of saying it. "Any computer or program"? "Use or manipulate"? Yeesh.

- "Variables are usually given names so that a program can assign values to them and refer to them later symbolically."

"Usually" given names? That's like saying numbers "usually" have values. And the program doesn't "assign values" to those names-- the programmer does. Variables exist *solely* for benefit of a human programmer, not an executing program. Variables and their names (generally) do not persist beyond the compilation stage, and even when they do (as in the case of late binding or debugging), they still exist for the use of the human programmer only, not the "program". Explaining this concept in such a hazy and clearly incorrect manner is poison for a beginner's understanding.

- "Another commonality between Python, Lua and Ruby is using parentheses() to state precedence;"

This may be true, but why phrase it this way? It implies that the parentheses is a specific feature to these three languages. In reality, the only mainstream alternative to parentheses is RPN, which is used virtually nowhere in modern programming languages. Parentheses are a de facto standard among all high-level languages if ever there was one, not a "commonality" between these three languages. He might as well say the same thing about variables, conditional logic, iteration, and what have you.

To sum up, this is a book that doesn't have a clearly defined target audience (by a long shot), is written in a savagely unprofessional and often baffling style, and is riddled with subtle and not-so-subtle mistakes and innappropriate tangents.

The only reason I've written a review so early into the book (page 31!) is that I'm already thinking about returning it, and want to make sure others have some idea of what they're getting into before they buy it. At best, if you're still curious, give this thing a good 30 minutes at least in your local bookstore, and keep an eye out for the things I mentioned.

The Premier Press GameDev series actually does have a lot of good, underrated titles, and gets a bad rap more often than it deserves, but books like this definitely aren't doing it any favors.

First let me preface this by saying that i'm only on page 31 and ALREADY am I compelled to write a review about how bad this book is. however, if I get further into the book to find that by some miracle it actually improves, I will revise this review as appropriate. However, the first 31 pages alone are so bad i had to say something before other people blow their cash on this.

Where to begin? I suppose my biggest problems with the book are:

1) It's like no one edited the book AT ALL:
By only page 31, already i've had to re-read more than a few sentences because of the blatant grammar errors that I simply don't expect when reading a professionally published book, such as

"A strings is basically..." (p31)
"In the1960's software development..." (p13).
"They can be composed numbers, letters..." (p30)

There are numerous others but I can't remember them off hand.

Also, in Chapter 1 as the three languages are introduced, the author produces a diagram for each language's "family tree". Two out of three of these are completely wrong. Figure 1.5 is labeled as "The Python language family tree", yet the diagram itself doesn't contain Python anywhere-- rather, the root of the tree is Lua. Figure 1.6 is labeled "The Lua language family tree", but again, Lua is nowhere to be found; rather, the root of the tree is Ruby.

How can so many errors exist already, less than one TENTH of the way through the book?

2) Numerous technical errors and misconceptions:
With all due respect, I seriously question the author's grasp of even basic subjects so far.

For instance, on page 25, we're told that the # symbol is used for one-line comments in numerous languages, including *C*. As anyone with even a semester of junior college CS classes knows, the # symbol denotes a proprocessor directive in C, not a single-line comment. This would be nitpicking anywhere else, but in the context of a professionally published book, especially one that's already on such shakey ground, this is unnerving.

On page 18, one of Lua's features is described as the ability to be compiled into byte-code, "simulating a virtual machine". "Simulating" a "virtual" machine? In other words, Simulating a simulated machine. You don't simulate VM's-- the whole concept of a VM is a simulation in the first place. It'd be like "simulating" virtual reality. Again, it wouldn't normally be a big deal, but I can't help but wonder how much the author really "gets" this stuff. This becomes less of a joke when you consider genuine newbies reading this stuff, setting them up for real long-term confusion.

There are other examples but those are two I remember off the top of my head.

3) A book clearly aimed at no one:
This book, as I understood it at least, is aimed at game programmers who want to learn how to use scripting languages to either script their games, or implement their games while using native languages like C++ to handle performance-critical elements such as graphics.

Unfortunately, it also seems to be aimed (in certain parts) at newbies and flat-out non-programmers. On the one hand, the author has gone out of his way to explain what CPU is (!), what commenting is (!), and how parentheses are used to denote order of operations in math expressions (!). Not more than a few pages later, however, we get this sentence (typo taken from actual text):

"[Lists] can be composed numbers, letters, or even constructs such as arrays, hashes or even other lists." (p30)

Exactly what type of reader needs to be told what CPU stands for, what a comment is, and what parentheses mean, but has no problem following along when you mention "constructs" such as arrays and hashes?

My point is that the author is continually wasting time with useless explanations of things that would only serve a *brand new* programmer who knows virtually *nothing* about computers or programming in general. Needless to say, that person simply won't learn anything from a book like this, which would clearly only be useful to an intermediate programmer or better (so far at least). So those of us actually trying to learn something have to sit through these absurd sidebars and tangents instead of focusing on what we came for. Of course, if you actually were a total newbie, you wouldn't be able to understand 90% of the content *aside* from these useless sidebars and tangents.

4) Strange organization:
I'm only about 7 pages into Chapter 2, and I'm already about to give up on this book. This chapter is an absolute train wreck and is the total opposite of the approach that would have worked. Believe it or not, the author is attempting to introduce all three languages, Lua, Python and Ruby, *simulatneously*. In some ways this sounds like a decent idea, since it seems like it would allow the reader to directly compare the languages feature-for-feature. Unfortunately, keep in mind that this book is designed to *teach* these languages, not just compare them. Imagine having to learn three separate topics at one time simply because later on, you'll have to chose one of them to go with. I've never read anything so disjointed in my life. Fortunately, I already know a thing or two about two of these languages, so I can keep my head above water, but it's obvious that if I didn't understand any of them I would be totally lost.

This book is begging to be rewritten in a straightforward divide-and-conquer approach. Teach me things in separate, discrete, understandable chunks, and THEN tie them all together and make the necessary comparisons. Throwing them all into a single chapter TOGETHER makes things endlessly confusing for no reason whatsoever.

5) A weird, sketchy writing style overall:
Lastly, and I admit I don't know quite how to categorize this, the author writes in a style that is just bizarre. Overall, it often sounds like I'm reading a conversation between one beginner-level programmer trying to explain programming concepts to another beginner. Ugh:

- "Variables are holders for data any computer or program might need to use or manipulate."

I know what he's trying to say, but this is a REMARKABLY obtuse way of saying it. "Any computer or program"? "Use or manipulate"? Yeesh.

- "Variables are usually given names so that a program can assign values to them and refer to them later symbolically."

"Usually" given names? That's like saying numbers "usually" have values. And the program doesn't "assign values" to those names-- the programmer does. Variables exist *solely* for benefit of a human programmer, not an executing program. Variables and their names (generally) do not persist beyond the compilation stage, and even when they do (as in the case of late binding or debugging), they still exist for the use of the human programmer only, not the "program". Explaining this concept in such a hazy and clearly incorrect manner is poison for a beginner's understanding.

- "Another commonality between Python, Lua and Ruby is using parentheses() to state precedence;"

This may be true, but why phrase it this way? It implies that the parentheses is a specific feature to these three languages. In reality, the only mainstream alternative to parentheses is RPN, which is used virtually nowhere in modern programming languages. Parentheses are a de facto standard among all high-level languages if ever there was one, not a "commonality" between these three languages. He might as well say the same thing about variables, conditional logic, iteration, and what have you.

To sum up, this is a book that doesn't have a clearly defined target audience (by a long shot), is written in a savagely unprofessional and often baffling style, and is riddled with subtle and not-so-subtle mistakes and innappropriate tangents.

The only reason I've written a review so early into the book (page 31!) is that I'm already thinking about returning it, and want to make sure others have some idea of what they're getting into before they buy it. At best, if you're still curious, give this thing a good 30 minutes at least in your local bookstore, and keep an eye out for the things I mentioned.

The Premier Press GameDev series actually does have a lot of good, underrated titles, and gets a bad rap more often than it deserves, but books like this definitely aren't doing it any favors.

I flipped through this book before buying it, so I should have known what I was getting, but still I was disappointed. The discussion of the languages is pretty elementary. I was hoping that the discussion of game libraries for the various libraries would be of value, but the selection presented is much smaller than you can easily find online - and being a book, the information presented is out of date, too.

Additionally, there are some pretty atrocious editing errors, including syntax errors in the code that completely obscure the point being made, as well as figures incorrectly matched with their respective captions.

It's not ALL bad, though. There are a few examples here and there that changed the direction of how I considered using Python in games.

I hate giving this book a bad review because I ordered it without seeing the Table of Contents. If I had seen it, I would've known it wasn't what I was looking for. In any case, I don't think the book has anything useful in it for intermediate or experienced programmers. Normally I would say that this book is for beginners only, but I don't think it covers any of the scripting languages well enough for beginners.

The introductory chapter is mostly fluff, as it is in most computer books. Each language has 3 chapters dedicated to it: the first is a crash course on the language, the second introduces some useful extensions for the language (without explaining them well enough for you to be able to use them), and the third lists some existing projects that use the language. The concluding chapter has a little information on extending the scripting languages, and a comparative list of pros and cons.

Because the book is too short to reasonably cover three languages and their various extensions, it should've avoided explaining them and directed the user to the online documentation for them. With the possible exception of the Ruby SDL extension, which is only documented in Japanese, the online documentation is much better. The online documentation probably could've been distributed with the binaries that came with the CD.

When I bought this book, I was hoping to find some examples of game and game engine architecture/design that use scripting languages. Some are written with C/C++ extending the scripting language, and others are written the other way around. I wanted to see examples of both, with explanations of how the code was organized and why it was organized that way. Memory and performance pitfalls should be pointed out, along with tips on debugging and profiling.