Genuinely curious. There are several dev methods when it comes to developing software, some better than the other. As software development is a complex business (it terms of scope, feasibility etc.) it’s always smart to stay ahead of the curve.
In light of the way WoW is being developed which method do you guys the team uses? Personally? I think they adhere to the (ancient) waterfall method. aka:
Requirements > Analysis > Design > Implementation > Testing > Deployment.
This method isn’t useful for large project because it doesn’t allow for changes later along the way. Because large software project are complex issues you cannot plan ahead of time in an in-depth manner (See Stacey diagram). It’s mainly useful for small changes in existing software. Aka complicated issues. Reason why I think the WoW dev team still uses this outdated method is the lack of flexibility, how else can they only chance a system one year after its implementation? They already went through the requirements, analysis and design phase during the alpha, where it was already implemented.
IF the teams follow the agile method of development I’d be shocked how badly they use it. Agile (as the name implies) allows for more flexibility. A team makes a MVP (Minimal viable product) in a ‘‘sprint’’ ranging about 1-4 weeks. This allows for adjustment in later sprints when it’s concluded that things cannot work or need a revision. This also includes giving a demo after each sprint to stakeholders and/or end-users. Blizz kinda shows this with the PTR, but then again, PTR is mostly, if exclusively, just to test for bugs. Nothing in the PTR (at least to my knowledge) that had been designed and implemented in it had been adjusted to such a degree it strayed from the initial design. (Torghast may be the only thing?) But lets also not get into product owners (if they have them). Blizzard seems to be the kind of company that’d rather put the least amount of money in for the biggest profit margins.
But what do you guys think? Does Blizzard work with the latest, (or older) efficient methods? Or have they been working the same way they had been working for 20 so years?
I think their biggest problem is their failure to respect their paying customers enough to do research necessary to characterize the playerbase into target demographics and determine what should be done to keep them playing.
This expansion is a vanity project. It doesn’t matter how efficiently they created it, if it’s something that they made because they wanted to, knowing that a lot of customers were going to hate it.
As i’m not a blizzard dev, i unfortunately cannot answer your question here and I doubt anyone whos not a blue really can effectively answer your question. I also don’t think a blue would tell anyone that cuz its likely a trade secret and could get them yeeted out of the company.
He’s not looking for an answer from Blizzard. He’s looking for a discussion among people who care about things like the fact that Blizzard has long had the industry reputation for being glacially slow to respond to the need for critical changes.
I doubt giving out what methodology you use as a company aversely impacts your business. Using agile is hardly a ‘‘secret’’, in fact, saying you use it or promoting its use can be a promotion for new employees looking to expand their toolkit. In fact, saying you use x method and y tools is often used as a selling point for devs (besides signalling you are innovative). Software development is a trade where you constantly need to learn, so using only the old method of working can be a turn-off for people that want to broaden their career prospects.
Bingo. I agree with your first post. In a perfect scenario the community council would act as stakeholders for their team. They get demo’d a MVP every so often with a NDA tied to it and talk with business analysts about requirements… if they worked agile… in a perfect world. But it seems Blizzard puts too much trust in analytics and player ‘‘behaviour’’. Without taking any context into consideration as to why people do x, y or z.
I’d say they do a mix between a DevOps and a Waterfall method, while everyone just thinks they should be working with Agile, it just isn’t that feasible with their type of game development.
Blizz has plans for the future and does active development for expansions to come. This can be hard to grasp for some, but think of it this way: when 9.0 was released, they started production on 10.0 and pre-production on 11.0. Asset management, CGI and Video, wireframes, textures, and a lot of other things that my head can’t grasp this early in the morning take a while to produce and while are in active development all the time, they have to focus them down for the current expansion and start to solidify their designs. Remember it does take roughly 3-4 years to make a game and they want to bring out an expansion every 2 years, so some of the development starts early.
Anyways, all that stuff is going on for 10.0, while 9.0 is just launching. They are also working on the story aspects for 11.0. They figure out where they want the characters and get the art teams to start designing. As 9.0 progresses, they listen to their customers (yeah feel free to laugh) and start working on changes. However, since they’ve been working on future projects, 9.1 would have been scoped out almost prior to Beta being released. Any major changes had a hard time getting mixed in with plans and programming that already was in place. It would take another 6 months to do those changes.
That is more than likely going to be the issues and why people get frustrated with Blizz, the scopes. They always have these great plans and want to get 10 pounds of content into a 2 pound hat, but when they have to start trimming, cutting, and players aren’t found of the contents because of the trimming and cutting, it ruins their steam. It is hard for them to go back and re-do plans for step C when they are working on step M.
Understand where I am going? I do agree that if they brought out smaller content patches and went to a pure DevOps method we might get more content, the sad thing is we’d probably end up having the same build times. The planning stage could be 2 months with maybe another 4 of building, top it off with the 2 months of testing and there is most of a year for a patch half the size. It really is all about the perspective and they have to start stuff earlier.
I have no idea how they work now. Blizzard used to be a -work 15+ hours a day and sleep under your desk- kind of company… I get the feeling it’s more of a -do a little work every day until you’re about to be fired and then try to unionize- kind of company.
Good insights overall! I agree that it is hard for anything agile to work out in game development, but I think it lends itself reasonably well to MMORPG’s. Of course, a lot comes down to budget and having bodies who work on things. Risk taking is something foreign to Blizzard but, maybe, the game can benefit from small content patches. Experimenting with a team who brings out something like a story quest line, zone event with a transmog or any other cosmetic reward every 2-3 months can be a way to find/renew the look on MMORPG development - Content which is small enough which isn’t test/design heavy.
Overall though, I think communication can help a lot when dealing with scope creep. People can be dicks, but it’s better than the current situation where a lot of people get the feeling that decisions are being made from an ivory tower. Better to admit it will take until next patch to fix things, or that it’s a hard process than be silent.
Good point! Just had a quick look. Erixi is right in that they use DevOps since there were postings for it, but I don’t see anything agile related. (Product owner, scrum master or mention/experience with it or related tools.)
It’s my perception that WoW was written in C++ which implies an object oriented approach. Watts Humphrey suggested a software process maturity model that has five levels, the first being rather chaotic which is overcome by programming superstars who make the product happen. When I was in software, I remember a seminar where it was suggested that 75% of software development was at level 1, 20% at level 2 and 5% at level 3. The problem with the maturity model is that the more effective the process, the larger the overhead footprint so companies usually won’t opt for a more robust software process. The Waterfall model doesn’t exactly complement O-O development.
Since classic was purportedly based on the backup of a backup, I suggest that there was no concerted configuration management when the game was created which points more toward a level 1 process. This implies no detailed design, and no ‘standard’ for development or testing which suggests to me that the game was created by impassioned people, software professional and digital artist superstars, guided by someone or group of leaders with a vision, to create this amazing game.
So what I expect now is that they have millions of lines of code interfacing with an immense amount of data for which there is not a lot of documentation or commented code. Make a change and things get impacted that no dev anticipated. More changes, more impacts until finally the impacts are sufficiently insignificant that they can be relegated to a back burner. Consequently, my perception is that the method they use is ‘get it done’, i.e., no formal method is universally applied, just individual methods of O-O, database, and client-server development that the devs brought with them when they were hired.
I think Guild Wars 2 had some good systems and did a great job with Agile sprints, but still had to plan things out. They had a content patch every 3ish months that would change a zone or add more story. While their content was smaller in comparison to WoW, it felt like a lot. Specially when you get say 4 patches a year.
The problems they had is that sometimes those patches removed something you enjoyed. If you weren’t a super active player, you might miss out on a lot of content or wonder why a zone is completely different never knowing a story element took place 3 months ago. It also felt like you had to rush through that content to experience it.
But that is just examples of the double edge sword of design.
Good points in your entire post. It is too late, but, if the development team had any maturity in its early stages they’d have a, or, multiple software architects to create some form from an otherwise not-so-insightful blob. If there still aren’t architect at Blizzard I reckon they can bring a positive change to at least map the landscape and prevent (unwanted) wild growth. Of course, this might introduce more red tape, but, as long as an architect (team) doesn’t make decisions from an ivory tower they can really help in creating structure.
I think Blizzard has already a somewhat decent solution to the issue of missing content with the time travel NPC’s in selected zones (Dark shore, Blasted lands etc.) With the only downside that it can split players who are doing old or new content. Even so, given the fastness and amount of old zones I think any team would have their hands full to bring each zone to current lore events.
I think what you are describing is the ideal. But issues ranging from massive waves of layoffs to boost short-term profits, Activision moving release dates up because of upcoming releases from other companies, covid, more recent legal issues, and just in general low employee morale from a toxic workplace leading to a continuing exodus of their most productive employees means they are probably behind on everything.
I think this is the first expansion built entirely around whales. The development was told to cut costs after BFA was such a huge investment loss, and so we got minimal product and whale squeezing techniques.
I think it was already the long-term plan to cut development costs by streamlining development with design-by-template systems like mission tables, world quests, etc.
I think that’s why they promoted Ion to his present position. They were looking for someone who would commit to a project like that.
