In the new game trailer for Soul Calibur 5 http://www.gametrailers.com/video/character-creation-trailer/723519 they show the awesome character customization ability. This is quite well done, and while not exactly the same as something like Spore, where appendages and weight changes, it is nevertheless still quite impressive.
While it is amazing technological work for a two player game, currently this type of extreme customization wouldn't work in an MMORPG. Not to say you couldn't have customization in an MMORPG, it happens all the time, but even then 100s or 1000s of characters in a town would likely bring even the best gaming computers to a crawl as every texture and separate geometry tried to get rendered. Sure, there are tricks that can be done (different level of detail, texture resoultion sizes, combining as many pieces into a single draw call, replacing similar pieces into one piece, etc.) most of these however have the distinct chance of making all the other characters look similar and simplified (which is not what extreme customization is about).
There will likely be a time when every character, tree, rock, brick, stone and even blade of grass is unique, but until then, one of the main problems I have seen with game designers (and developers) going down the customization path is knowing where to draw the line. It is very important (crucial) to establish how much customization can be allowed by the player and whether it can be supported. If you want to go the Second Life route, you will have to make sure the engine was designed with that specifically in mind. If you find yourself worrying about how to render each character's belts, earrings, shoelaces, cufflinks, ties and shirt pins you have likely gone too far (perhaps even off the deep end).
Computer games (and graphics) are mostly a series of tricks, but you would need a whopper to trick the graphics card and cpu into rendering outrageous customizations in an MMORPG without it running like a screen saver. Still, the Soul Calibur customization sure is pretty, and it will only be a matter of time before someone tries to do that with 100s of characters (hopefully the computers in the future will be that much better).
Best of luck,
Michael Hubbard
http://michaelhubbard.ca
Showing posts with label game programmer. Show all posts
Showing posts with label game programmer. Show all posts
Thursday, November 3, 2011
Sunday, May 22, 2011
Full Indie Meetup
I went to another Full Indie meetup http://www.fullindie.com/2011/05/12/full-indie-anniversary-event-thursday-may-19th/ this one had a talk with Chris Stewart from Barking Dog studios and Andy Moore from Radial Games. The talk was good, quite a lot of people coming out, and a good motivator for going home and working on your own games.
I especially like some of the stuff that Chris had to say, it was along the lines of "fake it till you make it", but in more graphic terms. From his experience, there can be a lot of stress in being a indie game dev, and a lot of the business aspects of the job can prove to be more challenging than expected, even for a developer that is used to a lot of hard challenges. He mentioned that nothing will "kill you", and you just have to go out there and do it. The talk also contained some aspects of how to deal with people. People are the most difficult part of any company, and it is important to do your best to move everyone in the same direction. It is useful to group artists and developers together since they are the least likely to talk, and it is worthwhile in a small group that everyone has a lot of communication with each other, since there is often not someone around to manage all the important aspects.
Overall, I think that the talks were good, I did not stay too long as I had other plans, but look forward to more of these at some point.
Cheers,
Michael Hubbard
http://michaelhubbard.ca
I especially like some of the stuff that Chris had to say, it was along the lines of "fake it till you make it", but in more graphic terms. From his experience, there can be a lot of stress in being a indie game dev, and a lot of the business aspects of the job can prove to be more challenging than expected, even for a developer that is used to a lot of hard challenges. He mentioned that nothing will "kill you", and you just have to go out there and do it. The talk also contained some aspects of how to deal with people. People are the most difficult part of any company, and it is important to do your best to move everyone in the same direction. It is useful to group artists and developers together since they are the least likely to talk, and it is worthwhile in a small group that everyone has a lot of communication with each other, since there is often not someone around to manage all the important aspects.
Overall, I think that the talks were good, I did not stay too long as I had other plans, but look forward to more of these at some point.
Cheers,
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
Saturday, April 16, 2011
Full Indie (Game Dev Event)
In order to keep up with some of the game development stuff, I decided to attend Vancouver Game Indie community (Full Indie) demo night: http://www.fullindie.com/2011/04/12/april-event-game-demo-night-rocked/ It was interesting to see what Vancouver had in the way of indie developers, and looked like there was some good stuff. I suspect that a large percentage of the community was students, but it is always interesting to see what the professional indie developers are up to.
All of the games were interesting, but I especially liked Justin Smith's No Brakes Valet, which is a flash game he created at a game jam, in which you attempt to park cars in different parking stalls, but occasionally there will be some with "no brakes" which makes the car crash into things. He also had a good quote about this: "if you are good at the game, it should be fun, if you are bad at it, it should be fun" (paraphrase). This is good advice for any game designer, and was especially true in his game when the cars banged into each other (without brakes) and caused the other cars to bounce around making a really enjoyable mess. Overall a good experience and look forward to seeing what else it out there (who knows, maybe I will get a chance to contribute something sometime in the future).
Cheers,
Michael Hubbard
http://michaelhubbard.ca
All of the games were interesting, but I especially liked Justin Smith's No Brakes Valet, which is a flash game he created at a game jam, in which you attempt to park cars in different parking stalls, but occasionally there will be some with "no brakes" which makes the car crash into things. He also had a good quote about this: "if you are good at the game, it should be fun, if you are bad at it, it should be fun" (paraphrase). This is good advice for any game designer, and was especially true in his game when the cars banged into each other (without brakes) and caused the other cars to bounce around making a really enjoyable mess. Overall a good experience and look forward to seeing what else it out there (who knows, maybe I will get a chance to contribute something sometime in the future).
Cheers,
Michael Hubbard
http://michaelhubbard.ca
Friday, April 8, 2011
Game Review: GameDev Story
There is a fun little game GameDev Story for the iphone/ipod http://itunes.apple.com/ca/app/game-dev-story/id396085661?mt=8 that I have been meaning to write about. The game itself is pretty addictive, and kudos to the idea and execution (if you haven't tried it, it is definitely worth a look, and some of the games you compete against like "Street Cleaner 2" are pretty funny). That being said, the thing I liked was the focus on the people, and getting the right people can really make or break your success in the game industry.
With the focus on people I think a few additional attributes would be appropriate/realistic for those who have never worked in the game industry:
1. Training time for new hires. It is nearly impossible to expect people to jump into a new or established company and be as productive as someone else who has been there a while. It would be interesting to see what replacing someone at the start compared with at the end would do for the training.
2. Employee moral, the devs come and go and often appear to be working all hours of the day (some just leaving while others are coming in). It would be interesting to have some sort of happiness meter that decides whether or not the devs decide to stay at the company or go work somewhere else.
3. Teamwork. How well to the devs work together? It would be interesting that those with great people skills and coding skills are not always in the same package. What kind of results would happen if the devs were not working well together, or there were personalities that clashed. This would also go with employee moral, as it can be a burden on the entire team, even if it is only two that are having problems.
4. Budget vs Time: In the game you are not really punished for fixing the bugs, and can release it earlier if needed. Instead, it would be interesting to factor in some sort of delay mechanism, if a project is not on track and how to get it back on track.
5. More human factors (sick days, holidays, vacations, bad days, stressed days, tired days, etc.), also would be intersting to see how well the work life balance played out for these happy little characters :P
For those looking at running a game studio, the best advice I can give is to join one yourself, even if you don't learn exactly what to do, learning what not to do is also a useful experience.
Best of luck,
Michael Hubbard
http://michaelhubbard.ca
With the focus on people I think a few additional attributes would be appropriate/realistic for those who have never worked in the game industry:
1. Training time for new hires. It is nearly impossible to expect people to jump into a new or established company and be as productive as someone else who has been there a while. It would be interesting to see what replacing someone at the start compared with at the end would do for the training.
2. Employee moral, the devs come and go and often appear to be working all hours of the day (some just leaving while others are coming in). It would be interesting to have some sort of happiness meter that decides whether or not the devs decide to stay at the company or go work somewhere else.
3. Teamwork. How well to the devs work together? It would be interesting that those with great people skills and coding skills are not always in the same package. What kind of results would happen if the devs were not working well together, or there were personalities that clashed. This would also go with employee moral, as it can be a burden on the entire team, even if it is only two that are having problems.
4. Budget vs Time: In the game you are not really punished for fixing the bugs, and can release it earlier if needed. Instead, it would be interesting to factor in some sort of delay mechanism, if a project is not on track and how to get it back on track.
5. More human factors (sick days, holidays, vacations, bad days, stressed days, tired days, etc.), also would be intersting to see how well the work life balance played out for these happy little characters :P
For those looking at running a game studio, the best advice I can give is to join one yourself, even if you don't learn exactly what to do, learning what not to do is also a useful experience.
Best of luck,
Michael Hubbard
http://michaelhubbard.ca
Sunday, March 20, 2011
The Programming Languages to Know
The programming languages to know (for Game Programmers and Technical Artists), but can really be applied to almost any programming task:
1. C++: The language to learn, and while I like C, object oriented programming is nearly always a better approach for large game projects. This is the language that job market talks in, is the language you want to be taught in university and the language you should be the most comfortable with. While a number of other languages are gaining interest (see C#) the low level control and history of code written in C++ will keep this language in the running for a long time (or at least until C++0X).
2. Javascript: While this may surprise some, this is the language for Adobe product pipeline scripting. Need something automated for Photoshop, Illustator or After Effects? Of course you do... always automate any tasks can be automated, and with javascript this will be one of the only options that these products have API support for. It was also great for some XSI scripting back in the day. Oh and it doesn't hurt that it is the language of client side websites either.
3. Python: This is quickly becoming the language for scripting and glue logic. Once, I would have put Perl here which is great for tasks you need a "swiss army chainsaw", but if your script needs to be maintained or is very long, it is often better to go with Python's object oriented approach. Maya including Python (along with MEL) also bumps this signficantly up the list.
4. C#: Really? Sure, more indie engines like Unity or XNA are worth picking up and playtesting with. While you can use Javascript with Unity, for a very large project it is worth going with C# and the tools (Visual Studio or MonoDevelop) that go along with it.
5. Cg (shader language): If you learn this NVIDIA shader language you will find both HLSL and GLSL a snap. If you are looking at Unity's ShaderLab or the very cool cgFX you should definitely pick up this language in your toolkit of skills.
Other languages that are great to know about are web based languages like Ruby or PHP, some other more unusual languages like Prolog or Scheme (so that you can think about solving problems in different ways) and of course knowing and using a little assembly never hurts (if you really need to optimize).
You will likely look at other languages in your career: such as Java, Obj-C, Lua and more. In fact, the more languages you know and practice with the easier that it will be to transition to other languages. Most languages (especially the popular ones) have lots of good books on them, and lots of examples, but don't worry so much about the syntax anyway, learning the syntax and key words is only the first step. Learning how to program effectively can be done in any language, focus on the language you work in, and learn it inside out. Learn how to architect software, break down problems into solutions, how to optimize and debug what you have written, and what it really comes down to is being able to think in a programming language. When you learn other languages, picking up the syntax differences and a few specialties in the libraries shouldn't be too hard to pick up after that.
If you really want a challenge, you could always try http://www.muppetlabs.com/~breadbox/bf/ or try some of the more obscure ones at http://c2.com/cgi/wiki?HelloWorldInManyProgrammingLanguages and http://www.99-bottles-of-beer.net/
But only if you are up for a challenge...
Michael Hubbard
http://michaelhubbard.ca
1. C++: The language to learn, and while I like C, object oriented programming is nearly always a better approach for large game projects. This is the language that job market talks in, is the language you want to be taught in university and the language you should be the most comfortable with. While a number of other languages are gaining interest (see C#) the low level control and history of code written in C++ will keep this language in the running for a long time (or at least until C++0X).
2. Javascript: While this may surprise some, this is the language for Adobe product pipeline scripting. Need something automated for Photoshop, Illustator or After Effects? Of course you do... always automate any tasks can be automated, and with javascript this will be one of the only options that these products have API support for. It was also great for some XSI scripting back in the day. Oh and it doesn't hurt that it is the language of client side websites either.
3. Python: This is quickly becoming the language for scripting and glue logic. Once, I would have put Perl here which is great for tasks you need a "swiss army chainsaw", but if your script needs to be maintained or is very long, it is often better to go with Python's object oriented approach. Maya including Python (along with MEL) also bumps this signficantly up the list.
4. C#: Really? Sure, more indie engines like Unity or XNA are worth picking up and playtesting with. While you can use Javascript with Unity, for a very large project it is worth going with C# and the tools (Visual Studio or MonoDevelop) that go along with it.
5. Cg (shader language): If you learn this NVIDIA shader language you will find both HLSL and GLSL a snap. If you are looking at Unity's ShaderLab or the very cool cgFX you should definitely pick up this language in your toolkit of skills.
Other languages that are great to know about are web based languages like Ruby or PHP, some other more unusual languages like Prolog or Scheme (so that you can think about solving problems in different ways) and of course knowing and using a little assembly never hurts (if you really need to optimize).
You will likely look at other languages in your career: such as Java, Obj-C, Lua and more. In fact, the more languages you know and practice with the easier that it will be to transition to other languages. Most languages (especially the popular ones) have lots of good books on them, and lots of examples, but don't worry so much about the syntax anyway, learning the syntax and key words is only the first step. Learning how to program effectively can be done in any language, focus on the language you work in, and learn it inside out. Learn how to architect software, break down problems into solutions, how to optimize and debug what you have written, and what it really comes down to is being able to think in a programming language. When you learn other languages, picking up the syntax differences and a few specialties in the libraries shouldn't be too hard to pick up after that.
If you really want a challenge, you could always try http://www.muppetlabs.com/~breadbox/bf/ or try some of the more obscure ones at http://c2.com/cgi/wiki?HelloWorldInManyProgrammingLanguages and http://www.99-bottles-of-beer.net/
But only if you are up for a challenge...
Michael Hubbard
http://michaelhubbard.ca
Thursday, March 17, 2011
RateMyEmployer.ca
In case you did not know there is the site for rating employers: http://www.ratemyemployer.ca/ But how useful is it really for you as a potential employee? Well, from what I can tell, most of the time the ratings are generally pretty negative. This has to be taken in context, and a company that has a lot of employees but not a lot of ratings may potentially be a decent company, while a smaller company that does not have a lot of employees but a lot of negative ratings may not be very good. If you are lucky you will have a lot of comments and will be given reasons for why they were rated that way, either positive or negative. Having only one comment (positive or negative) is usually not enough information to accurately assess whether or not it was just one happy or one angry employee posting from a good or bad day.
For those of you still in school also check out http://www.ratemyprofessors.com/
Regardless, if you are really interested, it never hurts to do a little research. If you are scoping out a new job, try and check it out before you apply. See if the people are happy working there (if you can ask them), check and see if people flood out at 5:00, if there are a lot of fancy cars in the parking lot, if people are smiling or are walking zombies. What kind of stuff has the company produced, do they have a good track record of many successful products, or are they struggling? Another good indication is how much activity (new and leaving) does a company get on Linked In ? Do they have a lot of turn around, and what kind of people are they bringing in (experienced, or fresh out of school)?
It never hurts to do your homework, after all, it is your life.
Best of luck,
Michael Hubbard
http://michaelhubbard.ca
For those of you still in school also check out http://www.ratemyprofessors.com/
Regardless, if you are really interested, it never hurts to do a little research. If you are scoping out a new job, try and check it out before you apply. See if the people are happy working there (if you can ask them), check and see if people flood out at 5:00, if there are a lot of fancy cars in the parking lot, if people are smiling or are walking zombies. What kind of stuff has the company produced, do they have a good track record of many successful products, or are they struggling? Another good indication is how much activity (new and leaving) does a company get on Linked In ? Do they have a lot of turn around, and what kind of people are they bringing in (experienced, or fresh out of school)?
It never hurts to do your homework, after all, it is your life.
Best of luck,
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
Sunday, February 20, 2011
Day in the Life of a Game Programmer/ Team Lead (in Crunch)
Well, the day still starts at 7:00 AM, but the timeline is a bit different in a crunch. See my original post for comparison: http://gameprogrammertechnicalartist.blogspot.com/2010/10/day-in-life-of-game-programmer-team.html
07:00-07:14 (00:14) Wake up to an alarm, keep hitting snooze.
07:14-07:32 (00:18) Shower, (skip breakfast) and leave.
07:32-07:51 (00:19) Leave apartment walk to bus stop.
07:51-08:30 (00:39) Get on bus, rest my eyes, but do not sleep.
08:30-08:33 (00:03) Walk to office, drop stuff off at my desk.
08:33-08:37 (00:04) Grab one of the many coffees of the day.
08:37-08:44 (00:07) Update code, check email, some admin stuff.
08:44-08:54 (00:10) Talk with one of the dev, answer questions.
08:54-09:15 (00:21) Update and print out bug list from QA.
09:15-09:30 (00:15) Stand up meeting for half the dev team.
09:30-09:45 (00:15) Stand up meeting for the other half of team.
09:45-10:00 (00:15) Meeting with server leads, about bug list.
10:00-10:06 (00:06) Grab another coffee, talk about a bug.
10:06-10:36 (00:30) Code.
10:36-10:42 (00:06) Clarify some code standard.
10:42-10:50 (00:08) Give current status.
10:50-10:54 (00:04) Answer some questions about specific feature.
10:54-11:38 (00:44) Code.
11:38-12:18 (00:40) Test and submit some bug fixes.
12:18-12:24 (00:06) Walk to get some lunch, call girlfriend.
12:24-12:36 (00:12) Buy some lunch (Subway), take it to my desk.
12:36-01:07 (00:31) Update repository, eat, and continue to code.
01:07-01:10 (00:03) Give status.
01:10-01:14 (00:04) Code.
01:14-01:21 (00:07) Answer important emails for clarification.
01:21-01:26 (00:05) Code.
01:26-01:29 (00:03) Help answer a developer question.
01:29-01:35 (00:06) Code.
01:35-01:43 (00:08) Grab another coffee, and coffee related break.
01:43-01:48 (00:05) Answer some questions in email.
01:48-01:51 (00:03) Code.
01:51-02:33 (00:42) Help developer debug an issue.
02:33-02:35 (00:02) Grab another coffee.
02:35-02:57 (00:22) Code.
02:57-03:01 (00:04) Answer email.
03:01-03:36 (00:35) Merge code and look over changes.
03:36-03:46 (00:10) Answer questions.
03:46-04:11 (00:25) Code.
04:11-04:20 (00:09) Give status.
04:20-04:24 (00:04) Code.
04:24-04:47 (00:23) Grab coffee with another dev.
04:47-05:59 (01:12) Code.
05:59-06:14 (00:15) Discuss implementation issue with other dev.
06:14-06:27 (00:13) Pizza arrives, grab a few slices and a pop.
06:27-07:17 (00:50) Code.
07:17-07:36 (00:19) Talk with developer, write email for tomorrow.
07:36-09:58 (02:22) Code.
09:58-10:09 (00:11) Add notes and tasks for tomorrow.
10:09-10:43 (00:34) Talk with other devs about tasks, status.
10:43-10:58 (00:15) Leave and walk/wait for bus.
10:58-11:36 (00:38) Rest on bus, phone and reading.
11:36-11:46 (00:10) Walk home.
11:46-12:02 (00:16) Talk with girlfriend, get ready for bed.
12:02-12:36 (00:34) Personal email, brief web surf.
12:36-07:00 (06:24) Sleep, so the whole thing can start again.
Breakdown:
Work:
Administration (email, delegating tasks, status): 2 hour 8 minutes.
Breaks (lunch, dinner, coffee): 1 hour and 14 minutes.
Coding: 8 hours and 33 minutes.
Helping Others: 1 hour and 30 minutes.
Meetings: 45 minutes.
Home:
Computing (web surfing, project coding): 34 minutes.
Exercise: 0 minutes.
Personal Maintenance (food, shower, etc.): 48 minutes.
Reading (including bus travel time): 38 minutes.
Sleep: 6 hours 24 minutes.
Travel (not including bus reading time): 1 hour 26 minutes.
Other Facts:
Read 48 emails.
Sent 13 emails.
No code review.
If you compare this with the previous day in the life entry there are a few substantial differences. Even though I am spending approximately 16 hours and 14 minutes away from home, the coding time still only amounts to half of my day. All the other aspects including meetings, admin and help have gone up, and nothing has gone down (on the work side).
The home side is where all the time goes. Sleep takes a hit (about half and hour less), exercise is non-existent, and coupled with fast food for lunch and dinner is going to make me gain weight and have less energy overall. This plays into attempting to sleep on the bus, but really turns into wasted time, since I want to sleep in the morning (and am too tired to read), but can't really get to sleep on the bus with all the noise and crowded seats in the morning. I also tend to miss making breakfast, but will try and grab something like a banana, apple or bagel on my way out the door to eat on the way to the bus.
There are still a lot of interruptions, a lot more status updates and emails. Organizing the crunch is tricky since there are always "fires" that have to be put out, and as things move faster, more coordination is needed to make everything work smoothly.
With so much time at work, there is very little personal time for any time with loved ones, projects, additional reading, or relaxation. I try and phone when I have free time (lunch and on the bus), but this is not the same as being around. If you are at this pace (or worse) for a prolonged period of time, that means you are on a death march. If this lasts longer than a few weeks (longer than three weeks maximum) it will start to take a toll. This is not the worse pace I have been on (I slept under my desk multiple consecutive nights earlier in my career), but it is a difficult one to maintain.
With so many tired devs, so much extra coordination, many interruptions, minimal code reviews, extra status updates, it becomes a tricky situation to balance. Throw in low energy, running on coffee and a lot of other tired developers and co-workers, it can quickly turn ugly if spirits are not high. Everyone wants to see the project out, but there is still a lot of work to do. I should probably take my vitamins.
Wish me luck,
Michael Hubbard
http://michaelhubbard.ca
07:00-07:14 (00:14) Wake up to an alarm, keep hitting snooze.
07:14-07:32 (00:18) Shower, (skip breakfast) and leave.
07:32-07:51 (00:19) Leave apartment walk to bus stop.
07:51-08:30 (00:39) Get on bus, rest my eyes, but do not sleep.
08:30-08:33 (00:03) Walk to office, drop stuff off at my desk.
08:33-08:37 (00:04) Grab one of the many coffees of the day.
08:37-08:44 (00:07) Update code, check email, some admin stuff.
08:44-08:54 (00:10) Talk with one of the dev, answer questions.
08:54-09:15 (00:21) Update and print out bug list from QA.
09:15-09:30 (00:15) Stand up meeting for half the dev team.
09:30-09:45 (00:15) Stand up meeting for the other half of team.
09:45-10:00 (00:15) Meeting with server leads, about bug list.
10:00-10:06 (00:06) Grab another coffee, talk about a bug.
10:06-10:36 (00:30) Code.
10:36-10:42 (00:06) Clarify some code standard.
10:42-10:50 (00:08) Give current status.
10:50-10:54 (00:04) Answer some questions about specific feature.
10:54-11:38 (00:44) Code.
11:38-12:18 (00:40) Test and submit some bug fixes.
12:18-12:24 (00:06) Walk to get some lunch, call girlfriend.
12:24-12:36 (00:12) Buy some lunch (Subway), take it to my desk.
12:36-01:07 (00:31) Update repository, eat, and continue to code.
01:07-01:10 (00:03) Give status.
01:10-01:14 (00:04) Code.
01:14-01:21 (00:07) Answer important emails for clarification.
01:21-01:26 (00:05) Code.
01:26-01:29 (00:03) Help answer a developer question.
01:29-01:35 (00:06) Code.
01:35-01:43 (00:08) Grab another coffee, and coffee related break.
01:43-01:48 (00:05) Answer some questions in email.
01:48-01:51 (00:03) Code.
01:51-02:33 (00:42) Help developer debug an issue.
02:33-02:35 (00:02) Grab another coffee.
02:35-02:57 (00:22) Code.
02:57-03:01 (00:04) Answer email.
03:01-03:36 (00:35) Merge code and look over changes.
03:36-03:46 (00:10) Answer questions.
03:46-04:11 (00:25) Code.
04:11-04:20 (00:09) Give status.
04:20-04:24 (00:04) Code.
04:24-04:47 (00:23) Grab coffee with another dev.
04:47-05:59 (01:12) Code.
05:59-06:14 (00:15) Discuss implementation issue with other dev.
06:14-06:27 (00:13) Pizza arrives, grab a few slices and a pop.
06:27-07:17 (00:50) Code.
07:17-07:36 (00:19) Talk with developer, write email for tomorrow.
07:36-09:58 (02:22) Code.
09:58-10:09 (00:11) Add notes and tasks for tomorrow.
10:09-10:43 (00:34) Talk with other devs about tasks, status.
10:43-10:58 (00:15) Leave and walk/wait for bus.
10:58-11:36 (00:38) Rest on bus, phone and reading.
11:36-11:46 (00:10) Walk home.
11:46-12:02 (00:16) Talk with girlfriend, get ready for bed.
12:02-12:36 (00:34) Personal email, brief web surf.
12:36-07:00 (06:24) Sleep, so the whole thing can start again.
Breakdown:
Work:
Administration (email, delegating tasks, status): 2 hour 8 minutes.
Breaks (lunch, dinner, coffee): 1 hour and 14 minutes.
Coding: 8 hours and 33 minutes.
Helping Others: 1 hour and 30 minutes.
Meetings: 45 minutes.
Home:
Computing (web surfing, project coding): 34 minutes.
Exercise: 0 minutes.
Personal Maintenance (food, shower, etc.): 48 minutes.
Reading (including bus travel time): 38 minutes.
Sleep: 6 hours 24 minutes.
Travel (not including bus reading time): 1 hour 26 minutes.
Other Facts:
Read 48 emails.
Sent 13 emails.
No code review.
If you compare this with the previous day in the life entry there are a few substantial differences. Even though I am spending approximately 16 hours and 14 minutes away from home, the coding time still only amounts to half of my day. All the other aspects including meetings, admin and help have gone up, and nothing has gone down (on the work side).
The home side is where all the time goes. Sleep takes a hit (about half and hour less), exercise is non-existent, and coupled with fast food for lunch and dinner is going to make me gain weight and have less energy overall. This plays into attempting to sleep on the bus, but really turns into wasted time, since I want to sleep in the morning (and am too tired to read), but can't really get to sleep on the bus with all the noise and crowded seats in the morning. I also tend to miss making breakfast, but will try and grab something like a banana, apple or bagel on my way out the door to eat on the way to the bus.
There are still a lot of interruptions, a lot more status updates and emails. Organizing the crunch is tricky since there are always "fires" that have to be put out, and as things move faster, more coordination is needed to make everything work smoothly.
With so much time at work, there is very little personal time for any time with loved ones, projects, additional reading, or relaxation. I try and phone when I have free time (lunch and on the bus), but this is not the same as being around. If you are at this pace (or worse) for a prolonged period of time, that means you are on a death march. If this lasts longer than a few weeks (longer than three weeks maximum) it will start to take a toll. This is not the worse pace I have been on (I slept under my desk multiple consecutive nights earlier in my career), but it is a difficult one to maintain.
With so many tired devs, so much extra coordination, many interruptions, minimal code reviews, extra status updates, it becomes a tricky situation to balance. Throw in low energy, running on coffee and a lot of other tired developers and co-workers, it can quickly turn ugly if spirits are not high. Everyone wants to see the project out, but there is still a lot of work to do. I should probably take my vitamins.
Wish me luck,
Michael Hubbard
http://michaelhubbard.ca
Sunday, January 30, 2011
Why do people crunch?
I was asked by a friend an colleague: "why do people crunch"? This is not an easy one to answer. I suppose for everyone it is a little different, and is often based on the person themself, their attitude, personality and history. For me, I usually enjoy the work, and like the challenge and the feeling of accomplishment when all is said and done (to a point). There are others who will feel it is their duty and responsibility to complete a task to the best of their ability. Others still will fear the consequences if they do not get their work done, and for many it is likely a different combination of all of these responses (and more).
What a crunch can be, is a way of finally pushing the efforts of your labor out into the real world. It can be a symbol of pride to get your work out there, and to finally see it stand by itself. It is hopefully something to be proud of, to feel a sense of accomplishment and satisfaction of what was achieved (often the more difficult projects are the most rewarding in the end). Hopefully along the way you have gelled with the other developers and created a great and fun team.
The opposite end of the spectrum is a situation where whips crack, and people yell. Where all of your blood, sweat and tears is just going towards making someone else richer, and everyone on the team feels that way. While some overtime is almost always expected with any sort of programming job, a ridiculous work schedule should not be accepted for any job. Do what you can, and make sure that whatever you do, you work as a team. Making games should be fun, if it is not, something is going seriously wrong.
Best of luck,
Michael Hubbard,
http://michaelhubbard.ca
What a crunch can be, is a way of finally pushing the efforts of your labor out into the real world. It can be a symbol of pride to get your work out there, and to finally see it stand by itself. It is hopefully something to be proud of, to feel a sense of accomplishment and satisfaction of what was achieved (often the more difficult projects are the most rewarding in the end). Hopefully along the way you have gelled with the other developers and created a great and fun team.
The opposite end of the spectrum is a situation where whips crack, and people yell. Where all of your blood, sweat and tears is just going towards making someone else richer, and everyone on the team feels that way. While some overtime is almost always expected with any sort of programming job, a ridiculous work schedule should not be accepted for any job. Do what you can, and make sure that whatever you do, you work as a team. Making games should be fun, if it is not, something is going seriously wrong.
Best of luck,
Michael Hubbard,
http://michaelhubbard.ca
Friday, January 14, 2011
Choosing a Game Engine for a Project
So, you have a new project, lots of shiny new game engines abound, but which one to choose?
Forget the marketing, forget the bells and whistles, forget the hype. Instead get down to the basics.
1. What do your people know? Learning a new engine is time consuming, and without experts there will be numerous "gotchas" that can crop up in even the most tried and tested engines (someone will say "you need to do it the ____ way"). If you have to hire new people, make sure there is a market for those and the budget to get some expert skill level. This can be the biggest hurdle, and often the reason that you may not be able to go with the newest engine. Having a good community that supports the engine is also important.
2. Does the engine do everything you need? Does it really? Really, really? Doing your homework on what the engine can and can't do comes back to the first point. If you don't know what the engine is capable of, you should reach out to as many people as possible to get real experience with that engine.
3. Look at the history of the engine. What kind of games have been created with the engine? What kind of timeline, investment and skill set did it require to accomplish this? A game engine is not going to do everything for you, and knowing what developers, level designers, pipeline and server developers need to do to interact with the engine will let you know approximately what the engine can do.
4. How "unique" is your game? This is often a deal breaker for which engine to choose. If you are trying something that has never been done before, or has a high level of customization of different parts, you will likely hit a wall (in some engines sooner than others) where completing that task the "right" way can not be accomplished because of restrictions on the APIs the game engine provides. If you need to do things like access internal buffers, memory or anything else to accomplish your task, make sure your engine supports this flexibility. Unfortunately these kinds of requirements happen too late, but being aware of these kinds of issues will help you choose a flexible engine.
5. Where (and on what) is your game going to run? If the engine does not support multiple platforms this can be a significant amount of effort to port over to other operating systems. Some things can port easier than others, but each platform that needs to be supported will complicate the code base.
6. Do you have the source code? It is great to have the source in order to control your own destiny (although be sure to read the license agreement), but some game engine source code is not meant for public consumption. Often times the internal workings of the game engine are very difficult to modify or extend, and touching one line of source code will make merging future updates to the engine from the distributor one more complex task to manage. Open source game engines are pretty good, but they are still a bit behind the leading engines.
There is no "perfect" engine, all have strengths and weaknesses, all can make great or bad games. Be careful with this decision though, as it can be one of the biggest decisions for the path and people that work on your game.
Good luck and do your homework,
Michael Hubbard
http://michaelhubbard.ca
Forget the marketing, forget the bells and whistles, forget the hype. Instead get down to the basics.
1. What do your people know? Learning a new engine is time consuming, and without experts there will be numerous "gotchas" that can crop up in even the most tried and tested engines (someone will say "you need to do it the ____ way"). If you have to hire new people, make sure there is a market for those and the budget to get some expert skill level. This can be the biggest hurdle, and often the reason that you may not be able to go with the newest engine. Having a good community that supports the engine is also important.
2. Does the engine do everything you need? Does it really? Really, really? Doing your homework on what the engine can and can't do comes back to the first point. If you don't know what the engine is capable of, you should reach out to as many people as possible to get real experience with that engine.
3. Look at the history of the engine. What kind of games have been created with the engine? What kind of timeline, investment and skill set did it require to accomplish this? A game engine is not going to do everything for you, and knowing what developers, level designers, pipeline and server developers need to do to interact with the engine will let you know approximately what the engine can do.
4. How "unique" is your game? This is often a deal breaker for which engine to choose. If you are trying something that has never been done before, or has a high level of customization of different parts, you will likely hit a wall (in some engines sooner than others) where completing that task the "right" way can not be accomplished because of restrictions on the APIs the game engine provides. If you need to do things like access internal buffers, memory or anything else to accomplish your task, make sure your engine supports this flexibility. Unfortunately these kinds of requirements happen too late, but being aware of these kinds of issues will help you choose a flexible engine.
5. Where (and on what) is your game going to run? If the engine does not support multiple platforms this can be a significant amount of effort to port over to other operating systems. Some things can port easier than others, but each platform that needs to be supported will complicate the code base.
6. Do you have the source code? It is great to have the source in order to control your own destiny (although be sure to read the license agreement), but some game engine source code is not meant for public consumption. Often times the internal workings of the game engine are very difficult to modify or extend, and touching one line of source code will make merging future updates to the engine from the distributor one more complex task to manage. Open source game engines are pretty good, but they are still a bit behind the leading engines.
There is no "perfect" engine, all have strengths and weaknesses, all can make great or bad games. Be careful with this decision though, as it can be one of the biggest decisions for the path and people that work on your game.
Good luck and do your homework,
Michael Hubbard
http://michaelhubbard.ca
Monday, October 4, 2010
Day in the Life of a Game Programmer/ Team Lead
In order to improve my time (and hack my life) I have to know what it has in it. Here is my breakdown of an average (quiet) day, although it is still 9:00-6:30. We have been pretty good about doing 9:00-5:00 hours and that is what most of our guys do, and I would prefer to keep it that way. For me, every day is slightly different, some days I have five hours worth of meetings. Other days I do not leave the office till 8:00pm or come in the next day at 7:00am. It is still better than the hours I have spent at other companies, and have been a member of the 100 hours a week club more times than I would like. But this is a pretty good indication of what I would consider average for now, and with the hope I can get back to more 9:00-5:00 days once the major deadlines have passed.
The day starts for me (usually) at 7:00 AM, and I also included the time it takes for each task in parenthesis.
07:00-07:09 (00:09) Wake up, and then really wake up.
07:09-07:32 (00:23) Morning routine, get dressed.
07:32-07:53 (00:21) Make and eat breakfast while checking email.
07:53-07:59 (00:06) Cleanup, brush teeth, put shoes on.
07:59-08:17 (00:18) Leave apartment start walking to bus stop.
08:17-08:54 (00:37) Get on bus to work, start reading a book.
08:54-08:58 (00:04) Get off bus walk to office and my desk.
08:58-09:29 (00:31) Update code, check email, handle admin duties.
09:29-09:45 (00:16) Stand up meeting for half the dev team.
09:45-10:00 (00:15) Stand up meeting for other half of the devs.
10:00-10:30 (00:30) Assist devs requiring clarification on tasks.
10:30-10:36 (00:06) Write emails to other departments on tasks.
10:36-10:39 (00:03) Grab a glass of water.
10:39-10:45 (00:06) Help a developer find a bug they are fixing.
10:45-11:01 (00:16) Read source code and documentation.
11:01-11:35 (00:34) Code.
11:35-11:38 (00:03) Answer a few questions on a feature.
11:38-12:05 (00:27) Code.
12:05-01:00 (00:55) Lunch.
01:00-01:57 (00:57) Code and test, submit some updated APIs.
01:57-02:10 (00:13) Discuss bug fixes and design strategy.
02:10-02:23 (00:13) Code.
02:23-02:33 (00:10) Work with developer finding bugs.
02:33-02:40 (00:07) Code.
02:40-03:01 (00:21) Work with developer solving issue.
03:01-03:09 (00:08) Code.
03:09-03:21 (00:12) Help developer fix bugs.
03:21-03:27 (00:06) Get some tea.
03:27-03:37 (00:10) Code.
03:37-03:41 (00:04) Answer questions about code base.
03:41-04:00 (00:19) Reply to email and write additional email.
04:00-04:12 (00:12) Work on bug fixes with developer.
04:12-04:28 (00:16) Code.
04:28-05:01 (00:33) Read code review from large feature drop.
05:01-05:06 (00:05) Discuss some updates to a part of the code.
05:06-05:31 (00:25) Finish code review and add comments.
05:31-05:55 (00:24) Read updates to code base from other devs.
05:55-06:24 (00:29) Code and submit.
06:24-06:33 (00:09) Shut down, start walking to bus stop.
06:33-07:15 (00:42) Get on bus, read book.
07:15-07:24 (00:09) Get off bus, start walking home.
07:24-07:31 (00:07) Freshen up.
07:31-07:53 (00:22) Check mail and email.
07:53-08:36 (00:43) Make dinner, eat and cleanup.
08:36-09:56 (01:20) Personal code, while listening to music or tv.
09:56-10:41 (00:45) Get changed for gym, pump iron and shower.
10:41-11:45 (01:04) Play around on computer, code, art or games.
11:45-11:51 (00:06) Get ready for bed.
11:51-12:05 (00:14) Read a bit in bed.
12:05-06:59 (06:55) Sleep (perchance to dream).
Breakdown:
Work:
Administration (email, delegating tasks): 1 hour 53 minutes.
Breaks (lunch, coffee): 1 hour and 4 minutes.
Coding: 4 hours and 2 minutes.
Helping Others: 1 hour and 56 minutes.
Meetings: 31 minutes.
Home:
Computing (web surfing, project coding): 3 hours 7 minutes.
Exercise: 45 minutes.
Personal Maintenance (food, shower, etc.): 1 hour 34 minutes.
Reading (including bus travel time): 1 hour 33 minutes.
Sleep: 6 hours 55 minutes.
Travel (not including bus reading time): 40 minutes.
Other Facts:
Read 39 emails.
Sent 5 emails.
Added 37 comments to code review.
A few noteworthy points to consider about the data. The travel time is actually 1 hour and 59 minutes total for me every day, but I only counted the parts I do not do anything else (i.e. not the reading time). Looking over the numbers, it is interesting to see how much time is spent on helping others and administrative tasks. When I first joined the company as a game programmer, I was able to spend almost my full-time on coding and sent very few emails. However as time went on and more people were hired, I spent more time helping the other programmers too. Still, it is interesting to see how the day breaks down like this, and on further investigation where I can improve my use of time (like maybe try exercising in the morning as part of the regular morning routine)? Or take 30 minute lunches instead of the full hour and leave at 6:00 PM? Or try and come in earlier instead of leaving later?
Another thing to consider is how long it takes a game developer to get "in the zone". Some people at work estimate it can take up to ten minutes to get in the zone, but only one second to get out of it. While it would be great to minimize interruptions, it is far better for me to help remove the other developers roadblocks whenever possible.
Anyway, I will think over the data and may update any changes I made to my day, in a future post.
Until then,
Michael Hubbard
http://michaelhubbard.ca
The day starts for me (usually) at 7:00 AM, and I also included the time it takes for each task in parenthesis.
07:00-07:09 (00:09) Wake up, and then really wake up.
07:09-07:32 (00:23) Morning routine, get dressed.
07:32-07:53 (00:21) Make and eat breakfast while checking email.
07:53-07:59 (00:06) Cleanup, brush teeth, put shoes on.
07:59-08:17 (00:18) Leave apartment start walking to bus stop.
08:17-08:54 (00:37) Get on bus to work, start reading a book.
08:54-08:58 (00:04) Get off bus walk to office and my desk.
08:58-09:29 (00:31) Update code, check email, handle admin duties.
09:29-09:45 (00:16) Stand up meeting for half the dev team.
09:45-10:00 (00:15) Stand up meeting for other half of the devs.
10:00-10:30 (00:30) Assist devs requiring clarification on tasks.
10:30-10:36 (00:06) Write emails to other departments on tasks.
10:36-10:39 (00:03) Grab a glass of water.
10:39-10:45 (00:06) Help a developer find a bug they are fixing.
10:45-11:01 (00:16) Read source code and documentation.
11:01-11:35 (00:34) Code.
11:35-11:38 (00:03) Answer a few questions on a feature.
11:38-12:05 (00:27) Code.
12:05-01:00 (00:55) Lunch.
01:00-01:57 (00:57) Code and test, submit some updated APIs.
01:57-02:10 (00:13) Discuss bug fixes and design strategy.
02:10-02:23 (00:13) Code.
02:23-02:33 (00:10) Work with developer finding bugs.
02:33-02:40 (00:07) Code.
02:40-03:01 (00:21) Work with developer solving issue.
03:01-03:09 (00:08) Code.
03:09-03:21 (00:12) Help developer fix bugs.
03:21-03:27 (00:06) Get some tea.
03:27-03:37 (00:10) Code.
03:37-03:41 (00:04) Answer questions about code base.
03:41-04:00 (00:19) Reply to email and write additional email.
04:00-04:12 (00:12) Work on bug fixes with developer.
04:12-04:28 (00:16) Code.
04:28-05:01 (00:33) Read code review from large feature drop.
05:01-05:06 (00:05) Discuss some updates to a part of the code.
05:06-05:31 (00:25) Finish code review and add comments.
05:31-05:55 (00:24) Read updates to code base from other devs.
05:55-06:24 (00:29) Code and submit.
06:24-06:33 (00:09) Shut down, start walking to bus stop.
06:33-07:15 (00:42) Get on bus, read book.
07:15-07:24 (00:09) Get off bus, start walking home.
07:24-07:31 (00:07) Freshen up.
07:31-07:53 (00:22) Check mail and email.
07:53-08:36 (00:43) Make dinner, eat and cleanup.
08:36-09:56 (01:20) Personal code, while listening to music or tv.
09:56-10:41 (00:45) Get changed for gym, pump iron and shower.
10:41-11:45 (01:04) Play around on computer, code, art or games.
11:45-11:51 (00:06) Get ready for bed.
11:51-12:05 (00:14) Read a bit in bed.
12:05-06:59 (06:55) Sleep (perchance to dream).
Breakdown:
Work:
Administration (email, delegating tasks): 1 hour 53 minutes.
Breaks (lunch, coffee): 1 hour and 4 minutes.
Coding: 4 hours and 2 minutes.
Helping Others: 1 hour and 56 minutes.
Meetings: 31 minutes.
Home:
Computing (web surfing, project coding): 3 hours 7 minutes.
Exercise: 45 minutes.
Personal Maintenance (food, shower, etc.): 1 hour 34 minutes.
Reading (including bus travel time): 1 hour 33 minutes.
Sleep: 6 hours 55 minutes.
Travel (not including bus reading time): 40 minutes.
Other Facts:
Read 39 emails.
Sent 5 emails.
Added 37 comments to code review.
A few noteworthy points to consider about the data. The travel time is actually 1 hour and 59 minutes total for me every day, but I only counted the parts I do not do anything else (i.e. not the reading time). Looking over the numbers, it is interesting to see how much time is spent on helping others and administrative tasks. When I first joined the company as a game programmer, I was able to spend almost my full-time on coding and sent very few emails. However as time went on and more people were hired, I spent more time helping the other programmers too. Still, it is interesting to see how the day breaks down like this, and on further investigation where I can improve my use of time (like maybe try exercising in the morning as part of the regular morning routine)? Or take 30 minute lunches instead of the full hour and leave at 6:00 PM? Or try and come in earlier instead of leaving later?
Another thing to consider is how long it takes a game developer to get "in the zone". Some people at work estimate it can take up to ten minutes to get in the zone, but only one second to get out of it. While it would be great to minimize interruptions, it is far better for me to help remove the other developers roadblocks whenever possible.
Anyway, I will think over the data and may update any changes I made to my day, in a future post.
Until then,
Michael Hubbard
http://michaelhubbard.ca
Tuesday, September 28, 2010
Game performance and optimization
The question of performance and what can benefit from additional work optimizing code (or art) is a very complex problem. To grossly oversimplify the questions of performance, it is worth looking at a few of the terms used to describe what involved in the actual measure of performance. Usually when talking with people about a game's performance in simplistic terms they will focus on fps (frames-per-second) but there are many other considerations memory usage, texture memory usage, cpu usage, gpu usage, network usage (if applicable) or things like load time, amount of loads, and more. To measure any of these it is worth focusing on testing different types of components, and the platform and/or engine and getting minimum specs for what you need (size of art assets, number of triangles, animations, size of textures, number of lights, number of postprocess fx, complexity of shaders, etc.), the list goes on and on.
One thing that is often talked about CPU bound vs GPU bound, meaning that one of these systems is a bottleneck for the other.
CPU bound could be for a lot of processing, physics calculations (on the CPU) or a lot of other complex calculations (searching or sorting large amounts of data or complex AI calculations like pathfinding).
GPU bound if a lot of polygons, high resolution textures, or dealing with a lot complex shaders (often with multiple lights and shadows).
The best approach is to find the first largest bottleneck and try to minimize it, then the next largest and so on. While it is sometimes worthwhile to look at the code and try and optimize it (things like replacing divides, multiplications ect. with bitshifts and attempting to precalculate as much as possible before actually hitting runtime), this won't solve the problem if the game falls over from huge art assets that the hardware does not easily support. It is often considered that premature optimization is a huge mistake, since it is often difficult to know if you are optimizing the right part of the code (and often the code becomes significantly more complex and more difficult to maintain if it is optimized). It is still worthwhile to make as efficient code as possible while writing it (considering order of magnitude algorthims (big O notation)), but if you don't actually test with real data, you may be wasting huge amounts of time optomizing the wrong thing.
In terms of performance and optimizations, I almost always come back to an example that a colleague of mine gave me that he saw on a previous project. The project was on a 3D handheld and the team wanted to add a depth of field postprocess render fx to the game, but were worried that the performance hit would be too expensive. They decided that the look was so cool, they had to try it and see what it would cost. What they found was that by adding this fx they actually got better performance! On this particular 3D handheld both the CPU and GPU shared the same bus, so by adding this postprocess fx the bus was freed up to handle a lot of CPU processing, while the GPU was dealing with this more complex rendering. Not an easy thing to estimate or plan for :P
There are a few useful tools in helping debug performance, PerfStudio for AMD http://developer.amd.com/gpu/PerfStudio/Pages/default.aspx and PerfHUD for NVIDIA http://developer.nvidia.com/object/nvperfhud_home.html are great tools for seeing the low level API calls to the graphics card as well as debugging tools for texture visualization and overrides which are great for shader debugging, checking mipmap level etc.
One of the things that really impressed me in the UDK was the use of performance and memory built right into the editor, as well as things like mipmap levels, shader complexity, that are great ways of helping artists debug scenes and texture sizes. Unity3D offers a few tools (like the stats window and profiler) to help see where some of the memory is being used, but I haven't seen it at the level of UDK anywhere (and will still need to look at XNA, but without an editor, it may be difficult to provide any of these kinds of tools).
In the end, it all comes down to trade offs, and what you can live with for performance for your game, usually at the expense of something else, and hopefully not too much of the visual look. It is worthwhile to develop some tests that check for significant changes in memory usage, video memory usage, frame rate, etc. on every commit (or at least everyday) to help catch these memory issues as soon as possible (especially on a large project).
Best of luck optimizing,
Michael Hubbard
http://michaelhubbard.ca
One thing that is often talked about CPU bound vs GPU bound, meaning that one of these systems is a bottleneck for the other.
CPU bound could be for a lot of processing, physics calculations (on the CPU) or a lot of other complex calculations (searching or sorting large amounts of data or complex AI calculations like pathfinding).
GPU bound if a lot of polygons, high resolution textures, or dealing with a lot complex shaders (often with multiple lights and shadows).
The best approach is to find the first largest bottleneck and try to minimize it, then the next largest and so on. While it is sometimes worthwhile to look at the code and try and optimize it (things like replacing divides, multiplications ect. with bitshifts and attempting to precalculate as much as possible before actually hitting runtime), this won't solve the problem if the game falls over from huge art assets that the hardware does not easily support. It is often considered that premature optimization is a huge mistake, since it is often difficult to know if you are optimizing the right part of the code (and often the code becomes significantly more complex and more difficult to maintain if it is optimized). It is still worthwhile to make as efficient code as possible while writing it (considering order of magnitude algorthims (big O notation)), but if you don't actually test with real data, you may be wasting huge amounts of time optomizing the wrong thing.
In terms of performance and optimizations, I almost always come back to an example that a colleague of mine gave me that he saw on a previous project. The project was on a 3D handheld and the team wanted to add a depth of field postprocess render fx to the game, but were worried that the performance hit would be too expensive. They decided that the look was so cool, they had to try it and see what it would cost. What they found was that by adding this fx they actually got better performance! On this particular 3D handheld both the CPU and GPU shared the same bus, so by adding this postprocess fx the bus was freed up to handle a lot of CPU processing, while the GPU was dealing with this more complex rendering. Not an easy thing to estimate or plan for :P
There are a few useful tools in helping debug performance, PerfStudio for AMD http://developer.amd.com/gpu/PerfStudio/Pages/default.aspx and PerfHUD for NVIDIA http://developer.nvidia.com/object/nvperfhud_home.html are great tools for seeing the low level API calls to the graphics card as well as debugging tools for texture visualization and overrides which are great for shader debugging, checking mipmap level etc.
One of the things that really impressed me in the UDK was the use of performance and memory built right into the editor, as well as things like mipmap levels, shader complexity, that are great ways of helping artists debug scenes and texture sizes. Unity3D offers a few tools (like the stats window and profiler) to help see where some of the memory is being used, but I haven't seen it at the level of UDK anywhere (and will still need to look at XNA, but without an editor, it may be difficult to provide any of these kinds of tools).
In the end, it all comes down to trade offs, and what you can live with for performance for your game, usually at the expense of something else, and hopefully not too much of the visual look. It is worthwhile to develop some tests that check for significant changes in memory usage, video memory usage, frame rate, etc. on every commit (or at least everyday) to help catch these memory issues as soon as possible (especially on a large project).
Best of luck optimizing,
Michael Hubbard
http://michaelhubbard.ca
Tuesday, August 11, 2009
Welcome to Game Programmer Technical Artist Blog
Hello Blog Reader,
I am here to share my interests in game programming, art pipelines, shaders and technology. First a little introduction.
My name is Michael Hubbard and I have been a Game Programmer / Technical Artist for a couple of years now focusing on both game play aspects and the art pipeline. I began professional programming on the Allen Bradley PLC 5 and SLC 500s working on logic controls for a gold room security system. From that I decided to become a game programmer (cause if you are gonna work you might as well play too) and I had always loved games since I first placed my Dad's old Atari 800 XL (with such classics as Lode Runner, Archon, River Raid and dozens more) as well racking up considerable play time in the arcade, NES, SNES, Genesis, N64, Wii, Playstation, 2, 3, Xbox, 360, PC, Gameboy, DS, PSP and now the iPhone.
My first job in the game industry was working as a Art Engineer / Game Developer for Leap In Entertainment, and the product JustLeapIn it is worth checking out if I do say so myself.
Currently I am developing iPhone games at Hooler Studios and I will post the game links when Apple have finished their reviews.
Otherwise I plan on making this a blog about my own experiences and technical achievements (and sometimes the struggles), and hope that they will be of interest to anyone passing by.
Bye for now,
Michael Hubbard
http://michaelhubbard.ca
I am here to share my interests in game programming, art pipelines, shaders and technology. First a little introduction.
My name is Michael Hubbard and I have been a Game Programmer / Technical Artist for a couple of years now focusing on both game play aspects and the art pipeline. I began professional programming on the Allen Bradley PLC 5 and SLC 500s working on logic controls for a gold room security system. From that I decided to become a game programmer (cause if you are gonna work you might as well play too) and I had always loved games since I first placed my Dad's old Atari 800 XL (with such classics as Lode Runner, Archon, River Raid and dozens more) as well racking up considerable play time in the arcade, NES, SNES, Genesis, N64, Wii, Playstation, 2, 3, Xbox, 360, PC, Gameboy, DS, PSP and now the iPhone.
My first job in the game industry was working as a Art Engineer / Game Developer for Leap In Entertainment, and the product JustLeapIn it is worth checking out if I do say so myself.
Currently I am developing iPhone games at Hooler Studios and I will post the game links when Apple have finished their reviews.
Otherwise I plan on making this a blog about my own experiences and technical achievements (and sometimes the struggles), and hope that they will be of interest to anyone passing by.
Bye for now,
Michael Hubbard
http://michaelhubbard.ca
Subscribe to:
Posts (Atom)