stavrus

This just reads as a random mishmash of missteps the company has taken over its 33 years of existence (remember, it's older than Amazon or Google) rather than a proper critique of when it arguably lost its shine in the public's eyes. The company still generates a ton of money, continues to set records for day 1 sales of its games, and owns extremely valuable IP in the gaming industry, so you can't really say it hasn't adapted well to the current industry norms. At times, it practically sets them. It has certainly missed a lot of opportunities, such as turning BattleNet into a public digital storefront before Steam, or capitalizing on the MoBA genre that spawned from their own games before competitors did, but I doubt that they would have had as much success even if they did because their approach would have been different.

Jason Schreier's recent book covers some of the game cancellations. The Warcraft adventure game was cancelled after they flew out one of the best designers in the genre for a week to try to make it work, and make it fun, and couldn't. It was a game that was outsourced to a different company, and they didn't feel like it was up to their quality standards to ship. Shutting down Blizzard North came about as a consequence of the distance between them and HQ, leading to a different studio culture that became difficult to manage, and the uncontested resignation of Blizzard North's executive team when they tried to make demands from Blizzard's owners, Vivendi.

Polygon [1] covered the Starcraft: Ghost game. Long story short, it got canned because it was in development hell for too long. Originally under development by a studio in the Bay area, there apparently wasn't a dedicated Blizzard producer to the game for the longest time, and the idea of what it should be kept changing as new games came out and HQ wanted them to copy those ideas. At some point, Blizzard shifted development to a different studio just miles away from them because they wanted multiplayer, but the same issues persisted. And then they released WoW, which consumed all of their attention. With the release of the gen 7 consoles around the corner, requiring further investment, they made the sensible choice to shelve it so they could focus their time and money on their new cash-printing machine instead.

Experimentation is important for finding the fun, and cancelling what isn't working is a required part of the process. And while, yes, there's a ton of games in the Blizzard graveyard, they're no exception. Valve has a list of cancelled games that's probably just as long. And they're all the better for it. Titan died in favor of Overwatch, Nomad died in favor of World of Warcraft.

[1] https://www.polygon.com/2016/7/5/11819438/starcraft-ghost-wh...

I don't think the license change is unwarranted. At a previous employer we used Terraform but the pricing on the cloud/enterprise offerings was prohibitive enough that we instead had a dev create simple wrapper scripts in our CI/CD system to run the deploy jobs. Significantly cheaper, but I spent years pushing for us to eventually move to the paid offerings as the developer experience was significantly lacking (and to support Hashicorp), up until I left the company. I think they're still using those wrappers today despite how awful they were to use.

There was definitely room for improvement around using Terraform to do actual deployments. From better UX around doing PR's -- showing not only the commit diff but the output of a "tf plan" as well to see what it might actually do -- to actually running the deployments on isolated build machines that could hold the sensitive cloud API keys and provide a deployment audit trail, these were all features that teams absolutely needed to use Terraform sanely. As a solo developer you don't really need those features, but if you're on a team you definitely did, and were almost certainly willing to pay for it. Hashicorp recognized that need and created the cloud/enterprise offerings to provide that.

At some point the thought even crossed my mind of creating some open-source tool that could provide a nice enough web interface for dealing with Terraform for teams, building on what we had and providing the features I listed above, but the main reason I didn't was because it would be biting the hand that feeds. Such a tool would take away people's incentives from using Hashicorp's paid offerings and ultimately reduce their investment in Terraform and their other fantastic tools, and in my opinion, be disrespecting the tremendous work Hashicorp had done up to that point. I've been a user of their stuff since they only had Vagrant, and of course have loved them seeing them succeed.

It seems others, however, had different opinions and saw a business opportunity thanks to the permissive licensing and the high costs of Hashicorp's paid offerings. Plenty of money to be made from making it easy to use TF in teams, especially when you're not obligated to contribute back or maintain the underlying software [1]. Any time I saw a "Launch/Show HN" post from a company that was offering such TF wrapper web interfaces, I kept being surprised that Hashicorp hadn't yet clamped down on preventing lower-cost offerings of their paid services. It was only a matter of time.

[1]: I realize this reads as overly harsh to some of these companies, especially as some of them are in here replying and pledging to give back, so let me try to explain my reasoning here. When I use a product, I like it when the source is available from me to learn from and understand how it works [2] and to contribute back to for needed features or bugfixes [3].

When a company makes a product open-source, that's great! But if that product is the core of that company's business model [4], and another company starts competing with that company using the same open-source product, then I see a problem down the line. While you can make the argument that the competition is good and motivates the two companies to compete on the value they bring to their customers, which is a net-benefit to the open-source ecosystem as a whole as the open-source product is improved, it eventually turns into a race to the bottom. Pricing will be used as a core differentiator, reducing the overall R&D spending on the open-source product because ultimately the two companies have to maintain non-R&D staff like sales, finance, and support. If the Total Addressable Market is fixed (obviously not, but work with me), then that's two or more companies with the same fixed non-R&D costs diverting revenue that could be spent instead on improving the open-source product. Sure, the reality is that a lot of that revenue isn't going back to the open-source product, as a lot of people are complaining about in the comments, but that diversion is probably going to happen anyway whether there's 1 company or 20, so I'd accept it as a cost of doing business.

If instead the competition were on providing a better but different open-source product in the same space (e.g. Pulumi), rather than working off the same base, that would be a different story. But if developers keep seeing businesses take open-source projects and directly compete with their creators, then I think we're going to see a net harm to the open-source community as it creates a sort of chilling effect as it'll demotivate them from going the open-source route so that they can find a viable way to sustain their efforts. I think licenses such as the BSL and SSPL are valid enough compromises, considering that even mentioning the AGPL inside of a lot of companies seems to be like someone saying Voldemort's name. We can't rely on large corporations sponsoring open-source projects, either with money or developer time, if we want them to succeed.

We grant inventors 20 years of exclusive-use on an invention, provided they explain how to reproduce it through the publishing of a patent. What's the difference between that and the BSL? I see a lot of complaints about bait-and-switches, but I don't really see the issue. If you contributed to the project under the old license, it's still available under the old license! You just don't get any of the new changes starting from the license change. If you decided to use Terraform in a non-competing way [5] solely because of the old license, and are concerned about the new one, then you have to recognize that Hashicorp is now another addition to a long-line of "open-core" companies trying to deal with the reality that companies will make money any way they legally can. This is where the industry is currently headed, and whatever replacement you find will probably be next.

If you believe different, then make an open-source offering, and don't just make a public statement saying it'll be open-source forever. Public statements are great and all, up until there's doubts about meeting payroll. Find a way to make the statement legally binding and then we're talking. Which is I guess why there's so much consternation, since the way to do it is through the license, but the OSI doesn't recognize any of these other licenses as "open-source" and the AGPL is a non-starter at most companies.

[2]: Reading the source code for libraries I use has been incredibly valuable in my understanding of how to use the libraries properly, much better than any documentation could. And of course, makes me a better programmer in the process.

[3]: At one point, Terraform was missing a feature that I badly needed. With the source available, I could easily get a new version of it running locally with that feature to unblock me, and then everyone benefited when I contributed it back to the project. It's also been invaluable having these locally modifiable builds to understand the quirks of products from cloud vendors, and to work around them. Ever had multiple deployment pipelines fail because Azure decided to one day change the format of the timestamps they returned in API calls, without publishing a new API version? I have.

[4]: As opposed to supplementing their business model. Google open-sourcing K8s was great for them because it drove adoption of their cloud VMs. Their cloud business makes money off the VMs, not GKE, so sponsoring K8s is essentially a marketing expense. But for Hashicorp, their core business model is paid offerings of their products.

[5]: Yes, I get that the license currently is un-clear, for all their products. But let's simply say that you're not trying to directly sell a wrapper around running Terraform.

Is this a new requirement? I remember for Kubecon Seattle 2018 using an iOS app (named KubeCon+CNC) that was nothing more than a schedule viewer for the event. It didn't even use native views and given how narrow the audience for the app was -- attendees for one of two 3-day conferences -- I was surprised at the time that it even existed as an app and had made it past the app store review.

I also know of at least one app, a sanitary self-certification app that allows your entry into a European country by generating a QR code to display, that is also basically a shell around a simple web app with a form. It absolutely should be an app given how convenient it makes accessing the entry requirements and generated QR code, but its existence does make these app store requirements seem absolutely arbitrary.

For what it's worth, I hope you do end up writing more posts in the future. It's easy to overlook or forget the pains and lows of projects in hindsight, especially for particularly successful ones like the ones you've worked on. Your blog posts have been some of my favorites because they don't gloss over the sacrifices required for those successes, a reality that Blizzard's historically secretive culture tended to hide a lot of. Your work more than speaks for itself, and you've definitely earned the right to be boastful of it.

I was actually excited to see your blog domain pop up on HN today, only to find out it was to an old post. You have a ton of valuable insight and knowledge into games and project management and I hope that commenters like the one you replied to don't put you off from sharing that with the world.

But something happened after the success of WoW the company grew quickly and with that came some bad people and after the merger, Bobby Kotick could exert his influence.

I don't think this was the case, and that rather WoW's success forced the company to become more professional but the sexual harassment culture was so ingrained that the company couldn't shake it off. The name thrown around the most due to the lawsuit was Alex Afrasiabi, who was hired in early 2004 to work on WoW (which released November 23, 2004). You can also take a look at WoW's credits [1] and see the mention of "sexy HR girls" or their internal tenth anniversary video [2] from 2001 that covers why they hired their first female employee.

A couple of weeks back the youtube algorithm decided to show me the youtube channel of one of the Warcraft 3 level designers who worked for Blizzard from 1998 to 2003, and in one of his videos, made 4 years ago mind you, he's pretty clear on what the culture was like there [3], with the choice quote "if I wanted to bring a sexual harassment lawsuit against Blizzard ... I could have easily done that."

The guy also said that Rob Pardo (lead designer of Starcraft, Warcraft III, and WoW, and now founder of Bonfire Studios since his ejection from Blizzard in 2014) was particularly toxic. And it seems he's not the only one with the same sentiment [4]. The other Rob from that tweet I'm guessing was Robert Bridenbecker [5], who was with the company since 1995. These were people that had to have been working closely with Morhaime due to the nature of their positions, so keeping them around for so long despite the outstanding HR complaints doesn't bode well.

Is it worth following and supporting the new gaming ventures if this is the culture those veterans fostered and had grown accustomed to?

[1] https://www.mobygames.com/game/windows/world-of-warcraft/cre... [2] https://twitter.com/GameAnim/status/1420581827698302980 [3] https://youtu.be/kVWyf7mzVR4?t=945 [4] https://twitter.com/gamedevconnie/status/1418946551834157056 [5] https://www.bloomberg.com/news/articles/2021-07-22/inside-ac...

This is the money they could have used to have a buffer to deal with these situations or to improve their systems.

Matt Levine covered this last year [1]. The basic gist of it was that the CEO is focused on the shareholders, and the best use of the money was on stock buybacks. Spending money on improving customer or labor relationships wouldn't have helped during the start of the pandemic when all the airlines were stuck in the same boat unable to fly planes, and the cash used by e.g. American Airlines for buybacks in the past 7 years to increase the stock value 113% would have only bought them 4 months of operating expenses. The most long-term value for shareholders was created through the buybacks, and the government being willing to prop the businesses up during downturns reduces the risk exposure from this strategy.

[1] https://www.bloomberg.com/opinion/articles/2020-03-17/the-go...

This isn't specific to the M1. I had my MBP 2016 13" die in the same exact way about two years ago. Same failure mode where it just refused to boot no matter what I did, though it was possible to sort of turn it on if you left it alone for a couple of days. Was able to use that to pull the data off the machine and create a Time Machine backup, but it turns out that Time Machine can lie to you about having completed a backup so I would have lost all of my data were it not for the manual backup I performed.

What was frustrating to me was that I knew my model had a diagnostics port that allowed direct access to the SSD (see https://9to5mac.com/2016/11/24/apple-special-cdm-tool-macboo...) to pull the data off of it, but the service wasn't offered when I went to get my machine repaired. I was forced to accept the data loss from having the logic board replaced.

I later had bluetooth issues on the same laptop, and that required another logic board replacement. Which, surprise, came with data loss once again. Also had a lot of fun learning with that repair that Apple changed the extension backups are stored as, and Time Machine can't recognize the new one as a restore source for some reason unless you rename the folder to use the old one. Wasted quite a few hours on that, and Apple's phone support had no idea about why Time Machine wasn't seeing it.

Anyway, moral of the story is, backup often, and have more than one backup method, unless you like losing your data.

Your repurposed analogy isn't quite right. Google is providing a service by running around and grabbing those samples. Value is provided not only to you, the searcher, by receiving an answer to a question you posed, but to the coffee shops as well by providing them with a potential customer. Is Google not allowed to profit off of providing this value for the work they're doing?

A coffee-shop owner could argue that Google is providing enough coffee that it's disincentivizing someone like you from making a purchase, but the issue here is that Google provides tools to the coffee-shop owners to opt-out of giving those samples to potential customers. Instead of using them, the owners want to force by law that Google pays them for the samples because they still want Google to do all that leg-work of finding new customers for them. This could make it cost-prohibitive to run the service, especially as the legislation can be interpreted broadly (e.g. Google says that as written it'd be difficult for an algorithm to distinguish between news and non-news content).

I think a better analogy would be around restaurant delivery drivers. Pretend for this analogy that restaurants have a captive supply of delivery drivers that can't go off and get another job, because all the drivers know is how to drive restaurant deliveries for a living. Restaurant owners are incentivized to use the delivery drivers because it allows them to get more customers. What if the owners started asking for a law to be passed that made delivery drivers have to pay them for providing delivery service. The drivers can still make money in the end after the tips they get anyway, right?

What's frustrating to me is that even though a lot of these frameworks and tools keep advertising themselves as making you more productive and letting you write less code in the pursuit of better client experiences -- ie, creating an "SPA", a single page application -- they keep adding more tools your way and more required boilerplate for you to write. You can argue that it's inevitable as they "mature", but then someone comes along a year later with a fix to those problems and you're forced to relearn everything to keep up. This cycle then starts over anew for the next 2-3 years as more tools and required boilerplate are added and someone gets frustrated enough to provide a new framework and tooling.

I've gone through this, in turn, as I've developed applications from plain old JS, to jQuery, to Backbone.JS/Marionette, to AngularJS, to Angular, and most recently to React, along with the similar change in tooling through Grunt, Gulp, and Webpack. Each time as the amount of boilerplate I'm forced to write begins to frustrate me, a new framework conveniently rolls around and convinces me to switch. I haven't looked at Vue.js yet, but a co-worker on a different team showed me a React/Redux project and I ran away screaming -- figuratively, not literally! -- from the boilerplate involved (if you're wondering, so far I've been pairing React with MobX but the applications haven't been particularly big). The dev experience has been better each step, but it's not been an easy ride and it's obvious that these frameworks don't represent the end of the chain.

All this time I thought this was just the required tax for providing a nice front-end experience, but recently I've been diving heavily into Blazor Server-Side and Phoenix LiveView on some personal toy projects to see what the server-side landscape is like, and it's a breath of fresh air. It's surprisingly quick and easy to write code that provides an SPA experience where changes on one connected client immediately propagate to other connected clients, and with so little code to boot. They have their pros and cons, but the dev/productivity experience has felt so much better. Because C# is such a great language, Blazor is super easy to jump into and immediately understand what's going on, and since it's part of ASP.NET you're not going to lack in good libraries/documentation/examples/support. However, it doesn't really have a good reload-on-changes functionality yet even while running under dotnet watch, as you'll have to manually reload your browser tab after changes. Phoenix LiveView on the other hand has a great reload-on-changes functionality for fast iteration, but its drawback is that it has a much steeper learning curve and initial hurdle. Fortunately it's offset by the fantastic documentation it provides, but it is something to keep in mind as it makes on-boarding people not used to Elixir/Phoenix a bit difficult.

Honestly, if the OP article resonates with you, I recommend giving one of those two server-side frameworks a spin. It's nice to temporarily escape from the craziness of the modern JS landscape, and to not have to write your models twice.

I remember watching a GDC talk of JAM (https://www.gdcvault.com/play/1018184/Network-Serialization-...), which was Blizzard's solution to network serialization for WoW back in 2004. The talk even had performance comparisons against protobuf and it seemed like a decent alternative that worked well for them. Was this new alternative an extension of JAM, or a full rewrite? I know they have millions of players monthly, but I can't imagine saving a bit on bandwidth could have warranted a full rewrite, especially when the majority of their traffic is from their own datacenters.

It seems a lot of people are missing the true concern here because they only read the first half of the article.

Going to paraphrase the article a bit here but yes, the website is capturing the filled-in data even if the user hasn't hit the submit button. However, they're also running a tracking script from an advertisement network in the background that attempts to capture your e-mail. If you visit Site A as a result of one of the ads from that network, but leave without putting down your e-mail address, and then go to Site B and do leave your e-mail address, the ad network will send your e-mail address to Site A in an attempt to "re-capture" that lost impression for Site A even if you never even hit submit on Site B. They're marketing it as a way of reducing ad-spend because you don't have to keep trying to target potential customers who've already shown interest through more ads.

I'm not a lawyer so I'm very curious to know how this doesn't easily violate COPPA for Site A, Site B, and the ad network, among other privacy laws. The wording from the ad network shown in the article is a bit vague around enabling a "triggered email sequence", so I'm wondering if they get around some legal issues by sending emails for Site A on their behalf rather than sharing the email address itself.

* Edited for minor typos I noticed after hitting submit.

They're also free to circumvent the software and play the game without it [...] People shouldn't have to abstain from playing a game they bought because the game company doesn't have total access to their machine.

Imagine we're playing soccer. We both know the rules. However I don't really like how those rules restrict me from using my hands when I'm not a goalie. You could say that I feel like the rules shouldn't have total access to dictate what I can and can't do with my body. But you want to play soccer and the rules that go with it. Who should abstain from playing the game?

For the sake of this example, please don't suggest saying that the rules should be changed by the players to accommodate both. This isn't a possibility in video games for the players. They can either choose to play with the existing ruleset or not play at all.

If your suggestion is to just avoid players that don't want follow the rules, with the game providing this as an in-game mechanism, please be aware this doesn't really work and is very ripe for abuse. There was a case early on in Overwatch where they had a top player complaining that they were no longer getting into games successfully. An investigation revealed that they were so good at the character they were playing -- a sniper -- that their opponents didn't want to play against him/her and thus used the in-game avoidance feature to do so. This had the net result of the match-making system not finding enough players for him/her to play against anymore.

They need to come up with better ways to detect cheaters. Methods that work on the server side.

But they are coming up with better ways to detect cheaters, and it's through these kernel drivers. Ultimately, differentiating between a regular player and a cheater is a matter of how many signals you can analyze. The quality of the model you can build for identifying cheaters increases as you add more signals. And with a good enough model you can reach a certainly level that allows you to comfortably start issuing bans. You can see it with the link you provided, where the researchers found a way to add more signals to the model by analyzing the network traffic patterns.

Unfortunately, server-side detection can only get you so far. If a player turns on a wallhack, what signal can the server use to figure out what's going on? If my LoL champion has a defensive ability that I can use to dodge attacks, and my cheat program can detect incoming attacks that'll hurt me and activate it for me, with it programmed to have a minimum time to activation in order to pretend the reaction time is human, what can the server do to detect this?

Ultimately, to answer these questions you have to start asking the client to assist you by providing more signals, but when the client is under user-control it's trivial to lie to it. Hence the need to move some of the anti-cheat code to driver-space.

By the way, server-side detection doesn't really account for the reality of how cheaters actually cheat. Fancy detection methods like dynamic Bayesian networks for statistically analyzing shooting accuracy in FPS's sound great in theory, but aimbots don't really snap to player's heads anymore. Instead they guide the player's aim when toggled on and only do this gently, so that even human reviewers have a tough time seeing what's going on. The intent there is to increase the uncertainty level of the model declaring the player a cheater, as companies fear banning players accidentally and will only issue bans once they are positively sure the player is a cheater.

I'm sure Riot and many other game companies are using as many server-side detection methods as they can, so what exactly do you expect the game companies to do when they run out of available server-side detection methods and still have a cheater problem to deal with that affects their bottom line?

You don't have to sacrifice your computing freedom and privacy. These anti-cheating modules tend to be explained to you upon game installation, so if you're not comfortable with what they do then just cancel the installation. You're not forced to play the game, but the modules are part of the game's rules and you have to adhere to them if you want to play it.

All the participants of a game agree to a common set of rules required to make the game fun, fair, and enjoyable. And this is true of any game, from online games such as LoL to offline games like poker and soccer. Unfortunately the prevalence of cheating has made the anti-cheating modules another bullet point on that set of rules for online games. There's still plenty of games out there that you can play with people you know personally and can trust, but I certainly cannot find and organize 59 other people to play Battle Royale shooters with me within minutes of wanting to play a match on my schedule, so I'm ok with the trade-offs involved in making that possible. Just please don't force your principled stance on others.

Unfortunately this doesn't apply for warranty repairs directly through Apple, as Apple won't bother using this port. They'll just tell you you're SoL and happily remind you of their iCloud services for backups. I had this happen to me on my 2016 TB MBP where the logic board had issues detecting the power level of the battery and wouldn't boot. I knew of the port, and asked them to use it, but their response was that the warranty would only cover like-for-like repairs and that I was responsible for backing up the data. Fair enough, except that Time Machine can and will lie to you about whether it actually backed up the data on your machine. Which is exactly what happened with my machine when I got it back and attempted a restore. Thankfully I had a separate non-Time Machine back up that I could use to bring my data back, but it wasn't fun manually restoring my OS profile and settings. I even managed to get a CS rep to confirm with me over the phone that I was not the only person to have had this happen to them.

Apologies for ranting here; I just hope I can save another person from this BS if they attempt to rely on this port. Through the entire process no Apple rep would confirm the existence of the tool so they made it seem like I was forced to use them for the warranty repair with total data loss.

If I may ask, samcat116, what's the normal procedure for handling warranty repairs at a certified repair center like the one you work at? Is it just labor cost, with parts billed to Apple? And does that include the copying of the data off the SSDs? I'm imagining for warranty repairs the easiest way to handle them is to just swap the logic boards out like Apple does and not bother doing actual diagnosing at the board level like https://www.youtube.com/user/rossmanngroup since the customer isn't paying for parts?

One of the level designers for WoW has apparently written a book on the game's original development. The Kickstarter [1] for it failed due to an unrealistic funding goal, but if you're looking for something along those lines it might be something you'd be interested in keeping track of as he's planning on re-launching a funding campaign with a smaller budget.

Not a book, but the blog posts on making the original Crash Bandicoot [2] make for a great read, especially due to some of the issues they ran into in trying to squeeze out every last bit of performance from the original Playstation. [3]

[1] https://www.kickstarter.com/projects/476291819/the-world-of-...

[2] https://all-things-andy-gavin.com/2011/02/02/making-crash-ba...

[3] https://www.quora.com/Whats-the-hardest-bug-youve-debugged

I'm not seeing how the two paragraphs are incongruous. The company is selling their brand, not the user info, when they run the promotions. If no-one signs up for the promotion, no user info gets shared. Ultimately it's the users who choose whether they want to sell themselves as a marketing lead in return for a slim chance at winning.

Interestingly enough Warcraft 3, despite being almost 15 years old, still gets new patches. The latest one came out just a month ago [1].

[1] https://us.battle.net/forums/en/bnet/topic/20753797075

This might particularly interest you: http://www.lettersofnote.com/2012/08/why-explore-space.html

The gist of it is, in 1970 someone asked a director of NASA why billions of dollars were being spent on exploring space when millions of children were still dying on Earth. The response in part explained that NASA's R&D was paving the way for satellites with better weather forecasting, better communications, and better equipment that was making its way into people's everyday lives. While a bit morbid to say, the advancements made by NASA have arguably saved many more lives in the long run.

It's hard to see the point in investing in experimental technology whose payoff is unknown, especially when we have definite problems with feasible solutions. That doesn't mean we shouldn't try. The possible payoffs - cancer cures, age prolongation, enhanced food production, disease and sickness prevention - that can come from investing in gene therapies are just too great to ignore.

As a side-thought, the technological singularity is thought of as the point at which we create an AI smarter than us, triggering a run-away effect of self-improvement. What if we end up doing it to our own race first through intelligence-improving gene modification? Can you imagine the implications of applying that intelligence to solving the rest of our problems?

Those have no costs, except for limited maintenance, and the game development has paid itself years ago. So it is virtually pure profit.

In the years since WoW came out Blizzard came out with a centralized authentication, billing, and support system known as Battle.Net. It took them quite a few patches over 2-3 expansions to integrate that system fully into WoW and a not insignificant effort would be required to port that over to the old game client, especially if they wanted to give it the same level of polish in integration that they're known for applying to their games.

Second, patch 2.0.1 (the Burning Crusade pre-patch) brought in a massive amount of changes designed solely to combat a growing player trend at the time - the use of addons to automate playing the game (no not bots, actual addons like Healbot) - through the concept of protected functions. And this was just a small portion of their overall effort in combating automation/bots. The player base would cry foul if they brought out legacy servers and didn't keep the anti-bot measures, Warden included, up-to-date. They tried for years to fight those problems head-on only and are only barely keeping up in the fight against Glider and its brethren. Log onto retail WoW nowadays and run non-100 dungeons and you'll easily run into quite a few sophisticated bots that'll run the dungeon with you, fully programmed to handle all the dungeon mechanics [1]. There's also plenty of people running bots with level 90 (from the character boost) druids farming dungeons like Stonecore, Gundrak, and the like. It's kind of hilariously sad seeing a chain of them all following the same pre-programmed path in the world, especially when they take advantage of how client movement works in the game to fly straight through obstructing terrain as if it weren't there.

Third, running a game, especially an MMO, also requires providing dedicated support staff. A very large effort would have to be made to recover/remember the issues and workarounds the GM staff would use back when the server was live and then train the new staff with this knowledge. There would probably be a rather significant engineering effort involved in this as well as the old GM ticketing system used to be done entirely in-client while nowadays it's some web-based thing (the former made it rather easy for players to impersonate GMs). Improvements like those and other GM tools like better insight/control over a player character and logged events that were made over the years would have to be back-ported in order to maintain the high expectation of quality Blizzard support has fought hard to maintain.

[1] https://www.youtube.com/watch?v=tsaE4pM9-cw

A friend did some research in this area, comparing FPGAs, CPUs and GPUs. He published a paper [1] in regards to performance for several common Linear Algebra computations across a variety of input sizes. In particular, Figure 2 shows you where each of the platforms works best.

FPGAs are essentially re-programmable hardware, so they tend to outperform CPUs/GPUs when you program them for a specific task. They don't have to deal with most of the overhead that the more generalized platforms deal with which is why they dominate in the small input sizes. However, with FPGAs you're trading space (silicon) for that re-programmability so you can't have as much hardware in the same area as say a GPU. Thus, when the data sizes have saturated the available hardware of the FPGA for computation, the GPU begins to outperform. Due to the decreasing node sizes (28nm, 22nm, etc), we can fit more programmable logic into the same area, which causes the chart I mentioned above to shift more into the FPGA's favor.

[1] http://www.researchgate.net/profile/Sam_Skalicky/publication...

Why would you consider these analytics scripts useless? The article mentioned several reasons they want to be tracking this timing information (monitoring of slow backends/CDNs and the performance of their own scripts) - having that information is vital for ensuring the usability of the site [1]. If a portion of your userbase all of a sudden starts loading the webpage much slower than usual (e.g. from issues as diverse as bad network routing or just a specific browser choking on your scripts), having the information available to you to quickly diagnose and fix the problem is a lifesaver. After all, the website is their product, so they need to ensure it's always available and usable for all their customers.

[1] http://timkadlec.com/2014/01/fast-enough/

A lot of companies force you to sign an agreement that essentially hands over the rights to anything and everything you do while employed, even if you did it outside of work hours and on your own personal equipment. I'm not a lawyer so I don't know how enforceable this type of agreement is, but as far as I'm aware it has yet to be tested in court.

Your friends probably don't do games on the side because of such an agreement. I couldn't even imagine the issues that might arise from an employee working on mods for a competitor's game, especially since for some games modding isn't explicitly supported by the developer and modders are forced to break EULA's (by reverse engineering) in order to make the mods in the first place.

One of the main limitations is actually power, as increasing the frequency increases the power draw. All that power turns into heat, which has to be dissipated. Modern processors already shut off inactive cores and change the frequency of the active cores on the fly depending on the workload to reduce the power draw [1], so it's easier to add performance by adding cores. The problem is that software hasn't quite caught up to take advantage of the added cores.

[1] http://en.wikipedia.org/wiki/CPU_power_dissipation

Just want to point out that if you're using an encrypted filesystem, vagrant up will fail if NFS is enabled. The workaround is to use rsync to maintain the synced folders, a feature introduced in Vagrant 1.5. Just use vagrant rsync-auto to keep the guest folder in sync automatically with your local folder. If you modify files within the VM (like with a bundle install that modifies your Gemfile.lock or with rails generators), I recommend installing the vagrant-rsync-back plugin (https://github.com/smerrill/vagrant-rsync-back).

That was probably the case back in vanilla (pre-expansion) WoW. With the introduction of cross-realm battlegrounds in 1.12 - a month before the first expansion - followed by the activation of arenas in the first expansion, they most likely considerably expanded their server capacity to accommodate for the increased load. I remember seeing news articles back in the day just a few months before Burning Crusade's launch that Blizzard had bought a massive amount of servers, but the only thing I can find now is this blog post: http://www.rahulsood.com/2006/02/blizzard-going-crazy-for-op...

However, it's important to note that around this time Blizzard was heavily improving their Battle.NET service and launched a download service where you could register your CD keys from their previous games such as Starcraft and Warcraft III and download a fully working ISO that did not require the physical CD to run. The server purchases may have gone towards that instead.

Would love it if Blizzard wasn't so secretive about everything, especially their tech. CCP, makers of Eve Online, have been very forthcoming in talking about their entire stack in their developer blogs and videos - from infrastructure and hardware, to how they profile their code and the software design choices they make.

A similar case happened with the Eve Online cluster (~50,000 concurrent users) a couple of years ago. A programmer, who for some reason had access to the live cluster, confused his local development instance with that of the live cluster and issued a shutdown. Luckily they were able to avert the incoming disaster in time (it was a timed shutdown), but jokes are still made about the mistake.

http://oldforums.eveonline.com/?a=topic&threadID=1232785