11 internautes sur 11 ont trouvé ce commentaire utile
- Publié sur Amazon.com
Short story: If you want to work as a game programmer in the industry, you absolutely should understand the information in this book 100%. However, it is truly an advanced book, and if you are just getting into C++ usage, this should probably be your second or third book (at least).
Long story: There are few textbooks required by the Digipen Institute, one of the best game programming schools in the country. It emphasizes working together with your classmates to actually learn how to create games, so there is not a lot of actual book work to be done. This is one of those few books required. That alone should be enough to convince you it is worthwhile.
Let's go into a bit further though. The game industry has been alive for decades now, and that has led to standards and styles of programming that proves more effective than other methods. It is accepted that C++, and object-oriented programming in general, is the way to go. Event-driven programming is common in large titles. Resource management is a common theme in a game with gigs of data that needs to be continually streamed in. Multiple controller schemes need to be supported.
The authors of this book have worked in the industry, and this book is their offering to help teach you how modern games are made. Other books will manually load in individual resources, or will read the state of the keyboard directly in their examples. This is fine when you are first learning DirectX, for instance. But if you plan to work with a team, and you have tens of thousands of lines of code to debug, much of which you may not have actually written yourself, you need a better structure supporting your game, or it will become top-heavy and impossible to finish. This is what they are focusing on getting across.
As good as the book is, even more valuable is the sample game that has been built and evolved since the first edition of this book. Teapot Wars is freely available on Google Code, and it is a working example of everything they are trying to get across. It actually has more complex examples of the topics discussed in the book, and internally it is a basic version of a AAA title. Understand its structure and you will have a massive leg up in your quest to become a game programmer.
So this should be the book to buy right? Just understand it and you will be good to go, right?
Well.... yes and no. This book assumes several things, without really saying them outright. It assumes you have proficiency in object-oriented programming, especially in C++ programming. They assume you are comfortable with the concepts of inheritance, using abstract interface classes, overloading, encapsulation, and all those fun names you see thrown around in the Wikipedia definition of OOP. They build some fairly complex abstract factories and just throw them at you in the book. It took me months upon months of carefully reading C++ books and going through their code to finally really start to get it. I bought this book right when it came out, and I only now feel comfortable to write this review.
So this absolutely should NOT be your first book. You must study OOP and C++ first. Another book that Digipen uses, C++ for Game Programmers by Noel Llopis, may be a good start. I went through Thinking in C++ by Bruce Eckel years ago, as it is freely available online, and it's a great start too.
This book uses the DXUT framework, which has been deprecated by Microsoft and stripped from their MSDN online documentation. No big deal, it still works fine, but the main function may seem tricky to you because of it. They do not use DirectInput which is good, as Microsoft is no longer supporting it and it doesn't seem to work in 64-bit code. It assumes you understand how DirectX works when you get to the graphics chapters, so understanding the graphics pipeline is a good idea.
So you see, this is not the kind of book that says it's the only resource you need. In fact, it's probably the third or fourth resource you probably need. There's a steep learning curve, though kudos are due to the authors for being extremely available on their forum at [...] Seriously, they respond within 24 hours to any question anyone has.
However, if you understand everything in this book (a process that could easily take a year or more), you will have a clear idea of how a modern AAA game is created. It's just a framework, but you will probably be ready to start taking on major game programming projects. And that is a compliment that no other book on the market likely can boast of.
So in conclusion, I think any budding game programming will be doing themselves a HUGE advantage by making sure they understand everything this book is talking about. It is the more Complete book I have ever read on game programming, and is 100% essential to anyone taking themselves seriously. Just make sure you understanding object-oriented programming in and out before you begin, or you will be very lost very quickly.
8 internautes sur 8 ont trouvé ce commentaire utile
- Publié sur Amazon.com
At a little over 900 pages, this book (now in its 4th edition), covers the essentials of making games for programmers. I would recommend it for any programmer. It's not for artists or designers, but it considers how artwork and graphic design has to be factored into the CPU load. While I would recommend this book as the first book to read on programming concepts for gaming, it probably should not be the very first gaming book for beginners in either programming or game development. It is very much a conceptual->operational book, but it has enough concrete examples to provide grounded understandings of the concepts.
In my option what makes this book great is how it introduces the importance of Design Patterns in game development and design. (When I mention 'design' I'm talking about code design. Graphic or artistic design will be labeled as such.) In Chapter 2, the authors, Mike McShaffry and David Graham, spell out why object oriented programming and design patterns are practical tools to use in game architecture. They do not go into the details of working with OOP and design patterns, but they provide plenty of references that do. Their examples pretty much assume that the reader is familiar with classes, interfaces, methods and properties in the context of OOP. When reading what they were saying, I felt that I wanted to grab a young programmer by his Upper Playground t-shirt and and point to Chapter 2 and proclaim--'For God's sake! Listen to these guys! You may not see it now, but when you're 52 levels into your game, you'll understand!" So, yeah, I really like their approach.
The topics in this book deal with the essential elements of what you need as a game developer throughout its 24 chapters. I found myself running into fun and useful examples. For instance they showed the assembly listing for a 6502 chip from an Atari and a finite state machine in Lua for creating a simple AI. The AI example has a simple state chart showing how both the state machine and AI works rather than one of those awful old fashioned flow charts from the 1960s. (Some books still use those blasted things--to promote sequential programming it would seem.) Throughout their book they used what I consider "module" charts effectively and clearly. I would have liked some class diagrams illustrating using a design pattern in a game, but they can be confusing unless you're familiar with the UML, especially the version used by the Gang of Four (authors of design patterns).
Throughout their book, they use little "side stories" with special identifying cartoons. Included are Best Practices (most useful), Gotcha! (what to watch out for), and Mike's and Rez's tales from the Pixel Mines (interesting and useful experiences in working on different games for different companies.) In some books such asides often range from distracting to banal, but here, they are used very effectively. This does not seem to be the kind of book that you'd read from cover-to-cover (unless you're in a North Korean prison) but instead a book to keep nearby when developing a game and to look into for guidance in dealing with a specific issue. Chapter 2 is one you'll want to read from beginning to end and Chapter 3 has great tips if you have not programmed larger projects, but otherwise, it's easy to skip around between topic on UI, sound, input devices, multi-threaded programming (Introduction to Multiprogramming), gaming across the internet, game AI and other game coding topics.
At first I was concerned about the C++ dominating the examples, but very quickly it was clear they were easily translated into my favorite programming language, and they were used to illustrate a more general idea. The book's value lies in its concepts and practices. Those concepts and practices will be around long after the hardware, programming languages and game tastes have gone the way of the dodo bird.