Follow Up: Practical Matters of Breaking Newsgames
This was my rough draft of a post that Ian turned into something much better on our blog at http://jag.lcc.gatech.edu/blog/ (see that post for a much better numbers crunch by Bogost including consideration of the Pareto Principal and problems of scale)
Commenter Elle suggested that the model of Global Game Jam shows that people working concertedly for 48 hours could achieve amazing results; also, she asserted that newsgame developers should not balk at pulling all-nighters to make a breaking newsgame because mainstream developers do the same during crunch-time before going gold.
Certainly the Game Jam is an incredible asset to the development community, so let’s look at how it can and can’t work as a model for newsgame development. First, the groups working together for GGJ (up to five, with an average of four) are typically larger than most studios producing newsgames. We’re talking 1-3 person teams on a lot of the existing artifacts. Second, although a good number of finished pieces that come out of this competition, there’s an extraordinary mass of games that just don’t work. After the two day race is over, they’re completely broken. Many of the working games are basically hacked or jerry-rigged together. Professional game designers need to create something that works when thousands of people are visiting their site daily to play the game.
Ian and I did some calculations on the economic of Game Jam. There were 1600 participants, cramming in roughly a 40-hour work week within two days. This equates to 64,000 manhours. If we average the cost of a game designer at 50,000 dollars a year, we get an hourly pay of around 25 dollars. Multiplying that by manhours, Game Jam would cost about 1.6 million dollars. Three hundred and sixty working games came out of the project. Assuming all of them are “worth playing,” this comes to a rough cost of $4,500 dollars per game. This happens to be an incredibly appealing and realistic cost for a newsgame (according to Ian); however, the cost becomes quite preventative if you start considering which of these are “worth playing” (50% would be a generous figure). Game Jam’s website doesn’t give us an accurate measure for this percentage, because around 300 of the 360 games post an average of 3/5 stars.
Another dissatisfied comment came from game designer Kriss Daniels. Daniels, because he finds most gamers so daft and most game mechanics so derivative, develops purposefully mind-numbing games as a form of protest and play with the industry. He derided my use of “tabloid games” as examples of quickly-made products following a news event (the Steve Irwin Stingray games are an example of this). He also didn’t like that I was only thinking about the narrative aspect of these games; that is to say, most tabloid games are poorly coded versions of side-scrolling or top-down shooters with crude cartoonish skins pulled from the news event. Even most well-received and -conceived newsgames are often derivative of tried-and-true core mechanics from arcade games. When the mechanics and the purported “purpose” or “message” of a newsgame do not allow meaningful player action, we have what Ian would call a “loose coupling” of mechanic and argument. Needless to say, this is a major obstacle for us to overcome.
In the last post, I attempted to find a way out of this predicament by hypothesizing an independent company that would license regular newsgames out to several traditional news sites. The idea is that this would allow enough coders to be working in the same place to be able to craft game mechanics for newsgames that wouldn’t be so copy-paste. Since this is only a hypothetical solution with no proof of concept, I’d like to develop another way out.
When coding a newsgame, what’s the hardest decision a developer needs to make? The answer to this question seems to be what information and player actions to include or exclude. In the words of Miguel Sicart, what one chooses to include or exclude determines the editorial line of a newsgame.
One highly detailed explanation of how time-consuming this decision-making process can be comes from pioneering geopolitical game creator Chris Crawford. The book he wrote about the design and construction of Balance of Power goes into detail about how he chose what data and player actions to include in the game. Working on a Mac Lisa, the biggest constraint for Crawford was RAM (128k at the time, not including the RAM taken up by the then-new GUI). Working as a freelancer after the collapse of Atari, time was a relatively liquid asset for Crawford. He had the time to program everything he wanted into the game, but he had to make cuts to account for the memory limitations. This iterative trimming and playtesting process appears to have lasted around 9 months for Balance of Power.
The situation is somewhat the opposite today for a newsgame developer: they have an almost unlimited amount of memory to work with (with a limiting factor being that it should not be too large in order to load up relatively quickly in Flash), but time is working against them if they want to release breaking newsgames. Despite this disparity in resources, I think Crawford’s modus operandi can still function as a basic model today.
The key for Crawford, once he had a bunch of data and mechanics that needed cutting, was to decide exactly which actions were necessary in order to convey an argument or a system to the player. Honing in on the idea that the Cold War superpowers were at the greatest risk of nuclear confrontation when drawn into a indirect conflict by their proxies, he settled on only allowing players to provide money, arms, or political pressure to a either a secondary nation’s government or its insurgency. This is an unarguably tight coupling between player action and Crawford’s argument. The goal for a breaking newsgame developer would be to prime her mind in order to be able to generate such a coupling quickly on hearing of a game-able news story.
Now, what does a working programmer have that the average participant in Game Jam does not? Besides, of course, the structure of a paying job and professional experience working specifically on newsgames. An answer to this question comes from an article by Chaim Gingold, one of our recent graduates and a lead developer on Will Wright’s Spore.
Gingold describes the plight of the game coder as this: you come up with a lot of ideas, you try to code them, and they don’t work. Most people take this process as a failure and throw everything away. Gingold suggests another way to use this process: save your code, extract the mechanics you developed, and use them later on other projects. For proof that this works even in a corporate atmosphere, Gingold tells the story of how he found a bunch of algorithms and simulations that would later be used in Spore on modified builds of prior Maxis games kept in storage at their studio. His argument is this: Wright makes games that are critically well-received and commercially successful because he constantly prototypes mechanics and never throws away any of his experiments.