I just don't understand why there aren't more consumer boards with a lot more sockets, using FB-DIMM or registered DDR. You have to go to server boards for that ($$$).
One word: Windows.
Nobody uses 64-bit Windows, and (sadly) Windows users make up the majority of the computer buying population, so board makers don't see any reason to provide for more than 4G of RAM. At the current DDR2 prices, I'd love to drop 16G or 32G in a new system, but it's simply not an option with consumer boards, as you've noticed. As usual, Windows holds back everyone.
I don't agree w/ Eric on this one. The shift from 32-bit to 64-bit systems has been darn near seamless as compared to previous transitions. That's a far cry from the 8-to-16 jump or the 16-to-32 jump.
For Linux? Sure. I've been using 64-bit Linux for nearly 3 years now, and it's been quite seamless.
For Windows? Pretty much all preinstalled copies of Windows are still 32-bit. All in all, I doubt more than ~5% of Windows users are using 64-bit Windows (although the vast majority will have 64-bit capable hardware). Time has yet to tell how Windows fares on the 32-bit to 64-bit transition.
What I wanted you to explain is what makes you think a medium that has a burst speed of 4.8 Gbit/s will not be able to sustain > 1 Gbit/s (like your ethernet). I have read a bit, and not seen any info either way...
Pessimism based on USB's poor performance (as far as high speed devices go, anyways) in the past and general pessimism. I actually consistently see sustained speeds of ~115 MB/s over Gigabit ethernet, which is extremely close to the theoretical speed (minus TCP overhead), but I've never seen anything close to 60 MB/s over USB 2.0. Only time will tell for sure though.
No, it's that max speeds for USB 2.0 refer to the max burst speeds, not the maximum sustainable speed. A single 7200 RPM drive attached via USB 2.0 will be substantially slower than if you attached it via SATA or IDE, even though 60 MB/s (= 480 Mbit/s) should be enough for most drives.
The thing is that USB is bursty, in practice you'll probably still get much better speed out of Gigabit ethernet than you will with USB 3.0.
As for Gigabit ethernet, it's a massive upgrade from 100 megabit ethernet, at least in my usage. It only takes 2 modern drives in RAID 0 to saturate Gigabit ethernet, or just 1 fast SSD.
It works in Firefox 3 now, as the quirksmode link would suggest. Thankfully Firefox's adoption rate for new versions is about a trillion times better than IE's, with Firefox 2 numbers now almost vanishingly small. IE's limitations for inline-block are annoying but hardly insurmountable (though I'm not sure about IE in quirks mode, I don't deal with IE in quirks mode).
What is the best way to create accurate time estimates?
First, take your best estimate, then multiply it by two, and then increase the units to the next largest. So, if you estimate something will take 3 hours, tell the client it'll take 6 days.
LCD panel quality in general has been on the slide for a couple years now. Pretty much every LCD sold today has a trashy TN panel (6-bit colour and awful viewing angles), instead of mostly just the cheap ones like a couple years ago.
All of which, when applied to the simplest and most abstract of all strategy games (GO), fails to produce a competitive program. Search has its limits, even in zero-sum, perfect information, partisan, deterministic strategy games.
That's because Go has enormous average branching factor (>300). Go is definitely not the simplest of all strategy games.
GAs are interesting, but they're definitely less dynamic than the other approaches I mentioned. As you pointed out, GAs are much too slow to use on the fly, you have to prebake them. That has both pros and cons, the obvious con is that if you ever tweak any of the parameters, you'll have to rebake all of your behaviours. The obvious pro is that you can actually see the complete behaviour, and you can manually tweak it (if necessary).
Canonically, a GA is used when the search space is simply too large to search exhaustively. I'm not convinced that that's the case for most games, especially if you can apply a bit of domain knowledge to prune out irrelevant decisions.
I'm not saying GAs are pointless for real time games, but you'd probably need to use them in tandem with some more traditional game trees as well. (You also don't get God AIs because GAs generally don't find optimial answers.)
Games of perfect knowledge versus an opponent are pretty simple to solve. You'll find they all basically boil down to minimax applied to game trees plus an evaluation function (which gives you a fitness value). There's also alpha-beta pruning and things like Negascout which are just optimizations for Minimax. The trickiest part of this is writing an effective (and fast) evaluation function.
Freecell is a bit different because it's a single player game, but ultimately you can apply a similar method as above.
Real time decision making in games is often quite different. One problem is that you don't necessarily always want to make the "best" move. In Game! for example, each monster has a regular attack and may have one or more special attacks. Using simple AI to pick one (such as, pick the attack that does the most raw damage) each time wouldn't be as interesting as picking randomly. Say one of the special attacks for the monster is to steal some gold from the player, why would the AI ever pick that? It doesn't benefit the AI at all, but it does make the monster more interesting to fight for the player. Similarly, if one monster has an absolutely devastating attack, a "smart" AI would always use it. But if the AI always uses the devastating attack then either that monster will be impossible to kill, or the regular attacks must be really boring. But, if the monster with the devastating attack only uses it occasionally, it keeps the player on their toes, perhaps they'll heal more often, or use more powerful attacks to try and dispatch the monster faster.
Having said all of that, random picking isn't always the best way to go (although it's quite efficient with CPU time). The main problem with game trees is their branching factor. Chess is a fairly CPU intensive game for AI to play, as it has an average branching factor of ~36. For real time games, it's likely that you can use domain knowledge to substantially prune the branching factor, which makes the problem much simpler. For example instead of considering to, say, turn left 1 degree, or 2 degrees, or 3 degrees or... you could just consider turning left 90 degrees or 180 degrees. If you only end up with a dozen options left to pick from, you can fairly quickly expand several levels of the game tree and then make an informed decision.
However, some games are not games of perfect knowledge (Backgammon, for example), often they rely on chance. In this case, the value of deeper game tree expansion rapidly diminishes, and you simply need to temper your fitness values based on the expected probability of that move being possible. The other problem with games of chance is that the branching factor is usually very high, which typically makes it unfeasible to expand too many levels in the game tree anyways.
Of course you can precook a number of situations, most good Chess AIs have a large collection of book openings that they use. It's really just an application of domain knowledge again, then you can reuse your game tree expansion with evaluation function on each of the book openings to find the most appropriate one instead of doing an exhausive search of all possible moves.
Of course with AMD around Intel was forced to adopt x64 and produce the excellent Core, Core2 and now Core i7 microarchitectures and do it very quickly.
Actually the Core 1 doesn't support 64-bit and doesn't use the Core architecture, it's basically just a Pentium-M (or two). The first CPU to use the Core architecture is the Core 2.
If you've never made a game yourself, you'd be amazed at how much work it is to create content. Speaking as someone who has made a game (see Game! - The Witty Online RPG), I'll tell you it's way way more work to create content than it is to create game engines or anything else code related. Try looking at the credits for most any game created in the last 10 years and you'll probably find at least 5 content creators (artist, story editor, copy writer, map/model creator, etc) for every 1 programmer, if not more.
So, absolutely, procedural content generation is a huge boon if you do it correctly, much like the "social" aspect of Web 2.0 was a boon for the web, when done correctly. Of course, it's also tricky to do correctly, very few games are there at the moment, and it'll probably take awhile until we have lots of good examples.
Slashdot Mirror
I'm sorry... what? I don't see how that's a reasonable choice at all.
One word: Windows.
Nobody uses 64-bit Windows, and (sadly) Windows users make up the majority of the computer buying population, so board makers don't see any reason to provide for more than 4G of RAM. At the current DDR2 prices, I'd love to drop 16G or 32G in a new system, but it's simply not an option with consumer boards, as you've noticed. As usual, Windows holds back everyone.
Technically you wouldn't put it on the laptop per se, but you could add a link or desktop shortcut to Game!. It'll play on anything with a browser.
For Linux? Sure. I've been using 64-bit Linux for nearly 3 years now, and it's been quite seamless.
For Windows? Pretty much all preinstalled copies of Windows are still 32-bit. All in all, I doubt more than ~5% of Windows users are using 64-bit Windows (although the vast majority will have 64-bit capable hardware). Time has yet to tell how Windows fares on the 32-bit to 64-bit transition.
I agree, but I've never seen such a delay with Wine before. What program did you observe such a delay with, if any?
XP is three times more valuable than Vista.
Three times zero is still zero.
I have a trash can that has a nice big Microsoft "Designed for Windows XP" compatibility badge on it. ;-)
It's a shame they stopped using the "Ready for Microsoft Windows" stickers. They were much better.
What I wanted you to explain is what makes you think a medium that has a burst speed of 4.8 Gbit/s will not be able to sustain > 1 Gbit/s (like your ethernet). I have read a bit, and not seen any info either way...
Pessimism based on USB's poor performance (as far as high speed devices go, anyways) in the past and general pessimism. I actually consistently see sustained speeds of ~115 MB/s over Gigabit ethernet, which is extremely close to the theoretical speed (minus TCP overhead), but I've never seen anything close to 60 MB/s over USB 2.0. Only time will tell for sure though.
'bursty' ... is that sort of like 'minty'? ;)
No, it's that max speeds for USB 2.0 refer to the max burst speeds, not the maximum sustainable speed. A single 7200 RPM drive attached via USB 2.0 will be substantially slower than if you attached it via SATA or IDE, even though 60 MB/s (= 480 Mbit/s) should be enough for most drives.
The thing is that USB is bursty, in practice you'll probably still get much better speed out of Gigabit ethernet than you will with USB 3.0.
As for Gigabit ethernet, it's a massive upgrade from 100 megabit ethernet, at least in my usage. It only takes 2 modern drives in RAID 0 to saturate Gigabit ethernet, or just 1 fast SSD.
There's no reason to have Vista on any computer.
What about a dedicated torture device? For extra cruelty, you could use a netbook too.
It works in Firefox 3 now, as the quirksmode link would suggest. Thankfully Firefox's adoption rate for new versions is about a trillion times better than IE's, with Firefox 2 numbers now almost vanishingly small. IE's limitations for inline-block are annoying but hardly insurmountable (though I'm not sure about IE in quirks mode, I don't deal with IE in quirks mode).
You should learn about display: inline-block;.
First, take your best estimate, then multiply it by two, and then increase the units to the next largest. So, if you estimate something will take 3 hours, tell the client it'll take 6 days.
Konqueror isn't a Webkit browser, it's a KHTML browser (and Webkit was forked from KHTML).
LCD panel quality in general has been on the slide for a couple years now. Pretty much every LCD sold today has a trashy TN panel (6-bit colour and awful viewing angles), instead of mostly just the cheap ones like a couple years ago.
That's because Go has enormous average branching factor (>300). Go is definitely not the simplest of all strategy games.
Turning off and unplugging your computer?
GAs are interesting, but they're definitely less dynamic than the other approaches I mentioned. As you pointed out, GAs are much too slow to use on the fly, you have to prebake them. That has both pros and cons, the obvious con is that if you ever tweak any of the parameters, you'll have to rebake all of your behaviours. The obvious pro is that you can actually see the complete behaviour, and you can manually tweak it (if necessary).
Canonically, a GA is used when the search space is simply too large to search exhaustively. I'm not convinced that that's the case for most games, especially if you can apply a bit of domain knowledge to prune out irrelevant decisions.
I'm not saying GAs are pointless for real time games, but you'd probably need to use them in tandem with some more traditional game trees as well. (You also don't get God AIs because GAs generally don't find optimial answers.)
Games of perfect knowledge versus an opponent are pretty simple to solve. You'll find they all basically boil down to minimax applied to game trees plus an evaluation function (which gives you a fitness value). There's also alpha-beta pruning and things like Negascout which are just optimizations for Minimax. The trickiest part of this is writing an effective (and fast) evaluation function.
Freecell is a bit different because it's a single player game, but ultimately you can apply a similar method as above.
Real time decision making in games is often quite different. One problem is that you don't necessarily always want to make the "best" move. In Game! for example, each monster has a regular attack and may have one or more special attacks. Using simple AI to pick one (such as, pick the attack that does the most raw damage) each time wouldn't be as interesting as picking randomly. Say one of the special attacks for the monster is to steal some gold from the player, why would the AI ever pick that? It doesn't benefit the AI at all, but it does make the monster more interesting to fight for the player. Similarly, if one monster has an absolutely devastating attack, a "smart" AI would always use it. But if the AI always uses the devastating attack then either that monster will be impossible to kill, or the regular attacks must be really boring. But, if the monster with the devastating attack only uses it occasionally, it keeps the player on their toes, perhaps they'll heal more often, or use more powerful attacks to try and dispatch the monster faster.
Having said all of that, random picking isn't always the best way to go (although it's quite efficient with CPU time). The main problem with game trees is their branching factor. Chess is a fairly CPU intensive game for AI to play, as it has an average branching factor of ~36. For real time games, it's likely that you can use domain knowledge to substantially prune the branching factor, which makes the problem much simpler. For example instead of considering to, say, turn left 1 degree, or 2 degrees, or 3 degrees or... you could just consider turning left 90 degrees or 180 degrees. If you only end up with a dozen options left to pick from, you can fairly quickly expand several levels of the game tree and then make an informed decision.
However, some games are not games of perfect knowledge (Backgammon, for example), often they rely on chance. In this case, the value of deeper game tree expansion rapidly diminishes, and you simply need to temper your fitness values based on the expected probability of that move being possible. The other problem with games of chance is that the branching factor is usually very high, which typically makes it unfeasible to expand too many levels in the game tree anyways.
Of course you can precook a number of situations, most good Chess AIs have a large collection of book openings that they use. It's really just an application of domain knowledge again, then you can reuse your game tree expansion with evaluation function on each of the book openings to find the most appropriate one instead of doing an exhausive search of all possible moves.
Attics are terrible, all the heat gets trapped there! Just think of how many fewer computers you can viably run.
No, you can use Opterons on their own, if you want.
Actually the Core 1 doesn't support 64-bit and doesn't use the Core architecture, it's basically just a Pentium-M (or two). The first CPU to use the Core architecture is the Core 2.
But what if I want to play Crysis on my EeePC during that boring office meeting!?
Your 8 core Core i7 EeePC?
If you've never made a game yourself, you'd be amazed at how much work it is to create content. Speaking as someone who has made a game (see Game! - The Witty Online RPG), I'll tell you it's way way more work to create content than it is to create game engines or anything else code related. Try looking at the credits for most any game created in the last 10 years and you'll probably find at least 5 content creators (artist, story editor, copy writer, map/model creator, etc) for every 1 programmer, if not more.
So, absolutely, procedural content generation is a huge boon if you do it correctly, much like the "social" aspect of Web 2.0 was a boon for the web, when done correctly. Of course, it's also tricky to do correctly, very few games are there at the moment, and it'll probably take awhile until we have lots of good examples.