Rating: 
Summary: Excellent book, goes beyond hacking
Review: ** This is not a code-monkey book. ** If you're trying to figure out C++ inheritance or Direct 3D, you've got the wrong book.
This is a book that goes above and beyond the simple act of coding a game. It dares to say that there is more to writing a game than sitting down and hacking something out in an hour. The book makes the revolutionary statement that software design should be a professional undertaking, not just something on a napkin.
There are excellent articles on game theory, design strategies, and gameplay balancing that I have never seen in another game book. I have bought a lot of game programming books along with software methodology books, and I rank this one as one of the best in both categories. It is definitely the only game design book I have found that is deserves that title.
Yes, the book does include a section on managing a team...let me tell you, a lot of so-called managers could use to read this section. And personally, if "Joe Programmer" is so offended by that section, I hope to never have to work with him.
Rating:
Summary: It's like a Masters Degree in Game Design +20 yrs Experience
Review: I am a QA Tester, RPG DM/GM, and game design consultant. This book is great, but don't take my word for it alone. Look at these other stars man! In a nutshell this tomb uses case studies to emphasize points, and the points are detailed and listed like a text book. It's easy to read, full of useful details and vocabulary, and it actually has helped me immensely organize my game design philosophy. It covers Spec Writing, and the many stages of project developement. That is a huge book; if you don't know this stuff you need this book! But only if your serious, and want to read. Granted, it can be very funny as well~I found myself laughing at the case studies several times. Finally, I am using this book to finish my Masters (MBA) Thesis project ... because this book rocks, and it is the most professional omnibus I have found on the subject of Game Design.
Rating: 
Summary: Shallow, deceptively titled, out of date, and naive
Review: A combination of early 90's OO and cribbing from software engineerinng books that if, you are worth anything, you've already read. This book conspicuously fails to deal with the special problems of game architecture and development, or to deal with the most relevant developments in software engineering in the past ten years - or to mention that the authors' only major game shipped years late.
Rating: 
Summary: fun read, but mostly shallow
Review: This book is a little unusual in that it claims to cover very technical topics while reading more like a light novel. While it was still interesting, it's of the 'read once and forget' type, i.e. I do not regularly get this book out for reference like most of my other technical books. It's biggest problem is that it tries to cover too much ground in too little space (~700 pages) - there is no way to deal with the whole process of developing a commercial quality game in a single book. As a result the author only briefly touches on many topics which would have been better left out for more in-depth coverage from other books. For example, management, architecture design, design patterns and testing each require a book for themselves, rather than a short and superficial one chapter treatment. What's left is a lot of stating the obvious (breaking news: testing is good!) and a lot of personal opinions. While the chapters on design are quite readable, by their very nature they deal with lots of 'religious' issues, and although the author tries to be careful I sometimes felt offended by his preachy tone. I sometimes got the feeling the author had a somewhat ivory-tower, disconnected from reality view on many of the topics, especially the treatment of 'software factories' sounded utopian. The book also features lots of useless diagrams and code snippets of varying quality, which are, presented in isolation, again useless. The highlights are probably the 'case-studies', small anecdotes, scattered throughout the book. In summary, the book is like the internet: an ocean of information but mostly only knee deep.
Rating: 
Summary: You gotta take the bad with the good
Review: Rollings and Morris devote a page to bashing on what I consider one of the best games I've worked on, so it would be tempting to give them a [bad]review out of spite, but I'll try to be good. Where this book really shines is when it discusses dominant strategies and play balancing, and it should be required reading for anybody working on a strategy game of any kind, and it's pleasurable reading no matter what kind of game you're working on. Another important page in this book comes early on: they point out that game developers don't necessarily make games per se, but entertainment software. That is, it doesn't matter how good a game is by some strict definition of game that involves challenges, choices, winning-and-losing--what really matters is that the customer was entertained and doesn't regret the purchase. Unfortunately, after pointing this out, they devote the rest of the book to discussing exactly how to make game-game-type-games. The world is still waiting for the book that discusses more general entertainment software. The architecture section is quite good as well: our game engine had already been built by the time I read this book, and the general guidelines for how to layout a game engine pretty much matched what we had already done. So much that I could use their structure when documenting our engine. Where this book goes into space is in the production section: how to run a game company, how to run a game team. This section really reads like, "When I get to run a game company, this is how I'm going to do it," rather than, "This is how we do things. We've tried it, and it worked." For that kind of information, you're better off looking at Eric Bethke's book, *Game Development and Production* and the many software development books out there, such as McConnell's *Rapid Development.* (Which is my personal Bible.)
Rating:
Summary: A specific comment
Review: I was mainly interested in the 22 page chapter on the history of game development and technology, so I can only speak to that section, although I did peruse and read some of the other chapters, which also looked good. In this chapter, the author does an excellent job of recounting the history of game and graphics programming from the early 80's, when progammer's compiled their programs themselves by manually converting the op codes into hex and then using a hex loader to load them into the machine, to the development of the Watcom and Microsoft C compilers, to DirectX controls, and the development and use of the COM model, which has powerful features such as versioning support and other useful things. I found this history very interesting and well done, and accessible to a non-software engineer like myself. The author often uses examples of which games were the first to be developed with a new advance, such as Doom, which was the first major game to be written almost completely in C rather than assembler, something that wasn't thought practical at the time because of speed and performance concerns. The author mentions that the only thing not actually written in C was a couple of horizontal and vertical line-drawing routines. The author shows how the early history of games was dominated by the programmer's need to live within limits of the hardware, especially the limited amount of RAM, and the need to write in assembly language for speed purposes, or "writing directly to the metal," as it was called back then. And he shows how more powerful later developments freed programmers from these limitations, such as the advent of 32-bit memory architecture, which eliminated the need to use the old 20-bit segment:offset model with it's 1 meg total RAM limit and the need to partition and access memory in 64K blocks, and so on. As I said, I didn't read the entire book, but I did read some of the other chapters, and there seemed to be a lot of good, practical advice there on how to avoid many of the problems typical of developer teams and of the developing and managing process as well.
Rating: 
Summary: Should Take Architecture and Design out of the title.
Review: This book was misleading. I bought it in hopes of learning game designs and architectures. This is not what the book is about. This is book is about game developement process, documenting, and good planning. It does NOT cover anywhere ACTUAL DESIGNS. Not to mention that every chapter says the same thing over and over again, which I can sum up in one sentance. Plan well, document, and where possible reuse code. Thats all this book says. It might be a good for people who already know how to design games on doing a better job, but thats it.
Rating:
Summary: Really good book - inside view on development.
Review: As a game designer with 6 years of industry experience, this book really hits home. I'd recommend anyone involved in the game development industry to give it a read.
Rating:
Summary: Two thirds of the book was great for me.
Review: This really is an odd book. I would have given it 3 1/2 stars if possible, but decided it was above average so stuck with 4. This book serves a niche apart from the pure programming books that cover graphics or game design. Specifically, it covers three areas: 1) Game design 2) Game Company Environment and Procedures 3) Game development To me, the first and third elements were the most interesting. They described ways to inject originality and stability both into a game. The discussion on Stone-Paper-Scissors interactions was very worthwhile though the explanations of the mathematical equations is somewhat rushed. The application of design patterns to gaming was quite welcome. Part two simply didn't interest me, but then again, I don't plan to be part of a gaming company. A description of working procedures, environment and personalities seems mostly of interest to large projects. It was interesting reading, but not useful personally to me. This part also didn't seem to fit well with the rest of the book.
Rating:
Summary: this is THE Book
Review: Don't look further, you've founded the book you wanted to get into de games business. Explains from scratch how to design, develop and even how to create your development teams for games. With case studies, more than 700 pages, this book is your bible.
|
