Not so much a programming book as much as it is a look into the entire world of tools development, Game Engine Toolset Development by Graham Wihlidal is an interesting read for those wanting to improve the production pipeline or tool creation. Now that I my current job is focused more on the technical artist/programmer instead of a team lead game programmer, I figure I should take a bit more time on the technical artist and tools building aspects (which are for me back to basics). The book focuses on a wide range of topics, and focuses more so on implementation details than tool design.
The book begin largely on the politics of tools and maintenance and different stakeholders in the tools, as well as some examples of different environments in which tools are created and maintained. There are a few examples of professional studios, who focus on elaborate GUI systems, and WYSISYG (what you see is what you get) world editors.
From there, the book has a chapter on why to create tools with C# with .Net (which is the language and framework used throughout the book). While I agree that .Net can be a great and quick framework for developing solid tools quickly, I would recommend sticking with the language that is closest to the game engine or 3D application whenever possible (since it is often the case that some parts (or the entire tool) can be merged into the game code, and it is better to not have too many languages in any production environment (if possible)).
There is a lot of focus on coding standards, design and documentation which is extremely important for tools, since they are often written specifically for one project, and can be very difficult to port to other projects if the design and standards are poor. Plus, the fact that many tools are written once and then the programmer moves on to something else, it is easier to forget why the code was written a certain way when come back to it in six months. Having a good design and (up-to-date) documentation is very important if no one is going to be looking at the code until the next project, or something breaks. There is some discussion of code metrics, UI design, using NUnit for unit testing, Microsoft coding conventions and using FxCop to enforce coding policies (I also like StyleCop for coding standards). The coding documentation is with NDoc, which I am not as familiar with, but will have to check out sometime (I currently like Doxygen since it is useful for a lot of languages).
All in all, a good book that deals a lot more with the entire job of tools development, which is somewhat unique in terms of computer books. I realize that for some people (and companies) the need for tools is not quite so apparent. The best analogy I can think of is that tools are the "scaffolding" in which you can build up any project. They solve the simple problems, help tackle the larger problems, glue together what needs to be connected, and improve the productivity of the entire department. Without scaffolding tools everyone would be trying to add another floor to a building by hanging out a window, and if that is the case, you are not going to be able to build quite so high...
Keep reaching for the top,
Michael Hubbard
http://michaelhubbard.ca
The book begin largely on the politics of tools and maintenance and different stakeholders in the tools, as well as some examples of different environments in which tools are created and maintained. There are a few examples of professional studios, who focus on elaborate GUI systems, and WYSISYG (what you see is what you get) world editors.
From there, the book has a chapter on why to create tools with C# with .Net (which is the language and framework used throughout the book). While I agree that .Net can be a great and quick framework for developing solid tools quickly, I would recommend sticking with the language that is closest to the game engine or 3D application whenever possible (since it is often the case that some parts (or the entire tool) can be merged into the game code, and it is better to not have too many languages in any production environment (if possible)).
There is a lot of focus on coding standards, design and documentation which is extremely important for tools, since they are often written specifically for one project, and can be very difficult to port to other projects if the design and standards are poor. Plus, the fact that many tools are written once and then the programmer moves on to something else, it is easier to forget why the code was written a certain way when come back to it in six months. Having a good design and (up-to-date) documentation is very important if no one is going to be looking at the code until the next project, or something breaks. There is some discussion of code metrics, UI design, using NUnit for unit testing, Microsoft coding conventions and using FxCop to enforce coding policies (I also like StyleCop for coding standards). The coding documentation is with NDoc, which I am not as familiar with, but will have to check out sometime (I currently like Doxygen since it is useful for a lot of languages).
All in all, a good book that deals a lot more with the entire job of tools development, which is somewhat unique in terms of computer books. I realize that for some people (and companies) the need for tools is not quite so apparent. The best analogy I can think of is that tools are the "scaffolding" in which you can build up any project. They solve the simple problems, help tackle the larger problems, glue together what needs to be connected, and improve the productivity of the entire department. Without scaffolding tools everyone would be trying to add another floor to a building by hanging out a window, and if that is the case, you are not going to be able to build quite so high...
Keep reaching for the top,
Michael Hubbard
http://michaelhubbard.ca
