Historical Delivery of IT Services
When I entered the workforce in 1998, there was a “new way” of delivering IT functionality to an organization. In the past, specialized areas would deliver features within their areas, many times without testing or rigor. This worked pretty well when the “IT specialist” was really a business employee who did a little IT on the side, being both familiar with the business processes of his/her specific area and relying on the fact that IT could be pretty much contained within that area without affecting other parts of the business. As the need for centralized IT strategies grew, and disparate systems within the organization became more intertwined, IT departments were formed to focus on the growing information needs of the business. Since increased coordination between systems was required, and communication with business areas needed to be more intentional, the idea of project delivery was implemented. Projects brought many people from multiple areas together in order to coordinate the delivery of big, complex sets of features over a fairly lengthy timeline. It was into this “big project” era that I wandered haplessly as a fresh-out-of-university IT graduate.
I bring this up because it’s relevant to how software, and by extension video games, has been delivered to consumers over the past 20-30 years. This is the model used by Microsoft to deliver Windows and Office: huge applications that included massive system overhauls and (arguably) improvements, all while maintaining as much backwards compatibility and user familiarity as possible. The video game market was similar in that delivery of a game still consisted of a large, complete product assembled over a very long period of time.
The Rise of Rapid Development
When the Internet arrived on the scene, so did a new force in the software delivery world: Google. There were several issues with the “large project release” model. For one, it created several months or even years of “dead time” between releases. Also, once a product was released, it blasted users with a slew of new features resulting in a steep learning curve. Google tried to solve these problems by providing small, quick, incremental updates to services such as Gmail. This accomplished a couple of things. First, it kept the products fresh by constantly adding new features. Second, it gave users time to adjust to smaller, less noticeable changes. It wasn’t long before Google also realized that this approach gave them an advantage for initial service launches – they could launch a skeleton product (see: Google Music, Docs) with bare-bones features and plan to add to the initial offering over time, all while competitors were struggling to launch feature-rich products several months later. No longer was it imperative to launch with a “final product” because not only is “final product” a fallacy, but the delivery method of the Internet made fixing things in the software much quicker and easier. Faster to market is always a competitive advantage, especially if you’re the *only* one in the market for a certain period of time, and you can bring your service to the point of being on-par with those launching much later by the time their product/service actually launches.
It wasn’t long before IT departments around the world began to mimic this method of delivery. They had to; they were now competing with external providers like Google who could promise feature delivery in a fraction of the amount of time as the traditional project environment. They had to deliver more quickly in order to survive. Thus, rapid and waterfall types of project methodologies were adopted within organizations to deliver smaller chunks of functionality and to better adjust feature deliveries as business needs changed over time.
Business, business, business. Numbers. Is this working?
OK, enough of the IT business mumbo jumbo. But let’s not forget that game studios are software development companies, so it’s easy to see how these types of trends have influenced the way we consume our games. MMO’s, specifically, face the problem of a large release of content being delayed, pushed back, and finally burned through in a matter of days once live. They’ve attempted to solve this issue by moving towards the rapid release method of content development, leading to smaller, more frequent content drops in lieu of massive expansion packs. Guild Wars 2 especially favors this type of release schedule, and has kept it up since the game’s launch. Last year, LOTRO announced that 2014 would not include an expansion, and built on that strategy this year by hinting at episodic content releases in the latest executive producer’s letter.
But is rapid delivery good for MMO’s? In a world where first impressions on Twitch and YouTube are everything, is delivery of an incomplete system with the idea of improving it over time a wise move? At first, I was a fan of episodic delivery. It seemed like a good idea to have a continual stream of content delivered to the players every couple of weeks. It would keep people from meandering away from a game during the “downtime” between content releases, and give players something to look forward to with more frequency. But some recent conversations have forced me to re-think this stance.
First of all, the positive effects of marketing hype for large releases and expansions cannot be understated, as was demonstrated recently by Guild Wars 2’s Heart of Thrones announcement at PAX South. During the presentation from Arenanet CEO Mike O’ Brien, an eager audience member shouted “take my money!” prior to any of the expansion features even having been fully detailed. It’s just not possible to generate that level of excitement for a steady stream of content releases. Remember when you were a kid and you used to tell your parents that you wished Christmas was every day? They’d reply: “If it was every day than it wouldn’t be special!” Same thing, here. In the rapid world, players are spoiled by a constant stream of updates to the point of being unable to appreciate the amount they’ve consumed. New stuff isn’t as special as it used to be, and in a way, becomes expected instead of anticipated. How about the quality of game updates? Are smaller releases of equal or greater quality to massive expansions? I’ve read various grumblings about the quality of the writing within the living and personal stories within Guild Wars 2. The living story, at least, has been delivered in various installments to the game via smaller updates over the course of time. And while I’ve not experienced the living story yet, I can say that the dialog within my personal story has been laughable at times. I haven’t decided whether the comedy was intentional or non-intentional, but the adjective that lept to my mind was “cartoonish”. Personally, I didn’t think much of this, since I’m simultaneously reading the Guild Wars novel “The Ghosts of Ascelon” in order to polish up on my GW lore, and the quality/style between the two seems fairly consistent. I will say that I have enjoyed playing through the personal story. So, whatever the quality of the dialog, it hasn’t detracted from my enjoyment. But it does beg the question: could it be better? Does a quickened release schedule force Arenanet to make concessions for the sake of the project timeline?
Between perceived lowered quality, less hype, and diminished player excitement, I’m left to wonder if the Google “rapid release” theory applies to online games. Perhaps we should return to the days of big, hyped expansions that deliver a lot of things that work well.
Featured image by Matthew Hodgson on Flickr
Speed of Light image by John Talbot on Flickr