










Mainly Game Development related articles, analysis, whitepapers. Other items of personal interest may sneak in...
by John Biggs on December 31, 2010
Tags: progress bar, video
I always wondered why OS X progress bars had an odd ripple effect and now we know: rippling progress bars seem to move faster across the screen, making you think stuff is getting done faster.
What’s a QA team without a spec? A goddamned nuisance and a waste of time, that’s what.
Man I hate when QA people do their jobs without specs! It’s so irritating. When Asheron’s Call 2 launched, there were thousands of outstanding bugs in the QA database that we opted not to fix before launch. Sounds bad, doesn’t it? But if you looked at them, you’d understand. Hundreds of them were bugs about how buildings were floating 2 virtual inches off the ground; if you zoomed the camera down to the floor and looked up, you could see that these structures were very slightly hovering.
Yet few products these days can succeed without their online community, and the insight you can gain from interacting with that community is unparalleled, despite the pain. But to take advantage of that learning, you have to avoid the absolutely one and only cardinal sin of community management: not listening.
No, I don’t mean gankers. The PK mafia I refer to is that school of game design which believe that the only “true” PvP game is the one where PvP death has a real penalty. The proponents typically urge very harsh penalties, as found in Darkfall (where all your possessions fall to the ground for the enemy to loot).
Some years back a school of thought argued that a “true” role-playing experience required fully open PvP (anyone can kill anyone else). The leaders of Funcom’s design department for Age of Conan must have been believers, since the only “official” RP server for Conan is also a PvP server. Curiously, I never saw a single PK on that server result from RP, despite spending months in a bloodthirsty, hardcore RP guild. I did see plenty of casual killing and suffered a predictable dose of gankings. Nobody bothered to “dress it up” with roleplay. They were too busy ambushing the next victim or getting to a safer spot ASAP. The only RP PvP fight I saw was a carefully arranged event by people who knew each other, like a virtual world LARP.
Outline
This is a long article on a complex topic. An outline may help you skip to the “good parts.”
* Big Launch Fever – Why boxed game marketing is inappropriate for download MMOs.
* Product & Pricing Strategy – The F2P model and its essential components.
* Customer Management – The centerpiece of MMO marketing, and how it starts with CRM.
* Customer Acquisition – Customer segments and targeting, promotional approaches, social network strategies and continual acquisition.
* Customer Development – Understanding customer types, meeting their needs, promoting community, eliminating community-breakers and professionalism.
* Churn Analysis – The importance of analyzing customer departures.
* Retrospective – Additional thoughts and references.
2D BOY have published details of their World Of Goo First Birthday experiment. Offering the game for whatever price people wanted to pay (previously it was $20), this meant people could get a copy for as little as $0.01 or as much as fifty million squillion space dollars. (I believe that’s the upper limit.) Originally this was intended to last for a week, but has now been extended to 25th October. And being a rather open sort they’ve announced how many copies they’ve sold so far, and indeed how much people have been paying, along with much more. It’s an unprecedented amount of detailed sales information. Its significance shouldn’t be underplayed.
In the last week there have been approximately 57,000 sales of the game. Which is a pretty stunning number.
German National Gamers Survey 2009 | Graphs
Please find below all freely available graphs of the German National Gamers Survey 2009 as part of the Today’s Gamers series of surveys in UK, FR, DE, NL, BE and US:
Estimating and planning are critical to the success of any software development project of any size or consequence. Plans guide our investment decisions: We might initiate a specific project if we estimate it to take six months and €1 million but would reject the same project if we thought it would take two years and €4 million. Plans help us know who needs to be available to work on a project during a given period. Plans help us know if a project is on track to deliver the functionality that users need and expect. Without plans we open our projects to any number of problems.InformIT: An Agile Approach to Estimating and Planning > Chapter 3: An Agile Approach
An Agile Team Works As One
Critical to the success of a project is that all project participants view themselves as one team aimed at a common goal. There is no room for a “throw it over the wall” mentality on an agile project. Analysts do not throw requirements over the wall to designers. Designers and architects do not throw designs over a wall to coders; coders do not throw half-tested code over a wall to testers. A successful agile team must have a we’re-all-in-this-together mindset. Although an agile team should work together as one whole team, there are a number of specific roles on the team. It is worth identifying and clarifying those roles that play a part in agile estimating and planning.
The solution was to present the player with an opt-in page upon registration to use their Twitter account to tweet game updates. For each action that they permitted to be tweeted, the player gained an additional 1 per cent to income.
"There were people that turned it off," said Abad, "but early on most people switched them all on, and that was a really good way for us to get the word out - by building into the gameplay mechanics incentives for them to market it for us."
The survey of 2,425 respondents identified that free-to-play web games generated the highest revenue ($75 on average) and that virtual currencies were the most popular purchase. But the report unveiled a number of valuable insights into what works and what doesn’t in the world of microtransactions.
Head over to the icopartners blog to get it.
Very interesting article, mostly because Eric Lindstrom mentions a couple of good examples of anticipated risks which nevertheless became reality, regardless of mitigation efforts.
"It is particularly interesting to note that much of what went wrong in development involved pitfalls that we anticipated but still fell into despite our efforts to avoid them. It's important to note that most postmortems talk about "What Went Wrong" and not just "What We Did Wrong" because sometimes you make mistakes, but other times you suffer from acts of god and do your best to cope.
A Game Developer article last year ("What Went Wrong?" December 2008) specifically questioned why game development seems to make the same mistakes over and over. In light of that, some of the "wrongs" will be discussed in terms of how our methods to avoid known issues fell short."
A couple of useful comments about flash games and how to use microtransactions for monetization. Common sense is yet again very helpful.
"Done correctly, games designed with microtransactions in mind need not infuriate gamers. Harris recalls that his team was careful to build a complete game for those who just want to play -- and beat -- the game for free.
"You can go through all 30 levels of SAS without paying a dime," he says. "We believe that to be very important. And people who don't mind forking over a few dollars for extra content can go to the premium license tab and buy some kick-ass guns, the ability to regenerate health, and even something called 'guardian angel' which lets you continue from where you died."
Laszlo Szalvay of Danube talking about "impediments" in the context of Scrum:
"In the Scrum method of agile development, a scrum impediment is defined as anything that stands in the way of a team's productivity. This can literally be anything, from a team member who isn't pulling his or her weight to an uncomfortably warm team room. But if it's keeping the team from working at optimal efficiency, it's an impediment.
Luckily, Scrum dedicates an entire role to the resolution of these impediments: the ScrumMaster. The ScrumMaster works in a variety of capacities, such as helping the Product Owner prepare the backlog or radiating Scrum artifacts, but the primary responsibility of a ScrumMaster is to remove scrum impediments and facilitate a highly performing team. To help the ScrumMaster achieve this, the team is responsible for communicating what barriers are impeding their progress. This occurs each day in the daily Scrum, when team members report on their accomplishments for the past 24 hours, goals for the next 24 hours, and what scrum impediments stand in their way. This systematized feedback loop ensures that a ScrumMaster always knows what is keeping the team from success and work to remove them."
A nice article by Thomas and Diane which covers all aspects of localisation. Its impact on the localisation of the game content, Customer Support and community management.
Guido Schoonheim shares a case study about "fully distributed scrum". The study describes a project which involved 200 developers, located in India and the Netherlands. You can find the slides at the end of the article, interesting read.
"What is Fully Distributed Scrum?
Offshoring classically is performed in a waterfall process fashion, meaning that one party writes specifications and chucks them over the wall to the other party who then chucks a software product back after a period of time. When evolved to Agile software development, this is the last thing you want to do. However you do need to deal with the distance between your local staff and your talent in an offshore location.
The only way to get the benefits of both Agile development (hyperproductivity with high quality and motivated people) and the benefits of offshoring (lower costs, availability of talent, up/downscaling with no risk) is to apply Agile to the offshoring dilemma. Xebia has made this the core practice and differentiator of our offshored development"
A good FAQ, should work nicely in combination with "scrum in 5 minutes" by Jeff Sutherland if you want to intend to introduce SCRUM to a team or manager/director who is not familiar with SCRUM yet. Good questions, good answers.
"This Scrum FAQ section contains a transcript of Ken Schwaber answering commonly asked questions about Scrum."
Tobias Mayer shared some games and exercises at the Agile Conference 2009 which aim at providing a deeper understanding of agile dynamics and principles. Maybe something useful for your next SCRUM workshop?
"Customers are never thrilled to find out they can’t get all the features they want in release 1.0 of a new software product (at least, not if they want the features to work). However, if the development team cannot deliver every requirement by the scheduled initial delivery date, the project stakeholders must agree on which subset to implement first. Any project with resource limitations has to establish the relative priorities of the requested features, use cases, or functional requirements. Prioritization helps the project manager resolve conflicts, plan for staged deliveries, and make the necessary trade-off decisions."You can find his spreadsheet here.
"During our estimation (still doing hours effort estimation) we were trying to define the tasks necessary for a story to be completed, however the story had a “task A” that would lead to several “task B’s” that were known, however no-one could (and neither should they be expected to) estimate the hours effort on the “task B’s” simply because the input from “task A” was critical to the timing! Now you’re stuck with tasks that are KNOWN, but cannot be TIMED. And then the light went on and I realized why estimation with time was so bad…You may KNOW everything you need to do (the complexity), however you may not necessarily know how LONG everything will take (the effort), in other words, you know COMPLEXITY but you cannot measure the EFFORT. It now makes sense…"
The guys at http://highscalability.com released a list of 13 best practices about scaleability, check out their website if you want to know more about it and check the comments as well. Here are their top three:
AFK Partners has release what they feel are the Best Practices for Scalability:
1. Asynchronous - Use asynchronous communication when possible.
2. Swim Lanes – Create fault isolated “swim lanes” of hardware by customer segmentation.
3. Cache - Make use of cache at multiple layers.