America's Army looks, plays, and runs great... except for the parts that aren't the Unreal engine. All of the software around the engine needs some serious work. Here's hoping the new development team can whip this software into shape! Huah!
Warning, rant follows:
This is not the forum for complaining about the shoddy software (that Americans probably paid collective millions in taxes for), but here are a few of the simplest pieces of functionality that are miserable failures:
- Server can't cycle maps, causes client GP fault
- Client menu layout is incomprehensible
- Whether you're online or offline is some kind of mystery
- Plenty of 'Error connecting' messages with no information
- Connecting to a so-called LAN game requires opening the command console
- There was talk of 'admin mode' and the only documentation for logging in as an admin is in the FAQ (if it's so frequently asked, then how about making it part of the login dialog?) Then once you log in as admin, are you a player with admin ability, or some non-player observer. How do you get back to being a regular player? Others don't see you logged in, but your personal user name appears in the admin list of online players....
The web page calls this thing both a "phaser" and a "disruptor." They claim it's a molecular displacement attack (disruptor), but go on to say it works like a "phaser on stun." Does it use an phased energy amplification capacitance-and-release mechanism? Oh I don't think so. Where's my Star Trek technical manuals...
If they can't keep their terminology accurate, how can we take this seriously?
I admit, I had never heard of this either, until I saw a display at the Canadian War Museum (Ottawa). They have a nice description of the incindiary intent of the weapons, as well as a map of bombs that were found along the North American west coast (most were probably lost at sea). I think only one casualty for the entire effort - a US farmer who tampered with one he found.
The museum even had one of the devices! (Reproduction?)
I have a quick solution! Encrypting the stream is easy. Just pick some stream cipher (e.g., RC4), pick any key, send the data through the cipher prior to multicasting. In the clients, hard-code the key for decryption.
... Ohhh, but you probably also want it to actually be secure? You want to handle clients joining/leaving the multicast session, and need to change the key so they can't keep getting data? Real security is hard.
... Ohhh, and are you using the common best-effort (non-reliable) multicast, or are you using some type of reliability protocol? Stream ciphers do not fare well against lossy networks.
There is a lot of research on multicast security, but from your question, I don't think you're looking to do a thesis. So I don't really have a quick solution. Sorry, I was deliberately wasting your time.
Robo Rally is the best game ever designed (IMHO)! I design software, but I have yet to find anyone with any background that does not like this game. The pacing, "fun level," and social interaction is perfect. Each player's robot can interact on the game board, so there's a lot of interpersonal communication (e.g., OMG you pushed me onto the spinner, which caused me to walk into a double laser).
FYI, the story I was told involving the game's conception: Richard Garfield went to Wizards of the Coast with this game design in mind. WotC was concerned about production costs, so asked Garfield for another idea. Garfield came up with Magic: The Gathering rather "off the cuff." The Magic phenomenon is legendary (or will be if it's popularity ever ends), which provided the kinetic energy to produce Robo Rally.
"Complex" is exactly the wrong way to describe any security feature. If the feature is really "complex" how do they expect it to be used correctly?
(Answer to my own hypothetical question: They don't expect people to use it correctly. MS is not in the business of making correct software, they're in the business of making money. To make (more) money, they must (claim they) have security features.)
Probably all of us subscribers (*) surfing the face of the slashdot wave! I saw the blurb pre-post, and read the article before the crest came crashing down on everyone in the tube. Yea slashdot subscription service!
Ultima VII has an incredible musical score! I had a SoundBlaster with (TurtleBeach?) WAV table synthesis daughter board at the time. Not quite the Roland MT32, but sounded great.
The score was so well composed that it could transition based on game events. That happends a lot in games today, but it enhanced the gameplay immeasurably at the time. The whole mood of different towns and caves was set by the score.
The Exult project has Ogg-encoded music from the game, as generated by the Roland MT32. When I play the tracks, I can vividly recall the experience of the game.
... and much of the/. croud must be pedantic, as well. I expected this to be modded only Funny, but some have taken it as actual insight, which I think is just great!
The title should be updated. A Trekkie communicator brings to mind Captain Kirk flipping open a palm-held device. A Trekker communicator indicates a lappel-pinned badge. Please be more diligent when posts involve Star Trek sub-cultures.
... now, should I post this anonymously, or openly attach my geek-code
Go buy Screeching Weasels's Teen Punks in Heat album and listen to Six Percent. Before you leave for your tour, buy the rest of Screeching Weasel's albums.
Let's separate "beta" from "demo." Is it beneficial to have a limited-release beta? The beta probably has more bugs and less features than the eventual demo, but presumably will be played only by the "serious" gamers.
Does it make sense to end the beta phase with an open demo, or move right into the final product? MMO games tend to follow the beta path, since a "demo" of a persistent world doesn't really work.
Large software projects can manage parallel development. Not fixing problems with their product is inexcusable. However, this doesn't mean that have to freeze development on expansions.
To their internal project management, the two issues may be very separate (e.g., expansion team may be separate from maintenance team). The simplest branching mechanism in a revision control system should facilitate this (except of course MS VSS).
Does anyone have any inside knowledge on EA project structure?
I'm not an AI expert (but I worked with some in school). Catan is a GREAT game, but it seems to have a number of balance-swaying heuristics. That is, there are limited high-level strategic directions you can choose, which can really affect the gameplay. This is perfect for humans, but an AI routine can iterate a few general strategies to find out which one works with the current state of the board.
My point is, an AI could be too easy to develop and be too good at the game. Then again, I've seen a lot of games rebound unexpectedly.
Anyone out there have real experience developing an AI for Settlers?? Are my comments accurate at all?
The current crop of "anti-cheating" software mostly tries to analyze when a player is playing "too well." This does not solve the underlying flaws in the system.
There are some CS research papers, which are starting to address cheating from a more fundamental (theoretic) point of view. Here's one that applies cryptography to prevent cheating for distributed game protocols:
I agreee with malakai's philosophy: anything in the client is suceptible to attack by the local player. However, I do not share malakai's optimism that Palladium (and other DRM technologies) will solve any of this. Rather, it'll just be another level of the same "arms race."
It is a fundamental flaw to attempt to secure what is in the hands of the enemy (to paraphrase a well-said post below).
(OK, so I don't have anything of substance to add, yet. Sorry, I was deliberately wasting your time.)
The lack of proofreading aside, I get the strong impression this is the author's first application of cryptography. At the highest level, this does implement a DRM scheme (which is by definition fundamenatlly flawed, of course). The devil is in the details.
Take page 17 of the Systems Design Document, for example. The use of Low and High security levels is misguided and misleading: "This level of encryption ensures that content can only be decrypted by applications that are not malicious..." How so?
On the same page, the use of the term "PUBLICKEY" is questionable. Public key usually implies public key cryptography, but this is a symmetric key. Furthermore, what is a 1024-bit 3DES key? 3DES uses a 168-bit key.
Still on page 17, SHA1 values should not be referred to as checksums. Later, they are properly called hash values. Weak terminology is a minor complaint, but has no place in a security paper.
Overall, I hope the music industry (et al.) uses Media-S for all its DRM needs!
Slashdot Mirror
America's Army looks, plays, and runs great ... except for the parts that aren't the Unreal engine. All of the software around the engine needs some serious work. Here's hoping the new development team can whip this software into shape! Huah!
Warning, rant follows:
This is not the forum for complaining about the shoddy software (that Americans probably paid collective millions in taxes for), but here are a few of the simplest pieces of functionality that are miserable failures:
- Server can't cycle maps, causes client GP fault
- Client menu layout is incomprehensible
- Whether you're online or offline is some kind of mystery
- Plenty of 'Error connecting' messages with no information
- Connecting to a so-called LAN game requires opening the command console
- There was talk of 'admin mode' and the only documentation for logging in as an admin is in the FAQ (if it's so frequently asked, then how about making it part of the login dialog?) Then once you log in as admin, are you a player with admin ability, or some non-player observer. How do you get back to being a regular player? Others don't see you logged in, but your personal user name appears in the admin list of online players....
The web page calls this thing both a "phaser" and a "disruptor." They claim it's a molecular displacement attack (disruptor), but go on to say it works like a "phaser on stun." Does it use an phased energy amplification capacitance-and-release mechanism? Oh I don't think so. Where's my Star Trek technical manuals...
If they can't keep their terminology accurate, how can we take this seriously?
I admit, I had never heard of this either, until I saw a display at the Canadian War Museum (Ottawa). They have a nice description of the incindiary intent of the weapons, as well as a map of bombs that were found along the North American west coast (most were probably lost at sea). I think only one casualty for the entire effort - a US farmer who tampered with one he found.
The museum even had one of the devices! (Reproduction?)
Wow, two updates and still sloppy editing.
m = milli
M = mega
There is a lot of research on multicast security, but from your question, I don't think you're looking to do a thesis. So I don't really have a quick solution. Sorry, I was deliberately wasting your time.
Robo Rally is the best game ever designed (IMHO)! I design software, but I have yet to find anyone with any background that does not like this game. The pacing, "fun level," and social interaction is perfect. Each player's robot can interact on the game board, so there's a lot of interpersonal communication (e.g., OMG you pushed me onto the spinner, which caused me to walk into a double laser).
FYI, the story I was told involving the game's conception: Richard Garfield went to Wizards of the Coast with this game design in mind. WotC was concerned about production costs, so asked Garfield for another idea. Garfield came up with Magic: The Gathering rather "off the cuff." The Magic phenomenon is legendary (or will be if it's popularity ever ends), which provided the kinetic energy to produce Robo Rally.
Does anyone know how accurate this is?
"Complex" is exactly the wrong way to describe any security feature. If the feature is really "complex" how do they expect it to be used correctly?
(Answer to my own hypothetical question: They don't expect people to use it correctly. MS is not in the business of making correct software, they're in the business of making money. To make (more) money, they must (claim they) have security features.)
Probably all of us subscribers (*) surfing the face of the slashdot wave! I saw the blurb pre-post, and read the article before the crest came crashing down on everyone in the tube. Yea slashdot subscription service!
(Please forgive the surfing analogy.)
Ultima VII has an incredible musical score! I had a SoundBlaster with (TurtleBeach?) WAV table synthesis daughter board at the time. Not quite the Roland MT32, but sounded great.
The score was so well composed that it could transition based on game events. That happends a lot in games today, but it enhanced the gameplay immeasurably at the time. The whole mood of different towns and caves was set by the score.
The Exult project has Ogg-encoded music from the game, as generated by the Roland MT32. When I play the tracks, I can vividly recall the experience of the game.
... and much of the /. croud must be pedantic, as well. I expected this to be modded only Funny, but some have taken it as actual insight, which I think is just great!
The title should be updated. A Trekkie communicator brings to mind Captain Kirk flipping open a palm-held device. A Trekker communicator indicates a lappel-pinned badge. Please be more diligent when posts involve Star Trek sub-cultures.
... now, should I post this anonymously, or openly attach my geek-code
Go buy Screeching Weasels's Teen Punks in Heat album and listen to Six Percent. Before you leave for your tour, buy the rest of Screeching Weasel's albums.
Let's separate "beta" from "demo." Is it beneficial to have a limited-release beta? The beta probably has more bugs and less features than the eventual demo, but presumably will be played only by the "serious" gamers.
Does it make sense to end the beta phase with an open demo, or move right into the final product? MMO games tend to follow the beta path, since a "demo" of a persistent world doesn't really work.
Large software projects can manage parallel development. Not fixing problems with their product is inexcusable. However, this doesn't mean that have to freeze development on expansions.
To their internal project management, the two issues may be very separate (e.g., expansion team may be separate from maintenance team). The simplest branching mechanism in a revision control system should facilitate this (except of course MS VSS).
Does anyone have any inside knowledge on EA project structure?
I'm not an AI expert (but I worked with some in school). Catan is a GREAT game, but it seems to have a number of balance-swaying heuristics. That is, there are limited high-level strategic directions you can choose, which can really affect the gameplay. This is perfect for humans, but an AI routine can iterate a few general strategies to find out which one works with the current state of the board.
My point is, an AI could be too easy to develop and be too good at the game. Then again, I've seen a lot of games rebound unexpectedly.
Anyone out there have real experience developing an AI for Settlers?? Are my comments accurate at all?
The current crop of "anti-cheating" software mostly tries to analyze when a player is playing "too well." This does not solve the underlying flaws in the system.
There are some CS research papers, which are starting to address cheating from a more fundamental (theoretic) point of view. Here's one that applies cryptography to prevent cheating for distributed game protocols:
Cheat-Proof Playout for Centralized and Distributed Online Games
From the SIGNL lab at UMass, Amherst.
Anyone know of any more?
I agreee with malakai's philosophy: anything in the client is suceptible to attack by the local player. However, I do not share malakai's optimism that Palladium (and other DRM technologies) will solve any of this. Rather, it'll just be another level of the same "arms race."
It is a fundamental flaw to attempt to secure what is in the hands of the enemy (to paraphrase a well-said post below).
(OK, so I don't have anything of substance to add, yet. Sorry, I was deliberately wasting your time.)
The Video Game Awards were a great idea, but turned out to be the biggest pile of marketing trash I've ever fast forwarded through.
I'll let SpikeTV off the hook, because I love MXC.
The lack of proofreading aside, I get the strong impression this is the author's first application of cryptography. At the highest level, this does implement a DRM scheme (which is by definition fundamenatlly flawed, of course). The devil is in the details.
Take page 17 of the Systems Design Document, for example. The use of Low and High security levels is misguided and misleading: "This level of encryption ensures that content can only be decrypted by applications that are not malicious..." How so?
On the same page, the use of the term "PUBLICKEY" is questionable. Public key usually implies public key cryptography, but this is a symmetric key. Furthermore, what is a 1024-bit 3DES key? 3DES uses a 168-bit key.
Still on page 17, SHA1 values should not be referred to as checksums. Later, they are properly called hash values. Weak terminology is a minor complaint, but has no place in a security paper.
Overall, I hope the music industry (et al.) uses Media-S for all its DRM needs!