Autodesk Maya Techniques Official Training Guide More Hyper Realistic Creature Creation by Erick Miller and Jeff Unay and Paul Thuriot and Rudy Grossman is both a long title and an interesting read. The book focuses mainly on facial modeling (mostly using blend shapes), facial rigging (joint driven components) and full body setup (full body IK, influencing the skin, caching out deformations).
The book has some interesting information such as how to adjust to production changes. Accomodating art/design changes can be accomplished by creating a blend shape from the old base head to all blend shapes, which not only saves work, but also perserves all the original information. For accomodating topology changes the first option is to setup a driver to the new topology, or the second option is to bake toplogy to targets.
The list of standard (required) blend shape targets was quite thorough and included:
ooh mouth shapes (in between targets)
lips mouth up and down (upward and downward facial shturds)
lip corners up/down optional , smile frown
upper and lower lip roll (or lip curl)
lip corner sideways (inward pull/outward strecth)
lip mouth pull forward and back
lip volume shapes flattened /tightened and puffed out lips
eye blinks/wide open eyes
tightly squinted eyes
cheeks up/down (cheek squint, cheek droop)
puffed out and sucked in cheeks
inward outward and updward downward flares, nose sneer snarl
brow up and down (furrow and raise)
forehead brow sideways (inward pull/outward stretch)
jaw clench/foreched clench, neck clench
custom shapes
jaw corrective shape
Overall, the book is quite slim (at 157 pages) which makes it a quick read, but it comes with a DVD full of great example scenes and code scripts/plugins (which I will see about reviewing in another post(s)). If nothing else, the book is useful as a guide to the examples, but has some good information on more high level concepts and information. In some ways it is a sequel to Hyper-Realisitc Creature Creation, so it may be better to read that first, but still stands well enough on its own.
Bye for now,
Michael Hubbard
http://michaelhubbard.ca
Showing posts with label book review. Show all posts
Showing posts with label book review. Show all posts
Tuesday, February 14, 2012
Thursday, February 9, 2012
Book Review: More Python Programming for the Absolute Beginner
One thing I always want to do is try and look at programming from a fresh pair of eyes. While I am certainly not an absolute beginner it is sometimes interesting to see how a development book tries to instill the core concepts of programming into the new reader. In More Python Programming for the Absolute Beginner by Jonathan S. Harbour the focus is to hit the ground running. The book focuses on the pygame module to create 13 small games/demos including: Pie Game, Trivia, Bomb Catcher, Analog Clock, Orbiting Spaceship, Escape the Dragon, Zombie Mob, Block Breaker, Oil Spill, Snake, Tank Battle, Artillery Gunner and Dungeon RPG.
Overall, the code is quite straightforward and well contained, although in a few places it seemed like a little extra engineering might go over a few people's heads, but still produce more concrete code. The code examples actually get better with more classes and better encapsulation later on, and I suppose it can be a bit much to introduce everything to an "absolute beginner". One thing that I thought was interesting was the workarounds necessary to deal with the pygames sprite rotations: "Pygame does not correctly adjust for the change in image size when a sprite is rotated", the fix is to "shift the image by the amount of change in dimensions from the normal image to the rotated image" (pg 203, 205).
Overall, this is a pretty entertaining read, and gives some good quick examples of pygame. The book also links to the author's forum where there is more information and updates: http://jharbour.com/forum/index.php?PHPSESSID=f8s6pkk6tdvb47ullmqormult4&board=23.0
One of the most expansive topics was the Dungeon "Roguelike" RPG. For an example of that, see the link posted in the above forum at: http://roguebasin.roguelikedevelopment.org/index.php/Main_Page
It may be fun to experiment a bit more with pygame for some simple examples, but for now, I am focused far more on other python modules.
Until next time,
Michael Hubbard
http://michaelhubbard.ca
Overall, the code is quite straightforward and well contained, although in a few places it seemed like a little extra engineering might go over a few people's heads, but still produce more concrete code. The code examples actually get better with more classes and better encapsulation later on, and I suppose it can be a bit much to introduce everything to an "absolute beginner". One thing that I thought was interesting was the workarounds necessary to deal with the pygames sprite rotations: "Pygame does not correctly adjust for the change in image size when a sprite is rotated", the fix is to "shift the image by the amount of change in dimensions from the normal image to the rotated image" (pg 203, 205).
Overall, this is a pretty entertaining read, and gives some good quick examples of pygame. The book also links to the author's forum where there is more information and updates: http://jharbour.com/forum/index.php?PHPSESSID=f8s6pkk6tdvb47ullmqormult4&board=23.0
One of the most expansive topics was the Dungeon "Roguelike" RPG. For an example of that, see the link posted in the above forum at: http://roguebasin.roguelikedevelopment.org/index.php/Main_Page
It may be fun to experiment a bit more with pygame for some simple examples, but for now, I am focused far more on other python modules.
Until next time,
Michael Hubbard
http://michaelhubbard.ca
Saturday, November 5, 2011
Book Review: Head First Design Patterns
Head First Design Patterns by Eric and Elisabeth Freeman is a fun read. I always was curious about what kind of content some of these books by O'Reilly that seemed so different would be like (lots of pictures, jokes, crossword puzzles etc.) but it turned out to be both entertaining and informative. The book really does try to tackle a number of important issues, and doing an "arm chair discussion" where two design patterns talk (and argue) about their differences, is both funny and some of the most useful insights into distinguishing patterns I have seen.
The Freemans really do create a useful intro to design patterns, with a number of entertaining examples that will make you enjoy reading each page, and is certainly a breath of fresh air for anyone used to very academic and "serious" books. I felt the content was great, and the format was excellent for an introduction book.
While I don't normally go for books based on Java, this was more of a theory book, and while the source code examples are in Java, it should not be difficult for anyone to follow along (outside of maybe some of the Remote Proxy examples which leverage Java's Remote Method Invocation).
The main patterns covered include: Strategy, Observer, Decorator, Factory, Singleton, Command, Adapter, Facade, Template, Iterator, Composite, State, Proxy and Compound Patterns. There is also an appendix that contains a number of other patterns. I would have prefered to have seen a chapter on Flyweight or Builder instead of Singleton, but whether or not Singleton is an Anti-Pattern is still up for debate.
One of the most interesting approaches in the book is to break apart a Model-View-Controller paradigm into separate patterns. The Model becomes and Observer pattern (allowing state information to be passed back to the View or the Controller (allowing it to be independent of the View and Controller). The View becomes a Composite (likely a collection of widgets or something similar). The Controller implements the Strategy pattern, which configures the View with a strategy and changes the state of the Model as necessary. This explanation fits well (especially the Model using an Observer) which I think is one of the nicest ways to implement the MVC design.
While I have read a few books on Design Patterns already, I think as an intro, unless you are looking for a specific language implementation or the original Design Patterns book by the Group of Four, I think this is a good intro and an overall fun read.
Bye for now,
Michael Hubbard
http://michaelhubbard.ca
The Freemans really do create a useful intro to design patterns, with a number of entertaining examples that will make you enjoy reading each page, and is certainly a breath of fresh air for anyone used to very academic and "serious" books. I felt the content was great, and the format was excellent for an introduction book.
While I don't normally go for books based on Java, this was more of a theory book, and while the source code examples are in Java, it should not be difficult for anyone to follow along (outside of maybe some of the Remote Proxy examples which leverage Java's Remote Method Invocation).
The main patterns covered include: Strategy, Observer, Decorator, Factory, Singleton, Command, Adapter, Facade, Template, Iterator, Composite, State, Proxy and Compound Patterns. There is also an appendix that contains a number of other patterns. I would have prefered to have seen a chapter on Flyweight or Builder instead of Singleton, but whether or not Singleton is an Anti-Pattern is still up for debate.
One of the most interesting approaches in the book is to break apart a Model-View-Controller paradigm into separate patterns. The Model becomes and Observer pattern (allowing state information to be passed back to the View or the Controller (allowing it to be independent of the View and Controller). The View becomes a Composite (likely a collection of widgets or something similar). The Controller implements the Strategy pattern, which configures the View with a strategy and changes the state of the Model as necessary. This explanation fits well (especially the Model using an Observer) which I think is one of the nicest ways to implement the MVC design.
While I have read a few books on Design Patterns already, I think as an intro, unless you are looking for a specific language implementation or the original Design Patterns book by the Group of Four, I think this is a good intro and an overall fun read.
Bye for now,
Michael Hubbard
http://michaelhubbard.ca
Saturday, October 15, 2011
Book Review: More Effective C++
A blast from the past More Effective C++ by Scott Meyers is not just another C++ book, but touches on a number of features and concepts that should be talked about far more than you get from most C++ books.
Some of the topics include: smart pointers, lazy evaluation, preventing resource leaks in constructors, preventing exceptions from leaving destructors, understanding the cost of exception handling, understanding the origin of temporary objects, understanding the cost of virtual functions, base classes and RTTI and more.
One part I especially liked was avoiding gratuitous default constructors. This is more of a design decision, but still a useful one, in that if member functions have to test if fields have truly been initialized it complicates the design and can lead to bugs and more complicated behaviour in handling these uninitialized classes.
Meyers talks about a number of design decisions, and side effects of going too far with overloading methods, or operator new or operator delete (and the numerous hacks and design decisions that have to be considered if you do decide to handle your own new and delete (i.e. don't do it)).
The chapter on exceptions was particularly intresting, and is probably my favorite description of exceptions:
When thinking about exceptions in this way (as something that cannot be ignored), it is a great mindset for the programmer to consider what they really consider unignorable. This is quite a bit different than return codes, or status variables, which can be ignored, although at the risk of potentially undefined behaviour. Exceptions are best used when something exceptional happens. For performance reasons, it is best to limit the usage of exceptions whenever appropriate (and exceptional).
There are also some good practical advice, such as program in the future tense. Consider how the code will grow in the future, or how it will be used. Provide complete classes, even if some parts aren't currently used. Make the class easy to use, and hard to use incorrectly. Generalize the code whenever appropriate to maximize reuse. This is not to say design and program things you aren't going to need, but rather create logically complete classes (if something can be set, it probably should also have a get, and if an entry can be added, it probably needs a way to remove that entry too).
The book even though it is not hot off the presses, still offers quite a bit of useful insight into C++ and fills a role that few books really delve into. If corners of your C++ knowledge are growing some cobwebs, this is a useful book to help dust some of them off.
Cheers,
Michael Hubbard
http://michaelhubbard.ca
Some of the topics include: smart pointers, lazy evaluation, preventing resource leaks in constructors, preventing exceptions from leaving destructors, understanding the cost of exception handling, understanding the origin of temporary objects, understanding the cost of virtual functions, base classes and RTTI and more.
One part I especially liked was avoiding gratuitous default constructors. This is more of a design decision, but still a useful one, in that if member functions have to test if fields have truly been initialized it complicates the design and can lead to bugs and more complicated behaviour in handling these uninitialized classes.
Meyers talks about a number of design decisions, and side effects of going too far with overloading methods, or operator new or operator delete (and the numerous hacks and design decisions that have to be considered if you do decide to handle your own new and delete (i.e. don't do it)).
The chapter on exceptions was particularly intresting, and is probably my favorite description of exceptions:
The addition of exceptions to C++ changes things. Profoundly. Radically. Possibly uncomfortably. The use of raw, unadorned poniters, for example, becomes risky. Opportunities for resource leaks increase in number. It becomes more difficult to write constructors and destructors that behave the way we want them to. Special care must be taken to prevent program execution from abruptly halting. Executables and libraries typically increase in size and decrease in speed... so why mess with exceptions, especially if they are problematic as I say? The answer is simple: exceptions cannot be ignored (pg 44).
When thinking about exceptions in this way (as something that cannot be ignored), it is a great mindset for the programmer to consider what they really consider unignorable. This is quite a bit different than return codes, or status variables, which can be ignored, although at the risk of potentially undefined behaviour. Exceptions are best used when something exceptional happens. For performance reasons, it is best to limit the usage of exceptions whenever appropriate (and exceptional).
There are also some good practical advice, such as program in the future tense. Consider how the code will grow in the future, or how it will be used. Provide complete classes, even if some parts aren't currently used. Make the class easy to use, and hard to use incorrectly. Generalize the code whenever appropriate to maximize reuse. This is not to say design and program things you aren't going to need, but rather create logically complete classes (if something can be set, it probably should also have a get, and if an entry can be added, it probably needs a way to remove that entry too).
The book even though it is not hot off the presses, still offers quite a bit of useful insight into C++ and fills a role that few books really delve into. If corners of your C++ knowledge are growing some cobwebs, this is a useful book to help dust some of them off.
Cheers,
Michael Hubbard
http://michaelhubbard.ca
Saturday, September 10, 2011
Book Review: Cross-Platform Development in C++
I decided to look into some more books on cross-platform work to see what more professionals were doing in this field. The book Cross-Platform Development in C++:Building Mac OS X, Linx and Windows Applications by Syd Logan, describes some of the techniques used in creating the Mozilla/Netscape browser to multiple platforms, and the challenges involved in creating such a massive project.
The basic theme of the book is abstraction, especially when dealing with low level implementation details, file I/O, threads, byte order, any platform specific code etc. Logan recommends creating factory classes that returns a concrete class implementation of an interface for these types of problems. The code should NOT be sprinkled with #if defines as it makes coding and debugging these things a nightmare as nearly every line could contain one or more #defines. Instead creating an abstract factory for returning the necessary factory and concrete implementation is essential.
In this book Logan share tips and workflow processes that allowed these projects to succeed on multiple platforms. These included having multiple experts on each of the platforms for handling, requiring developers to test on all three major platforms (Windows, Mac OS and the target flavour of Linux) before commiting to the code base. Logan also suggests another requirement is to compile with different compilers, pay attention to warnings and consider whether the native compilers for each operating system are the best approach (whichever compiler makes the most sense). One scheduling requirement was that all functionality worked on all platforms at the same time, this was essential to keeping everything working and preventing features from only being implemented on a given platform (which goes against the application being entirely cross-platform).
The book goes into quite a bit of detail on setting up Makefiles for each of the platforms using Imake and having a cross platform make system. It is also suggested to use a cross platform bug reporting system (Logan uses Bugzilla and Tinderbox since they are other Netscape/Mozilla projects). CVS is used (although Subversion is mentioned) but it is also a requirement to have cross platform tools (while also relying on Cygwin to emulate a lot of Linux tools on Windows).
There are other tips such as consider using the NSPR platform abstraction library (Netscape Portable Runtime Library), being wary of what standards floating point calculations are done, avoiding serialization of binary data (unlss you are using a convention for the data), using the limits.h for any size information (instead of using sizeof), etc.
One particularly good example in the book was related to the floating point representation:
Trixul is an interesting project and some of the functionality of a browser (like embedded Javascript to interact with the DOM) are concepts that would be interesting to apply to a game engine, although perhaps in a slightly different way. Serializing in XML for the UI is incredibly valuable, although likely something that individuals will have to write themselves (see my post on XNA Serialization for this). Trixul allows C++ components to be written that can be accessed through a Javascript component manager to extend the functionality, within the SpiderMonkey Javascript engine. I won't go into too much detail about Trixul here, but if you are interested check out the links (and the book).
All in all, I think this book gives a great insight into the complexities of cross-platform development, especially in working in a large team. I still stand by my post about indie game developers should not initially target multiple platforms: http://gameprogrammertechnicalartist.blogspot.com/2011/08/indie-multi-platform-game-development.html as the amount of effort involved in making this work, the number of experts involved and the time it takes to get just three major platforms to work can be significant. If possible try to use tools that are platform independent, and see about abstracting all platform specific code, test on all systems as you write the code, and realize this is going to take some time.
Best of luck,
Michael Hubbard
http://michaelhubbard.ca
The basic theme of the book is abstraction, especially when dealing with low level implementation details, file I/O, threads, byte order, any platform specific code etc. Logan recommends creating factory classes that returns a concrete class implementation of an interface for these types of problems. The code should NOT be sprinkled with #if defines as it makes coding and debugging these things a nightmare as nearly every line could contain one or more #defines. Instead creating an abstract factory for returning the necessary factory and concrete implementation is essential.
In this book Logan share tips and workflow processes that allowed these projects to succeed on multiple platforms. These included having multiple experts on each of the platforms for handling, requiring developers to test on all three major platforms (Windows, Mac OS and the target flavour of Linux) before commiting to the code base. Logan also suggests another requirement is to compile with different compilers, pay attention to warnings and consider whether the native compilers for each operating system are the best approach (whichever compiler makes the most sense). One scheduling requirement was that all functionality worked on all platforms at the same time, this was essential to keeping everything working and preventing features from only being implemented on a given platform (which goes against the application being entirely cross-platform).
The book goes into quite a bit of detail on setting up Makefiles for each of the platforms using Imake and having a cross platform make system. It is also suggested to use a cross platform bug reporting system (Logan uses Bugzilla and Tinderbox since they are other Netscape/Mozilla projects). CVS is used (although Subversion is mentioned) but it is also a requirement to have cross platform tools (while also relying on Cygwin to emulate a lot of Linux tools on Windows).
There are other tips such as consider using the NSPR platform abstraction library (Netscape Portable Runtime Library), being wary of what standards floating point calculations are done, avoiding serialization of binary data (unlss you are using a convention for the data), using the limits.h for any size information (instead of using sizeof), etc.
One particularly good example in the book was related to the floating point representation:
float x = 4.0/5.0;The above example will print out "Different", since floating point expressions are evaluated to the greatest precision representation available (in this case double). The example below will print out "Same".
if (x == 4.0/5.0)
{
printf("Same\n");
}
else
{
printf("Different\n");
}
double x = 4.0/5.0;The book deals a lot with user interfaces as well (which are often a major issue with portability). Logan goes into some detail of the MVC (Model-View-Controller) paradigm, but also covers wxWidgets http://www.wxwidgets.org/, some of Netscape/Mozilla's XML-based GUI toolkit XUL https://developer.mozilla.org/En/XUL and his own open source project Trixul http://www.trixul.com/.
if (x == 4.0/5.0)
{
printf("Same\n");
}
else
{
printf("Different\n");
}
Trixul is an interesting project and some of the functionality of a browser (like embedded Javascript to interact with the DOM) are concepts that would be interesting to apply to a game engine, although perhaps in a slightly different way. Serializing in XML for the UI is incredibly valuable, although likely something that individuals will have to write themselves (see my post on XNA Serialization for this). Trixul allows C++ components to be written that can be accessed through a Javascript component manager to extend the functionality, within the SpiderMonkey Javascript engine. I won't go into too much detail about Trixul here, but if you are interested check out the links (and the book).
All in all, I think this book gives a great insight into the complexities of cross-platform development, especially in working in a large team. I still stand by my post about indie game developers should not initially target multiple platforms: http://gameprogrammertechnicalartist.blogspot.com/2011/08/indie-multi-platform-game-development.html as the amount of effort involved in making this work, the number of experts involved and the time it takes to get just three major platforms to work can be significant. If possible try to use tools that are platform independent, and see about abstracting all platform specific code, test on all systems as you write the code, and realize this is going to take some time.
Best of luck,
Michael Hubbard
http://michaelhubbard.ca
Sunday, August 28, 2011
Book Review: Write Portable Code
There are not a lot of books on portable code, but Write Portable Code: An Introduction to Developing Software for Multiple Platforms by Brian Hook does a good job handling many of the topics.
There are a number of rules for portability:
- Never assume anything (memory, size of built in types (int, float etc.)).
- The code will likely have to have non-portable elements to run efficiently.
- Establish a reasonable baseline of platforms, (not both PS3 and Commodore 64).
- Never read or write structures from memory or cast raw bytes to a structure.
- Always convert to or from a canonical format when moving data in or out of memory.
- Develop good habits and use tools and platforms that cooperate to strong practices.
- Avoid new langages or library features.
- Integrate testing.
- Use compile time assertions and strict compilations (avoid excessive conditional compilations).
- Write straightforward code.
- Understand anything can change between compilers (floating point can work different).
- Leverage portable third party libraries, but be careful.
- Performance and resource usage must be as portable as your features.
- Portability also means supportin other cultures, regions and languages.
- Consider using a language more suited to the task (python, C#, etc. are easier than C++).
- Systems are becoming more secure (folders, ports etc.).
Brian Hook also has a POSH (Portable Open Source Harness) at http://hookatooka.com/poshlib/ that demonstrates some examples of portability and a good stepping stone for those looking at porting C++.
I think the book was useful it demonstrates a number of source code examples for his Simple Audio Library (SAL). Brian Hook also goes through a number of examples of the different standards including the IEEE 754, C8 and C99 standards, which are interesting to look at from a portability focus, and it would great if more books looked at the standards in their work.
Bye for now,
Michael Hubbard
http://michaelhubbard.ca
There are a number of rules for portability:
- Never assume anything (memory, size of built in types (int, float etc.)).
- The code will likely have to have non-portable elements to run efficiently.
- Establish a reasonable baseline of platforms, (not both PS3 and Commodore 64).
- Never read or write structures from memory or cast raw bytes to a structure.
- Always convert to or from a canonical format when moving data in or out of memory.
- Develop good habits and use tools and platforms that cooperate to strong practices.
- Avoid new langages or library features.
- Integrate testing.
- Use compile time assertions and strict compilations (avoid excessive conditional compilations).
- Write straightforward code.
- Understand anything can change between compilers (floating point can work different).
- Leverage portable third party libraries, but be careful.
- Performance and resource usage must be as portable as your features.
- Portability also means supportin other cultures, regions and languages.
- Consider using a language more suited to the task (python, C#, etc. are easier than C++).
- Systems are becoming more secure (folders, ports etc.).
Brian Hook also has a POSH (Portable Open Source Harness) at http://hookatooka.com/poshlib/ that demonstrates some examples of portability and a good stepping stone for those looking at porting C++.
I think the book was useful it demonstrates a number of source code examples for his Simple Audio Library (SAL). Brian Hook also goes through a number of examples of the different standards including the IEEE 754, C8 and C99 standards, which are interesting to look at from a portability focus, and it would great if more books looked at the standards in their work.
Bye for now,
Michael Hubbard
http://michaelhubbard.ca
Tuesday, August 2, 2011
Book Review: Godel, Escher, Bach: An Eternal Golden Braid
Godel, Escher, Bach: An Eternal Golden Braid by Douglas Hofstadter, is not really a programming book, but is a worthwhile book for those interested in math, logic, intelligence, patterns and recursion. The book is one worthy of reflecting on, and is thick with examples and clever insights, thought provoking questions and enough content and puzzles to make it worthy of a re-read later in life.
The book is broken up by dialogues between chapters, of conversations between the Tortoise and Achilles (a homage to the philosopher Zeno) , in which the Tortoise is usually teaching Achilles some paradox or life lesson, and allows the reader to both enjoy the wit and wordplay that goes on between the characters, and also learn the lesson alongside Achilles. There are other characters introduced as the chapters go on, each one bringing something new, or introducing a new topic or idea (just wait for the Crab).
Those who get stuck on the title, the book is not about a comparison of math, art and music, but rather examines the strange loops, patterns and paradoxes that exist in the universe. You may have heard of one of the most famous quotes when estimating deadlines, "Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law". The self-referencing nature, and recursive elements play a large theme of the book, and lead towards one of the main themes of the book, that of consciousness and self-awareness, existing from complex neurological mechanisms. The idea of some form of complexity built upon different forms of complexity, suggests the building blocks of conciousness stem from the underlying mechanics.
The main example of the theme of consciousnessis is Hofstadter's example of the ant hill. The ants themselves exist as individuals but are also part of a much larger network, were each individual ant becomes part of a larger collective "consciousness". The ant hill as a whole is able to adapt to conditions in ways that an individual ant could not, and allows for better survival of the entire group. The ant hill, in essence is a consciousness made up of a collection of other consciousness, in some ways similar to the human brain is made up of neurons which have simpler functionality than the brain as a whole.
Do not let the book size be too daunting, I think those who start reading the first couple chapters will likely want to see it through, it will take some time, as the book is large and thick with examples and thought provoking content, if you don't think you will like it now, come back to it in ten years and try it than.
Recursion is a wonderful thing,
Michael Hubbard
http://michaelhubbard.ca
The book is broken up by dialogues between chapters, of conversations between the Tortoise and Achilles (a homage to the philosopher Zeno) , in which the Tortoise is usually teaching Achilles some paradox or life lesson, and allows the reader to both enjoy the wit and wordplay that goes on between the characters, and also learn the lesson alongside Achilles. There are other characters introduced as the chapters go on, each one bringing something new, or introducing a new topic or idea (just wait for the Crab).
Those who get stuck on the title, the book is not about a comparison of math, art and music, but rather examines the strange loops, patterns and paradoxes that exist in the universe. You may have heard of one of the most famous quotes when estimating deadlines, "Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law". The self-referencing nature, and recursive elements play a large theme of the book, and lead towards one of the main themes of the book, that of consciousness and self-awareness, existing from complex neurological mechanisms. The idea of some form of complexity built upon different forms of complexity, suggests the building blocks of conciousness stem from the underlying mechanics.
The main example of the theme of consciousnessis is Hofstadter's example of the ant hill. The ants themselves exist as individuals but are also part of a much larger network, were each individual ant becomes part of a larger collective "consciousness". The ant hill as a whole is able to adapt to conditions in ways that an individual ant could not, and allows for better survival of the entire group. The ant hill, in essence is a consciousness made up of a collection of other consciousness, in some ways similar to the human brain is made up of neurons which have simpler functionality than the brain as a whole.
Do not let the book size be too daunting, I think those who start reading the first couple chapters will likely want to see it through, it will take some time, as the book is large and thick with examples and thought provoking content, if you don't think you will like it now, come back to it in ten years and try it than.
Recursion is a wonderful thing,
Michael Hubbard
http://michaelhubbard.ca
Sunday, July 24, 2011
Book Review: Starting a Successful Business in Canada KIT
Disclaimer: Laws are constantly changing and this blog post makes no representations or warranties of the outcomes or results of using information in this post. The author of this post and source information will not assume any liability for any claims, losses or damages from the use of this information.
Sorry for that wordy disclaimer, but it would be a real shame if something that was meant to spark people's interest was used as anything else. The reason for this post is that something that I feel a lot of developers do not spend enough time with is learning parts of a business. If you are smart enough to to develop complex games, you should be able to know as much about a business as someone who sets up a hotdog stand (by the way I do like those guys a lot, and only meant as an example of the complexity of creating the final product).
The book Starting a Successful Business in Canada KIT 18th edition by Jack D. James. MBA, LLB is one of the first business type books I have read outside of a few business books for courses I took in university. James recommends developing a business for things you are passionate about as a business can quickly eat up a ton of your time. If you do not have an interest in what you are doing, you are less likely to continue and pursue through the hardtimes.
There are some useful techniques in setting up your business:
Constantly re-evaluate your business process, if you are doing minor tasks to make your business run (like repairs, tools etc.) consider expanding your business (James example was with boats, if you rent boats and motors, and spend a lot of time fixing the motors, you should also consider buying broken motors and fix them to rent or sell as part of your business).
Keep copies of everything, keep all your receipts, print outs, photocopies of cheques received for payment, bills, tax information. There is lots of software to help get organized, if you are finding it difficult to keep track yourself.
Before starting a business do a break-even analysis, which is:
Total Costs = Variable Costs + Fixed Costs
Fixed Costs are things you can not get away from (rent, insurance, salaries, equipment, etc.)
Variable Costs are any additional costs it takes to create a sellable unit (material, labour, etc.)
The goal of the break-even analysis is to see how much you have to sell to break even, everything above that is profit, everything below that is a loss and worth re-evaluating how if the business will make money.
There are multiple setups for creating a business Proprietorship, Partnership and a Limited Company (or Corporation). After reading the pros and cons (and though I am not a lawyer) it seems like almost everyone would recommend a Limited Company. It is a little bit more money to get started, but offers a lot more protection to you as an individual (unless you have signed a personal guarantee). The difference is, with a sole Proprietorship you and your business are considered "one entity" and can not easily be sold or transfered, may not be eligible for government loans and creditors can go after your personal assets (house, car, etc.) if your business is being sued. With a limited company the corporation exists as a separate legal entity and also offers better government tax considerations, and is eligible for government funding, can be sold, and is generally perceived as having more status in the marketplace.
There are a number of requirements that you should be aware of, they may include any or all of the following.
All Businesses:
Registering for GST (to recover money spent on business purchases).
Privacy Acts (acts for collecting personal information of clients)
Sales Tax (tax on all tangible personal property that is purchased or imported)
Patents (trademarks, copyright etc.)
Product Standards (CSA approved)
Manufacturing:
Licenses (loan money, handle food, transport items, manufacture, modify natural resources etc.)
Federal excise tax (for any manufacturing)
Custom duties (if dealing with imports and exports).
Employer:
Federal income tax (if you are an employer, need to handle the income deductions)
Employment insurance (if youa re an employer and not a proprietor)
Canada Pension Plan (if you are an employer)
Of course there is more to it, but it is likely that if you are a game programmer (potentially an indie programmer of one), you may not have to worry about the employer aspects or many of the manufacturing elements, but it is still worth while to have some knowledge of what is involved. All in all, if you need more advice consult a lawyer or accountant, they will likely help set you in the right direction. There are some tax benefits you can look at (even working from home), but you will have to do a bit more research on this part of it.
Fortunately there is lots of support the Business Development Bank of Canada (BDC) offers a wide range of services for all stages of business http://www.bdc.ca/. Canada Business Service Centers offers information about government services and programs: http://canadabusiness.ca/
All I am saying, is that do not be afraid of something that millions of people already do: http://www.ic.gc.ca/eic/site/sbrp-rppe.nsf/eng/h_rd01252.html. I'm not saying go out and create a business now, but if you have that next great idea, do not let the unknown fear of "what is a business" stop you. Sure, if you have never done something like this before it is a little out of your element, but like everything it will become second nature with a bit of knowledge and practice. You can even check out the information involced online: http://www.cra-arc.gc.ca/tx/bsnss/tpcs/bn-ne/bro-ide/menu-eng.html (sorry international friends, I hope you can find a similar link).
Best of luck,
Michael Hubbard
http://michaelhubbard.ca
Sorry for that wordy disclaimer, but it would be a real shame if something that was meant to spark people's interest was used as anything else. The reason for this post is that something that I feel a lot of developers do not spend enough time with is learning parts of a business. If you are smart enough to to develop complex games, you should be able to know as much about a business as someone who sets up a hotdog stand (by the way I do like those guys a lot, and only meant as an example of the complexity of creating the final product).
The book Starting a Successful Business in Canada KIT 18th edition by Jack D. James. MBA, LLB is one of the first business type books I have read outside of a few business books for courses I took in university. James recommends developing a business for things you are passionate about as a business can quickly eat up a ton of your time. If you do not have an interest in what you are doing, you are less likely to continue and pursue through the hardtimes.
There are some useful techniques in setting up your business:
Constantly re-evaluate your business process, if you are doing minor tasks to make your business run (like repairs, tools etc.) consider expanding your business (James example was with boats, if you rent boats and motors, and spend a lot of time fixing the motors, you should also consider buying broken motors and fix them to rent or sell as part of your business).
Keep copies of everything, keep all your receipts, print outs, photocopies of cheques received for payment, bills, tax information. There is lots of software to help get organized, if you are finding it difficult to keep track yourself.
Before starting a business do a break-even analysis, which is:
Total Costs = Variable Costs + Fixed Costs
Fixed Costs are things you can not get away from (rent, insurance, salaries, equipment, etc.)
Variable Costs are any additional costs it takes to create a sellable unit (material, labour, etc.)
The goal of the break-even analysis is to see how much you have to sell to break even, everything above that is profit, everything below that is a loss and worth re-evaluating how if the business will make money.
There are multiple setups for creating a business Proprietorship, Partnership and a Limited Company (or Corporation). After reading the pros and cons (and though I am not a lawyer) it seems like almost everyone would recommend a Limited Company. It is a little bit more money to get started, but offers a lot more protection to you as an individual (unless you have signed a personal guarantee). The difference is, with a sole Proprietorship you and your business are considered "one entity" and can not easily be sold or transfered, may not be eligible for government loans and creditors can go after your personal assets (house, car, etc.) if your business is being sued. With a limited company the corporation exists as a separate legal entity and also offers better government tax considerations, and is eligible for government funding, can be sold, and is generally perceived as having more status in the marketplace.
There are a number of requirements that you should be aware of, they may include any or all of the following.
All Businesses:
Registering for GST (to recover money spent on business purchases).
Privacy Acts (acts for collecting personal information of clients)
Sales Tax (tax on all tangible personal property that is purchased or imported)
Patents (trademarks, copyright etc.)
Product Standards (CSA approved)
Manufacturing:
Licenses (loan money, handle food, transport items, manufacture, modify natural resources etc.)
Federal excise tax (for any manufacturing)
Custom duties (if dealing with imports and exports).
Employer:
Federal income tax (if you are an employer, need to handle the income deductions)
Employment insurance (if youa re an employer and not a proprietor)
Canada Pension Plan (if you are an employer)
Of course there is more to it, but it is likely that if you are a game programmer (potentially an indie programmer of one), you may not have to worry about the employer aspects or many of the manufacturing elements, but it is still worth while to have some knowledge of what is involved. All in all, if you need more advice consult a lawyer or accountant, they will likely help set you in the right direction. There are some tax benefits you can look at (even working from home), but you will have to do a bit more research on this part of it.
Fortunately there is lots of support the Business Development Bank of Canada (BDC) offers a wide range of services for all stages of business http://www.bdc.ca/. Canada Business Service Centers offers information about government services and programs: http://canadabusiness.ca/
All I am saying, is that do not be afraid of something that millions of people already do: http://www.ic.gc.ca/eic/site/sbrp-rppe.nsf/eng/h_rd01252.html. I'm not saying go out and create a business now, but if you have that next great idea, do not let the unknown fear of "what is a business" stop you. Sure, if you have never done something like this before it is a little out of your element, but like everything it will become second nature with a bit of knowledge and practice. You can even check out the information involced online: http://www.cra-arc.gc.ca/tx/bsnss/tpcs/bn-ne/bro-ide/menu-eng.html (sorry international friends, I hope you can find a similar link).
Best of luck,
Michael Hubbard
http://michaelhubbard.ca
Monday, July 18, 2011
Book Review: MEL Scripting a Character Rig in Maya
The book MEL Scripting a Character Rig In Maya by Chris Maraffi, is an intersting book on how to automate more of the rig creation (something I am a big fan of). Maraffi has a video describing his tools on youtube at http://www.youtube.com/watch?v=x4s6-ahJWvU. This is a good book for those interested in MEL scripting and rigging, and has some more advanced concepts (such as creating a full UI for the rigs and some tools to create and bind rigs to a mesh.
Overall, the majority of the book covers the creation of a basic FK rig to a more complex IK rig, with a lot of focus on MEL scripting and setting up the GUI. The end result is a very nice collection of controls and GUI elements to drive the character, as well as some neat more advanced controls/scripts for handling the character's breathing, eye jitter and stretchy spine.
While it would be ideal if the code base was in python instead of MEL, it is understandable that this is still the most popular Maya language. The code base works and has a lot of comments which will help the beginner, but is also fairly reliant on its own naming conventions, which also results in a lot of magic strings to keep the code together. I also feel that the code may have benefitted a little by being broken into smaller, simpler functions. There are a number of cases where a function seems to do a lot, and while it is easy enough for those with a developer background to understand, I always feel that fairly long functions are more difficult for the beginner to wrap their head around. The Maya GUI programming is pretty straight forward, it is easy for a Maya GUI script to get quite messy, but Maraffi does a prettty good job in keeping everything organized and logical with the GUI examples.
All in all, a good book and good examples and code base of rigging in Maya. I would recommend it to those interested in rigging and MEL script, although would recommend those following along with experience in python to look at converting the scripts to that instead.
I am really enjoying automated breathing in the rig, it is pretty cool.
Later,
Michael Hubbard
http://michaelhubbard.ca
Overall, the majority of the book covers the creation of a basic FK rig to a more complex IK rig, with a lot of focus on MEL scripting and setting up the GUI. The end result is a very nice collection of controls and GUI elements to drive the character, as well as some neat more advanced controls/scripts for handling the character's breathing, eye jitter and stretchy spine.
While it would be ideal if the code base was in python instead of MEL, it is understandable that this is still the most popular Maya language. The code base works and has a lot of comments which will help the beginner, but is also fairly reliant on its own naming conventions, which also results in a lot of magic strings to keep the code together. I also feel that the code may have benefitted a little by being broken into smaller, simpler functions. There are a number of cases where a function seems to do a lot, and while it is easy enough for those with a developer background to understand, I always feel that fairly long functions are more difficult for the beginner to wrap their head around. The Maya GUI programming is pretty straight forward, it is easy for a Maya GUI script to get quite messy, but Maraffi does a prettty good job in keeping everything organized and logical with the GUI examples.
All in all, a good book and good examples and code base of rigging in Maya. I would recommend it to those interested in rigging and MEL script, although would recommend those following along with experience in python to look at converting the scripts to that instead.
I am really enjoying automated breathing in the rig, it is pretty cool.
Later,
Michael Hubbard
http://michaelhubbard.ca
Sunday, May 8, 2011
Book Review: Game Programming Golden Rules
The Game Programming Golden Rules by Martin Brownlow offers nine chapters on various game programming topics. For this review I will go through the chapters with a brief comment on each of them.
1. Embracing C++: This chapter is all about using the compiler to your advantage, the preprocessor, macros and other C++ goodies that are not so much game specific and it is making sure you know the language you are working in, and how best to save you time.
2. Orders of Complexity: Some Big O notations, Self Balancing Binary Trees, Red Black Trees, and Binary Space Partitioning (BSP) Trees.
3. Hashtables: Including creating hashtables and hash functions, reducing hash collision frequency, file name hashes, and probably the most interesting part of this chapter DNA hash for vertex shaders. Localization of text assets was also in this chapter, although I think that for a large game, an approach that used key value pairs in the same file is more maintainable than having the keys and values in separate file, since if a file gets very long it will be difficult for the person writing it (often more proficient in language than coding) to debug why the lines are not matching up properly.
4. Scripting: Creating your own scripting language with some sub rules: scripts should be easy to create, scripts should never crash the game, scripts should be dynamically loaded, scripts should handle multitasking, scripts should have a debugger, scripts should be extendable, scripts should never break the game build.
5. The Resource Pipeline: Handles some of the resource pipeline tools, similar to the Game Asset Pipeline book, suggests an intermediate format for all assets that the artists create, that has everything possible that you can think to include in the intermediate format (version numbers, dates, authors, etc.). The book also focuses on some file compression, platform differences, and cummulates in a version of a build assistant (called DataCon by Brownlow), which is a simple example of what should be the case for all development teams, a one-click build system.
6. Processing Assets: Includes, fonts, images, geometry and creating triangle strips.
7. Finite State Machines: Explicit vs. implicit state machines, scripting FSMs, creating combos, linking FSM objects, indirect animation lookups to allow the same FSM to be used for each character type (with different animations).
8. Saving Game State: The difficulties of saving game state, saving and loading a game and autodetecting object changes with a saving template.
9. Optimization: Measure Twice, Cut Once, using profilers, realizing that some optimizations do not actually improve the overall process, since all the moving parts can actually make it slower.
Overall the book was interesting, although a lot of the techniques I think could apply to any field and are not just game specific. I think this book would be good for beginners to intermediate and the source code that is provided is pretty clear for the examples.
Happy coding,
Michael Hubbard
http://michaelhubbard.ca
1. Embracing C++: This chapter is all about using the compiler to your advantage, the preprocessor, macros and other C++ goodies that are not so much game specific and it is making sure you know the language you are working in, and how best to save you time.
2. Orders of Complexity: Some Big O notations, Self Balancing Binary Trees, Red Black Trees, and Binary Space Partitioning (BSP) Trees.
3. Hashtables: Including creating hashtables and hash functions, reducing hash collision frequency, file name hashes, and probably the most interesting part of this chapter DNA hash for vertex shaders. Localization of text assets was also in this chapter, although I think that for a large game, an approach that used key value pairs in the same file is more maintainable than having the keys and values in separate file, since if a file gets very long it will be difficult for the person writing it (often more proficient in language than coding) to debug why the lines are not matching up properly.
4. Scripting: Creating your own scripting language with some sub rules: scripts should be easy to create, scripts should never crash the game, scripts should be dynamically loaded, scripts should handle multitasking, scripts should have a debugger, scripts should be extendable, scripts should never break the game build.
5. The Resource Pipeline: Handles some of the resource pipeline tools, similar to the Game Asset Pipeline book, suggests an intermediate format for all assets that the artists create, that has everything possible that you can think to include in the intermediate format (version numbers, dates, authors, etc.). The book also focuses on some file compression, platform differences, and cummulates in a version of a build assistant (called DataCon by Brownlow), which is a simple example of what should be the case for all development teams, a one-click build system.
6. Processing Assets: Includes, fonts, images, geometry and creating triangle strips.
7. Finite State Machines: Explicit vs. implicit state machines, scripting FSMs, creating combos, linking FSM objects, indirect animation lookups to allow the same FSM to be used for each character type (with different animations).
8. Saving Game State: The difficulties of saving game state, saving and loading a game and autodetecting object changes with a saving template.
9. Optimization: Measure Twice, Cut Once, using profilers, realizing that some optimizations do not actually improve the overall process, since all the moving parts can actually make it slower.
Overall the book was interesting, although a lot of the techniques I think could apply to any field and are not just game specific. I think this book would be good for beginners to intermediate and the source code that is provided is pretty clear for the examples.
Happy coding,
Michael Hubbard
http://michaelhubbard.ca
Sunday, May 1, 2011
Book Review: The Game Asset Pipeline
The Game Asset Pipeline by Ben Carter is interesting in that it is probably one of the only books out there on asset pipelines for games. The books is broken into too major parts: high level asset management, and low level processing details. Overall, the book handles these issues effectively and with some interesting insight into pipeline work in general.
Carter suggests a number of useful tips for those working on a asset pipeline. The output of all systems should be a custom intermediate file format. This will allow the intermediate files to be processed and transformed into final assets without the need to re-export all of the assets from the 3D applications (or other tools). By having them as simple text files, it will also allow any additional last minute processes, without the huge overhead of having to re-export from multiple tools (especially since the end format is likely to change). Since ideally the format should be as close as possible to what will actually be contained in memory while the game is running, the intermediate format can allow for processing into the final assets, without having to constantly re-export the same assets everytime the end file format changes (and it likely will a lot, especially at the end). Also the tools should do as much preprocessing as possible to ensure speed at game runtime.
The eternal debate of text vs binary files is also brought up in the book. It is recommended that text files are used (although binary can be brought in later if necessary), but more so than just using text files, is the idea of text files with an implicit structure. If a text file has no structure such as:
It becomes very difficult to add things in and the parser will likely be confusing since it is expecting things in a certain order. A much better approach is to have the structure built into the file such as:
With that kind of approach it is much easier to see what the structure is, and with a parser of this type, things can be added, reordered or removed without issue (such as if the AIType does not have to be set or whatever). A still better approach to the plain text file is some sort of structured file format like XML or JSON. While I like JSON for most things, as it closely resembles data structures, it is important to note that once you start getting into very large files, it becomes trickier to navigate all the closing brackets in JSON, whereas XML gives all the end tags which is somewhat easier to navigate. Both are entirely capable of getting the job done, but it is best to look at what languages you are using and what kind of support they have for parsing (C# and XML go hand in hand, as do more web languages like Javascript with JSON).
Carter continues with some of the high level asset management and that it is different than source control (although there are some basic similarities, the size of the assets, the number of binary files, etc.) makes for different challenges in an asset management system. The most important aspect of an asset management system are turnaround time, metadata about the assets, versioning and handling broken data. The book looks at a number of subversion systems including SVN, Perforce, CVS and Alienbrain. The use of databases (like MySQL or Oracle) are not usually the best options unless the database is setup to allow for huge file sizes.
The concepts of a client/server architecture for the asset management system is essential, and should support locking and unlocking files, versioning of files, preview functionality, showing modifications and some sort of caching system to improve performance.
The rest of the book is on more low level details such as texture, geometry, environment processing, asset dependency analysis and final data output. It is interesting, but is more platform specific than the high level concepts on asset management in the earlier chapters. In some ways, I would have preferred more of an expansion on the asset pipeline aspects and less on the low-level details (perhaps splitting up the two major topics into two separate books and get everyone to buy both :P)
Overall a good book on many of the concepts of the asset pipeline for those not familar, and is a good resource on a topic with not a lot of literature on it.
Bye for now,
Michael Hubbard
http://michaelhubbard.ca
Carter suggests a number of useful tips for those working on a asset pipeline. The output of all systems should be a custom intermediate file format. This will allow the intermediate files to be processed and transformed into final assets without the need to re-export all of the assets from the 3D applications (or other tools). By having them as simple text files, it will also allow any additional last minute processes, without the huge overhead of having to re-export from multiple tools (especially since the end format is likely to change). Since ideally the format should be as close as possible to what will actually be contained in memory while the game is running, the intermediate format can allow for processing into the final assets, without having to constantly re-export the same assets everytime the end file format changes (and it likely will a lot, especially at the end). Also the tools should do as much preprocessing as possible to ensure speed at game runtime.
The eternal debate of text vs binary files is also brought up in the book. It is recommended that text files are used (although binary can be brought in later if necessary), but more so than just using text files, is the idea of text files with an implicit structure. If a text file has no structure such as:
Fred
Solider
Aggressive
1000It becomes very difficult to add things in and the parser will likely be confusing since it is expecting things in a certain order. A much better approach is to have the structure built into the file such as:
CharacterName = Fred
CharacterType = Soldier
AIType = Aggresive
HitPoints = 1000With that kind of approach it is much easier to see what the structure is, and with a parser of this type, things can be added, reordered or removed without issue (such as if the AIType does not have to be set or whatever). A still better approach to the plain text file is some sort of structured file format like XML or JSON. While I like JSON for most things, as it closely resembles data structures, it is important to note that once you start getting into very large files, it becomes trickier to navigate all the closing brackets in JSON, whereas XML gives all the end tags which is somewhat easier to navigate. Both are entirely capable of getting the job done, but it is best to look at what languages you are using and what kind of support they have for parsing (C# and XML go hand in hand, as do more web languages like Javascript with JSON).
Carter continues with some of the high level asset management and that it is different than source control (although there are some basic similarities, the size of the assets, the number of binary files, etc.) makes for different challenges in an asset management system. The most important aspect of an asset management system are turnaround time, metadata about the assets, versioning and handling broken data. The book looks at a number of subversion systems including SVN, Perforce, CVS and Alienbrain. The use of databases (like MySQL or Oracle) are not usually the best options unless the database is setup to allow for huge file sizes.
The concepts of a client/server architecture for the asset management system is essential, and should support locking and unlocking files, versioning of files, preview functionality, showing modifications and some sort of caching system to improve performance.
The rest of the book is on more low level details such as texture, geometry, environment processing, asset dependency analysis and final data output. It is interesting, but is more platform specific than the high level concepts on asset management in the earlier chapters. In some ways, I would have preferred more of an expansion on the asset pipeline aspects and less on the low-level details (perhaps splitting up the two major topics into two separate books and get everyone to buy both :P)
Overall a good book on many of the concepts of the asset pipeline for those not familar, and is a good resource on a topic with not a lot of literature on it.
Bye for now,
Michael Hubbard
http://michaelhubbard.ca
Friday, April 22, 2011
Book Review: Game Engine Toolset Development
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
Friday, April 1, 2011
Book Review: Python Developer Handbook
A worthwhile tome of knowledge, Python Developer's Handbook by Andre Lessa is a good introduction to Python in all forms. While it does not deal with Python 3.X it still gives quite a lot of examples about how complete python is as a language, and how useful it is for tools. As one of the big three languages used by Google, one of the most popular languages in academia, API implementations for some of the big 3D tools (Maya, Blender, Fusion, etc.) and one of the most talked about languages in the world http://langpop.com/ Python is likely going to be around for a while.
For those that don't know, Python is also named after Monty Python (the greatest sketch comedy show and some of my favorite movies of all time), and throughout the book (as is Python tradition) to use examples from the sketches as part of the fun. Such as:
The development tools mentioned in the book are IDLE, but I would recommend Eclipse + Pydev as the way to go. Pydev is a great IDE, and the debugging options from Eclipse are really great.
I use Python for creation of tools, Maya API scripts, and more, but learning more of the networking tools makes for a more complete game programmer/technical artist :)
Bye for now,
Michael Hubbard
http://michaelhubbard.ca
For those that don't know, Python is also named after Monty Python (the greatest sketch comedy show and some of my favorite movies of all time), and throughout the book (as is Python tradition) to use examples from the sketches as part of the fun. Such as:
print "I'm a lumberjack and I'm ok!"The book start with the basic syntax, exception handling, and object oriented programming and then moves to more advanced topis such as extending and embedding python, distribution, databases, and threads. There is a significant section on network programming, web development data manipulation with XML. The book covers both some higher level modules and lower level details. Along with the network programming is some information on GUI and graphic elements, as well as UI elements with Tkinter.
The development tools mentioned in the book are IDLE, but I would recommend Eclipse + Pydev as the way to go. Pydev is a great IDE, and the debugging options from Eclipse are really great.
I use Python for creation of tools, Maya API scripts, and more, but learning more of the networking tools makes for a more complete game programmer/technical artist :)
Bye for now,
Michael Hubbard
http://michaelhubbard.ca
Saturday, March 26, 2011
Book Review: The Practice of Programming
A good book for those just starting out or wanting to look at programming again with a fresh set of eyes, The Practice of Programming by Brian K. Kernighan and Rob Pike has a good approach to teaching programming. Instead of focusing on syntax or abstract concepts right from the get go, the book instead looks as programming as a disipline with concrete examples.
Things like thinking about style of the code you write (use short names for private local variables, longer more descriptive names for more public variables), being consistent with the work, using active names for functions, breaking up complex expressions and algorithms and data structures.
Probably the most interesting coverage of the book is the Markov chains program that is written in multiple languages C, C++, Java as well as some information of Awk and Perl. Seeing how the same functionality can be acheived in multiple languages is very informative, and the book shows how the transition and design changes with the language.
Some of the chapters on debugging are also great, and the advice and examples are useful for everyone. Also, really taking time to think about the code and what it is doing, even in a hectic fastpaced environment is very good advice, and sometimes gets lost in the pace of the moment.
Overall, it is a good book for beginners, easy to read and to the point (and not the size of a phone book like many computer books). I would recommend it to anyone with an interst in programming, especially those just starting out.
Cheers,
Michael Hubbard
http://michaelhubbard.ca
Things like thinking about style of the code you write (use short names for private local variables, longer more descriptive names for more public variables), being consistent with the work, using active names for functions, breaking up complex expressions and algorithms and data structures.
Probably the most interesting coverage of the book is the Markov chains program that is written in multiple languages C, C++, Java as well as some information of Awk and Perl. Seeing how the same functionality can be acheived in multiple languages is very informative, and the book shows how the transition and design changes with the language.
Some of the chapters on debugging are also great, and the advice and examples are useful for everyone. Also, really taking time to think about the code and what it is doing, even in a hectic fastpaced environment is very good advice, and sometimes gets lost in the pace of the moment.
Overall, it is a good book for beginners, easy to read and to the point (and not the size of a phone book like many computer books). I would recommend it to anyone with an interst in programming, especially those just starting out.
Cheers,
Michael Hubbard
http://michaelhubbard.ca
Thursday, March 24, 2011
Book Review: The Productive Programmer
An intersting book The Productive Programmer by Neal Ford has some great tips for the everyday and really brings out interesting concepts about the daily tasks of programming, as well as some good advice such as "Don't Shave Yaks"(where you can delve so far into a problem you end up solving everything but the problem) and YAGNI (You Ain't Gonna Need It).
The book focuses on useful tips, but really emphasizes reflecting on the kinds of stuff you do. If you begin to see ways of doing something better, you will look for it all around you. Things like, if you always have to navigate to the same directory over and over again, create a shortcut. If you open up the same files every morning, use an accelerator or automate that to do it for you. If you have to send the same email report every week, automate that too.
Probably my favorite idea from the book is "search trumps navigation". Anytime you have to find something, you waste both brain power and time when you have to look through folders or files to find the one you need. Instead, use tools to find what you need. For my Visual Studio friends, I always use ">of myFileName" in the search bar to get the name of the file (this quickly became the most popular way of searching to those I introduced it to at Ganz :P). This is a lot faster than having to search for that class or file through thousands of files. For those on Windows that really miss out on grep (Ford mentions cygwin) but I recommend giving Astrogrep a try http://astrogrep.sourceforge.net/ .It is free open source, allows regular expressions and displays the contents of the file (you will never go back to Windows Explorer for searching again).
Ford also focuses on aspects of eliminating distractions: turning off popup messages, using rooted views for a directory, and automating everything that usefully can be (interaction with websites, spreadsheets, rss feeds, build machines etc.). The later chapters focus on more code examples such as test driven development, source code analysis, as well as some philosophy and psychology applied to coding.
All and all a good book especially for the ideas it will bring about of how to improve your own productivity.
Best of luck,
Michael Hubbard
http://michaelhubbard.ca
The book focuses on useful tips, but really emphasizes reflecting on the kinds of stuff you do. If you begin to see ways of doing something better, you will look for it all around you. Things like, if you always have to navigate to the same directory over and over again, create a shortcut. If you open up the same files every morning, use an accelerator or automate that to do it for you. If you have to send the same email report every week, automate that too.
Probably my favorite idea from the book is "search trumps navigation". Anytime you have to find something, you waste both brain power and time when you have to look through folders or files to find the one you need. Instead, use tools to find what you need. For my Visual Studio friends, I always use ">of myFileName" in the search bar to get the name of the file (this quickly became the most popular way of searching to those I introduced it to at Ganz :P). This is a lot faster than having to search for that class or file through thousands of files. For those on Windows that really miss out on grep (Ford mentions cygwin) but I recommend giving Astrogrep a try http://astrogrep.sourceforge.net/ .It is free open source, allows regular expressions and displays the contents of the file (you will never go back to Windows Explorer for searching again).
Ford also focuses on aspects of eliminating distractions: turning off popup messages, using rooted views for a directory, and automating everything that usefully can be (interaction with websites, spreadsheets, rss feeds, build machines etc.). The later chapters focus on more code examples such as test driven development, source code analysis, as well as some philosophy and psychology applied to coding.
All and all a good book especially for the ideas it will bring about of how to improve your own productivity.
Best of luck,
Michael Hubbard
http://michaelhubbard.ca
Tuesday, March 15, 2011
Book Review: Taming the Tiger
An interesting book Taming the Tiger: The Struggle to Control Technology by Witold Rybczynski, is not a programming or art book, but rather an interesting reflection of technology throughout history. The book brings up some intersting concepts, man as the prostetic god (able to extend his reach, life, travel and abilities far beyond natural levels all through technology) and the idea of houses as a comfortable living machine that we stay reside in.
The book also includes how technology is prevades all aspects of our society. People who barely remember their highschool physics are require to take sides in the nuclear power debate, "the fragmenation of modern society and reduction of shared experiences means people form opinions on most subjects on the basis of second hand experiences" (Rybczynski, 26).
Rybczynski delves into a number of historical backlashes against technology (Captain Swing and the Luddites, industrial revolution risings, Ford assembly worker overturn etc.) and the inability to "rollback" technology once it has been introduced (only delaying the inevitable). There is also a lot on the "Shock of the Machine" and how cultures try to adapt to new technologies.
Rybczynski has some great quotes about how technology is intertwined with our own society it is difficult to talk about (or tame)."Part of the difficulty of taming the tiger is we can't see the animal clearly. It is easy to identify the boldly striped beast in a cage, but in the splotchy light of the jungle its colors become confused with background shadows. So too with technology. It is easy to discuss in isolation, but immersed in the opacity of human culture its outlines frequently become indistinguishable from its surroundings" (Rybczynski, 213).
"Just as we have discovered that we are a part of the natural environment, and not just surrounded by it, so also we will find that we are an intimate part of the environment of technology. The auxiliary "organs" that extend our sight, our hearing, and our thinking really are an extension of our physical bodies. When we are able to acept this, we shall discover that the struggle to control technology has all along been a struggle to control ourselves" (Rybczynski, 227).
Interesting stuff,
Michael Hubbard
http://michaelhubbard.ca
The book also includes how technology is prevades all aspects of our society. People who barely remember their highschool physics are require to take sides in the nuclear power debate, "the fragmenation of modern society and reduction of shared experiences means people form opinions on most subjects on the basis of second hand experiences" (Rybczynski, 26).
Rybczynski delves into a number of historical backlashes against technology (Captain Swing and the Luddites, industrial revolution risings, Ford assembly worker overturn etc.) and the inability to "rollback" technology once it has been introduced (only delaying the inevitable). There is also a lot on the "Shock of the Machine" and how cultures try to adapt to new technologies.
Rybczynski has some great quotes about how technology is intertwined with our own society it is difficult to talk about (or tame)."Part of the difficulty of taming the tiger is we can't see the animal clearly. It is easy to identify the boldly striped beast in a cage, but in the splotchy light of the jungle its colors become confused with background shadows. So too with technology. It is easy to discuss in isolation, but immersed in the opacity of human culture its outlines frequently become indistinguishable from its surroundings" (Rybczynski, 213).
"Just as we have discovered that we are a part of the natural environment, and not just surrounded by it, so also we will find that we are an intimate part of the environment of technology. The auxiliary "organs" that extend our sight, our hearing, and our thinking really are an extension of our physical bodies. When we are able to acept this, we shall discover that the struggle to control technology has all along been a struggle to control ourselves" (Rybczynski, 227).
Interesting stuff,
Michael Hubbard
http://michaelhubbard.ca
Wednesday, March 9, 2011
Book Review: Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects
A great book by Edward Yourdon, Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects. Being part of a crunch turned to death march projects, this book speaks volumes on the subject and is a worthwhile read (hopefully before you start on a project). For a death march project to occur, one or more project parameters exceed the norm by more than, 50%, time or resources needed that are not available results in a death march. Yourdon continues with the disturbing news that "Death projects are the norm, not the exception", even with the data that "the average project is likely to be 6 to 12 months behind schedule and 50 to 100 percent over budget."
How do death marches occur? The book describes a number of possible catalysts: company political reasons, naive promises made by marketing, senior executives or naive project managers, naive optimisim of youth (build any system over the weekend), "marine corps" mentality (no sleep necessary for "real programmers"), intense competetion, startup mentality, or unexpected crises. Yourdon stresses the political aspect as the most likely candidate of a death march. The politics can boder on the completely irrational: "Hysterial optimism, which is when everyone in the organization desperately wants to believe that a complex project, which has never been attempted before, but which has been realistically estimated to require three years of effort, can somehow be finished in nine months" (pg 10).
Why do people participate? High risk, high reward, naivete or optimism of youth, buzz of working closely together, Mt. Everest syndrome, alternative is unemployment, or revenge. The results are sacrifice personal health, mental health and personal relationships. I also talked about some of this in my post: http://gameprogrammertechnicalartist.blogspot.com/2011/01/why-do-people-crunch.html
If management expects time and budget to be padded they are expecting the estimation of schedules to be some "negotiating game", but is also likely to be some degree of naivete and lack of understanding of what really goes on. The owner of a death march is often a much higher-level manager than would be normal for the software project, usually with a long hierarchy of shareholders, stakeholders, project managers and customers in between and around. A long hierarchy often gets distorted on the way down to the project manager, where (on the way down) additional elements are tacked on to the message, bloating the project scope and timeline, with additional requirements, constraints and processes.
The major cause of death march projects is politics, often related to the negotiating games. Management always wants the enormous luxury of a promise of what something will cost, how long it will take and not have to worry about these factors, and also gives them a scapegoat for blame if the promise is broken. Senior management needs to share the burden of uncertainty and allow for changes at all levels, not bringing in someone for an on the spot estimate and building their entire project around something that has not been careful worked through. Always defer instant estimates, and always give +- estimates like 3 to 6 months, or 6 months +-50%
The book talks about four different categories for death marches:
High moral & High chance of success = Mission Impossible (a lot of hard work, but exciting)
Low moral & High chance of success = Ugly (marine corp mentality, whips cracking).
High moral & Low chance of success = Kamikaze (try and go out with one last hurrah)
Low moral & Low chance of success = Suicide (no alternative)
The interesting thing is that these values are all relative to the individual programmer. Some programmers may feel they are on a Suicide project, while others feel like the same project is a Mission Impossible one. People's commitment changes over time, almost always in a worse way.
Work has to be mutually beneficial, and if the threat of being fired or bypassed for a raise or promotion are common, then the strongest bargaining chip you have is displaying that you are ready to walk away from the relationship, if the results aren't mutually acceptable. Two specific issues that also have a significant impact on motivation, and which are usually under the manager's direct control: rewards and overtime. Bonuses are tricky and can backfire, at a startup with part of stock option available they may be a good modivation (like tens of thousands, or millions of dollars), support for the whole family, taxi service, grocery service, and helping to provide medical attention to the whole family. This costs money, but usually a very small amount. Give extended vacation (they will need it) not just a few days but extended period of time. Consider a paid sabbatical (6 months to just work on whatever they want it to be), and loaning project equipment.
The main focus of the dealing with death marches is "triage", where each task is separated into "must-do," "should-do," and "could-do" categories. After all the tasks have been separated, all work is done on the must-dos, then the should-dos and then the could-dos (if there is time). The idea behind this is if "80-20" rule holds true, the project team might be able to deliver 80 percent of the "benefit" of the system by implementing 20 percent of the requirements (if they implement the right 20 percent). Stephen Covey puts it in First Things First [I], "the main thing is to make sure that the main thing is the main thing."
Yourdon offers some other project manager tips as well.
- Project leaders should put in as many hours as possible to lead by example.
- Target 60-80 hours a week, but know your limits, everyone reaches a point of diminishing returns.
- Need to be trueful with the team, disillusioning to find out crucial information later.
- Make sure people are compatible.
- Show work in increments, but avoid prototypes which only perpetuate an illusion of completed work.
- Modifications to baseline requirements should be made public for all to see.
- Don't introduce new processes to a death march project.
At some point the death march is likely to reach an "ugly crisis" where it is shown that the project will not be completed on time, and the project manager is fired and replaced with a new project manager who is supposed to "get it out on time". The work-in-progress created by the project team before the "ugly crisis" occurs usually ends with the sad result of being thrown away: "The real reason why all of this partially-completed work ends up being wasted inventory is that no one will ever have time to come back to it. Assuming that the project team members (now under the control of a new manager, whom they may or may not respect) is able to deliver the "bare minimum" of critical functionality, they're usually so exhausted that half of them quit. And the users are so disgusted with the project that they never bother asking for the rest of the unfinished functionality; or conversely, they're so satisfied with the minimal functionality that they never bother asking for the rest of the system".
Even though everyone understands the issues intellectually, the political battles surrounding death march projects makes it almost impossible to reach a consensus on a reasonable triage. It's only when the "ugly crisis" occurs that the various parties finally agree on something that they should have agreed upon when the project began.
Try to focus on what works, not the process or methodology, or buracracy. Not to say not to have a process, since that can be a significant process, but be reflective of what works and what doesn't. Minimize number of tools needed, like a mountain climber, just bring the essentials.
Finally, Yourdon recommends quitting or leaving if it is a viable option, learning something new for less pay will make you a happier person. If any of these succeed, what is to say that they won't try it again? Some companies need to fail to see what they are capable of, hopefully it doesn't ruin the company. It is important to not measure the success of a project by the number of divorces, broken relationships and ulcers.
I have been part of a few death marches, and while a few can be bearable for a little while, in the long run you will almost always regret it. Avoid these types of projects if at all possible, everyone needs balance in their lives. If you find yourself on this type of project, the most important thing to remember is this: Life > Job
Best of luck,
Michael Hubbard
http://michaelhubbard.ca
P.S. Or if you prefer Life > Work (Life is greater than Work, for my non-programming friends), I should make it a t-shirt :P
How do death marches occur? The book describes a number of possible catalysts: company political reasons, naive promises made by marketing, senior executives or naive project managers, naive optimisim of youth (build any system over the weekend), "marine corps" mentality (no sleep necessary for "real programmers"), intense competetion, startup mentality, or unexpected crises. Yourdon stresses the political aspect as the most likely candidate of a death march. The politics can boder on the completely irrational: "Hysterial optimism, which is when everyone in the organization desperately wants to believe that a complex project, which has never been attempted before, but which has been realistically estimated to require three years of effort, can somehow be finished in nine months" (pg 10).
Why do people participate? High risk, high reward, naivete or optimism of youth, buzz of working closely together, Mt. Everest syndrome, alternative is unemployment, or revenge. The results are sacrifice personal health, mental health and personal relationships. I also talked about some of this in my post: http://gameprogrammertechnicalartist.blogspot.com/2011/01/why-do-people-crunch.html
If management expects time and budget to be padded they are expecting the estimation of schedules to be some "negotiating game", but is also likely to be some degree of naivete and lack of understanding of what really goes on. The owner of a death march is often a much higher-level manager than would be normal for the software project, usually with a long hierarchy of shareholders, stakeholders, project managers and customers in between and around. A long hierarchy often gets distorted on the way down to the project manager, where (on the way down) additional elements are tacked on to the message, bloating the project scope and timeline, with additional requirements, constraints and processes.
The major cause of death march projects is politics, often related to the negotiating games. Management always wants the enormous luxury of a promise of what something will cost, how long it will take and not have to worry about these factors, and also gives them a scapegoat for blame if the promise is broken. Senior management needs to share the burden of uncertainty and allow for changes at all levels, not bringing in someone for an on the spot estimate and building their entire project around something that has not been careful worked through. Always defer instant estimates, and always give +- estimates like 3 to 6 months, or 6 months +-50%
The book talks about four different categories for death marches:
High moral & High chance of success = Mission Impossible (a lot of hard work, but exciting)
Low moral & High chance of success = Ugly (marine corp mentality, whips cracking).
High moral & Low chance of success = Kamikaze (try and go out with one last hurrah)
Low moral & Low chance of success = Suicide (no alternative)
The interesting thing is that these values are all relative to the individual programmer. Some programmers may feel they are on a Suicide project, while others feel like the same project is a Mission Impossible one. People's commitment changes over time, almost always in a worse way.
Work has to be mutually beneficial, and if the threat of being fired or bypassed for a raise or promotion are common, then the strongest bargaining chip you have is displaying that you are ready to walk away from the relationship, if the results aren't mutually acceptable. Two specific issues that also have a significant impact on motivation, and which are usually under the manager's direct control: rewards and overtime. Bonuses are tricky and can backfire, at a startup with part of stock option available they may be a good modivation (like tens of thousands, or millions of dollars), support for the whole family, taxi service, grocery service, and helping to provide medical attention to the whole family. This costs money, but usually a very small amount. Give extended vacation (they will need it) not just a few days but extended period of time. Consider a paid sabbatical (6 months to just work on whatever they want it to be), and loaning project equipment.
The main focus of the dealing with death marches is "triage", where each task is separated into "must-do," "should-do," and "could-do" categories. After all the tasks have been separated, all work is done on the must-dos, then the should-dos and then the could-dos (if there is time). The idea behind this is if "80-20" rule holds true, the project team might be able to deliver 80 percent of the "benefit" of the system by implementing 20 percent of the requirements (if they implement the right 20 percent). Stephen Covey puts it in First Things First [I], "the main thing is to make sure that the main thing is the main thing."
Yourdon offers some other project manager tips as well.
- Project leaders should put in as many hours as possible to lead by example.
- Target 60-80 hours a week, but know your limits, everyone reaches a point of diminishing returns.
- Need to be trueful with the team, disillusioning to find out crucial information later.
- Make sure people are compatible.
- Show work in increments, but avoid prototypes which only perpetuate an illusion of completed work.
- Modifications to baseline requirements should be made public for all to see.
- Don't introduce new processes to a death march project.
At some point the death march is likely to reach an "ugly crisis" where it is shown that the project will not be completed on time, and the project manager is fired and replaced with a new project manager who is supposed to "get it out on time". The work-in-progress created by the project team before the "ugly crisis" occurs usually ends with the sad result of being thrown away: "The real reason why all of this partially-completed work ends up being wasted inventory is that no one will ever have time to come back to it. Assuming that the project team members (now under the control of a new manager, whom they may or may not respect) is able to deliver the "bare minimum" of critical functionality, they're usually so exhausted that half of them quit. And the users are so disgusted with the project that they never bother asking for the rest of the unfinished functionality; or conversely, they're so satisfied with the minimal functionality that they never bother asking for the rest of the system".
Even though everyone understands the issues intellectually, the political battles surrounding death march projects makes it almost impossible to reach a consensus on a reasonable triage. It's only when the "ugly crisis" occurs that the various parties finally agree on something that they should have agreed upon when the project began.
Try to focus on what works, not the process or methodology, or buracracy. Not to say not to have a process, since that can be a significant process, but be reflective of what works and what doesn't. Minimize number of tools needed, like a mountain climber, just bring the essentials.
Finally, Yourdon recommends quitting or leaving if it is a viable option, learning something new for less pay will make you a happier person. If any of these succeed, what is to say that they won't try it again? Some companies need to fail to see what they are capable of, hopefully it doesn't ruin the company. It is important to not measure the success of a project by the number of divorces, broken relationships and ulcers.
I have been part of a few death marches, and while a few can be bearable for a little while, in the long run you will almost always regret it. Avoid these types of projects if at all possible, everyone needs balance in their lives. If you find yourself on this type of project, the most important thing to remember is this: Life > Job
Best of luck,
Michael Hubbard
http://michaelhubbard.ca
P.S. Or if you prefer Life > Work (Life is greater than Work, for my non-programming friends), I should make it a t-shirt :P
Thursday, January 13, 2011
Book Review: Focus on 3D Terrain Programming
Short and to the point, Focus on 3D Terrain Programming by Trent Polack is a good introduction to some of the algorithms used for 3D terrains. The book works well in introducing the simplest forms and growing more and more complex. Starting with a simple brute force algorithm, it covers terrain generation of fractal terrain, geo-mipmapping and culling, creating a quadtree terrain engine, ROAM (Realtime Optimally Adapting Meshes) with some optimizations as well.
Along with the terrain it also covers loading and creating texture files associated with terrain including texture map generation, using detail maps, and light maps.
There are also a few lighting techniques: height based lighting, slope lighting and some simple graphics fx for water, skyboxes and skydomes, particles etc.
This is more of a focused primer, but really the source code is what makes this book really standout. The code is very well commented, and easy to understand, which works handily with the descriptions in the book.
All in all, if you haven't worked with terrains before this is a good starting point, with lots of C++ examples to learn from.
Best of luck building,
Michael Hubbard
http://michaelhubbard.ca
Along with the terrain it also covers loading and creating texture files associated with terrain including texture map generation, using detail maps, and light maps.
There are also a few lighting techniques: height based lighting, slope lighting and some simple graphics fx for water, skyboxes and skydomes, particles etc.
This is more of a focused primer, but really the source code is what makes this book really standout. The code is very well commented, and easy to understand, which works handily with the descriptions in the book.
All in all, if you haven't worked with terrains before this is a good starting point, with lots of C++ examples to learn from.
Best of luck building,
Michael Hubbard
http://michaelhubbard.ca
Sunday, December 12, 2010
Book Review: Peopleware
The book Peopleware:Productive Projects and Teams (2nd edition) by Tom Demarco and Timothy Lister should be required reading for anyone in charge of or working with software projects. So much of it is such good sense, and yet so much of it will make you shake your head and say "why are we still doing it like this?" If you feel like you are not being able to do work between 9-5, read this book.
Two of the major concepts in the book are teams "jelling" and programmer "flow".
A team "jelling" or coming together is so important and yet nearly impossible to plan for. Demarco and Lister mention that you can create a scenario for a team to jel, but it all depends on the people involved in whether or not the team comes together. There are however elements that can be "teamicide" or kill a team (defensive management, bureaucracy, physical separation, fragmentation of time, quality reduction of the product, phony deadlines, and clique control).
Some recommendations are to group people together. Groups usually go quiet at the same time, you want them to interact and trust each other. If they are not sitting together, they are more likely they will interact with people on other projects and become friends with them instead of the people on their team. Trust your people. Get the right people and turn them loose, hiring the right people is the most important thing. Develop a feeling of permanence, train people to go through the ranks, make it a place people are expected to stay, not just passing through.The authors use the imagery of a team like a choir (or visualize an orchestra), with everyone playing their part in a complex symphony of sound and harmony, which differs from the traditional example of a team like a sports team, which often only focuses on the star players. The book also talks about having "free electrons", people whose judgement and work ethic make the decisions they make better than those mangaging them. Which again comes down to trusting your team. If you are a bad manager (and aware of your shortcomings), the best thing you can do is hire the best people you can find and get out of their way, and try and avoid changing too much.
You want your team to work together, to not compete against each other and to be happy and productive... how that happens is always complex, because it depends on the individuals in your team, but making it work is your job as a leader.
The other element programmer "flow" and how work is like sleep, it is best done in long periods of silence with minimal interruptions. Try to minimize interrupting people, programmers (and all workers) need quiet time to think and concentrate. Even with music or white noise the programmer is not using their full mental capacity, which, while they are able to perform some logical function, still might not be able to perform or think as creatively. The book also focuses on noise, how lots of people packed into cubicles make a lot of noise (the smaller the space, the more noise they make) and that a PA system is almost insulting to the occupants in disrupting the masses in order to find one person.
The book talks a bit about the Capability Maturity Model (CMM) and how so many companies are in the lowest levels (often with no sign of improvement).
Another part of the book that struck a cord with me is the huge cost of turnover. Even if the chair stays warm with a new body coming in, they are less then useless the first day, and take other peoples time to get up to speed. If they are lucky it will be less than 2 years before they replaced a senior person, but there is still no guarantee they will "jell with the team, be as reliable as the previous person, or will even stay long enough to get up to speed that the previous employer was able to manage. The cost can be enormous for replacing people, if it takes six months to get up to speed an be productive coming into a project that has seven months left, you have paid someone seven months worth of pay for one month of good work. A quote from the book suggests it can be even higher than that: "One of our clients, a builder of network protocol analyzers and packet sniffers, estimates that it takes more than two years to bring a new worker up to speed (pg 207)."
The book also has the idea that there is a "slumbering giant" in a corporation, against sillyness, sharing the load of responsibility against problems and focusing on the never ending battle of how to improve the workplace. Hopefully he awakens soon.
"The ultimate management sin is wasting people's time (pg 215)."
Great book, get it for your loved (or not so loved) managers for Christmas :P
Michael Hubbard
http://michaelhubbard.ca
Two of the major concepts in the book are teams "jelling" and programmer "flow".
A team "jelling" or coming together is so important and yet nearly impossible to plan for. Demarco and Lister mention that you can create a scenario for a team to jel, but it all depends on the people involved in whether or not the team comes together. There are however elements that can be "teamicide" or kill a team (defensive management, bureaucracy, physical separation, fragmentation of time, quality reduction of the product, phony deadlines, and clique control).
Some recommendations are to group people together. Groups usually go quiet at the same time, you want them to interact and trust each other. If they are not sitting together, they are more likely they will interact with people on other projects and become friends with them instead of the people on their team. Trust your people. Get the right people and turn them loose, hiring the right people is the most important thing. Develop a feeling of permanence, train people to go through the ranks, make it a place people are expected to stay, not just passing through.The authors use the imagery of a team like a choir (or visualize an orchestra), with everyone playing their part in a complex symphony of sound and harmony, which differs from the traditional example of a team like a sports team, which often only focuses on the star players. The book also talks about having "free electrons", people whose judgement and work ethic make the decisions they make better than those mangaging them. Which again comes down to trusting your team. If you are a bad manager (and aware of your shortcomings), the best thing you can do is hire the best people you can find and get out of their way, and try and avoid changing too much.
You want your team to work together, to not compete against each other and to be happy and productive... how that happens is always complex, because it depends on the individuals in your team, but making it work is your job as a leader.
The other element programmer "flow" and how work is like sleep, it is best done in long periods of silence with minimal interruptions. Try to minimize interrupting people, programmers (and all workers) need quiet time to think and concentrate. Even with music or white noise the programmer is not using their full mental capacity, which, while they are able to perform some logical function, still might not be able to perform or think as creatively. The book also focuses on noise, how lots of people packed into cubicles make a lot of noise (the smaller the space, the more noise they make) and that a PA system is almost insulting to the occupants in disrupting the masses in order to find one person.
The book talks a bit about the Capability Maturity Model (CMM) and how so many companies are in the lowest levels (often with no sign of improvement).
Another part of the book that struck a cord with me is the huge cost of turnover. Even if the chair stays warm with a new body coming in, they are less then useless the first day, and take other peoples time to get up to speed. If they are lucky it will be less than 2 years before they replaced a senior person, but there is still no guarantee they will "jell with the team, be as reliable as the previous person, or will even stay long enough to get up to speed that the previous employer was able to manage. The cost can be enormous for replacing people, if it takes six months to get up to speed an be productive coming into a project that has seven months left, you have paid someone seven months worth of pay for one month of good work. A quote from the book suggests it can be even higher than that: "One of our clients, a builder of network protocol analyzers and packet sniffers, estimates that it takes more than two years to bring a new worker up to speed (pg 207)."
The book also has the idea that there is a "slumbering giant" in a corporation, against sillyness, sharing the load of responsibility against problems and focusing on the never ending battle of how to improve the workplace. Hopefully he awakens soon.
"The ultimate management sin is wasting people's time (pg 215)."
Great book, get it for your loved (or not so loved) managers for Christmas :P
Michael Hubbard
http://michaelhubbard.ca
Saturday, December 4, 2010
Book Review: Herb Schildt's C++ Programming Cookbook
Cookbook books are interesting in that they often cover a wide range of topis in a short amount of time and space. Herb Schildt's C++ Programming Cookbook, handles a number of topics including string handling, STL containers, I/O, formatting data, overloading operators like subscript, new and delete, the increment and decrement operators and the use of typeid for RTTI runtime type information. The book has some useful information, and is given in a clear and concise format, with code examples to help explain the details. The book has been structured to make finding things easy, and as is the case with most cookbooks, becomes useful as a reference for how to accomplish some task/functionality (as well as explainations of the steps and logic behind that approach).
This book is especially interesting for beginners, as it is carefully explained and gives thorough example code for a number of tasks. For more intermediate to advanced programmers there is likely a few tricks that are new or interesting too. I wouldn't say the book is targetted at beginners, but they will likely be the ones that benefit the most from this type of book. It is not the kind of book you want to learn your first basic programming techinques from, but provides a good reference along the way.
Keep on cooking that code,
Michael Hubbard
http://michaelhubbard.ca
This book is especially interesting for beginners, as it is carefully explained and gives thorough example code for a number of tasks. For more intermediate to advanced programmers there is likely a few tricks that are new or interesting too. I wouldn't say the book is targetted at beginners, but they will likely be the ones that benefit the most from this type of book. It is not the kind of book you want to learn your first basic programming techinques from, but provides a good reference along the way.
Keep on cooking that code,
Michael Hubbard
http://michaelhubbard.ca
Subscribe to:
Posts (Atom)