Jay Wilson was the lead designer on Impossible Creatures and Dawn of War and did a fair-sized chunk of the multiplayer design on Company of Heroes. He's over at Blizzard now. I haven't talked to him in a while, but I'm assuming he's working on StarCraft 2.
In the book "Getting Things Done", David Allen talks about this, and he claims his system addresses it. His system is fairly elaborate, and starting to use it is a big committment that I haven't made, so I can't verify that it works. What he says sounds plausible, though.
Elaborate? Big committement? Really?
I've been using Allen's system for a while now. I've modified it to fit my needs. There is no large committment required. I have a milk crate sitting next to my desk. It's my InBox. Everything physical that needs processing goes into it. I have four packing boxes from Staples and a big pack of hanging files.
I try to clear out my InBox everyday but at least every other day. Everything is filed, junked, or tracked.
Tasks are tracked in a spreadsheet. I use Google Spreadsheets and the Joel Spolsky method.
It took me about 10 minutes to walk across the street to Staples. It took me about 5 minutes to dump everything in the milk crate and setup the spreadsheet.
Most support calls come at install time. If there are multiple installs, support costs increase.
Games that do not do stat tracking, matchmaking, and auto-update get lambasted in reviews and rightfully so. Multiple installs means multiple accounts even if the original account is not in use there is a maintenance cost.
Years after a game is sold there is still a team in place for play balance updates and patches whenever a new video card or set of drivers is released. If people are not buying the game first-hand anymore this support will stop.
Lastly, your assuming this debate is about you. It is not. Sure the publisher would rather have a person buy a new copy. But go ahead and lend, give away, or even sell your copy.
This debate is between the retailers and publishers. They are supposed to be partners. Publishers buy retail space and pay for co-marketing. But the retailer is doing their damndest to sell you a used copy. Publishers feel slighted.
This is ridiculous. You don't see car manufacturers trying to stop people selling second hand cars.
It's not about revenue. The point is that when a second sale is made the costs to the publisher go up.
Publishers have to pay for their 1-800 support lines, multiplayer servers, online community, etc. Have you played a Live! enabled game yet? The goal is to provide value to the player long after the sale of a game is made.
You are selling the game, not a license.
No. We are selling an experience, a community.
Car makers only allow transfership of warranty under strict guidelines. Publishers haven't decided what they think their guidelines should be.
Why? The Intel compiler seems to in general generate better code then MSVC and seems to do much better at vectorization than MSVC or GCC. The Intel compiler plugs right into Visual Studio so I would say that not using MSVC can be a good choice. I would have to say that to not consider the Intel compiler as a option for game development under windows would require someone to be ignorent or an employee of Microsoft.
At my previous job our volume renderer was compiled using ICC. ICC was only used for release builds. Since ICC is binary and link compatible with MSVC. Our higher-level SDK was compiled using MSVC.
Note, the following numbers are based on MSVC 7.0 and ICC 7.0. Since then, MSVC 7.1 has been released with the imminent release of 8.0. The latest version of ICC must be 8.0, not sure, haven't been keeping track anymore.
The benchmarks you point to are for compilers that were released in 1998.
We found that ICC sped up our renderer about 10%. The main advantage was that ICC is able to vectorize loops better than MSVC. It also supported OpenMP and PGO, which we didn't really use anyway. MSVC 8.0 will support those options. The advantage came from the fact that the code was a CPU-intensive software renderer. That is not the case for games. At my current place of employment, we have custom assembly for these cases (SSE, SSE2, 3DNow). Vectorized code is probably the last place where hand-rolled assembly can still beat a compiler.
The ICC compiled code suffered a penalty on AMD hardware. About 10% from what I remember.
The license cost of purchasing ICC is not a problem. Supporting two compilers is just not worth the burden. ICC is not a good choice for debug builds. It compiles slower and the diagnostics are less helpful.
That is my own actual first-hand experience. I am not an Microsoft employee and I am capable of spelling ignorant correctly.
BOINK. That was the sound of you hitting my Foe list. I don't know why I even post here anymore.
There has been a ton of interviews, developer diaries in the last few weeks covering this, along with an article in last months Game Developer Magazine.
The game is written in C++, with an C++ SDK that is exposed for the MOD community. Tweakable data is stored in XML files. They use Python as their scripting language. They use Boost.Python for binding. Google for "Who's using Boost".
How about you just switch to Shaw as your ISP? It'll cost you a lot less than a lawsuit. (And note me as your referer, so I get a free month.)
There is no point in doing business with Telus. Their service is horrible. Their installers are horrible. They never pick up the phone. (Go figure, for a telephone company). They sell poor quality cell phones. And they are the most expensive game in town.
I use to be a loyal Telus customer for the longest time. I used them for home phone service, long-distance, ISP, cell phone service, and tons of their value-added services. Spent a good chunk of money with them every month.
My cell phone contract expires in about 6 months and that will be the last business I ever do with them. It's just not worth it.
Thank you, Mr. AC. That was exactly what I was thinking. These "anonymous sources" are grumbling because they don't know how to program for these things.
You want non-anonymous sources. Listen to Chris Hecker's rant at this years GDC. If you don't know who Hecker is, he was the editor over at GDMag for years and is currently Lead Programmer on Spore.
Yeah...I've seen the soaring stock price of Google (market cap beats AOL/TW now, yeah, uh...wow) and I'm wondering when it's going to collapse. They provide some nice free things for the web, but their advertising revenue can't come close to justifying their $80B value.
The stock market is not about revenue. It is about expected revenue. Currently Google's P/E ratio is at about 115. However, their one-year Forward P/E ratio is about 45. Which isn't that bad for a company that just had an IPO.
Plus, they also have quarterly revenue growth of about 95% and quarterly earnings growth of 475%.
AOL/TW has never done that. AOL/TW will never do that.
What do they do that makes money?
I don't know. But they have revenue of $3.79B and a gross profit of $1.73B for the last 12 months.
Most of the things in the article (having shorter load times, better AI, no invisible borders, etc) are things decent game developers strive to do on every title. However, many of these problems are hardware-bound (you can only stream data from dvd so quickly regardless of how you optimize your code), knowledge-bound (AI isn't exactly a solved problem is it!), or practicality-bound (yeah, "come up with a new genre" is easy to say, you do it, find funding, get it published, etc.)
I agree. This guy is clearly not a developer. AI is not a solved problem. Even if it was, solving it in real-time would be a magnitude harder on top of that. And issues like loading time can be solved. But the next generation of consoles would cost $1000 -$1500 and he would complain that the hardware was too expensive.
And on top of that, users don't actually know what they want. Even though they think they do. This goes for software outside of games especially. Give them what they ask for and they will still complain. You have to really sit down and watch what they do and try to solve the problems that they encounter. Joel Spolsky has written a few articles on solving customer problems while ignoring customer requests. He's dead on with most of his observations on this topic.
Plus on top of that. Everything that the original articles asks for is very male, 18-35 centric. Don't we listen to these guys way too much already? That is what has gotten us into this mess in the first place.
#3 is certainly wrong. At the start of a generation you basically try to write an engine that will last you for the next 5 years. That task is expensive and exactly the reason why EA purchased Renderware, Microsoft is standardizing on Unreal internally and Sony have named it the official middleware provider.
At my last place of employment we had support emails sent directly to FogBugz. After that they were organized by priority and severity, dupe checked, and assigned to a developer to resolve. You should probably be able do that with any bug tracking software.
Oh... and starting a startup takes more than just time and associated costs... it also takes an original idea and enough social skills to be able to sell other people on the idea.
Original ideas are overrated. Execution is much more important. Insert quote about inspiration and perspiration.
Is this language compatible with Java? Can it / is it designed to live on a Java virtual machine, or interact with Java?
I doubt it. In Fortran all variables are value-types. In Java all variables are reference-types (well, except for primitives).
As mentioned in other posts, value types are very important for optimization of mathematical code.
1) The compiler doesn't need to worry about aliasing. Two references may refer to the same piece of memory. Hence that piece of memory may change behind the compiler's back. Hence the compiler must reload the variable being referenced into registers everytime there is a read.
2) Accessing memory contigously is much faster than accessing memory non-contigously. The JRE does not guarantee that arrays of objects will be allocated contigously. Heck, the JRE doesn't guarantee anything since it is not an ANSI/ISO/ECMA standard legalese like other languages/environments (C, C++, CLI, C#, Fortran, Ada, etc).
Blame the standards committee, not the GCC maintainers.
Insightful? Jesus eff-ing Christ. Now the slashbots don't like standards. I bet you wouldn't be presenting the same argument if this discussion was about the transition from MSVC 6.0 to 7.0/7.1.
Funny? Jesus eff-ing Christ. When did pointing out the hypocricy of slashdot group think become funny? I don't get which part of my original statement is funny.
Blame the standards committee, not the GCC maintainers.
Insightful? Jesus eff-ing Christ. Now the slashbots don't like standards. I bet you wouldn't be presenting the same argument if this discussion was about the transition from MSVC 6.0 to 7.0/7.1.
John Carmack reasons very simple from a game developer point of view. Basically anything that gets in the way of direct access to the hardware annoys him. This way of thinking about writing software is not really suitable for mobile development.
Bullshit. What Carmack is asking for is value types. That arrays of data be laid out contiguously. He's not asking for direct access to hardware. He's asking the runtime to not be so damn brain dead.
Supporting value types will not destroy hardware abstraction.
And this not a game developer's point of view only. For example,.NET/CLI supports value types.
This is based on a fundamental principle of computing that contiguous data access is better than non-contiguous data access. Period.
At work we have custom assert, breakpoint, trace, and crash handler code. This is in C/C++. Whenever an assert fires off, it will break in to the debugger if it is present. If not, it will do a stack trace package up a email and send it to our symbol server. The symbol server looks up function names and line numbers and sends out an email to the developers. We get an email within about 5 minutes of when an assert fires on a user's machine.
Design-by-contract is tha shiznit. It keeps your code base quite stable.
But still, of those two, i have to agree with Pat: at this point in time, KDE is just a better desktop.
Clearly, you and Pat don't agree. The article summary clearly states that Pat doesn't think there is anything major wrong with GNOME the desktop, it is the packaging of GNOME that is difficult.
Geez. Not only aren't we reading the articles, we aren't even reading the summaries anymore.
Slashdot Mirror
Jay Wilson was the lead designer on Impossible Creatures and Dawn of War and did a fair-sized chunk of the multiplayer design on Company of Heroes. He's over at Blizzard now. I haven't talked to him in a while, but I'm assuming he's working on StarCraft 2.
Elaborate? Big committement? Really?
I've been using Allen's system for a while now. I've modified it to fit my needs. There is no large committment required. I have a milk crate sitting next to my desk. It's my InBox. Everything physical that needs processing goes into it. I have four packing boxes from Staples and a big pack of hanging files.
I try to clear out my InBox everyday but at least every other day. Everything is filed, junked, or tracked.
Tasks are tracked in a spreadsheet. I use Google Spreadsheets and the Joel Spolsky method.
It took me about 10 minutes to walk across the street to Staples. It took me about 5 minutes to dump everything in the milk crate and setup the spreadsheet.
Ever consider that you may be procrastinating?
Games that do not do stat tracking, matchmaking, and auto-update get lambasted in reviews and rightfully so. Multiple installs means multiple accounts even if the original account is not in use there is a maintenance cost.
Years after a game is sold there is still a team in place for play balance updates and patches whenever a new video card or set of drivers is released. If people are not buying the game first-hand anymore this support will stop.
Lastly, your assuming this debate is about you. It is not. Sure the publisher would rather have a person buy a new copy. But go ahead and lend, give away, or even sell your copy.
This debate is between the retailers and publishers. They are supposed to be partners. Publishers buy retail space and pay for co-marketing. But the retailer is doing their damndest to sell you a used copy. Publishers feel slighted.
It's not about revenue. The point is that when a second sale is made the costs to the publisher go up.
Publishers have to pay for their 1-800 support lines, multiplayer servers, online community, etc. Have you played a Live! enabled game yet? The goal is to provide value to the player long after the sale of a game is made.
You are selling the game, not a license.
No. We are selling an experience, a community.
Car makers only allow transfership of warranty under strict guidelines. Publishers haven't decided what they think their guidelines should be.
I speak for myself, not my employer.
At my previous job our volume renderer was compiled using ICC. ICC was only used for release builds. Since ICC is binary and link compatible with MSVC. Our higher-level SDK was compiled using MSVC.
Note, the following numbers are based on MSVC 7.0 and ICC 7.0. Since then, MSVC 7.1 has been released with the imminent release of 8.0. The latest version of ICC must be 8.0, not sure, haven't been keeping track anymore.
The benchmarks you point to are for compilers that were released in 1998.
We found that ICC sped up our renderer about 10%. The main advantage was that ICC is able to vectorize loops better than MSVC. It also supported OpenMP and PGO, which we didn't really use anyway. MSVC 8.0 will support those options. The advantage came from the fact that the code was a CPU-intensive software renderer. That is not the case for games. At my current place of employment, we have custom assembly for these cases (SSE, SSE2, 3DNow). Vectorized code is probably the last place where hand-rolled assembly can still beat a compiler.
The ICC compiled code suffered a penalty on AMD hardware. About 10% from what I remember.
The license cost of purchasing ICC is not a problem. Supporting two compilers is just not worth the burden. ICC is not a good choice for debug builds. It compiles slower and the diagnostics are less helpful.
That is my own actual first-hand experience. I am not an Microsoft employee and I am capable of spelling ignorant correctly.
BOINK. That was the sound of you hitting my Foe list. I don't know why I even post here anymore.
The game is written in C++, with an C++ SDK that is exposed for the MOD community. Tweakable data is stored in XML files. They use Python as their scripting language. They use Boost.Python for binding. Google for "Who's using Boost".
http://www.dignews.com/feature.php?story_id=11457
And they probably use MSVC. Everyone uses MSVC. They'd be on crack if they didn't.
Technical questions are probably best answered by someone on the Civ team other than Sid Meier since he is a designer.
There is no point in doing business with Telus. Their service is horrible. Their installers are horrible. They never pick up the phone. (Go figure, for a telephone company). They sell poor quality cell phones. And they are the most expensive game in town.
I use to be a loyal Telus customer for the longest time. I used them for home phone service, long-distance, ISP, cell phone service, and tons of their value-added services. Spent a good chunk of money with them every month.
My cell phone contract expires in about 6 months and that will be the last business I ever do with them. It's just not worth it.
Me - "Yes"
It's actually a 3rd person game: Link
To be more general, you can kiss indirections good-bye. A virtual call is just a specific case of indirection.
This is all good and well for graphics and AI. But a pain in the ass for AI.
You want non-anonymous sources. Listen to Chris Hecker's rant at this years GDC. If you don't know who Hecker is, he was the editor over at GDMag for years and is currently Lead Programmer on Spore.
Carmack said the same at his 2004 GDC keynote.
The stock market is not about revenue. It is about expected revenue. Currently Google's P/E ratio is at about 115. However, their one-year Forward P/E ratio is about 45. Which isn't that bad for a company that just had an IPO.
Plus, they also have quarterly revenue growth of about 95% and quarterly earnings growth of 475%.
AOL/TW has never done that. AOL/TW will never do that.
What do they do that makes money?
I don't know. But they have revenue of $3.79B and a gross profit of $1.73B for the last 12 months.
http://finance.yahoo.com/q/ks?s=GOOG
I agree. This guy is clearly not a developer. AI is not a solved problem. Even if it was, solving it in real-time would be a magnitude harder on top of that. And issues like loading time can be solved. But the next generation of consoles would cost $1000 -$1500 and he would complain that the hardware was too expensive.
And on top of that, users don't actually know what they want. Even though they think they do. This goes for software outside of games especially. Give them what they ask for and they will still complain. You have to really sit down and watch what they do and try to solve the problems that they encounter. Joel Spolsky has written a few articles on solving customer problems while ignoring customer requests. He's dead on with most of his observations on this topic.
Plus on top of that. Everything that the original articles asks for is very male, 18-35 centric. Don't we listen to these guys way too much already? That is what has gotten us into this mess in the first place.
#3 is certainly wrong. At the start of a generation you basically try to write an engine that will last you for the next 5 years. That task is expensive and exactly the reason why EA purchased Renderware, Microsoft is standardizing on Unreal internally and Sony have named it the official middleware provider.
At my last place of employment we had support emails sent directly to FogBugz. After that they were organized by priority and severity, dupe checked, and assigned to a developer to resolve. You should probably be able do that with any bug tracking software.
Original ideas are overrated. Execution is much more important. Insert quote about inspiration and perspiration.
I am in total agreement with your second point.
I doubt it. In Fortran all variables are value-types. In Java all variables are reference-types (well, except for primitives).
As mentioned in other posts, value types are very important for optimization of mathematical code.
1) The compiler doesn't need to worry about aliasing. Two references may refer to the same piece of memory. Hence that piece of memory may change behind the compiler's back. Hence the compiler must reload the variable being referenced into registers everytime there is a read.
2) Accessing memory contigously is much faster than accessing memory non-contigously. The JRE does not guarantee that arrays of objects will be allocated contigously. Heck, the JRE doesn't guarantee anything since it is not an ANSI/ISO/ECMA standard legalese like other languages/environments (C, C++, CLI, C#, Fortran, Ada, etc).
Funny? Jesus eff-ing Christ. When did pointing out the hypocricy of slashdot group think become funny? I don't get which part of my original statement is funny.
Insightful? Jesus eff-ing Christ. Now the slashbots don't like standards. I bet you wouldn't be presenting the same argument if this discussion was about the transition from MSVC 6.0 to 7.0/7.1.
Compatibility with what? No standard exists. You need to pick a specific dialect implemented by a specific runtime.
Having spent 12 hour days the last week sitting in front of VTune and NvPerfHUD, I would like to strongly disagree.
Physics, collision detection, and software vertex skinning are all amenable to parallelization.
Symbol Server and IsDebuggerPresent and look in imagehlp.h.
Our crash handler works similiar to Netscape/Mozilla talkback.
Maybe someday I'll put together something equivalent at home for Linux.
Bullshit. What Carmack is asking for is value types. That arrays of data be laid out contiguously. He's not asking for direct access to hardware. He's asking the runtime to not be so damn brain dead.
Supporting value types will not destroy hardware abstraction.
And this not a game developer's point of view only. For example, .NET/CLI supports value types.
This is based on a fundamental principle of computing that contiguous data access is better than non-contiguous data access. Period.
Design-by-contract is tha shiznit. It keeps your code base quite stable.
Clearly, you and Pat don't agree. The article summary clearly states that Pat doesn't think there is anything major wrong with GNOME the desktop, it is the packaging of GNOME that is difficult.
Geez. Not only aren't we reading the articles, we aren't even reading the summaries anymore.
-- KDE user and summary reader.
All Your Bandwidth Are Belong To Us.