Hot of the press!! The demographics of social gaming

Who are social gamers?

Futurelab are seeking a network of educators interested in the use of computer games in schools

Posted on behalf of Claire at Futurelab….

Futurelab has been appointed as the UK National Coordinator for a pan-European study of the use of computer and video games in schools. Our Games and Learning project is a programme of research, events and planned publications intended to stimulate discussion and the development of new intelligence.

The overall aim is to demonstrate what challenges and opportunities have emerged from debates and developments in this field to date, and to identify practical actions and interventions to be taken forwards. We are looking to set up a network of educators interested in the project who would like to receive more information about our research.

If anyone is interested or would like to become involved, they can email me at claire.denney@futurelab.org.uk.

Computer games kill children – official (UK government)

Change4life 'infomercial'

Has anyone else seen the ridiculous, sanctimonious adverts that the UK Government is putting out which link games to premature death?

See the article at MCV if not by clicking this link

The advert, which has appeared in woman\’s magazines shows a young boy sitting on a sofa and the words \”Risk and early death, just do nothing\”.

Of course we need to get our kids (and adults) more active, exercising and eating properly but it seems lost on this puritanical civil servants and their Daily Mail-reading marketing advisors, that if that kid was sitting reading a book, listening to music, doing his homework or watching TV he\’d be doing equally little exercise (or even less if he is playing on a Wii).

My blood doth boil over!!!!!!!!

E-Learning job opportunities in Ireland

I have been asked if I can help a talent search organisation to find suitable candidates for a range of new positions for a new R&D center established in Dublin. Examples of the roles are as follows:

• Technical Project Managers
• VP Interactive Design
• Content Engineering Manager
• Interactive Designer
• Business Analyst
• Director of Business Analysis
• Flash Engineer
  …and plenty more

The employer organisation is a very large, global leader in digital and print-based educational solutions.

In addition, the search agency are also searching for internet technology people with business experience for online gaming (as in gambling not learning) with experience in development, test, online payments, online marketing and other roles. These roles are also in Ireland.

If you want to put yourself forward please contact me  ( kevincorti [at] yahoo [dot] co [dot] uk ) and I shall provide your details to the search organisation for consideration.

Kevin

Work for Hire – is there a better way?

As we at PIXELearning approach our 7^th year of trading, and with a pretty good picture of the overall sector, I find it strange that there remains, still, a predominance of the ‘work for hire’ business model.

Work for hire might work for professional services where you can charge out, for example, your auditors for $200 an hour because, although some projects will be more challenging than others, a firm will pretty much know what a typical audit engagement will entail. Looking closer to home, a traditional eLearning company will most likely work from a total cost/learner hour or n (development hours)/hour of learning basis and, barring major errors of judgement, be pretty much accurate.

From my experience to date over six years working in this space and spanning 40+ projects ranging from between $5,000 and $500,000, the work for hire model is undesirable for serious games developers and for a multitude of reasons:

[1] Clients are not capable of creating a specification

I have yet to see a specification, RFI or RFP document that clearly articulates the full extent of the client’s requirements in a way that covers organisational goals, instructional objectives,  content/curricula definitions, learning evaluation strategies, business impact/ROI approach, creative brief, technical guidelines and ,, somewhat fundamentally, the game/simulation vision. Some of these will be adequately covered – usually where that aspect is related in some way to what the issuing organisation actually does as its business – but I have never seen a comprehensive document upon which one could base an accurate price.

This is a problem as invariably the developer is required to provide a fixed price based only on the initial RFP information. It takes a brave developer to stand their ground on this issue and even if they do they will very probably lose the contract.

Now I don’t expect that your average insurance, automotive, banking or retail multinational should be able to create a proper serious games specification. Why should they? It isn’t their area of expertise. What I am surprised about is that even now, in 2008, why only a tiny few organisations employ a consultant at the scoping and procurement stage to help them define their true requirements. I would stand up in a court of law and testify that if they did do this they would save money, time and stress and significantly de-risk the project.

So what we end up with is a client that has taken a leap of faith, internal sponsors who have put their reputations (or careers) at risk, the involvement of a wider group of reluctant stakeholders and a developer who now faces delivering upon a project with no defined start point, specification or defined set of deliverables. What they do have is a defined (fixed) project deadline and contract price.

This situation is akin to a builder agreeing to design and build an ‘office’ without knowing where it will be built, using what materials and whether it is to house 10 or 1,000 office workers. Now I probably paint an exaggerated picture here, but I’ll bet that it is an analogy that resonates well with many a developer.

[2] Clients are usually very large. Developers are always minnows

This may not be a situation which is unique to the serious games space but the chances are that, when measured by revenue, balance sheet or head count, most clients will be at least several dozen times bigger than the developer. Often it will be a developer with an annual turnover of less than $2million working for a global multinational firm with revenues in excess of $1 billion. Big does not mean bad but it does mean that on the one hand you have a young, innovative firm with strong technological and creative leanings with a flat management structure and a dynamic ‘can do’ attitude. On the other hand you have a large, slow-moving goliath packed with 9 to 5 ‘staffers’, a risk-averse culture, big company politics, rigid administrative procedures and little or no understanding of what it takes to deliver a successful serious games project.

This clash of cultures can often make for personality clashes and client-vendor communication breakdown if not acutely-well managed. It is also worth noting that if things turn really ugly that the client’s lawyers are bigger than the developers! Managing expectations at both a macro and micro level is crucial. It is also a frustrating diversion when efforts are needed elsewhere.

[3] Design (scoping) comes after agreeing a fixed-price

The developer has agreed a price. The initial scoping, needs assessment and design have been undertaken. Now, however, the client’s project team have had a chance to get up to speed and they want to get creative. They have been shown some prior examples and possibly some prototypes. They have dusted down the SNES and PS1 from the attic and got all excited about the idea of contributing ideas to the game project. They have a much better idea of what is possible and want to get their hands dirty. Everybody gets a buzz out of getting creative and picturing what could be…. but the developer is working on a fixed price and time is tick tick ticking.

The biggest danger here is project creep. The client won’t recognise this as chargeable changes as you are still in the design phase….so no comparison point exists from which to measure change and besides, they engaged with the developer in order to benefit from a creative company to help them flesh out the ideas. “What’s the rush?” they are thinking. Meanwhile, the developer is asking, “where has my margin gone?” and, “how are we going to deliver on time now?”

I have rarely seen a project where the design phase is completed on time. For small discreet mini or casual games-based projects this is less of a problem. For large serious games or immersive learning simulations it is rather more of a challenge.

[4] There are always changes to a signed off design…but rarely extra payment

I spent nearly seven years working in the construction industry for a mechanical and electrical building services engineering firm. We worked rigidly from very detailed specifications, technical designs and Bills of Quantities. If the client’s team (e.g. the architect or design engineer) made a change of any kind then there was a well-understood process of quantifying the time, cost and other implications. The client’s team then, assuming they accepted the costs, issued a formal change request and the contractor (my employer) billed them for the work.

For the serious games developer it is not so easy. Firstly the client nearly always struggles to envisage what the finished application will look like and how it will function until they see it and try it. When they get the early prototypes, alpha and beta releases it gives them the opportunity to ‘suggest’ numerous improvements on the basis that only at this point are they able to appreciate the implications of the written design document.  It is highly unlikely that the developer’s tender bid included an explicit cost for ‘client mind changes’. An iterative approach to software development can be an excellent way of getting a perfect end result from a technical standpoint but it does not make for an easily quantifiable development schedule or controlled costs. Seeing as time deadlines and budgets are the two factors about which they client will most likely fixate upon, it is easy to see how this approach can easily lead to project failure for the developer, the client or both.

Harping back to the ‘clients are large, developers are small’ point, it is very hard for the under-pressure developer to fight to be paid for each and every change irrespective of how legitimate the basis. Refusing to carry out the change will most likely be viewed by the client as deliberate intransigence or even belligerence on the part of the developer and probably a withheld milestone payment.

Most developers, engage don a work for hire model, will seek a gross margin of between 40% and 60% in order to achieve genuine net margins. A project that involves numerous and frequent changes can quite easily go from sound profitability to a loss-making situation for the developer.

It is also fair to say that the client’s project team will nearly always fail to realise the level of impact for what, to them, appear to be very minor changes. A recent client of ours, for example, repeatedly asked us to make changes to some of the in-game characters. These characters featured in many pre-rendered animations.  To the client these seemed to be a quick job for an artist of, I guess, an hour or so. The reality was several weeks of artist time and a cost to the company of a few thousand dollars.

[5] The source code issue

For a developer targeting the learning and development sector this can be a major challenge. Clients for traditional eLearning are used to getting and owning the source code and IP to the finished product. This is not unwarranted as invariably, with eLearning, the end product and the source code are one and the same being made up of HTML, images and static content. JavaScript code to create a drag and drop ‘course interaction’ is hardly likely to form part of a developer’s core intellectual property and enterprise value.

For a serious games developer however, this demand is nearly always untenable. It is rare that a project will not involve some level of prior IP in the form of application code or source assets. These assets are the lifeblood of a serious games developer. They reflect significant R&D, prior capital investment, commercial risk and specialist know-how. Handing that over to a client is akin to commercial suicide yet developers will very often face a major battle on this issue.

The ironic fact is that the source code is practically worthless to the client as they are very unlikely to possess the technical ability to do anything with it. Even a competent 3^rd party developer will face a massive challenge in making sense of the code and the originating developer is hardly likely to help them in that endeavour.

In reality, the client probably only demands the source code because it wants to protect it’s development in the eventuality of the developer going bust. That eventuality can easily be handled by a source code escrow agreement. Philosophically however, the ‘work for hire’ model puts the client in a frame of mind where they feel that obtaining the source code is a normal request.

[6] The ongoing ‘input’ of the well-meaning amateur

This is (usually) a minor threat – and not unique to the WFH model – but when that ‘well-meaning amateur’ is a key member of the client’s team then their desire to input into the technical, creative and instructional design process can easily create problems for the developer.

At best it is a distraction for the developer’s project manager. At worst it ends up causing project delays (which will be seen by outsiders as the developer’s fault) and eating into that profit margin.

[7] The 20:80 rule

This is a reverse of the commonly referenced Pareto’s Rule. Whereas traditional web content or eLearning development is fundamentally linear – meaning clients get to see progress early and consistently – serious games development is all back-ended. A significant proportion of the project timeline is eaten up by design and preparation. Underlying software engineering invariably takes time before it yields demonstrable releases. All of this makes clients nervous as they are being asked to approve milestone payments yet cannot yet play anything.

Serious games projects will almost (always?) be based on milestone payments. Not being able to show anything tangible (in the client’s eyes) makes getting paid in accordance to actual costs incurred, very challenging.

[8] Its hard to create and leverage IP

For a developer to make the transition from a WFH services provider to being an IP holder in it’s own right, significant capital will be required. It is challenging to raise that capital on commercially acceptable terms in good times. The collapse of the private equity markets and the extreme cautiousness of commercial banks (especially towards small companies and start ups) in recent times makes it practically impossible.

It is not in a client’s interest to help the developer achieve this by way of a WFH contract as it complicates the contracting process (the legals get far more complex) and besides if the developers starts to own it’s core IP it can potentially lock the client in (never appealing to the client) and possibly even take the same IP to competitors of the client.

The flip side is that a healthy and sustainable serious games industry would give clients major benefits e.g. stability, innovation and cost reduction through reusability but those are benefits that come from long term thinking and clients, understandably, are driven by the requirements of current projects not possible future ones.

[9] N.D.A. hell

“Seeing is believing,” or so the saying goes. Serious games are a medium that is hard to convey the value of…until you see them and try them. Sales people need to be able to show stuff off in order to generate new leads and close new deals.

Clients do not like that for the understandable reasons that their project is most probably linked to a desired increase in competitive advantage in one way or another. Naturally they do not want their competitors to hear about this.

When it is the client that is funding the project through a WFH model then the developer is always locked into a frustrating Catch 22 situation where their future growth and sustainability depends on sales but it is hard to generate new sales when you cannot demonstrate (or even talk about) your prior experience and project successes.

[10] A fixed gross margin…that shrinks

‘Work for hire’ is very probably going to be on a fixed price basis. The developer will target a gross profit margin that they seek to achieve. Depending on a number of factors (use of prior IP, eagerness of the developer to win the project, direct and overhead cost basis etc) this is likely to be in the 40-60% range.

Whether this works operationally depends a lot on the capital base of the developer (do they have private equity investment and an aggressive growth strategy for example?) their approach to operational resourcing (a fixed-cost internal team or a burstable model based on variable cost contractors and freelancers?) and their underlying overhead cost base. It also depends upon scale. The overhead cost base should be fairly static. The developer will need to achieve a critical volume of profitable projects in order for the gross margin to flow through to cover (and hopefully exceed) the overhead costs.

Delays to projects starting, design creep, post-design feature creep and other factors will occur and will therefore eat into this gross margin. The danger is that this makes it very hard to cover the overhead base at times and the finance director and company owners will find this very uncomfortable.

[11] Projects fall into fiscal quarters

Big companies think in quarters. Invariably the required project timeline will be either three months or, if the developer is lucky, six months. We often think in terms of the 40:40:20 rule. That is 40% of the project time for design, 40% for core development and 20% for final QA and integration. Given the peculiar hybrid of skills, experience and content that goes into a serious game project and thus, the wide number of people involved in it on the client side (who all have day jobs) it is very hard to create and agree a robust design in anything less than two months.

Starting development for a three month project in month three is project suicide. Starting development on a large project without a robust, signed-off design is also project suicide. Inevitably this leads to a project delay of anything up to 50%. Whilst internal client stakeholders will feel the heat from their superiors, it is hard for the developer to overcome the perception that they are the cause of a ‘slippage’.

Invariably what this pressure leads to is an iteratively created design and for a substantial proportion of the design and development activities being run in parallel. The likelihood of achieving this without frequent design and/or development changes, delays to the process (whilst the developer awaits client sign off, content or clarification on a design aspect) are going to occur no matter how much effort the developer puts micro managing the project.

So, clearly I am not a strong advocate of a work for hire business model for the serious games space. The question is what are the alternatives and is it even possible for the development community to adopt these?

Answers on a stamped, addressed postcard please!