You also need checking that an entry reads well, makes sense, and is informative.
A few people have mentioned Wikipedia - my first experience of it came when someone on slashdot linked to an article in a comment a few weeks back.
It was an article about Tesla's Wardenclyffe Tower. Not knowing what it was, but knowing Tesla was generally an interesting guy with some weird theories, I decided to have a look.
Go and have a look, and see if you can work out what the hell the Wardenclyffe Tower is, or what it is for. I was at least halfway through the article before I had much of a clue, and even then I don't think I was sure. That's just bad writing.
I love this part from the 3rd paragraph of the article:
In 1903, the tower structure was near completion, although it was not yet functional due to a design error
Me: "Yeah, but you haven't told us what the function is yet!"
I've heard this said a few times, but you have to bear one important thing in mind - which I'm sure a few mod creators who've transitioned into an actual paid job in the industry have found:
When you write a game, most of the time, you don't get the finished tools at the start of the project. They're not finished, usually buggy, or maybe they're being started from scratch. They're usually incomplete for most of the project lifecycle.
For example: if HL2 comes out (ever), then take a look at the tools they provide you with the SDK. I can pretty much guarantee you that the artists, designers and programmers didn't have those complete finished tools ready to use at the start of the project.
Using unfinished tools, having to rework content/code all the time as the tools improve, takes a surprisingly large amount of time in a project. Or perhaps it's not surprising.
When creating a mod, although some of them extend the game in ways the creators are surprised by, you're generally working in a fixed universe and feature set. Either the game can do X, or it can't. This cuts down your design decisions hugely, and you go down fewer dead ends.
When working on a game project, anything is possible, because the game isn't finished yet. Can we add feature X? Sure we can, if we have the time and resources. Sorry designers, we're not sure if we'll be able to get that feature in - we'll let you know in about 3 months' time. Can you just carry on designing the game anyway?
Like the man said, it's not as easy as it seems.
Incidentally, could you give me an example of a total conversion mod that is much better overall than the original game?
The problem is that games are just too big and cutting-edge for this kind of design approach to work. You can only do this for relatively simple problems that you completely understand.
Hmmm...I liked the article, but I don't think I'm going to let you get away with that. I found the "build times are really long!" part of the article the most troubling. Here are some observations, which I'm not suggesting you're completely unaware of, it's just a convenient place for me to impart information that people don't know. Before anyone flames me, yes, they should know, but they don't. That's not my fault.
First of all, stop having a go at Microsoft's tools. You try using the PS2 dev tools for a while, and you will ache to go back to the MS tools - incremental compilation and linking, decent debugger, etc. I know you weren't really moaning (and maybe you have used PS2 tools - my sympathy), but if you're using VC6 or higher, then I don't think tool quality is going to be a major problem. Enough said.
Most big C++ projects have long build times because everyone bitches about them but nobody tries to do anything about it. I think this is often down to programmers not really understanding how compilers/linkers work, or actually being any good at performance tuning.
Job #1 when solving slow build times is really easy - all you need is some money - and not much. It's real easy - buy some more RAM. If your developers don't have at least 1Gb of RAM in their PCs, then there's probably something wrong. The good news is, it's easy to fix (buy some RAM), and RAM is so cheap that it'll pay for itself in improved productivity in a couple of weeks in extreme cases (I've experienced that first hand myself).
Yes, yes, code bloat, I remember when all you got was 16k, blah blah, "7167 bytes free", Windows sucks, etc., etc. - yes, very nice, but the fact is that buying a dev $50 worth of RAM usually saves them shedloads of time, so suck it up and do it.
After the easy stuff, here's some more easy stuff. When it comes to C++, there are trivial things you can do wrong (and often) to make your build times balloon. The single most important question to ask in C++ with respect to build times is: do I need to include that file, or can I use a forward declaration?
If no thought goes into choosing which files to include, then you don't really notice it that much on smaller projects, but on larger projects it kills your productivity (due to large build times). A few months back, I spent a couple of days pruning include directives from our project's source files. In only two cases did I actually change any implementation (on both cases, to use the pimpl idiom on a couple of choke point classes). It took me about 2 days and was hell, but at the end of it our build times were half what they used to be.
On other projects where the tools support pre-compiled headers ("Luxury!"), I've reduced
build times by a factor of 4-6.
The effects are two-fold - first, each source file takes less time to compile, because it isn't including the whole bloody project, and secondly, less files get recompiled when you change stuff. Again, obvious, I know, but you'd think it wasn't, judging by the lack of effort most people put into fixing this. This addresses the "I just changed the animation file format, so why the hell is the physics system being rebuilt?" problem.
As for not being able to use design patterns, etc, in something as complicated as a game, that's a bit of a cop out, as I suspect you know. If you don't plan and manage your design rigourously, then your development time will usually be longer, due to bugs in the design and code. Essentially you're saying "Games are too complicated to be designed". Put like that, it doesn't sound that defensible (but: possible Straw Man alert
So I showed them three different GUI interfaces for CVS. That didn't convince them.
To be fair, I've tried a few GUIs for CVS, and they didn't convince me either. Most of them seemed to be a clunky front-end for running command line based stuff, and if you wanted to know if anything was working, you had to know how the command line stuff worked anyway.
Not everything that people say is impossible is some sort of persecuted idea that will have its day.
Or, to put it slightly differently:
But the fact that some geniuses were laughed at does not imply that all who are laughed at are geniuses. They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown. -- Carl Sagan
I remember a few years back on usenet, there was a guy called Fred Read active on the C groups (he possibly still is) whose signature went along the lines of "F.Read - how many people do *you* know whose name is also a C function?"
After a certain period of time there was a reply addressing that question from a Scandinavian fellow named Mr Scanf:-)
Well, that was fun:)
Good to see the old 'What do you need an IDE for?' and 'All the best programmers I know don't use IDEs, they hand-tool each individual character from raw pixels' arguments coming out. Don't think I need to address those opinions - if you can't see the advantage of integrated debugger, context-sensitive help, auto-complete, integrated revision control, etc, then there's no point arguing. Seriously - I'm not trying to have a go; if you don't think those are useful, then fair enough. It's just they'll have to pry Visual Assist from my cold dead hands.
I wasn't so much insisting that the MS IDE is the best ever (although I've yet to try a better one, for my tastes - but I haven't tried XCode yet), simply that it's not the steaming pile of crap it's usually made out to be on slashdot. For example, I, along with many other VC++ users, laughed like a drain when XCode fanboys were enthusing about the brand new 'Fix and continue' feature of XCode, and that it was yet another example of how Microsoft didn't "get it". (VC6 has had that feature for years).
And Metrowerks? Pah. Speak to me not of such annoying IDEs:-)
Interesting survey results though. I did try Eclipse quite recently, after someone told me about it - it sounded cool. However, after the usual battle to get any kind of Java app running, it failed at the first hurdle by being the first programmer's editor I've ever used that won't let you just load a frigging text file from disk and start editing it! It has to be part of some project, or solution, or view, or workspace or whatever the crap they call it. I mean - a programmer's editor with no "File open" command? What's that about? I decided there and then that I didn't want to use a product so clearly driven* by the IDE equivalent of language lawyers.
Call me old fashioned, but I just like to be able to go, "Hey - that XML file. I want to edit it. Like, now."
Seriously, that's the kind of thing that makes you think the vi guys have a point sometimes;-)
* Kind of like the Mozilla "ctrl-enter doesn't add www and com to a domain name" bug - Moz developers argued endlessly about the ideological problems with this, until someone on the Phoenix team presumably just said "Oh, for bleep's sake!" and implemented it (or, if I remember correctly, re-enabled the code that the zealots had disabled).
"A good game is only late until it ships. A bad game sucks forever."
Or, to quote Sid Meier:
"Great game. On time. Pick one."
Being a games developer myself, one thing that winds me up is hearing the poor quality of games being blamed on 'lazy developers'. Now, it's true that many games developers may not have the best engineering skills in the world, or be any good at planning/project management, but trust me, having seen so many people work late nights/weekends for long stretches of time, the problem is not that they are 'lazy', or that they don't care about the quality of the product. Lay that particular blame at the doors of other people, where it rightfully belongs.
As for dates - that usually comes down to publishers, rather than developers, as has been pointed out. The publishers push for a date related to their selling peaks (i.e. Thanksgiving), and usually refuse to consider any other date, even though they'll be going up against almost every other game that is released that year. Developers are pretty much powerless to prevent this - unless you're Valve or Bungie or Blizzard, then the publishers have all the money, and they dictate the terms. (Speaking personally, I loved the fact that when Valve demo'd Half-Life 2 at E3 and blew everyone away, they responded to questions about publishers with "We don't have a publisher yet." Unless you've worked in game development, you've probably no idea how good it felt to hear that.)
Publishers also need stuff to give their marketing guys to take around and show buyers to build interest in the game. This usually comes in the form of some shoddy demo/progress build that the developers are harrassed into producing. The same goes for game demos - ever wonder why most game demos don't actually seem to do a good job of demo'ing the game, and have lots of problems that 'will be fixed in the final game'? It's because the publishers demand a demo before the game is finished.
On a game I worked on previously, we tried to avoid building up lots of hype for the game when it wasn't ready, and focussed on quality, because that's what we thought people would be interested in. Hell, no, the publisher didn't seem to care about that. They wanted screenshots, and they wanted them now! Never mind that the game wasn't even a game yet. The most important thing to them seemed to be when the profits would show up on their books. For example, they wouldn't accept a 3 month delay because then the income would slip through to the next financial year. I mean, the profits would be the same (actually, they would probably be significantly larger); they would just be appearing 3 months later. Now, I don't know much about accountancy/finance, but it seems to me that something somewhere is broken if that's how things are run. The best part was, in the trade mags, all we ever heard from games publishers was how developers were useless at business and couldn't see the bigger picture.
If your focus is always on the next quarter's results, at the expense of everything else, I think that's a good way of not having a long term plan.
I found another use for it - when I was working on the team developing the first version of this, I had to make sure the rendering code was efficient for partial redraws (scrolling diagonally, floating windows). Also we used XOR plotting to do the selection UI, etc.
When you get redraw glitches with that, it's often hard to see what's going on. Pressing the turbo button on our 486-66 machines would turn them into a very slow PC, which made it really obvious where the redraw was screwing up:-)
Sony did actually make a Mini-Disc data drive, but it cost about 500ukp. At the same time, player/recorder walkmans were selling at only 200ukp. It's not hard to see why that didn't take off. I think it also had its own crappy software, and didn't appear as a 'proper' drive, which probably didn't help.
When I visited Apple HQ a couple of years ago (as a developer) I was told by one of the Apple guys that it was a standing company joke that Apple is the only ship that leaks from the top:-)
If you'd read the article (ha) you'd know that they tried that - see the section "Amateur Neurosurgery" on page 4 of the article. They bought a battery from such a site, took their iPod apart, tried to replace it. The iPod died.
I know you're bound to tell me that they are idiots for breaking their iPod. Personally, I think they're right to direct their anger at a company that [a] Made the battery non-user replaceable, and [b] presumably knew that the batteries could die in about 18 months. If [b] isn't true, then it's just incompetence.
Disclosure: I own an iPod, and it's working ok, but the battery no longer holds its charge for longer than about 3 days, which is kind of annoying, but iPods are so great otherwise I can live with it. I'm not looking forward to my battery finally dying though.
Not unless they up the feature set - when I looked into XP's firewall, it only blocked incoming connections, not outgoing. I use outgoing blocks as a matter of course to catch spyware, etc, and to prevent Outlook Express/MSNIM from fetching images/ads from web servers, etc. I was looking at the XP firewall for my laptop, because Kerio made my laptop's suspend/sleep functions stop working (grrr) so had to find an alternative. As it turned out, I tried Norton Personal Firewall, which was actually quite good, and not nearly as bad as I had feared. None of them are particularly great at config UI though. Norton especially requires a lot of clicks to set rules up.
It's just occurred to me that maybe MS don't want to implement an outgoing firewall, given that the number of Windows components that randomly connect to MS servers is quite high, and it would highlight this fact if they did outgoing connection blocking. Hmm.
Slashdot Mirror
I've neither seen nor heard of the Talk page, which is why I didn't use it.
It's the first one I came across.
:-)
I speak as I find
You also need checking that an entry reads well, makes sense, and is informative.
A few people have mentioned Wikipedia - my first experience of it came when someone on slashdot linked to an article in a comment a few weeks back.
It was an article about Tesla's Wardenclyffe Tower. Not knowing what it was, but knowing Tesla was generally an interesting guy with some weird theories, I decided to have a look.
Go and have a look, and see if you can work out what the hell the Wardenclyffe Tower is, or what it is for. I was at least halfway through the article before I had much of a clue, and even then I don't think I was sure. That's just bad writing.
I love this part from the 3rd paragraph of the article:
Me: "Yeah, but you haven't told us what the function is yet!"
I've heard this said a few times, but you have to bear one important thing in mind - which I'm sure a few mod creators who've transitioned into an actual paid job in the industry have found:
When you write a game, most of the time, you don't get the finished tools at the start of the project. They're not finished, usually buggy, or maybe they're being started from scratch. They're usually incomplete for most of the project lifecycle.
For example: if HL2 comes out (ever), then take a look at the tools they provide you with the SDK. I can pretty much guarantee you that the artists, designers and programmers didn't have those complete finished tools ready to use at the start of the project.
Using unfinished tools, having to rework content/code all the time as the tools improve, takes a surprisingly large amount of time in a project. Or perhaps it's not surprising.
When creating a mod, although some of them extend the game in ways the creators are surprised by, you're generally working in a fixed universe and feature set. Either the game can do X, or it can't. This cuts down your design decisions hugely, and you go down fewer dead ends.
When working on a game project, anything is possible, because the game isn't finished yet. Can we add feature X? Sure we can, if we have the time and resources. Sorry designers, we're not sure if we'll be able to get that feature in - we'll let you know in about 3 months' time. Can you just carry on designing the game anyway?
Like the man said, it's not as easy as it seems.
Incidentally, could you give me an example of a total conversion mod that is much better overall than the original game?
Hmmm...I liked the article, but I don't think I'm going to let you get away with that. I found the "build times are really long!" part of the article the most troubling. Here are some observations, which I'm not suggesting you're completely unaware of, it's just a convenient place for me to impart information that people don't know. Before anyone flames me, yes, they should know, but they don't. That's not my fault.
First of all, stop having a go at Microsoft's tools. You try using the PS2 dev tools for a while, and you will ache to go back to the MS tools - incremental compilation and linking, decent debugger, etc. I know you weren't really moaning (and maybe you have used PS2 tools - my sympathy), but if you're using VC6 or higher, then I don't think tool quality is going to be a major problem. Enough said.
Most big C++ projects have long build times because everyone bitches about them but nobody tries to do anything about it. I think this is often down to programmers not really understanding how compilers/linkers work, or actually being any good at performance tuning.
Job #1 when solving slow build times is really easy - all you need is some money - and not much. It's real easy - buy some more RAM. If your developers don't have at least 1Gb of RAM in their PCs, then there's probably something wrong. The good news is, it's easy to fix (buy some RAM), and RAM is so cheap that it'll pay for itself in improved productivity in a couple of weeks in extreme cases (I've experienced that first hand myself).
Yes, yes, code bloat, I remember when all you got was 16k, blah blah, "7167 bytes free", Windows sucks, etc., etc. - yes, very nice, but the fact is that buying a dev $50 worth of RAM usually saves them shedloads of time, so suck it up and do it.
After the easy stuff, here's some more easy stuff. When it comes to C++, there are trivial things you can do wrong (and often) to make your build times balloon. The single most important question to ask in C++ with respect to build times is: do I need to include that file, or can I use a forward declaration?
If no thought goes into choosing which files to include, then you don't really notice it that much on smaller projects, but on larger projects it kills your productivity (due to large build times). A few months back, I spent a couple of days pruning include directives from our project's source files. In only two cases did I actually change any implementation (on both cases, to use the pimpl idiom on a couple of choke point classes). It took me about 2 days and was hell, but at the end of it our build times were half what they used to be.
On other projects where the tools support pre-compiled headers ("Luxury!"), I've reduced build times by a factor of 4-6.
The effects are two-fold - first, each source file takes less time to compile, because it isn't including the whole bloody project, and secondly, less files get recompiled when you change stuff. Again, obvious, I know, but you'd think it wasn't, judging by the lack of effort most people put into fixing this. This addresses the "I just changed the animation file format, so why the hell is the physics system being rebuilt?" problem.
In short, more people need to read Large Scale C++ Design by John Lakos.
As for not being able to use design patterns, etc, in something as complicated as a game, that's a bit of a cop out, as I suspect you know. If you don't plan and manage your design rigourously, then your development time will usually be longer, due to bugs in the design and code. Essentially you're saying "Games are too complicated to be designed". Put like that, it doesn't sound that defensible (but: possible Straw Man alert
To be fair, I've tried a few GUIs for CVS, and they didn't convince me either. Most of them seemed to be a clunky front-end for running command line based stuff, and if you wanted to know if anything was working, you had to know how the command line stuff worked anyway.
Or, to put it slightly differently:
But the fact that some geniuses were laughed at does not imply that all who are laughed at are geniuses. They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown.
-- Carl Sagan
I remember a few years back on usenet, there was a guy called Fred Read active on the C groups (he possibly still is) whose signature went along the lines of "F.Read - how many people do *you* know whose name is also a C function?"
:-)
After a certain period of time there was a reply addressing that question from a Scandinavian fellow named Mr Scanf
I wasn't so much insisting that the MS IDE is the best ever (although I've yet to try a better one, for my tastes - but I haven't tried XCode yet), simply that it's not the steaming pile of crap it's usually made out to be on slashdot. For example, I, along with many other VC++ users, laughed like a drain when XCode fanboys were enthusing about the brand new 'Fix and continue' feature of XCode, and that it was yet another example of how Microsoft didn't "get it". (VC6 has had that feature for years).
And Metrowerks? Pah. Speak to me not of such annoying IDEs :-)
Interesting survey results though. I did try Eclipse quite recently, after someone told me about it - it sounded cool. However, after the usual battle to get any kind of Java app running, it failed at the first hurdle by being the first programmer's editor I've ever used that won't let you just load a frigging text file from disk and start editing it! It has to be part of some project, or solution, or view, or workspace or whatever the crap they call it. I mean - a programmer's editor with no "File open" command? What's that about? I decided there and then that I didn't want to use a product so clearly driven* by the IDE equivalent of language lawyers.
Call me old fashioned, but I just like to be able to go, "Hey - that XML file. I want to edit it. Like, now."
Seriously, that's the kind of thing that makes you think the vi guys have a point sometimes ;-)
* Kind of like the Mozilla "ctrl-enter doesn't add www and com to a domain name" bug - Moz developers argued endlessly about the ideological problems with this, until someone on the Phoenix team presumably just said "Oh, for bleep's sake!" and implemented it (or, if I remember correctly, re-enabled the code that the zealots had disabled).
Out of interest, would you name some better IDEs..?
Or, to quote Sid Meier:
Being a games developer myself, one thing that winds me up is hearing the poor quality of games being blamed on 'lazy developers'. Now, it's true that many games developers may not have the best engineering skills in the world, or be any good at planning/project management, but trust me, having seen so many people work late nights/weekends for long stretches of time, the problem is not that they are 'lazy', or that they don't care about the quality of the product. Lay that particular blame at the doors of other people, where it rightfully belongs.
As for dates - that usually comes down to publishers, rather than developers, as has been pointed out. The publishers push for a date related to their selling peaks (i.e. Thanksgiving), and usually refuse to consider any other date, even though they'll be going up against almost every other game that is released that year. Developers are pretty much powerless to prevent this - unless you're Valve or Bungie or Blizzard, then the publishers have all the money, and they dictate the terms. (Speaking personally, I loved the fact that when Valve demo'd Half-Life 2 at E3 and blew everyone away, they responded to questions about publishers with "We don't have a publisher yet." Unless you've worked in game development, you've probably no idea how good it felt to hear that.)
Publishers also need stuff to give their marketing guys to take around and show buyers to build interest in the game. This usually comes in the form of some shoddy demo/progress build that the developers are harrassed into producing. The same goes for game demos - ever wonder why most game demos don't actually seem to do a good job of demo'ing the game, and have lots of problems that 'will be fixed in the final game'? It's because the publishers demand a demo before the game is finished.
On a game I worked on previously, we tried to avoid building up lots of hype for the game when it wasn't ready, and focussed on quality, because that's what we thought people would be interested in. Hell, no, the publisher didn't seem to care about that. They wanted screenshots, and they wanted them now! Never mind that the game wasn't even a game yet. The most important thing to them seemed to be when the profits would show up on their books. For example, they wouldn't accept a 3 month delay because then the income would slip through to the next financial year. I mean, the profits would be the same (actually, they would probably be significantly larger); they would just be appearing 3 months later. Now, I don't know much about accountancy/finance, but it seems to me that something somewhere is broken if that's how things are run. The best part was, in the trade mags, all we ever heard from games publishers was how developers were useless at business and couldn't see the bigger picture.
If your focus is always on the next quarter's results, at the expense of everything else, I think that's a good way of not having a long term plan.
...and boy are my thumbs tired!
Maybe they should just rename the game "Duke Nukem Preorder".
It amuses me that you misspelt 'buffoon' :-)
When you get redraw glitches with that, it's often hard to see what's going on. Pressing the turbo button on our 486-66 machines would turn them into a very slow PC, which made it really obvious where the redraw was screwing up :-)
Sony did actually make a Mini-Disc data drive, but it cost about 500ukp. At the same time, player/recorder walkmans were selling at only 200ukp. It's not hard to see why that didn't take off.
I think it also had its own crappy software, and didn't appear as a 'proper' drive, which probably didn't help.
As I understand it, your Karma doesn't increase if you get a 'Funny' mod.
Ha, that should me get an 'Informative' mod, surely.
No, Informative...not Funny! NOT Funny!
You fools..
I thnk you meant :-)
It disabled the Esc key?
<pedant>
When I visited Apple HQ a couple of years ago (as a developer) I was told by one of the Apple guys that it was a standing company joke that Apple is the only ship that leaks from the top :-)
"Blast his freaking head off!!!"
Yes, but I don't seem to recall complaints about a significant number of, e.g. Palm V batteries dying. Why is that?
If you'd read the article (ha) you'd know that they tried that - see the section "Amateur Neurosurgery" on page 4 of the article. They bought a battery from such a site, took their iPod apart, tried to replace it. The iPod died.
I know you're bound to tell me that they are idiots for breaking their iPod. Personally, I think they're right to direct their anger at a company that [a] Made the battery non-user replaceable, and [b] presumably knew that the batteries could die in about 18 months. If [b] isn't true, then it's just incompetence.
Disclosure: I own an iPod, and it's working ok, but the battery no longer holds its charge for longer than about 3 days, which is kind of annoying, but iPods are so great otherwise I can live with it. I'm not looking forward to my battery finally dying though.
Not unless they up the feature set - when I looked into XP's firewall, it only blocked incoming connections, not outgoing. I use outgoing blocks as a matter of course to catch spyware, etc, and to prevent Outlook Express/MSNIM from fetching images/ads from web servers, etc. I was looking at the XP firewall for my laptop, because Kerio made my laptop's suspend/sleep functions stop working (grrr) so had to find an alternative. As it turned out, I tried Norton Personal Firewall, which was actually quite good, and not nearly as bad as I had feared. None of them are particularly great at config UI though. Norton especially requires a lot of clicks to set rules up.
It's just occurred to me that maybe MS don't want to implement an outgoing firewall, given that the number of Windows components that randomly connect to MS servers is quite high, and it would highlight this fact if they did outgoing connection blocking. Hmm.