The lack of a monthly fee is the *only* reason I even tried Guild Wars. I've avoided all the MMORPGs mostly out of a fear I might like one and get sucked into yet another monthly bill that I didn't need.
Just curious, here: do you feel you're "sucked into" cable television?
I used to have cable, but I found I got much more "entertainment value" out of the monthly fee from a single MMORPG (and the monthly fee was much cheaper, to boot). Of course, I use DSL instead of "cable modem"...
I still have television. You might not be aware of it, but the WB, NBC, CBS, ABC and even *gasp* FOX will broadcast their shows through the air directly to your television... all absolutely free!
I laugh when people complain about paying $15 for an MMO subscription (which pays for servers to run the game world), but they don't even blink at paying $30/mo for cable to watch network-broadcast television.
I'm not sure why I'm bothering to explain this. If you haven't listened any of the other times you've been told, you're not likely to listen this time.
Writing an MMORPG game engine + content takes years of work. Buying the boxed game pays for this work.
Running an MMORPG server requires hardware, bandwidth, and customer support staff. The monthly fee pays for this, and provides the profit necessary to justify a "business model."
When an expansion is released, there is a charge for the expansion, used to cover development costs. Again, the box on the shelf is not priced to generate profit. The profit margin is built into the cost of running the game servers (monthly fee is 10% or 20% more than budgetted operating & advertising costs).
Over time, the original boxed release stops generating income to offset the development costs, and the rest of that development cost is written off as investment. At that point, the game itself becomes free for download, with a week's trial. They can afford to give you the game free, because that was never where the profit came from.
Guild Wars is a new business model, because they intend to price their content releases high enough to make a profit -- enough of a profit, in fact, to cover the operating cost of their game servers.
If you're expecting those $20 packs to be "massive" content releases, I have a feeling you're going to be disappointed. A stand-alone game takes less time to develop than an MMO (even a game as complex as Halo), and it sells millions of copies. MMOs (even Guild Wars) do not have that scale. Single-player games can be designed to make money off the sale of boxes. An MMO making that decision is setting themselves up for... well. We'll see if Guild Wars is around in 5 years or not, I guess. They're certainly taking a risk.
Assuming you're building a custom system (as opposed to finding something off-the-shelf):
Tip 5ish - Communication lines fail. Power lines go down at your remote sites. If something fails at the wrong time, your nightly process might not get the data in time to finish. I recommend a "trickle" approach, where the transaction processing software on your remote nodes hands off the resulting data to a separate "central update" program. (This can be as simple as setting a "complete for transfer" flag in your local database, or it can be as complex as establishing a separate queuing mechanism with message passing.) The "central update" process (running on your remote site) continuously handles sending data to the central server (as a low-priority process) and receiving confirmations.
Tip 6ish - use date/timestamps for all your flags (such as "ready to send")! A null value indicates "false," a date/time indicates "true". This kind of information is invaluable when troubleshooting communication breakdowns, and will be of incalculable aid in getting your databases synchronized once again. Timestamps are just A Good Idea.
Tip 7ish - no update is complete until a confirmation has been received from the central server. A "closed loop" transaction, which receives a confirmation back from the central server, will save you more headaches than you can comfortably imagine. TCP/IP confirmations are not enough; those will tell you the message was received, but not that it made it into the database, or that it was successfully validated. You need a separate audit process on the central server(s), scanning your main database(s) for successful updates which have not been confirmed. That process then sends a confirmation back to the originator of the data. The beauty of this approach is that the remote system can be designed to automatically re-send transactions which have not been confirmed in a "reasonable" amount of time. No intervention on the part of live humans is necessary.
If you use an automatic re-send process, make sure the central update server is ready to handle duplicate transactions when a confirmation is lost.
I can see you hated DAoC. In the interest of keeping the facts straight, though, there are currently 5 expansions, and the game was released three and a half years ago. That's about 9 months between expansions.
Love it or hate it, DAoC made some strides forward in the genre: = 3-faction RvR (2-on-1 teaming against the leader) = positional & situational combat moves = stealth system that relied on distance = clever magic lines, such as Bladeturn and the Theurist "one target" pets = PvP where ability to hit an opponent was independant of level (level 20 could hit a level 50 -- although they barely did any damage) = massive scale PvP: 150 vs. 150 was not uncommon during the first year = a stable release. They raised the bar for Acceptable Release Day Performance.
You can focus on the negatives, of course. If that's your karma, then it's your karma. I just want to get the record straight for anyone else taking the time to read comments here.
As far as Imperator: I thought the same thing... wierd concept. But then again, Warhammer has Elves in Space, so... meh. A game is fun or not based on gameplay, not on realism.
Given that Warhammer has a huge existing fanbase, and everyone looks at Imperator and says, "Romans in Space? Wierd."... it makes sense that they would shift their development efforts away from Imperator and onto Warhammer. Mythic produces a polished product, and having Mythic acquire the Warhammer Online rights is a great move for everyone.
Netflix is successful mostly because they have over 40,000 titles on tap. That's more than Blockbuster. Their queueing system allows you to add a movie to your rental queue when you hear about it... instead of wandering into the store, wondering what's good, and trying to remember what your friend mentioned 4 weeks ago. Oh: and you get to browse reviews by other people who have watched the movie. They have over a million movie reviews from customers in their database!
How often have you picked up a box in Blockbuster and thought, "Hmph. Pretty pictures. I wonder if it's any good?"
Anyway, Netflix recently announced (http://ir.netflix.com/, listen to Webcast "Morgan Stanley Small Cap Conference") that they no longer felt download was a viable approach in the short term, and they were investing their time in other directions.
As mentioned elsewhere here, DRM is a big issue with downloads. Yes, you can rip DVDs, but it's the STUDIO EXECS that you have to convince about the "safety" of downloading. If they won't sign on for letting their movies be downloaded from Netflix, then it's not gonna happen. End of story.
If there are any downloads that let you key morse on your phone and have it appear as text in the display, they are very well hidden.
Plenty of PC stuff that will translate typed text into morse code, and even use a microphone to listen to sounds and interpret them as morse (displaying text)... but even that stuff isn't for the phone. The only "Morse" downloads I could find for a phone was Ring Tones.
They would have aborted Alan Turing and let the Germans win.
This is just as broken as the other question.
If Alan Turing didn't exist, there is a very real possibility someone else would have risen to meet the challenge of the German ciphers. Or, that a solution would have been found to the Nazi problem that didn't rely on reading encrypted messages.
Wake up! For all we know, someone was aborted who would have stopped Hitler from ever rising to power in the first place!
Once you start playing "what ifs," anything becomes possible. Don't waste your time going there (at least, not when engaging in serious debate).
I support AMD. I bought AMD even back when Intel performed better, because I wanted to see free market competition. Not only did it work, but it turned out AMD had some pretty smart people on board, and their current architecture is not only excellent, but will continue to scale up for some time to come. I even own AMD stock.
However....
And Dell will keep selling Intel, for a while.
Until it start to hurt the bottom line.
Dell doesn't sell "Intel PCs." They sell service and ease-of-use. Their call centers use scripts based on what they know about the systems they build. Dell doesn't care nearly as much about speed as they do about dependability... both of which can contribute to measures of "performance." (Ask me how well I think a website "performs" when it crashes for 1 hour per week.)
If (my stock portfolio hopes, "when") AMD processors ever provide such clearly superior computing speed that Dell loses market share, then Dell will take the time to gain the expertise with AMD-based configurations. For right now, it is actually cheaper for them to ignore AMD completely, and spend all their effort/$$$ on wringing the best dependability out of their Intel-based configurations.
Quick note: electromagnetic radiation (radio waves, and static) are also emitted by any electronic circuit. I'm not saying this is where a significant portion of the energy goes; I'm quick to admit that almost all of it is released as heat. I'm just pointing out that there are by-products other than heat and light (and those same electro-magnetic side effects are a big source of lost power from energy transmission lines).
Any given design document should address only a limited set of problems, or it will become too complex. Ideally, any given document should be small, compact and address one or (at most) two issues.
I do work at a CMM level 2 company, doing designs, and I don't agree with this principle.
First, though, I'll agree with a point made earlier: no one ever has the full set of requirements. Real-world schedules simply do not allow for it. When business people commit to a project, the money is allocated now, and you'd better be ready for the testing team to do their work sooner, rather than later. So, in practice: you start with the system architect gathering high-level requirements, and sketching a high-level design out of that. He then hands this off to the subject matter experts, so they can begin work on the design of each component -- but meanwhile, the architect fills in suggested low-level requirements, formalizes the document, and reviews it with the customers. He then revises the document as necessary, and passes the "near complete" requirements to the component designers, so they can revise their own designs.
In practice, the customer will sit on the requirements for weeks before signing off on them... even though they are effectively complete at this stage of the game.
It then becomes the job of the architect to merge all low-level designs into a single, comprehensive document. Why? Because ten (or even 3) documents are not handy. In any discussion, people need to be able to refer to a single document, or they waste time looking for the files. Central document management systems help here, but in practice, people will grab something they have printed out when they're headed for the conference room.
So, on to my suggestions for the actual design itself, rather than for the process surrounding it:
1. Use grammatically correct english. Someone else is going to have to read this; english grammar defines the tried-and-true rules for communicating effectively.
2. Use diagram(s) to explain the high-level architecture. Before people can absorb details, they need a contextual framework on which to hang that trivial knowledge. I prefer a data flow approach, where each object in the diagram represents an i/o or storage system; the arrows which connect systems should represent processes which move/transform data.
3. List key requirements, and explain how they are addressed by the architecture. It would be pointless to list everything, but some people work better from lists than they do from diagrams, and it helps to supplement the diagram with a list of key functionality.
4. Section the detailed design into chapters. Each design chapter should be a subsystem from the high-level design, and it should begin with the same sort of overview: a diagram of how the subsystem will function, with a list of key requirements and explanation of how you are meeting them. Many people suggest putting each of these sub-components in a separate design document; you've already had my thoughts on why they should stay together.
5. Peer reviews. Each section of the document should be reviewed by at least one other person, to make sure it is both clear and complete.
One thing to keep in mind as you write the design is that most projects involve trial-and-error; if the designer knew exactly the best way to implement every feature, then the final product wouldn't be innovative in the slightest. You're better off buying off-the-shelf for something that's been done before. Your project is unique, and odds are that some of the design choices are going to be inefficient (or just plain not work!) when push comes to shove... or maybe you will discover during the testing phase that you have a hole in the security layer (you designed security, right?) you could drive a truck through... or maybe when debugging a test scenario, you find your logs (you designed application-level logging, right?) don't provide the right kinds of information. Extensive re-writes of some key components of the design might need to be done.
Design is not documentation. Design is the blueprint, and blueprints make notoriously poor Owner's Manuals.
While we're (almost) on the subject...
If people never bought anything from Telemarketters, companies would stop paying them to make the calls. Same principle.
Case in point: very few people ever clicked on those early web ads. Results? Companies stopped paying sites to display them (started only paying when they were clicked).
I'm going to take a moment to point out that "pip" is a program, usable by the CP/M operating system -- not part of the operating system itself.
command.com was a shell, not an operating system. A sophisticated user won't look at the commands available in ksh or bash and equate them with Unix. Likewise, the commands used to change directories and copy files in MS-DOS are very different from the operating system underlying that shell.
I have a co-worker who just got her laptop stolen. Now if the computer could be tracked when the jerk logs it into the Internet, that would be helpful in tracking the guy down.
Hmph... now there's an interesting thought: "Low-jack" software for portables that automatically connects to a central security service whenever the computer is connected to the Internet. Somebody steals your laptop, you report it stolen to the service, and the system calls the cops if the thieves try to use it without wiping the hard drive.
I caught the same story on NPR, and was overwhelmed by the depth of incidents they were able to uncover. People had their tickets taken away and torn up. Students were thrown out because one of them had a faded Kerry sticker on his wallet... and then their teacher was thrown out when he stepped in and tried to vouch for their behaviour!
If it had been just one story, I would have wondered why they even mentioned it, but NPR went on and on recounting different incidents at different rallies and appearances.
A man with power surrounds himself with people he trusts. If he trusts people who treat our voters this way... what decisions will his trusted advisors make regarding our rights? I never believed the Patriot Act was an insidious plot to sieze power over the american people, because I don't believe our leaders are that corrupt. I can believe, however, that they are just so callous and high-handed that they don't believe the little people need rights. I think that scares me the most.
Slashdot Mirror
The lack of a monthly fee is the *only* reason I even tried Guild Wars. I've avoided all the MMORPGs mostly out of a fear I might like one and get sucked into yet another monthly bill that I didn't need.
...
... all absolutely free!
Just curious, here: do you feel you're "sucked into" cable television?
I used to have cable, but I found I got much more "entertainment value" out of the monthly fee from a single MMORPG (and the monthly fee was much cheaper, to boot). Of course, I use DSL instead of "cable modem"
I still have television. You might not be aware of it, but the WB, NBC, CBS, ABC and even *gasp* FOX will broadcast their shows through the air directly to your television
I laugh when people complain about paying $15 for an MMO subscription (which pays for servers to run the game world), but they don't even blink at paying $30/mo for cable to watch network-broadcast television.
I'm not sure why I'm bothering to explain this. If you haven't listened any of the other times you've been told, you're not likely to listen this time.
... well. We'll see if Guild Wars is around in 5 years or not, I guess. They're certainly taking a risk.
Writing an MMORPG game engine + content takes years of work. Buying the boxed game pays for this work.
Running an MMORPG server requires hardware, bandwidth, and customer support staff. The monthly fee pays for this, and provides the profit necessary to justify a "business model."
When an expansion is released, there is a charge for the expansion, used to cover development costs. Again, the box on the shelf is not priced to generate profit. The profit margin is built into the cost of running the game servers (monthly fee is 10% or 20% more than budgetted operating & advertising costs).
Over time, the original boxed release stops generating income to offset the development costs, and the rest of that development cost is written off as investment. At that point, the game itself becomes free for download, with a week's trial. They can afford to give you the game free, because that was never where the profit came from.
Guild Wars is a new business model, because they intend to price their content releases high enough to make a profit -- enough of a profit, in fact, to cover the operating cost of their game servers.
If you're expecting those $20 packs to be "massive" content releases, I have a feeling you're going to be disappointed. A stand-alone game takes less time to develop than an MMO (even a game as complex as Halo), and it sells millions of copies. MMOs (even Guild Wars) do not have that scale. Single-player games can be designed to make money off the sale of boxes. An MMO making that decision is setting themselves up for
Assuming you're building a custom system (as opposed to finding something off-the-shelf):
Tip 5ish - Communication lines fail. Power lines go down at your remote sites. If something fails at the wrong time, your nightly process might not get the data in time to finish. I recommend a "trickle" approach, where the transaction processing software on your remote nodes hands off the resulting data to a separate "central update" program. (This can be as simple as setting a "complete for transfer" flag in your local database, or it can be as complex as establishing a separate queuing mechanism with message passing.) The "central update" process (running on your remote site) continuously handles sending data to the central server (as a low-priority process) and receiving confirmations.
Tip 6ish - use date/timestamps for all your flags (such as "ready to send")! A null value indicates "false," a date/time indicates "true". This kind of information is invaluable when troubleshooting communication breakdowns, and will be of incalculable aid in getting your databases synchronized once again. Timestamps are just A Good Idea.
Tip 7ish - no update is complete until a confirmation has been received from the central server. A "closed loop" transaction, which receives a confirmation back from the central server, will save you more headaches than you can comfortably imagine. TCP/IP confirmations are not enough; those will tell you the message was received, but not that it made it into the database, or that it was successfully validated. You need a separate audit process on the central server(s), scanning your main database(s) for successful updates which have not been confirmed. That process then sends a confirmation back to the originator of the data. The beauty of this approach is that the remote system can be designed to automatically re-send transactions which have not been confirmed in a "reasonable" amount of time. No intervention on the part of live humans is necessary.
If you use an automatic re-send process, make sure the central update server is ready to handle duplicate transactions when a confirmation is lost.
What the heck -- let's make it six comments.
... wierd concept. But then again, Warhammer has Elves in Space, so ... meh. A game is fun or not based on gameplay, not on realism.
... it makes sense that they would shift their development efforts away from Imperator and onto Warhammer. Mythic produces a polished product, and having Mythic acquire the Warhammer Online rights is a great move for everyone.
I can see you hated DAoC. In the interest of keeping the facts straight, though, there are currently 5 expansions, and the game was released three and a half years ago. That's about 9 months between expansions.
Love it or hate it, DAoC made some strides forward in the genre:
= 3-faction RvR (2-on-1 teaming against the leader)
= positional & situational combat moves
= stealth system that relied on distance
= clever magic lines, such as Bladeturn and the Theurist "one target" pets
= PvP where ability to hit an opponent was independant of level (level 20 could hit a level 50 -- although they barely did any damage)
= massive scale PvP: 150 vs. 150 was not uncommon during the first year
= a stable release. They raised the bar for Acceptable Release Day Performance.
You can focus on the negatives, of course. If that's your karma, then it's your karma. I just want to get the record straight for anyone else taking the time to read comments here.
As far as Imperator: I thought the same thing
Given that Warhammer has a huge existing fanbase, and everyone looks at Imperator and says, "Romans in Space? Wierd."
Netflix is successful mostly because they have over 40,000 titles on tap. That's more than Blockbuster. Their queueing system allows you to add a movie to your rental queue when you hear about it ... instead of wandering into the store, wondering what's good, and trying to remember what your friend mentioned 4 weeks ago. Oh: and you get to browse reviews by other people who have watched the movie. They have over a million movie reviews from customers in their database!
How often have you picked up a box in Blockbuster and thought, "Hmph. Pretty pictures. I wonder if it's any good?"
Anyway, Netflix recently announced (http://ir.netflix.com/, listen to Webcast "Morgan Stanley Small Cap Conference") that they no longer felt download was a viable approach in the short term, and they were investing their time in other directions.
As mentioned elsewhere here, DRM is a big issue with downloads. Yes, you can rip DVDs, but it's the STUDIO EXECS that you have to convince about the "safety" of downloading. If they won't sign on for letting their movies be downloaded from Netflix, then it's not gonna happen. End of story.
If there are any downloads that let you key morse on your phone and have it appear as text in the display, they are very well hidden.
... but even that stuff isn't for the phone. The only "Morse" downloads I could find for a phone was Ring Tones.
Plenty of PC stuff that will translate typed text into morse code, and even use a microphone to listen to sounds and interpret them as morse (displaying text)
This is just as broken as the other question.
If Alan Turing didn't exist, there is a very real possibility someone else would have risen to meet the challenge of the German ciphers. Or, that a solution would have been found to the Nazi problem that didn't rely on reading encrypted messages.
Wake up! For all we know, someone was aborted who would have stopped Hitler from ever rising to power in the first place!
Once you start playing "what ifs," anything becomes possible. Don't waste your time going there (at least, not when engaging in serious debate).
I support AMD. I bought AMD even back when Intel performed better, because I wanted to see free market competition. Not only did it work, but it turned out AMD had some pretty smart people on board, and their current architecture is not only excellent, but will continue to scale up for some time to come. I even own AMD stock.
....
... both of which can contribute to measures of "performance." (Ask me how well I think a website "performs" when it crashes for 1 hour per week.)
However
And Dell will keep selling Intel, for a while. Until it start to hurt the bottom line.
Dell doesn't sell "Intel PCs." They sell service and ease-of-use. Their call centers use scripts based on what they know about the systems they build. Dell doesn't care nearly as much about speed as they do about dependability
If (my stock portfolio hopes, "when") AMD processors ever provide such clearly superior computing speed that Dell loses market share, then Dell will take the time to gain the expertise with AMD-based configurations. For right now, it is actually cheaper for them to ignore AMD completely, and spend all their effort/$$$ on wringing the best dependability out of their Intel-based configurations.
Quick note: electromagnetic radiation (radio waves, and static) are also emitted by any electronic circuit. I'm not saying this is where a significant portion of the energy goes; I'm quick to admit that almost all of it is released as heat. I'm just pointing out that there are by-products other than heat and light (and those same electro-magnetic side effects are a big source of lost power from energy transmission lines).
What the heck happened? All my newline characters got thrown out ... oh, woe is me! Why didn't I preview?
...
....
Testing
Testing more
I guess I should have switched from "HTML Formatted" to "Plain Old Text." Live and learn!
Any given design document should address only a limited set of problems, or it will become too complex. Ideally, any given document should be small, compact and address one or (at most) two issues. I do work at a CMM level 2 company, doing designs, and I don't agree with this principle. First, though, I'll agree with a point made earlier: no one ever has the full set of requirements. Real-world schedules simply do not allow for it. When business people commit to a project, the money is allocated now, and you'd better be ready for the testing team to do their work sooner, rather than later. So, in practice: you start with the system architect gathering high-level requirements, and sketching a high-level design out of that. He then hands this off to the subject matter experts, so they can begin work on the design of each component -- but meanwhile, the architect fills in suggested low-level requirements, formalizes the document, and reviews it with the customers. He then revises the document as necessary, and passes the "near complete" requirements to the component designers, so they can revise their own designs. In practice, the customer will sit on the requirements for weeks before signing off on them ... even though they are effectively complete at this stage of the game.
It then becomes the job of the architect to merge all low-level designs into a single, comprehensive document. Why? Because ten (or even 3) documents are not handy. In any discussion, people need to be able to refer to a single document, or they waste time looking for the files. Central document management systems help here, but in practice, people will grab something they have printed out when they're headed for the conference room.
So, on to my suggestions for the actual design itself, rather than for the process surrounding it:
1. Use grammatically correct english. Someone else is going to have to read this; english grammar defines the tried-and-true rules for communicating effectively.
2. Use diagram(s) to explain the high-level architecture. Before people can absorb details, they need a contextual framework on which to hang that trivial knowledge. I prefer a data flow approach, where each object in the diagram represents an i/o or storage system; the arrows which connect systems should represent processes which move/transform data.
3. List key requirements, and explain how they are addressed by the architecture. It would be pointless to list everything, but some people work better from lists than they do from diagrams, and it helps to supplement the diagram with a list of key functionality.
4. Section the detailed design into chapters. Each design chapter should be a subsystem from the high-level design, and it should begin with the same sort of overview: a diagram of how the subsystem will function, with a list of key requirements and explanation of how you are meeting them. Many people suggest putting each of these sub-components in a separate design document; you've already had my thoughts on why they should stay together.
5. Peer reviews. Each section of the document should be reviewed by at least one other person, to make sure it is both clear and complete.
One thing to keep in mind as you write the design is that most projects involve trial-and-error; if the designer knew exactly the best way to implement every feature, then the final product wouldn't be innovative in the slightest. You're better off buying off-the-shelf for something that's been done before. Your project is unique, and odds are that some of the design choices are going to be inefficient (or just plain not work!) when push comes to shove ... or maybe you will discover during the testing phase that you have a hole in the security layer (you designed security, right?) you could drive a truck through ... or maybe when debugging a test scenario, you find your logs (you designed application-level logging, right?) don't provide the right kinds of information. Extensive re-writes of some key components of the design might need to be done.
Design is not documentation. Design is the blueprint, and blueprints make notoriously poor Owner's Manuals.
While we're (almost) on the subject ...
If people never bought anything from Telemarketters, companies would stop paying them to make the calls. Same principle.
Case in point: very few people ever clicked on those early web ads. Results? Companies stopped paying sites to display them (started only paying when they were clicked).
I'm going to take a moment to point out that "pip" is a program, usable by the CP/M operating system -- not part of the operating system itself. command.com was a shell, not an operating system. A sophisticated user won't look at the commands available in ksh or bash and equate them with Unix. Likewise, the commands used to change directories and copy files in MS-DOS are very different from the operating system underlying that shell.
I caught the same story on NPR, and was overwhelmed by the depth of incidents they were able to uncover. People had their tickets taken away and torn up. Students were thrown out because one of them had a faded Kerry sticker on his wallet ... and then their teacher was thrown out when he stepped in and tried to vouch for their behaviour!
... what decisions will his trusted advisors make regarding our rights? I never believed the Patriot Act was an insidious plot to sieze power over the american people, because I don't believe our leaders are that corrupt. I can believe, however, that they are just so callous and high-handed that they don't believe the little people need rights. I think that scares me the most.
If it had been just one story, I would have wondered why they even mentioned it, but NPR went on and on recounting different incidents at different rallies and appearances.
A man with power surrounds himself with people he trusts. If he trusts people who treat our voters this way