Happy 2011, how time flies. Hopefully I can get on here more with something cool.
Some blog related New Years Resolutions:
- Blog about cool (cooler?) things
- Update my website http://michaelhubbard.ca
- Try and get some more demos in the blog and code snippits.
- Explore more programming techniques, managment, graphics and more.
Lets see if I can make some of them work :)
Have a great year,
Michael Hubbard
http://michaelhubbard.ca
Saturday, January 1, 2011
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
Monday, November 22, 2010
Book Review: Essentials of Interactive Computer Graphics
Essentials of Interactive Computer Graphics by Kevin Sung, Peter Shirley, Steven Baer is a good book for theory of how to work in and with interactive graphics. Their chapters include things like event driven programming, model view controller architecture, GUI APIs and working with the graphics APIs. I especially liked how they brought in real world examples like dealing with 3D modeling packages (Maya), abstracting behaviour of game elements and the number of examples available.
The book is a mix of Direct X and OpenGL, but there are lots of examples that make it worthwhile. This book is targetted more for a beginner to intermediate, but I especially liked the concepts of event driven programming in a book about graphics. So often, I find programmers from other disciplines and backgrounds (with the exception of real-time programmers) are not as concerned with event driven programming. Often, in application programming event driven programming may only be used for GUI elements, which in most cases is all that is needed. In a game however, there are often a lot of elements (objects colliding, proximity triggers, network sync events etc.) that cause a lot of events to be happening simultaneously, and having a good grasp on how to deal with these events and design code to work with these events becomes very important.
Good book overall, especially for those new to the concepts (and hopefully everyone has at least heard of model-view-controller).
Best of luck,
Michael Hubbard
http://michaelhubbard.ca
The book is a mix of Direct X and OpenGL, but there are lots of examples that make it worthwhile. This book is targetted more for a beginner to intermediate, but I especially liked the concepts of event driven programming in a book about graphics. So often, I find programmers from other disciplines and backgrounds (with the exception of real-time programmers) are not as concerned with event driven programming. Often, in application programming event driven programming may only be used for GUI elements, which in most cases is all that is needed. In a game however, there are often a lot of elements (objects colliding, proximity triggers, network sync events etc.) that cause a lot of events to be happening simultaneously, and having a good grasp on how to deal with these events and design code to work with these events becomes very important.
Good book overall, especially for those new to the concepts (and hopefully everyone has at least heard of model-view-controller).
Best of luck,
Michael Hubbard
http://michaelhubbard.ca
Saturday, November 20, 2010
Unity 3.0 ShaderLab
Everybody loves shaders, and Unity's 3.X ShaderLab http://unity3d.com/support/documentation/Components/SL-Reference.html is interesting in what they have done (ShaderLab is similar to CgFX scripts, but unique to Unity).
Unity 3.X has updated their rendering model, and specifically changed how to write shaders for Unity 3.X. The newly structured surface shaders, which through a combination of ShaderLab syntax (often pragma settings) and Cg progamming language allowed shaders to be created that would work with both Unity's forward and deferred rendering lighting model. The pragma basics include the Lambert and BlinnPhong lighting models as well as more complex bump, cubemap and emission shader properties and logic. The Unite talk I went to also mentioned a specific “gotcha” related to Unity's use of the specular color, requiring the specular color parameter to be specifically named _SpecColor to allow Unity access to the separate specular highlight (this appears to be a hardcoded issue, but is different from the Unity 2.X standard).As a whole Unity is still rendering average scenes with minimal lights much faster in forward rendering (at least in the test scenes that I have been working with). The deferred rendering will likely be useful for very specialized scenes with lots of lights, but it is nice to have options.
Unfortunately the biggest issue for large scale projects is the incompatibility between Unity 2.X shaders and Unity 3.X. If you have written custom shaders, and have exported assetBundles using those shaders, you will have to rewrite the shader using Unity 3.X techniques and re-export all the assetBundles (hopefully you have an automated build process, for your assets to help with this, but not everyone will). If you notice assetBundles brought in with bright pink colors, it means that your shaders are incompatible and will need to be updated (which makes QA much easier on these assets).
Overall, there is not turning back, and you should strive ahead using Unity 3.X and all the other great features it has, the ShaderLab language is much simpler and will allow more artists to contribute their ideas for shaders and will greatly improve writing time and debugging of shaders in general. Still, would have been nice if the shaders were backwards compatible and not pink :P
Hopefully you have minimal pink,
Michael Hubbard
http://michaelhubbard.ca
Unity 3.X has updated their rendering model, and specifically changed how to write shaders for Unity 3.X. The newly structured surface shaders, which through a combination of ShaderLab syntax (often pragma settings) and Cg progamming language allowed shaders to be created that would work with both Unity's forward and deferred rendering lighting model. The pragma basics include the Lambert and BlinnPhong lighting models as well as more complex bump, cubemap and emission shader properties and logic. The Unite talk I went to also mentioned a specific “gotcha” related to Unity's use of the specular color, requiring the specular color parameter to be specifically named _SpecColor to allow Unity access to the separate specular highlight (this appears to be a hardcoded issue, but is different from the Unity 2.X standard).As a whole Unity is still rendering average scenes with minimal lights much faster in forward rendering (at least in the test scenes that I have been working with). The deferred rendering will likely be useful for very specialized scenes with lots of lights, but it is nice to have options.
Unfortunately the biggest issue for large scale projects is the incompatibility between Unity 2.X shaders and Unity 3.X. If you have written custom shaders, and have exported assetBundles using those shaders, you will have to rewrite the shader using Unity 3.X techniques and re-export all the assetBundles (hopefully you have an automated build process, for your assets to help with this, but not everyone will). If you notice assetBundles brought in with bright pink colors, it means that your shaders are incompatible and will need to be updated (which makes QA much easier on these assets).
Overall, there is not turning back, and you should strive ahead using Unity 3.X and all the other great features it has, the ShaderLab language is much simpler and will allow more artists to contribute their ideas for shaders and will greatly improve writing time and debugging of shaders in general. Still, would have been nice if the shaders were backwards compatible and not pink :P
Hopefully you have minimal pink,
Michael Hubbard
http://michaelhubbard.ca
Sunday, November 14, 2010
Unite 10
I was at Unity's UNITE conference in Montreal, and it was both informative and fun http://unity3d.com/unite/ UNITE is an annual conference to showcase and educate users and developers using Unity technologies. This conference is the largest annual Unity developer conference and is the tenth such conference. UNITE is often the platform Unity uses to announce new releases and features, as well as gain feedback and interact with the Unity developers.
Unity appears to be gaining popularity with more mainstream game and interactive media companies. They have begun to announce more pronounced companies such as EA, Disney, Marvel and Nokia developing software using Unity. Unity has currently carved out a niche market with its attempt to support as large a range of platforms as possible (mobile devices to high end consoles) and have attracted more attention because of this business model. With fiercer competition in the game and web/browser market it is important to get additional training and knowledge directly from the source.
The conference allowed developers to have one-on-one talks with the Unity developers as well as see demos of competing vendors and hear about alternative implementations and solutions for development problems. The networking opportunities also provide us additional information about how Unity is being used.
The main keynote presentation was broken into two main parts. The first part was a talk by David Helgason (CEO of Unity Technologies) and Brett Seyler, who presented information about some current Unity stats and upcoming Unity enhancements (of course mentioning the release of Unity 3.1). The information provided included the current number of Unity plugins installed at 40 million, and over one thousand iPhone games produced using Unity's iPhone license (including some top selling games). Helgason also showed Unity's commitment to the indie market with what would become the common phrase of the conference “democratization” which when used by the Unity team, described a philosophy of providing more large scale production tools and options to indie developers. The major democratization addition was the Unity Asset Store, which allows developers to buy, sell and share content through the Unity editor (similar to the Apple App Store, but embedded in the editor) The focus on the indie developer can also be seen in the announcement of the Unity Union, which allows companies to get into a contractual agreement with Unity to provide custom licenses and options for developing Unity game on a platform currently not supported by Unity (such as the Nokia phones).
The second part of the talk was by Jesse Schell a game designer (previously a creative director at Disney's virtual imagineering studio) but the focus of Schell's talk was not specific to Unity, but mroe on game character's and virtual characters. Schell provided a of his predictions on the direction of game and character interaction, including a focus on: facial expression tracking; persistent databases; speech recognition; natural language understanding; emotion sensing; integrated multi-platform games; interface to everything; cognitive tutors; intelligent actors; and augmented reality. Schell also mentioned that he is doing work on ‘The Mummy Online’ in collaboration with Universal and Bigpoint for launch in Winter 2010.
I learned some new things about Unity and how it was used, although much of the conference was focused on the high level introduction, and since I have been using Unity since 2007 in many forms (Mac, PC, Unity source code, web and iPhone) I would have liked to have had a bit more indepth approach about the low-level details.
A number of talks were focused on developing tools for Unity that more commercial engines (such as Unreal or the Hero engine) already have and maintain. It did not appear that many companies were using Unity for large scale MMOs (outside of the mention of the upcoming Mummy MMORPG) and Unity's immediate focus still appears to be indie (over large scale commercial) support.
I really enjoy Unity and feel like the company has a bright future, with Unity 3.X and their support for consoles, more and more companies will look to Unity as their potential engine. As always, it is so important to use the right tool for the job, and I can't stress that enough. Unity covers a wide range of options, and feel like it is a great engine to use for an indie to intermediate sized project. Unity has a great and helpful community and you can make some fun games. It is always worthwhile in doing your homework on any engine, and look at what kinds of games are produced, and make sure that these are the approximate types of results you would expect. One caveat though, Unity also deals with some additional licenses for undocumented features which may give other companies a competitive advantage, some other companies also purchase the Unity source code and develop their own plugin that gives them additional features that do not exist "out of the box". There are some fun games and applications made with Unity, and I wish you best of luck with yours.
Unite Montreal,
Michael Hubbard
http://michaelhubbard.ca
Unity appears to be gaining popularity with more mainstream game and interactive media companies. They have begun to announce more pronounced companies such as EA, Disney, Marvel and Nokia developing software using Unity. Unity has currently carved out a niche market with its attempt to support as large a range of platforms as possible (mobile devices to high end consoles) and have attracted more attention because of this business model. With fiercer competition in the game and web/browser market it is important to get additional training and knowledge directly from the source.
The conference allowed developers to have one-on-one talks with the Unity developers as well as see demos of competing vendors and hear about alternative implementations and solutions for development problems. The networking opportunities also provide us additional information about how Unity is being used.
The main keynote presentation was broken into two main parts. The first part was a talk by David Helgason (CEO of Unity Technologies) and Brett Seyler, who presented information about some current Unity stats and upcoming Unity enhancements (of course mentioning the release of Unity 3.1). The information provided included the current number of Unity plugins installed at 40 million, and over one thousand iPhone games produced using Unity's iPhone license (including some top selling games). Helgason also showed Unity's commitment to the indie market with what would become the common phrase of the conference “democratization” which when used by the Unity team, described a philosophy of providing more large scale production tools and options to indie developers. The major democratization addition was the Unity Asset Store, which allows developers to buy, sell and share content through the Unity editor (similar to the Apple App Store, but embedded in the editor) The focus on the indie developer can also be seen in the announcement of the Unity Union, which allows companies to get into a contractual agreement with Unity to provide custom licenses and options for developing Unity game on a platform currently not supported by Unity (such as the Nokia phones).
The second part of the talk was by Jesse Schell a game designer (previously a creative director at Disney's virtual imagineering studio) but the focus of Schell's talk was not specific to Unity, but mroe on game character's and virtual characters. Schell provided a of his predictions on the direction of game and character interaction, including a focus on: facial expression tracking; persistent databases; speech recognition; natural language understanding; emotion sensing; integrated multi-platform games; interface to everything; cognitive tutors; intelligent actors; and augmented reality. Schell also mentioned that he is doing work on ‘The Mummy Online’ in collaboration with Universal and Bigpoint for launch in Winter 2010.
I learned some new things about Unity and how it was used, although much of the conference was focused on the high level introduction, and since I have been using Unity since 2007 in many forms (Mac, PC, Unity source code, web and iPhone) I would have liked to have had a bit more indepth approach about the low-level details.
A number of talks were focused on developing tools for Unity that more commercial engines (such as Unreal or the Hero engine) already have and maintain. It did not appear that many companies were using Unity for large scale MMOs (outside of the mention of the upcoming Mummy MMORPG) and Unity's immediate focus still appears to be indie (over large scale commercial) support.
I really enjoy Unity and feel like the company has a bright future, with Unity 3.X and their support for consoles, more and more companies will look to Unity as their potential engine. As always, it is so important to use the right tool for the job, and I can't stress that enough. Unity covers a wide range of options, and feel like it is a great engine to use for an indie to intermediate sized project. Unity has a great and helpful community and you can make some fun games. It is always worthwhile in doing your homework on any engine, and look at what kinds of games are produced, and make sure that these are the approximate types of results you would expect. One caveat though, Unity also deals with some additional licenses for undocumented features which may give other companies a competitive advantage, some other companies also purchase the Unity source code and develop their own plugin that gives them additional features that do not exist "out of the box". There are some fun games and applications made with Unity, and I wish you best of luck with yours.
Unite Montreal,
Michael Hubbard
http://michaelhubbard.ca
Thursday, November 4, 2010
Book Review: The Art of Concurrency
One of the books I picked up recently is The Art of Concurrency A Thread Monkey's Guide to Writing Parallel Applications by Clay Breshears. The book itself is an interesting read, and Breshears is a funny writer, I especially liked the quote: "No evil threads, just threads programmed for evil". He also had some interesting examples, one especially vivid example of how code can interact was to think of two hands as threads, each finger as a line of code and how many different arrangements those fingers can be intertwined when clasping your hands together.
Breshears mentions threading as the future of applications, with multicore becoming more and more popular, and concurrent programming eventually becoming the norm for everything wanting to take advantage of all these additional processors.
The book talks about approaching concurency and threading with eight simple rules:
1. Identify Truly Independent Computations.
2. Implement Concurrency at the Highest Level Possible.
3. Plan Early for Scalability to Take Advantage of Increasing Numbers of Cores.
4. Make Use of Thread Safe Libraries Whenever Possible.
5. Use the Right Threading Model.
6. Never Assume a Paricular Order of Execution.
7. Use Thread Local Storage whenever possible or associate locsk to specifi data.
8. Date to change the algorithm for a better chance of concurrency.
There are also some talk of various threading libraries, OpenMP (implicit threading) , Intel Threading Building Blocks as well as explicit threading: such as pthreads and Windows Threads.
The book also shows some threading examples of sorting, searching, graphs, as well as some information on the Intel's VTune Performance Analyzer which sounds pretty useful in finding those hotspots that would be potential candidates for parallel computing.
Lots of interesting stuff, and the book covers quite a bit of different areas. I especially liked the eight rules and found the overarching view of the different areas of threading interesting.
Best of luck managing your threads,
Michael Hubbard
http://michaelhubbard.ca
Breshears mentions threading as the future of applications, with multicore becoming more and more popular, and concurrent programming eventually becoming the norm for everything wanting to take advantage of all these additional processors.
The book talks about approaching concurency and threading with eight simple rules:
1. Identify Truly Independent Computations.
2. Implement Concurrency at the Highest Level Possible.
3. Plan Early for Scalability to Take Advantage of Increasing Numbers of Cores.
4. Make Use of Thread Safe Libraries Whenever Possible.
5. Use the Right Threading Model.
6. Never Assume a Paricular Order of Execution.
7. Use Thread Local Storage whenever possible or associate locsk to specifi data.
8. Date to change the algorithm for a better chance of concurrency.
There are also some talk of various threading libraries, OpenMP (implicit threading) , Intel Threading Building Blocks as well as explicit threading: such as pthreads and Windows Threads.
The book also shows some threading examples of sorting, searching, graphs, as well as some information on the Intel's VTune Performance Analyzer which sounds pretty useful in finding those hotspots that would be potential candidates for parallel computing.
Lots of interesting stuff, and the book covers quite a bit of different areas. I especially liked the eight rules and found the overarching view of the different areas of threading interesting.
Best of luck managing your threads,
Michael Hubbard
http://michaelhubbard.ca
Subscribe to:
Posts (Atom)