Rating:  Summary: A Game Project management guide Review: The authors start the introduction with: "The philosophy behind this book is simple , stark and absolutely true. If you are failing to plan , then you are planning to fail.". That turned a red light on in my head , as it sounds like a management intro.As a start , the book contains three parts, and not two as the title might suggest. The parts are: Game design , Team building and management , Game Architecture. Part 1 of the book starts with Game design. At first , it was odd for me to see a book that talks about design , and only then , architecture. Suspecting the meaning, I let it slip and read on. In subsequent chapters , the authors seem to wear their management hats when sat to write this one. What the authors call "design" is actually ideas , playability & usability requirements for the game , terms used by marketing employees , not developers. Moving to the second part of the book , the authors dedicated few (7 to be precise) chapters concerning to management. Seeing there is nothing to learn here , I moved to the third part. I was doubtful when I started reading about architecture (pg. 345) , knowing that 2/3 of the book was meaningless. This part did shed some light on the issue of game architecture. Actually only one chapter , named "Initial Design" (shouldn't it be in the "Game Design" part?!) was contributing. Even when the book discusses what modules should be in the game , it mostly explain the how, whereas the *most* important thing to know is the why (we can figure out the how when dealing elementary concepts). The only place I could see some code (or design , or architecture!) was in the Building Blocks chapter , where the authors describe Design patterns (it seems like every software development article or book have to include its own interpretation of DP) , where as this information is absolutely unnecessary in the context of the book. For learning Design Patterns read the bible: "Design Patterns" by Gamma et al. The authors stuff in comments about management all through the book , even in Architecture and Design parts. That and the repetition of ideas and full paragraphs again and again makes it *very* difficult to read (just to have a clue: The question "what is a game" is discussed for about 20 pages , and it is revisited several times). The authors did get it right on the cover , though: Project development starts from architecture (after gathering requirements), and then moves to design , and not the other way around! Bottom line: Just a waste of 50$!
Rating:  Summary: Somewhat intersting Review: The first 3rd of the book was intersting because it dealt with game play. The rest of the book was a rehash of project management material. If you already know about project management then go look for a book on game design because other books cover Project management better.
Rating:  Summary: Interesting book on the subject but too long and personnal Review: This book could have been shorter if only the authors had concentrated on their subject: the design and architecture of games. All in all they advocate sound project management and design practices but they emphasise too much on the peculiar culture and characters one can find in this rather young industry. The authors present the software factory as the solution to the problem that plague the industry which they resume to indiscipline. There is a strong feeling of intolerance towards certain types of people in the book that I found inappropriate. If the authors can draw examples from the movie industry and its specialized team work, they should also acknowledge that being able to work with big egos and many different kinds of personnalities is a sign of maturity that they should try to emulate.
Rating:  Summary: Great book, but...! Review: The book is very well writen. It touchs the design part, the team management part and the architecture part of game programming. If you are, or want to be, in the game programming industry this book is a MUST. Maybe the authors are stereotyping people so much in the team management part of the book, but, what the hell. You have to know that this book focus on the "How should be" or "How will be" the game industry and not on the "How it is". :)
Rating:  Summary: I've been waiting for this book forever... Review: Finally someone goes over design tradeoffs in a meaningful way. One of the most important, but little understood areas of games is game design, and now there is a solid reference available. The technical part looks good, but I haven't delved into it yet. I give this book a high rating based on the design aspects alone.
Rating:  Summary: This book is required reading Review: I can do more than recommend this book; I've made it the required text for a series of courses that I teach on Computer Game Design at a Midwestern U.S. University. There are many good 'code' books. We've all bought them and they have a practical life of about 6 months before new hardware makes them obsolete. "Game Architecture and Design" is not just a 'code' book. It is the first comprehensive study that I've read that deals specifically with the issues of Computer Game Design and Computer Game Team Management. This book is a great read. It is a well thought out explanation of the intricacies of the Computer Game Industry and the entire process of Computer Game Development from start to finish.
Rating:  Summary: Get It, Read It Review: If this book has a weak point it is in the first Appendix, the Sample Design Documents. You really have to put your thinking cap on while studying them. If I was going to give a class in Game Development I'd use this as my text. It covers all of the issues and problems and its organization is clean and clear cut allowing the reader to just read those parts he/she is interested in. You may disagree with some of the Authors ideas and recommendations, I did, but it gets you thinking about the issues and I found this very helpful. Get it, Read it, Think About It
Rating:  Summary: Excellent book Review: I completely disagree with the reviewer who says the book is too long and badly written. It's one of the clearest and most readable "technical" books I have read. It's certainly not a rehash of information available in Steve McConnells books - where does *he* write about game design and other game specific topics?... Good architecture and design is good architecture and design - no matter who writes about it. And this stuff is written with the games industry in mind - not like all those other books. And what's with the guy who says this book is excellent and then gives it one star? A slip of the mouse? If only I could give 10 stars in order to balance that out ;)
Rating:  Summary: Too long Review: Sloppily written, repetitious, too many unsupported opinions, too many loose facts, and far too long. If one despite these deficiencies decides to trust the authors, there is plenty of healthy, eye-opening information, however, in particular in the game-specific sections, but for those who have read some of the software development classics (such as Steve McConnell's Code Complete) much of the book is old news badly presented.
Rating:  Summary: An excellent book Review: All games companies should have a copy of this book which will help them superate the difficulties of creating a quality game. Even if you are a "Lone Wolf" you'll learn a lot with this book.
|