It's not really exact, since the C64 existed in 2 forms: one for the US and one for the Europe.
I vaguely remember that it introduced a difference in the fast disk-loading routine mentioned in a message above, because there was one cycle of difference (yes, simply a NOP).
If somebody is interested, I can dig in my very old source code to retrieve this information (I coded several games for the C64 in the years 1985-1988).
I suppose this is some sort of primitive way to count objects, like an abacus but written on eggshells, since they didn't know paper at this time. There are a lot of segments, and they probably didn't have an advanced mathematical system to represent large numbers.
How can the searchers deduce it's some undecipherable writing ? This is a mystery for me.
Kociemba is the creator of a very fast algorithm that solves most of the cubes in less than 25 moves in one second, using a two-phase technique (by using large precomputed tables).
Even with a slow robot only able to execute 2 moves every second, it's easy to reach 12 seconds that way.
BTW, the human records are below the 10 seconds limit: http://www.speedcubing.com/records/recs_cube_333av.html Average means that the human solves several cubes and computes the average time to solve them all. Of course, humans can rotate the faces a lot faster than a robot.
So for a long term saving, it's often cheaper to stay with what you've got (or for a new installation, choose the same as everyone else) and pay a lot of licensefees, than to change to something that's cheaper in licensing and have a shitload of other costs.
With Windows, you have to pay for license fees, and you have to pay every ten years (and I suppose that their next OS will have much smaller lifespan).
Either for Windows or Linux, you'll have a lot of hidden costs. For Linux, it may be the users needing to be trained once, or the cost of a team for managing your computers. For Windows, you'll need an antivirus if you don't want to spend your time reinstalling the computers, you'll have to renew all your licenses every few years, and train your users after every new version since Office will probably change its interface in the next version (to be 'easier' for the users). Maybe you'll be able to use a smaller team to manage your computers, but in my experience, administrators did a pretty awful job on Windows, except when they stopped changing the configurations.
I think what is important is not the amount of money you'll save in the short term, but in the long term.
It may be expensive to train the users at first, but if your computers are never upgraded (and have no virus problems), it will save you a lot of money. On the contrary, if you always need the latest versions, it's obvious that it will cost you a lot of money.
My perception is that corporate companies don't really need all the latest features of Office. People want to be able to build nice presentations, use preformatted documents or send emails, I think you can find these tools on Linux as well.
If you really need Windows, for example for Exchange, it's better to only buy them as servers, since qualified people will be less likely to mess them.
Also, evaluating a single chunk is more accurate than evaluating a whole project.
We use cards for keeping track of all the tasks and assign them a number of points, given the complexity of the card. This does not mean that a complex card will take more time than an easier card, but it gives a good average value.
Oh, and our velocity is always very low, except when we have very small tasks...
So, splitting a task in very small chunks helps motivate the coders, since they think they are very fast;-)
It's interesting to note that movie-making has become very much a waterfall model business. A few decades ago, moviemaking was much more "agile", and most directors came from a theatrical background. For a theatrical director, there's a debugging phase involving actors on a bare stage, and the content may change considerably during development. Big-budget moviemaking today involves going from script to storyboard to previsualization (making a low-end animated version as a planning tool) to production. That's very much a waterfall process.
Yes, you are right. When a sector becomes mature, a process can be defined. But this is because making a movie is very expensive, and much more than creating a video game. On the very few games costing more than 10 millions, there is a lot of procedures.
"Agile" methodologies are most appropriate when the project consists of a large number of loosely coupled user-oriented features with no major architectural or technical innovations. Like PHP-based web sites. Or, in fact, much programming which involves using an existing "framework". Someone else has already figured out what the different parts of the system need to say to each other and roughly how they will say it. Development is mostly filling in the blanks.
Hum, as an ex-game programmer and a current agile developer, I have to say that you are wrong.
Writing a game now requires using lots of frameworks (3D engine, controller input, and in some cases AI).
Using frameworks has nothing to do with agile programming. Note also that programming nowadays has become like playing with Legos: you use the pieces that you bought, and you never build your own pieces.
As the article states, using agile will slow down your progress by at least 15%, but you'll have an average of 60% less bugs (quality might not be an important factor in a game).
Although I use agile methodologies, I know that some of them don't work with everybody. Pair programming is the typical example that won't work in game programming. Why ? Simply because you cannot afford to write every line of code by two programmers when you write a game.
What works in agile are:
1) TDD (test-driven development): writing tests before or at least covering your code with tests. 2) Tasks splitting: split your project in small tasks, and define what you expect from every task (we use cards for that). 3) Pair committing: every commit must be reviewed by two programmers. This reduces the obvious bugs. 4) Minimal effort: always write the smallest amount of code to write a task. Don't start building a skyscraper when you need a home. 5) Daily standup meeting: all the team stand up and talk about their progress during one minute per person 6) Iterative process: define small 'milestones' named iterations, for example every two weeks. At the beginning of the iteration, you define what tasks you want to be done. At the end, you check what has been done. 7) Continuous integration: when you commit, a build is launched and the tests are executed. If you break the build, you fix it immediately. 8) Retrospective: at the end of every iteration, take some hours (one hour per week is enough) to analyze what went right and what went wrong. It's like a post-mortem (check Gamasutra's post-mortems), and allows you to better react when there are problems.
As agile processes are people-centric, every team should have its own rules.
Frankly, optimizing assembly code is a PITA, since there are so much different flavors. For example, AMD and Intel processors have different types of optimization.
If I were to code in assembly nowadays, I'd prefer to use something like LLVM: http://llvm.org/ which should be able to generate good optimized code for any kind of processors, without the hassle of maintaining one routine per processor.
In some very extreme cases (like coding a RC5 decoder or multiprecision routines), it's still useful to use assembler, but in most other cases, I'm sure that LLVM is able to generate code much better than you could achieve manually in the same amount of time.
Right...and raped women are responsible for their rape.
That's a very bad analogy. There is no violence from the managers (in case of a rape, I doubt that this is the case).
A few people here already explained why the employees were partly responsible for their enslavement. I'll give you some other arguments.
On one side, you have young guys who never worked previously (or who know only the game industry) and who dream about writing games (because they love them). On the other side, you have companies that need to release a game at a given date (yes, it's for the next september !). The only way that these companies know is to pressure these guys so that they will work days and nights until the game is finished.
Now, take the place of the coders, they don't even think that there is another option than to work 24/7.
It's the job of the managers to realize this, but the managers have to maintain a team of 40+ people (and frankly, managing people is not really their priority, since they concentrate on the technical problems, like making sure that the graphic artists deliver their part on time, that the music will fit with the game, etc...). So, we have now a whole team of people working like crazy to deliver a product.
I'll take a real case: Ubisoft China on Splinter Cell. Ubisoft wanted to reduce the cost of their games, since the french and canadian divisions have a lot of well paid people. Why not try China ? For the same amount of money, they can hire plenty of engineers (and by plenty, I mean 10 times more than the occidental divisions). Since they are engineers, it will be easy for them to write games, nothing could go wrong, right ? And if there is a problem, they could always hire more people.
So the development starts. After several months, they realize that the engineers never worked on games, and have no idea how to make one. They hire more workforce, since they hope that within all these employees, a few of them will be able to do something meaningful (I won't tell you that all the employees already work 24/7 at this stage). A few months pass, and the problem is still unsolved, except that the release date approaches. Now, Ubisoft realized that the game won't finish in time, so the solution was to reinforce the team with a lot of experienced people from France and Canada (and yes, the cost skyrocketed here).
When the game is finished, all the tension disappears in an instant, and a lot of people ask themselves why it was such a nighmare to work on this project. They hate the project, but they have no solution to change the situation.
What is the lesson to learn ? No, it's not that chinese coders are unable to write games. The lesson to learn is that it's absolutely useless to work 24/7 if you have no idea how to finish the game. Just take a pause, and realize that coding the game needs to be done little by little, not everything at the same time (that is what the managers all think: I need to have all the code ready so that I can start scripting the levels, or for graphists: I need all the first level to start scripting).
it's all the same thing, an attempt to quantify a programmer's productivity
In my 20 years experience, no manager ever used metrics for code, since none of them ever coded. Their best criterion is your amount of presence. Working 10 hours in a corner won't help you either, you have to brag about it, and criticize people that are present during less hours than you. It's a pretty wicked system, where the more victimized will criticize the less victimized.
Now, a good manager can and should be aware of such details in the people for whom he is responsible, and should make an effort to understand why some programmers perform better than others.
Managers don't care about coders, they have a team of 40+ people (and in general, half of the team has a personality problem), so they really can't concentrate on a few people, or it would take all their time. And for them, coding is like magic, so they tend to prefer artists, because they can grasp their work easily (how could you understand the beauty of a few lines of code if you are not programmer yourself ?).
Managers are so stressed (because of the deadline, or because if the project fails, the company dies), so they will pass their stress to all the team.
BTW, who cares of quality, the project is already so late !
I happen to work for such a manager right now
Wow, you are so lucky, but let me guess: you are not working into the game industry anymore.
When coding games, I once encountered such a manager, but the company went down because the project was so huge they were never able to finish it (it was so obvious when I entered this project, I quit after one month).
The reason this kind of abuse happens routinely is Managers can get away with it and Coders let them.
Yes, you are right, but managers will only hire people that they can enslave.
And this explains why the coders are so young and inexperienced. The coders still believe that making games is a passion, so why not spend all their time on their work ? It's so fun !
He could be describing Electronic Arts. Look, the game industry has been run this way for the better part of thirty years. I worked as a coder for a couple of game companies back in the mid-eighties... and I left for the reasons described in the summary.
I totally agree: I worked for several companies during 20 years in France, and this behavior can be found in 50% of the companies. But it's the fault of the employees, because they don't know how to set limits.
Since most of the developers are young or inexperienced, they don't have a life outside of their work. Once I realized this trick, I told them that I will start at a given hour, and will return home at another given hour, and I was probably the only one in my company to do that, and I became their most efficient coder.
I also remember a job interview, where the project leader told me that doing an all-nighter occasionally was very beneficial for the group (WTF !).
As much as I enjoyed that line of work, management practices were abusive even then.
It's true, but it's because:
- the managers don't know how to lead a project (90% of the cases)
- the managers are not coders themselves (95% of the cases)
- the managers never finished a game before (99% of the cases)
- the managers never encountered another way of work (100% of the cases)
The problem is managers that use simple metrics like lines of code written per day to determine a developer's value.
No, this is not true. What is valued is the number of hours you do every day. It doesn't matter if you do something or not !!! I worked 8 hours a day, but was less considered than some other guys who were working 2 hours, but been present 10 hours. Also, socializing is an important part if you are ambitious and want to be paid more, so it's necessary to spend your time chatting with the management, otherwise you'll be ignored (of course, I never did that and my salary stagnated).
In general, any project is already late as soon as it begins. Working 12 hours every day won't help the game finish in time (and in general, it does the opposite by draining the energy out of the team).
The problem is that the games start with too much elements, instead of building progressively. So, you have to code everything from the beginning, and that's very bad. And worse, the final goal changes constantly. Also, when a game is really on time (by some miracle), managers tend to add even more features, because they suppose that the programmers will easily code them.
The real solution is to stop building large games at the very beginning, and simply add one feature after another. When the time runs out, you'll have at least something to deliver, not incomplete parts everywhere.
upper management is hiring sadists to run their development teams
No, it's just that everybody only knows this bad way of working, and nobody intends to change that: they don't have the time to try other ways !!!
This work process is so bad that 30% of the coders leave the company at the end of an exhausting project. That's why there is so much turnover in game companies.
Interesting stuff. Just don't think you will be writing software with this.
Since a few years, programming has become equivalent to placing Lego bricks in the correct order (I'm working with Microsoft.NET and tons of components).
So I'm not very surprised by the approach, as long as we can find all the possible varieties of pieces.
A few years ago, when Microsoft's Windows source code was leaked, a hacker found a problem in the handling of the standard BMP format (IIRC, it was an integer that was not considered signed, and it contained the size of the picture), which could allow arbitrary code execution.
What bothers me is that Apple's developers don't check if they have the same problems as their direct competitor.
IE's reputation is terrible. It's so bad that it's tainting all their other softwares. On the contrary, Google is really working hard to create a strong brand.
Microsoft should not declare that IE8 is one of the most secure browsers (even if it's partially true). People don't even know how to differentiate between IE6 and IE8 ! In my company, some people uses IE and google our company name to get to our homepage !
Microsoft should instead try to rename the browser to something like IEasy, or whatever, like they did with Vista. Then once the new browser will be completely hacked, rename it to something like IE10, so that everybody will have forgotten the terrible brand.
Anyway, it's entirely their fault that Web development became such a nightmare, and forced large companies to keep IE6 due to the ugly ActiveX components.
Sitting at home wanking in front of the computer screen is not an activity around which groups tend to organize.
Do not forget that: 1) prostitution is illegal in China 2) pornography is illegal in China, so it's not possible to get porn videos easily 3) in the current generation, there are more men than women (because of the unique child policy, the chinese preferred to get guys than girls), so it's not easy to get married
Add to this the fact that they can't use Internet for pornography, and we can just imagine the level of frustration. Such an amount of frustration will only lead to increased violence (and the women are the first targets with rapes).
Slashdot Mirror
Probably, but the Basic was written by Microsoft, and the ROM took 16 Kb (not counting the code when using a disk-drive).
Since an opcode is between 1 and 3 bytes, there would be around 8000 to 10000 LoC.
It's not really exact, since the C64 existed in 2 forms: one for the US and one for the Europe.
I vaguely remember that it introduced a difference in the fast disk-loading routine mentioned in a message above, because there was one cycle of difference (yes, simply a NOP).
If somebody is interested, I can dig in my very old source code to retrieve this information (I coded several games for the C64 in the years 1985-1988).
Did you try hitting F12 and change the compatibility mode ?
For example, Virtual PC does not work in IE8 mode, and this is the only way to make it work.
you might be interested in something like this: http://www.filehippo.com/updatechecker/
Here are 2 better ones:
http://www.kcsoftwares.com/index.php?sumo
http://cleansofts.org/view/update-notifier.html
They are free too.
The only thing I see is vertical segments.
I suppose this is some sort of primitive way to count objects, like an abacus but written on eggshells, since they didn't know paper at this time.
There are a lot of segments, and they probably didn't have an advanced mathematical system to represent large numbers.
How can the searchers deduce it's some undecipherable writing ? This is a mystery for me.
They probably used Herbert Kociemba's program:
http://kociemba.org/cube.htm
check the webcam section.
Kociemba is the creator of a very fast algorithm that solves most of the cubes in less than 25 moves in one second, using a two-phase technique (by using large precomputed tables).
Even with a slow robot only able to execute 2 moves every second, it's easy to reach 12 seconds that way.
BTW, the human records are below the 10 seconds limit:
http://www.speedcubing.com/records/recs_cube_333av.html
Average means that the human solves several cubes and computes the average time to solve them all.
Of course, humans can rotate the faces a lot faster than a robot.
So for a long term saving, it's often cheaper to stay with what you've got (or for a new installation, choose the same as everyone else) and pay a lot of licensefees, than to change to something that's cheaper in licensing and have a shitload of other costs.
With Windows, you have to pay for license fees, and you have to pay every ten years (and I suppose that their next OS will have much smaller lifespan).
Either for Windows or Linux, you'll have a lot of hidden costs.
For Linux, it may be the users needing to be trained once, or the cost of a team for managing your computers.
For Windows, you'll need an antivirus if you don't want to spend your time reinstalling the computers, you'll have to renew all your licenses every few years, and train your users after every new version since Office will probably change its interface in the next version (to be 'easier' for the users). Maybe you'll be able to use a smaller team to manage your computers, but in my experience, administrators did a pretty awful job on Windows, except when they stopped changing the configurations.
I think what is important is not the amount of money you'll save in the short term, but in the long term.
It may be expensive to train the users at first, but if your computers are never upgraded (and have no virus problems), it will save you a lot of money.
On the contrary, if you always need the latest versions, it's obvious that it will cost you a lot of money.
My perception is that corporate companies don't really need all the latest features of Office.
People want to be able to build nice presentations, use preformatted documents or send emails, I think you can find these tools on Linux as well.
If you really need Windows, for example for Exchange, it's better to only buy them as servers, since qualified people will be less likely to mess them.
My motto is:
Don't buy it if you don't need it !
Also, evaluating a single chunk is more accurate than evaluating a whole project.
We use cards for keeping track of all the tasks and assign them a number of points, given the complexity of the card.
This does not mean that a complex card will take more time than an easier card, but it gives a good average value.
Oh, and our velocity is always very low, except when we have very small tasks...
So, splitting a task in very small chunks helps motivate the coders, since they think they are very fast ;-)
It's interesting to note that movie-making has become very much a waterfall model business. A few decades ago, moviemaking was much more "agile", and most directors came from a theatrical background. For a theatrical director, there's a debugging phase involving actors on a bare stage, and the content may change considerably during development. Big-budget moviemaking today involves going from script to storyboard to previsualization (making a low-end animated version as a planning tool) to production. That's very much a waterfall process.
Yes, you are right.
When a sector becomes mature, a process can be defined.
But this is because making a movie is very expensive, and much more than creating a video game.
On the very few games costing more than 10 millions, there is a lot of procedures.
"Agile" methodologies are most appropriate when the project consists of a large number of loosely coupled user-oriented features with no major architectural or technical innovations. Like PHP-based web sites. Or, in fact, much programming which involves using an existing "framework". Someone else has already figured out what the different parts of the system need to say to each other and roughly how they will say it. Development is mostly filling in the blanks.
Hum, as an ex-game programmer and a current agile developer, I have to say that you are wrong.
Writing a game now requires using lots of frameworks (3D engine, controller input, and in some cases AI).
Using frameworks has nothing to do with agile programming. Note also that programming nowadays has become like playing with Legos: you use the pieces that you bought, and you never build your own pieces.
As the article states, using agile will slow down your progress by at least 15%, but you'll have an average of 60% less bugs (quality might not be an important factor in a game).
Although I use agile methodologies, I know that some of them don't work with everybody.
Pair programming is the typical example that won't work in game programming.
Why ? Simply because you cannot afford to write every line of code by two programmers when you write a game.
What works in agile are:
1) TDD (test-driven development): writing tests before or at least covering your code with tests.
2) Tasks splitting: split your project in small tasks, and define what you expect from every task (we use cards for that).
3) Pair committing: every commit must be reviewed by two programmers. This reduces the obvious bugs.
4) Minimal effort: always write the smallest amount of code to write a task. Don't start building a skyscraper when you need a home.
5) Daily standup meeting: all the team stand up and talk about their progress during one minute per person
6) Iterative process: define small 'milestones' named iterations, for example every two weeks. At the beginning of the iteration, you define what tasks you want to be done. At the end, you check what has been done.
7) Continuous integration: when you commit, a build is launched and the tests are executed. If you break the build, you fix it immediately.
8) Retrospective: at the end of every iteration, take some hours (one hour per week is enough) to analyze what went right and what went wrong. It's like a post-mortem (check Gamasutra's post-mortems), and allows you to better react when there are problems.
As agile processes are people-centric, every team should have its own rules.
Frankly, optimizing assembly code is a PITA, since there are so much different flavors.
For example, AMD and Intel processors have different types of optimization.
If I were to code in assembly nowadays, I'd prefer to use something like LLVM: http://llvm.org/ which should be able to generate good optimized code for any kind of processors, without the hassle of maintaining one routine per processor.
In some very extreme cases (like coding a RC5 decoder or multiprecision routines), it's still useful to use assembler, but in most other cases, I'm sure that LLVM is able to generate code much better than you could achieve manually in the same amount of time.
Right...and raped women are responsible for their rape.
That's a very bad analogy.
There is no violence from the managers (in case of a rape, I doubt that this is the case).
A few people here already explained why the employees were partly responsible for their enslavement.
I'll give you some other arguments.
On one side, you have young guys who never worked previously (or who know only the game industry) and who dream about writing games (because they love them).
On the other side, you have companies that need to release a game at a given date (yes, it's for the next september !).
The only way that these companies know is to pressure these guys so that they will work days and nights until the game is finished.
Now, take the place of the coders, they don't even think that there is another option than to work 24/7.
It's the job of the managers to realize this, but the managers have to maintain a team of 40+ people (and frankly, managing people is not really their priority, since they concentrate on the technical problems, like making sure that the graphic artists deliver their part on time, that the music will fit with the game, etc...).
So, we have now a whole team of people working like crazy to deliver a product.
I'll take a real case: Ubisoft China on Splinter Cell.
Ubisoft wanted to reduce the cost of their games, since the french and canadian divisions have a lot of well paid people.
Why not try China ?
For the same amount of money, they can hire plenty of engineers (and by plenty, I mean 10 times more than the occidental divisions).
Since they are engineers, it will be easy for them to write games, nothing could go wrong, right ?
And if there is a problem, they could always hire more people.
So the development starts. After several months, they realize that the engineers never worked on games, and have no idea how to make one.
They hire more workforce, since they hope that within all these employees, a few of them will be able to do something meaningful (I won't tell you that all the employees already work 24/7 at this stage).
A few months pass, and the problem is still unsolved, except that the release date approaches.
Now, Ubisoft realized that the game won't finish in time, so the solution was to reinforce the team with a lot of experienced people from France and Canada (and yes, the cost skyrocketed here).
When the game is finished, all the tension disappears in an instant, and a lot of people ask themselves why it was such a nighmare to work on this project. They hate the project, but they have no solution to change the situation.
What is the lesson to learn ?
No, it's not that chinese coders are unable to write games.
The lesson to learn is that it's absolutely useless to work 24/7 if you have no idea how to finish the game.
Just take a pause, and realize that coding the game needs to be done little by little, not everything at the same time (that is what the managers all think: I need to have all the code ready so that I can start scripting the levels, or for graphists: I need all the first level to start scripting).
it's all the same thing, an attempt to quantify a programmer's productivity
In my 20 years experience, no manager ever used metrics for code, since none of them ever coded.
Their best criterion is your amount of presence.
Working 10 hours in a corner won't help you either, you have to brag about it, and criticize people that are present during less hours than you.
It's a pretty wicked system, where the more victimized will criticize the less victimized.
Now, a good manager can and should be aware of such details in the people for whom he is responsible, and should make an effort to understand why some programmers perform better than others.
Managers don't care about coders, they have a team of 40+ people (and in general, half of the team has a personality problem), so they really can't concentrate on a few people, or it would take all their time.
And for them, coding is like magic, so they tend to prefer artists, because they can grasp their work easily (how could you understand the beauty of a few lines of code if you are not programmer yourself ?).
Managers are so stressed (because of the deadline, or because if the project fails, the company dies), so they will pass their stress to all the team.
BTW, who cares of quality, the project is already so late !
I happen to work for such a manager right now
Wow, you are so lucky, but let me guess: you are not working into the game industry anymore.
When coding games, I once encountered such a manager, but the company went down because the project was so huge they were never able to finish it (it was so obvious when I entered this project, I quit after one month).
The reason this kind of abuse happens routinely is Managers can get away with it and Coders let them.
Yes, you are right, but managers will only hire people that they can enslave.
And this explains why the coders are so young and inexperienced.
The coders still believe that making games is a passion, so why not spend all their time on their work ? It's so fun !
I would have sworn that the company's motto was "Work harder, not smarter."
Totally right.
BTW, when a company tells you that they are like a family (yes, it happened a few times !), you can be sure that they'll make you work like a slave.
It's not: Welcome to our family
it's: Welcome to Hell !
Check my reply to your anonymous post above.
He could be describing Electronic Arts. Look, the game industry has been run this way for the better part of thirty years. I worked as a coder for a couple of game companies back in the mid-eighties ... and I left for the reasons described in the summary.
I totally agree: I worked for several companies during 20 years in France, and this behavior can be found in 50% of the companies.
But it's the fault of the employees, because they don't know how to set limits.
Since most of the developers are young or inexperienced, they don't have a life outside of their work.
Once I realized this trick, I told them that I will start at a given hour, and will return home at another given hour, and I was probably the only one in my company to do that, and I became their most efficient coder.
I also remember a job interview, where the project leader told me that doing an all-nighter occasionally was very beneficial for the group (WTF !).
As much as I enjoyed that line of work, management practices were abusive even then.
It's true, but it's because:
- the managers don't know how to lead a project (90% of the cases)
- the managers are not coders themselves (95% of the cases)
- the managers never finished a game before (99% of the cases)
- the managers never encountered another way of work (100% of the cases)
The problem is managers that use simple metrics like lines of code written per day to determine a developer's value.
No, this is not true.
What is valued is the number of hours you do every day. It doesn't matter if you do something or not !!! I worked 8 hours a day, but was less considered than some other guys who were working 2 hours, but been present 10 hours.
Also, socializing is an important part if you are ambitious and want to be paid more, so it's necessary to spend your time chatting with the management, otherwise you'll be ignored (of course, I never did that and my salary stagnated).
In general, any project is already late as soon as it begins.
Working 12 hours every day won't help the game finish in time (and in general, it does the opposite by draining the energy out of the team).
The problem is that the games start with too much elements, instead of building progressively.
So, you have to code everything from the beginning, and that's very bad.
And worse, the final goal changes constantly.
Also, when a game is really on time (by some miracle), managers tend to add even more features, because they suppose that the programmers will easily code them.
The real solution is to stop building large games at the very beginning, and simply add one feature after another.
When the time runs out, you'll have at least something to deliver, not incomplete parts everywhere.
upper management is hiring sadists to run their development teams
No, it's just that everybody only knows this bad way of working, and nobody intends to change that: they don't have the time to try other ways !!!
This work process is so bad that 30% of the coders leave the company at the end of an exhausting project.
That's why there is so much turnover in game companies.
Interesting stuff. Just don't think you will be writing software with this.
Since a few years, programming has become equivalent to placing Lego bricks in the correct order (I'm working with Microsoft .NET and tons of components).
So I'm not very surprised by the approach, as long as we can find all the possible varieties of pieces.
Here is the slashdot article:
http://it.slashdot.org/article.pl?sid=04/02/16/1737200
Speculation ? I found the slashdot article:
http://it.slashdot.org/article.pl?sid=04/02/16/1737200
A few years ago, when Microsoft's Windows source code was leaked, a hacker found a problem in the handling of the standard BMP format (IIRC, it was an integer that was not considered signed, and it contained the size of the picture), which could allow arbitrary code execution.
What bothers me is that Apple's developers don't check if they have the same problems as their direct competitor.
I have always been partial to Superman 64.
It's this game that probably killed its company: Titus Software (or at least damaged its reputation irremediably).
http://en.wikipedia.org/wiki/Titus_Software
And later, Interplay disappeared too.
Or more simply, use OperaTor (Opera+Tor):
http://archetwist.com/en/opera/operator
IE's reputation is terrible.
It's so bad that it's tainting all their other softwares.
On the contrary, Google is really working hard to create a strong brand.
Microsoft should not declare that IE8 is one of the most secure browsers (even if it's partially true).
People don't even know how to differentiate between IE6 and IE8 !
In my company, some people uses IE and google our company name to get to our homepage !
Microsoft should instead try to rename the browser to something like IEasy, or whatever, like they did with Vista.
Then once the new browser will be completely hacked, rename it to something like IE10, so that everybody will have forgotten the terrible brand.
Anyway, it's entirely their fault that Web development became such a nightmare, and forced large companies to keep IE6 due to the ugly ActiveX components.
And then they will get to take a job with a Baidu.
I doubt so.
When you betray some company, you'll always be marked as a traitor.
Sitting at home wanking in front of the computer screen is not an activity around which groups tend to organize.
Do not forget that:
1) prostitution is illegal in China
2) pornography is illegal in China, so it's not possible to get porn videos easily
3) in the current generation, there are more men than women (because of the unique child policy, the chinese preferred to get guys than girls), so it's not easy to get married
Add to this the fact that they can't use Internet for pornography, and we can just imagine the level of frustration.
Such an amount of frustration will only lead to increased violence (and the women are the first targets with rapes).