Sunday, 1 May 2011
Monday, 3 January 2011
Progress Bar Illusions
Progress Bar Illusions
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.
Sunday, 19 September 2010
What’s a QA team without a spec?
Elder Game: MMO game development » What’s a QA team without a spec?
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.
Saturday, 18 September 2010
The cardinal sin of community management
Lessons Learned: The cardinal sin of community management
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.
How the PK Mafia Ruins Business
How the PK Mafia Ruins Business « MMO Tidbits
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.
Selling MMOs
Selling MMOs « MMO Tidbits
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.
Thursday, 10 June 2010
Where can I fly for how much?
Neat little helper for travel planning:
http://www.kayak.com/explore/?airport=YYC#/DUB?a=any&d=any&fb=30,510&l=any&ll=53.435719,-6.328125&ns=n&s=0&t=0,100&z=3
Saturday, 21 November 2009
World Of Goo Sales
World Of Goo Sale Offers Fascinating Results | Rock, Paper, Shotgun
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.
Thursday, 8 October 2009
German National Gamers Survey 2009
GAMESINDUSTRY.COM | Graphs Germany
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:
Wednesday, 7 October 2009
Free chapters of Mike Cohn's book about agile planning and estimation
InformIT: The Purpose of Agile Planning > Chapter 1: The Purpose of Planning
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.
Friday, 2 October 2009
Developers should 'incentivise fans to market for you'
Developers should 'incentivise fans to market for you' | Game Development | News by Develop
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."
Monday, 28 September 2009
Microtransactions: will pay for power-ups and self-expression, but not for new content
Free to play gamers will pay for power-ups and self-expression, but not for new content | Games Brief
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.
Thursday, 3 September 2009
20% Discount code for GDC Austin 2009 at icopartners
ICO Partners » Blog Archive » GDC Austin 2009: get your 20% discount code here!
Head over to the icopartners blog to get it.
Tomb Raider: Underworld post mortem
Gamasutra - Features - Postmortem: Crystal Dynamics' Tomb Raider: Underworld
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."
Microtransactions and flash games
Gamasutra - Features - Generating Cash For Premium Flash
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."
Tuesday, 1 September 2009
Definition of impediments in SCRUM
Scrum Impediments
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."
Localisation of games
ICO Partners » Blog Archive » Localise and shine: it may be easier than you think
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.
Thursday, 27 August 2009
Case Study: Fully Distributed Scrum
Fully Distributed Scrum - Agile2009, Schoonheim & Sutherland, Xebia India TBD case | Xebia Blog
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"
Wednesday, 26 August 2009
Scrum FAQ
Scrum for Team System - Process Guidance
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."
SCRUM training: games and exercises
The Agile Playground | Agile 2009
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?
Help for Product Owners: Prioritizing the backlog
First Things First: Prioritizing Requirements
Karl Wiegers provides some advice on the topic of prioritizing the backlog and he throws in a spreadsheet for free as well:
Karl Wiegers provides some advice on the topic of prioritizing the backlog and he throws in a spreadsheet for free as well:
"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.
Estimations: storypoints vs hours
Refactor Your Mind » complexity
Another good posting of Tick Tonoli regarding the reoccuring topic of estimating by using abstract storypoints vs hours. I rarely managed to get the point across, maybe his explanation works better:
Another good posting of Tick Tonoli regarding the reoccuring topic of estimating by using abstract storypoints vs hours. I rarely managed to get the point across, maybe his explanation works better:
"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…"
Tuesday, 25 August 2009
Game developer locations
For those who are looking for a nice index of game development related companies which are located in the UK:
UK game developer locations
And here is global map of "all" game development studios:
http://www.gamedevmap.com
UK game developer locations
And here is global map of "all" game development studios:
http://www.gamedevmap.com
Monday, 24 August 2009
Affinity Estimation-when there are a lot of stories to be estimated
I came across Rick Tonoli`s Blog and found a couple of very interesting articles. Still working my way through his postings, i'll praise him later in a separate article after covering his and other opinions on the topic of "affinity estimation". I didnt apply it myself, but it does sound like a good approach to get a high level estimation done without wasting too much time.
He is refering to Kane Mar's blog who in return references to Jukka Lindström who posted his comment here. I would love to test it as it sounds very intuitive. A might be more suitable for a pretty senior team, but then again, what isn't...
Here is Kane Mar's comment on it:
"We started by reading out each Story to the entire team. Lowell then asked us to arrange the stories horizontally on a wall in order of size, without talking. We placed the largest stories on the left and the smallest stories on the right. This only took a few minutes. We were then given a final opportunity to make adjustments to the ordering, again without talking.
...
Finally, “Affinity Estimating” helps make estimating a positive experience rather than a confrontational one. The next time you have a need to estimate a large number of User Stories, consider trying “Affinity Estimating."
Sounds like it could also be an interesting tool for team(member)s that struggle to speak their mind or or have problems with confrontations. Ball-parking new projects should/could be simpler as well.
You can find a more detailed description about how it works here.
He is refering to Kane Mar's blog who in return references to Jukka Lindström who posted his comment here. I would love to test it as it sounds very intuitive. A might be more suitable for a pretty senior team, but then again, what isn't...
Here is Kane Mar's comment on it:
"We started by reading out each Story to the entire team. Lowell then asked us to arrange the stories horizontally on a wall in order of size, without talking. We placed the largest stories on the left and the smallest stories on the right. This only took a few minutes. We were then given a final opportunity to make adjustments to the ordering, again without talking.
...
Finally, “Affinity Estimating” helps make estimating a positive experience rather than a confrontational one. The next time you have a need to estimate a large number of User Stories, consider trying “Affinity Estimating."
Sounds like it could also be an interesting tool for team(member)s that struggle to speak their mind or or have problems with confrontations. Ball-parking new projects should/could be simpler as well.
You can find a more detailed description about how it works here.
Scalability: best practices
13 Scalability Best Practices | High Scalability
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.
Subscribe to:
Posts (Atom)