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
Thursday, January 13, 2011
Sunday, January 9, 2011
Dunning-Kruger effect
The worst part about a crunch is the toll it takes on the people. Everyone starts to get tired and cranky (shame programmers don't have cheerleaders). Anyway, for whatever reason my mind wandered over to the Dunning-Kruger effect taken from wikipedia (I know I know, I will try and find a better site for sourcing): http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
The Dunning–Kruger effect is a cognitive bias in which unskilled people make poor decisions and reach erroneous conclusions, but their incompetence denies them the meatcognitive ability to appreciate their mistakes. The unskilled therefore suffer from illusory superiority, rating their ability as above average, much higher than it actually is, while the highly skilled underrate their own abilities, suffering from illusory inferiority. Actual competence may weaken self-confidence, as competent individuals may falsely assume that others have an equivalent understanding. As Kruger and Dunning conclude, "the miscalibration of the incompetent stems from an error about the self, whereas the miscalibration of the highly competent stems from an error about others"
A lot of attitudes come out of a crunch, more often than not poor attitudes, with people being "thrown under the bus" or "getting yelled at". It is sad really, but such is the nature of business. The Dunning-Kruger effect is important to think about, during this time, as everyone seems to have an opinion at these times. However, it is also important to consider this related to your own abilities.
How much do you know about a subject? It has been suggested that it requires around 10,000 hours for mastering something (which in most cases is ~10 years). The game dev community is fairly young, and finding a lot of people with 10+ years in a specific field is rare, couple that with the enormous amount of research and different elements that game dev and tech art consists of and you will never find someone who has mastered it all. I always like to compare know-it-alls to the socratic intelligence, where claiming to know nothing is considered the greatest intelligence:
"I know that I know nothing"
Social gadfly · Trial of Socrates
This is a much better attitude in my opinion, as it leaves you open to possibilities that you never would have considered before. It can get a little cheesy if you take it too far, but still it is good to consider all options and occassionally the source of opinions too.
Do I know that I know nothing?
Michael Hubbard
http://michaelhubbard.ca
The Dunning–Kruger effect is a cognitive bias in which unskilled people make poor decisions and reach erroneous conclusions, but their incompetence denies them the meatcognitive ability to appreciate their mistakes. The unskilled therefore suffer from illusory superiority, rating their ability as above average, much higher than it actually is, while the highly skilled underrate their own abilities, suffering from illusory inferiority. Actual competence may weaken self-confidence, as competent individuals may falsely assume that others have an equivalent understanding. As Kruger and Dunning conclude, "the miscalibration of the incompetent stems from an error about the self, whereas the miscalibration of the highly competent stems from an error about others"
A lot of attitudes come out of a crunch, more often than not poor attitudes, with people being "thrown under the bus" or "getting yelled at". It is sad really, but such is the nature of business. The Dunning-Kruger effect is important to think about, during this time, as everyone seems to have an opinion at these times. However, it is also important to consider this related to your own abilities.
How much do you know about a subject? It has been suggested that it requires around 10,000 hours for mastering something (which in most cases is ~10 years). The game dev community is fairly young, and finding a lot of people with 10+ years in a specific field is rare, couple that with the enormous amount of research and different elements that game dev and tech art consists of and you will never find someone who has mastered it all. I always like to compare know-it-alls to the socratic intelligence, where claiming to know nothing is considered the greatest intelligence:
"I know that I know nothing"
Social gadfly · Trial of Socrates
This is a much better attitude in my opinion, as it leaves you open to possibilities that you never would have considered before. It can get a little cheesy if you take it too far, but still it is good to consider all options and occassionally the source of opinions too.
Do I know that I know nothing?
Michael Hubbard
http://michaelhubbard.ca
Friday, January 7, 2011
Crunch together
A team in crunch has a good chance of jelling, it is often during this time that a team can really learn more about each other and bond. Working long hours after many of the other employees have gone home does not feel quite so bad when you are not alone. It gives a better feeling of teamwork if you are all sitting together working away, bouncing ideas of one another and helping solve problems that is often more personal than during the regular work day.
This time can often generate some great war stories, I remember at a previous company one time another developer and I stayed up until 2 am Saturday night (Sunday morning) working away on some sync server integration. After banging our head against the wall of a server call that was blocking us, we went to the Subway for a midnight snack. When we came back, I began hacking into some server code (totally different language and code base than what we were working on) and hooked it up to give us the parameters we needed for syncing game elements so we could continue working. It was a lot of fun, and gave a great sense of accomplishment and while it was modified and properly "fixed" by one of the other server programmers the following Monday, it was great to remove the blockage to allow us to continue working and was rewarding to overcome these kinds of challenges together.
Until next time, try not to work too hard,
Michael Hubbard
http://michaelhubbard.ca
This time can often generate some great war stories, I remember at a previous company one time another developer and I stayed up until 2 am Saturday night (Sunday morning) working away on some sync server integration. After banging our head against the wall of a server call that was blocking us, we went to the Subway for a midnight snack. When we came back, I began hacking into some server code (totally different language and code base than what we were working on) and hooked it up to give us the parameters we needed for syncing game elements so we could continue working. It was a lot of fun, and gave a great sense of accomplishment and while it was modified and properly "fixed" by one of the other server programmers the following Monday, it was great to remove the blockage to allow us to continue working and was rewarding to overcome these kinds of challenges together.
Until next time, try not to work too hard,
Michael Hubbard
http://michaelhubbard.ca
Wednesday, January 5, 2011
Crunch
Crunch, overtime, force-overtime, deathmarch. Call it what you want, no one likes it, no one wants it, and yet it seems to happen in far too many places, and far too often (will have to read that Deathmarch book soon I think).
So, how do you deal with significant amount of overtime? Well, hopefully, you are doing something fun, like a cool game, animation, film or whatever project that you are excited to go to work for, and that will get you by for a little while (if you are lucky for the remainder of the crunch). Either way here are a few tips that I have come up with, that may help you too.
1. Eat: if all you are thinking about is how hungry you are, you are not thinking about how to solve that complex problem. Eating will also give you a bit of a break, hopefully a chance to talk to a few other tired soliders about their battles, and gives your body extra energy for the next attack (managers you should be getting food for your team, variety is nice, try and get from as many different places as possible, eating pizza everyday is only fun for the first week). Oh, and yes you will gain weight during the crunch :P
2. Drink: avoid overdoing too much caffeine (use sparingly or save it for the final few days, if you need it). Too often, people ramp up too fast and can't maintain the pace. Go slow, drink lots of water as well as some other things (I like green tea, but go with whatever you like (I like energy drinks occassionally too, but use in moderation)). Remember, this isn't a sprint, this is a marathon.
3. Call your loved ones: you won't be seeing them very much, so try and call them during your lunch break or whenever you get a chance during the day, and make sure you do it, and be consistent. Too often it is easy to get wrapped up in the world of the job, but while it is taking all the time of your current life, don't let it take your future life too (a project should success should not be measured by number of divorce papers, heart breaks and forgotten kids).
4. Take some breaks: get up, walk around, stretch, do some pushups (or consider doing some pushups) to ward of some of the pizza, grab another cup of coffee or tea or water. All this sitting and you will be getting tired, having a quick break and tiny use of energy will still let your brain think on the backburner while giving your body a chance to adjust and feel more alive. Whenever you get really stuck and have been stuck for a long time, get up and take a break.
5. Sleep: you will not be able to do all the things you like to do during a crunch period. Instead, focus on getting some sleep when you get home. If you are lucky, you will have someone else who can help with things (clean laundry is nice), but only focus on the essentials and be sure to sleep as much as you can (you are taxing your body and will need the recovery time).
6. Take a weekend: sometimes things will pile up (laundry?) that you will need to take care of them. You should try and take one weekend a week if possible, or at least half a day on the weekend to see those people you have been calling, and take some personal time.
7. Try and do some work from home: if possible working from home will help, you won't be as productive or have as much team building as you would at the office, but you will at least be able to help around the house if necessary and see those people you haven't for a while.
8. Keep track of your time: it is worth knowing how much time you put in. This is time you are unlikely to get back (hopefully you will get some undertime or lieu days) but it becomes far more important for future project planning. When someone says, of course you can get that done in a month you can say no, actually it took four, 70-hour weeks to accomplish, which is more like seven, 40-hour weeks to finish, which becomes a huge difference.
All in all, crunch is usually something that should be minimized (in my experience, 3-weeks of hard straight crunch is usually about most people's limit). Extended crunch for months on end becomes a death march, and often it is not just the project that is in danger, but also keeping the team intact.
Best of luck in the crunch,
Michael Hubbard
http://michaelhubbard.ca
So, how do you deal with significant amount of overtime? Well, hopefully, you are doing something fun, like a cool game, animation, film or whatever project that you are excited to go to work for, and that will get you by for a little while (if you are lucky for the remainder of the crunch). Either way here are a few tips that I have come up with, that may help you too.
1. Eat: if all you are thinking about is how hungry you are, you are not thinking about how to solve that complex problem. Eating will also give you a bit of a break, hopefully a chance to talk to a few other tired soliders about their battles, and gives your body extra energy for the next attack (managers you should be getting food for your team, variety is nice, try and get from as many different places as possible, eating pizza everyday is only fun for the first week). Oh, and yes you will gain weight during the crunch :P
2. Drink: avoid overdoing too much caffeine (use sparingly or save it for the final few days, if you need it). Too often, people ramp up too fast and can't maintain the pace. Go slow, drink lots of water as well as some other things (I like green tea, but go with whatever you like (I like energy drinks occassionally too, but use in moderation)). Remember, this isn't a sprint, this is a marathon.
3. Call your loved ones: you won't be seeing them very much, so try and call them during your lunch break or whenever you get a chance during the day, and make sure you do it, and be consistent. Too often it is easy to get wrapped up in the world of the job, but while it is taking all the time of your current life, don't let it take your future life too (a project should success should not be measured by number of divorce papers, heart breaks and forgotten kids).
4. Take some breaks: get up, walk around, stretch, do some pushups (or consider doing some pushups) to ward of some of the pizza, grab another cup of coffee or tea or water. All this sitting and you will be getting tired, having a quick break and tiny use of energy will still let your brain think on the backburner while giving your body a chance to adjust and feel more alive. Whenever you get really stuck and have been stuck for a long time, get up and take a break.
5. Sleep: you will not be able to do all the things you like to do during a crunch period. Instead, focus on getting some sleep when you get home. If you are lucky, you will have someone else who can help with things (clean laundry is nice), but only focus on the essentials and be sure to sleep as much as you can (you are taxing your body and will need the recovery time).
6. Take a weekend: sometimes things will pile up (laundry?) that you will need to take care of them. You should try and take one weekend a week if possible, or at least half a day on the weekend to see those people you have been calling, and take some personal time.
7. Try and do some work from home: if possible working from home will help, you won't be as productive or have as much team building as you would at the office, but you will at least be able to help around the house if necessary and see those people you haven't for a while.
8. Keep track of your time: it is worth knowing how much time you put in. This is time you are unlikely to get back (hopefully you will get some undertime or lieu days) but it becomes far more important for future project planning. When someone says, of course you can get that done in a month you can say no, actually it took four, 70-hour weeks to accomplish, which is more like seven, 40-hour weeks to finish, which becomes a huge difference.
All in all, crunch is usually something that should be minimized (in my experience, 3-weeks of hard straight crunch is usually about most people's limit). Extended crunch for months on end becomes a death march, and often it is not just the project that is in danger, but also keeping the team intact.
Best of luck in the crunch,
Michael Hubbard
http://michaelhubbard.ca
Saturday, January 1, 2011
Happy New Year
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
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
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)