I thought I would kick this blog off with a discussion of getting projects going. Seeing how I've been working for a few months to get this new version of our site off the ground
Web sites aside though the issue of getting a serious game project off the ground is a major issue in the space. In fact, this last month I've been struggling to get a new project off the ground with a non-profit that my company hopes to announce soon. None of the problems with getting this project off the ground is really all that abnormal to what I've heard from other companies working in the non-entertainment gaming space.
I thought I would kick this blog off with a discussion of getting projects going. Seeing how I've been working for a few months to get this new version of our site off the ground
Web sites aside though the issue of getting a serious game project off the ground is a major issue in the space. In fact, this last month I've been struggling to get a new project off the ground with a non-profit that my company hopes to announce soon. None of the problems with getting this project off the ground is really all that abnormal to what I've heard from other companies working in the non-entertainment gaming space.
At our December 2003 D.C. Serious Games Day Doug Whatley from Breakaway highlighted the lead time for a serious game project being one of the key problems for the space.
So what exactly is this problem?
The length of time it takes a serious game project to happen is heavily caused by the fact that many organizations thinking about building a comptuer game simply have never done so before. This of course raises the risk factor to the point that many groups take a very slow pace. Meanwhile the developer is struggling to get projects online and is wary of any client who isn't surefooted enough. With traditional game publishers you at least have an entity that makes decisions quicker (on average) and you don't have to waste time going over basic game devleopment issues. That still doesn't mean you jump through hoops or other problems - it just means you get a bit more fluid process and quicker reaction.
But the story is also deeper then just inexperience by the clients. There are other issues that cause problems with ramp up schedules:
1. Funding
Many serious game projects have to fight for funding. Whereas a commercial game publisher is seeking to allocate funds to game projects the rest of the world is not automatically doing this. Often a serious game is struggling to get funds allocated vs. a host of other projects (not just games) and that means the bar may be set a bit higher. In other cases the entity that wishes to see the game built is not the same entity that will fund it. This means you've got to not only sell the original client, but their backers as well. The funding agent then must have faith not only in the client but in the developer as well. Sometimes the client has clout you wish you have, other times they're as unfamiliar to funding agents as you are.
2. End Results
Another issue is that serious games must have end results that are different from most games. This can create a host of other project development issues that bogs down the greenlight of a game project. For example, an educational game may have to comply with a variety of cirricumlum standards and have a proper advisory council. Time spent putting this together and vetting the design is one more roadblock to approval. Another example might be a project that the client may want to test before the product even gets built by holding a series of meetings throughout the organization to try and gauge the acceptance of the product.
3. Organization Resistence
When a game publisher brings a product to market the only resistence points they worry about are the buyers at major accounts (do they like the packaging, will they support it with promotions, etc.) and the end customer acceptance. Throw the press in their as well.
A serious game on the other hand often runs into a series of resistence points especially at a point in time where the acceptence of games as anything other then weekend entertainment for kids is still fairly prevelant. Resistence can take many forms including the ever popular technophobia people may have about a particular project. Sure, at times you will actually encounter quite the opposite. The right executive may actually be a fan of games, but the conventional wisdom hits in the other direction.
So what can we do?
Having identified some issues that cause serious game projects to have long and labor intensive ramp approval stages what then can we do about it?
The biggest thing we can do is education (no suprise there) and also validation efforts that loosen the general resistence and fear organizations have about embarking on expensive software projects that rely on skills they don't have in-house. Within that though we can do a better job of identifying specific problems and resistence points and methodically smooth those out. For example, a number of government agencies expressed concern about game compliance with accessibility standards. As a result the Serious Games Initiative working with the IGDA's Accessibilty SIG is trying to produce a whitepaper and set of resources that will help agencies and other organizations dealing with accessibility compliance work through that issue.
What potential developers can do is educate themselves by helping to highlight sticking points and sharing them. As we identify consistent issues we can work together to dissolve them. Developers also should seek to take as much charge of the early discussions of a project because managing the client through the process can help speed it vs. letting them casually let it stall. There is a fine line between pushiness and client management but smart bizdev folks figure this out. And finally developers can work with us to learn how to do a better job at project development. As both sides of the equation get better at walking through a potential project the ramp-up times will decrease and that alone will go a long way toward growing the market.
Now it's your turn. What sorts of sticking points do you commonly come across trying to get a serious game project off the ground? What ideas have worked for you to cut decision times down and improve the productivity of a client's decision process?
Posted by bsawyer at March 13, 2004 04:57 PMMy own personal experience has been that subversion of the system is a good way to overcome institutional/organizational resistance. Basically, if people just can't "get" what it is you want to do, you may just have to do it behind their backs, and then show it to them. Only then will they perhaps get it. I actually heard several stories at the GDC Serious Games Summit of people also using this tactic.
In my own case, I wanted to use game technology to model a large research facility being built at Oregon State University. The inital reaction was negative and of the "that's not of any use really" type. So I went ahead and created a "virtual walkthrough" of the facility using Valve's Half-Life game, and it ended up being VERY well received. People could see the value when they could literally see it in action. It was also easy for me to point at the screen and say, "Now with more work, we could add features such as A and B". The prototype gave the potential customers a learning environment where they could see the possibilities. It actually was sort of a "meta use" of game technology to sell the idea of game technology if you think about it.
From that initial proof of concept, a whole new project was spun off that's kept a professor and a few students involved and busy. If you go to http://nees.oregonstate.edu/presentations/NSF.tsunami.nugget.pdf you can see a small writeup on the spinoff project. At http://www.nacse.org/~moorchri/ you can find a download for the Java based "game".
Posted by: Tim Holt at March 25, 2004 09:50 PMAs one of those biz dev people and with experience both inside of a publisher and representing small developers its easy to understand what both sides of the fence look at:
Publishers want to
a) quantify what you are creating, so they can estimate the potential market. If you are creating something outside of the well defined markets you need to give them assistance in figuring out what you product is most like. (IE FPS with Strategy or Role Playing Elements/ Doom meets Warcraft)
b) define your risk in delivery.
Elements publishers look at is
1) how experienced are the individual members of the team?
2) has the team shipped something as a team before
3) what technology is the game being created on? If you are creating a new game engine that adds to the technical risk. If you are creating additions to an existing engine your risk is lower.
All in all, publishers are looking for good ROI or return on investments. With market consolidation and established platforms the bar for what a product needs to be to be commercial goes up. This makes publishers risk adverse as they are investing more dollars for less titles. Only the titles who ship over 500K units are profitable in most scenarios and only those who ship 1 Million + are considered successes.
If you aren't making games that will ship 1 Million units or more because of platform restrictions, or they are nitch products, you need to look at special distribution or partner with a smaller value publisher. This of course brings down your development budget and makes you creative about your asset creation.
Developers invariably want to:
a) work on things they are passionate about. ( as well they should, development is hard work and it sucks to work on things you hate)
b) Make sure they at least pay the bills and are covered for the development costs.
c) Work hard to create something that will bring them more business, extended royalties and generate a name.
Developers are more open to innovation and exploring markets. Publishers are risk adverse as they not only sink advances into products but COGS (cost of goods) marketing dollars and their sales teams time.
That's why when you innovate you have to be prepared to take a game much further along to find a publisher. Of course if you don't innovate somewhat, your product probably won't find much of an audience.
BTW: Publishers view dev teams who slip project goals to "try something new" poorly. Keeping your producer in the dark about what you are doing even if you are current on your project goals is a sure way to weaken trust. Outlining what you are doing, and how much resource it will take and the effort involved is the best way to assure your producer stays your champion.
Producers are frequently on board for innovation, but they have to mitigate risk or loose their jobs.
- Susan Manley
I run a development company in the UK that has developed 2 "serious" games and 34 none serious titles. I have been in the games business for some twenty years now and frankly I have never even attempted to sell a "serious" title into the tradition games publishing companies. They simply would not be interested in what Susan explains above as a niche market.
I have concentrated my efforts to government agencies.
In both my previous titles I have found that the games experience that my company has turns them on. They talk about the games with a great deal of excitement and are generally very interested at being a part of something that is in thier eyes very creative.
At Aqua we hold forums at regular intervals throughout the development. I have found that these are far more enjoyable affairs than those I have hosted for the gaming community, who I believe tend to be running at a different agenda. (May be they are worried about loosing thier jobs as Susan points out).
In the case of our last project, the English Taxi, developed for the British Council, we held a forum for 5 English Language Training professionals. Although there was the enevitable tour of the offices and pointing at computer screens over peoples shoulders we made it a productive experience by having the ELT specialists devise the scripts spoken by the virtual people and also the background scenarios that set the scene.
We genuinely had a great time. I think it came down to the fact that both sets of people could play to thier own skill set
We are just starting the process agaiin (literally in the last week). This project is for the Learning and Skills COuncil of Great Britain. I'll upodate you with the process if you are interested!
Posted by: Paul Ranson at April 7, 2004 05:34 PMHi
I just want to echo Tim Holt's comment that the fastest way to overcome organisational blockages is to just do it and wear the consequences.
I have a website that can be used to develop simple educational games.
In my experience attempts to close down the game site by local management are being offset by the growing number of website users.
As they come from a variety of well known and respected University and Learning organisations aroundthe world it makes local management a little more reluctant to 'pull the plug'.
It works for me.
regards
mike capstick