<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Preserving Games &#187; creation process</title>
	<atom:link href="http://www.ibiblio.org/winget/tag/creation-process/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.ibiblio.org/winget</link>
	<description>Archiving the Creation Processes of the Video Game Industry</description>
	<lastBuildDate>Mon, 27 Sep 2010 17:06:17 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Book Review: Racing the Beam</title>
		<link>http://www.ibiblio.org/winget/2010/02/book-review-racing-the-beam/</link>
		<comments>http://www.ibiblio.org/winget/2010/02/book-review-racing-the-beam/#comments</comments>
		<pubDate>Fri, 12 Feb 2010 17:01:19 +0000</pubDate>
		<dc:creator>walker</dc:creator>
				<category><![CDATA[Literature Review]]></category>
		<category><![CDATA[consoleGames]]></category>
		<category><![CDATA[creation process]]></category>
		<category><![CDATA[creative limitation]]></category>
		<category><![CDATA[creative limitations]]></category>
		<category><![CDATA[history]]></category>
		<category><![CDATA[videogame]]></category>

		<guid isPermaLink="false">http://www.ibiblio.org/winget/?p=306</guid>
		<description><![CDATA[Montfort, N., &#38; Bogost, I. (2009). Racing the Beam: The Atari Video Computer System. Platform Studies. Cambridge, Massachusetts: MIT Press.
Just want to give a brief rundown on a really great read I&#8217;ve come across. MIT has started a &#8220;Platform Studies&#8221; series of books where the idea is to examine a platform and its technologies to [...]]]></description>
			<content:encoded><![CDATA[<p><strong>Montfort, N., &amp; Bogost, I. (2009). Racing the Beam: The Atari Video Computer System. Platform Studies. Cambridge, Massachusetts: MIT Press.</strong><br />
<div class="wp-caption alignright" style="width: 250px"><img alt="Racing the Beam: The Atari Video Computer System" src="http://www.ischool.utexas.edu/~walker/racingTheBeam.jpg" width="240" height="360" /><p class="wp-caption-text">Racing the Beam: The Atari Video Computer System</p></div><br />
Just want to give a brief rundown on a really great read I&#8217;ve come across. MIT has started a &#8220;Platform Studies&#8221; series of books where the idea is to examine a platform and its technologies to understand how this informs creative work done on the platform. Platforms could range from gaming consoles, to a programming language, to an operating system, or even the Web itself if this is the platform upon which creative work is being made. The platform in this case is the Atari Video Computer System, the first Atari home system, later referred to as the Atari 2600 in the wake of the newer Atari 5200.</p>
<p>The authors examine the Atari VCS as a computing system, and take care to elaborate the unique (really exceptionally odd) constraints found there. Six games are investigated in chronological order, giving the reader a sense of the programming community&#8217;s advancing skill and knowledge of the system: <em>Combat</em> (1977), <em>Adventure</em> (1980), <em>Yar&#8217;s Revenge</em> (1981), <em>Pac-Man</em> (1982), <em>Pitfall!</em> (1982), and <em>Star Wars: The Empire Strikes Back</em> (1982).</p>
<p>The most prominent technical details are explained in first few chapters, and they illuminate each game&#8217;s construction as an exceptional act of engineering and ingenuity. Just to give an idea of the unique affordances of the Atari VCS, here are a few of the most characteristic details:</p>
<ul>
<li>The custom sound and graphics chip, the Television Interface Adapter (TIA), is specifically designed to work with a TV&#8217;s CRT ray. The ray itself sprays the electrons onto the inside of a TV screen, left to right, one horizontal scan line at a time, taking a brief break at the end of each line (a &#8220;horizontal blank&#8221;) and a longer break at the bottom line, before resetting to the top and starting over again (a &#8220;vertical blank&#8221;). A programmer only has those tiny breaks to send any instructions to the TIA, and really only the vertical break provided enough time to send any game logic to the system.</li>
<li>It was imperative that game logic be sent at these breaks because the Atari VCS had no room for a video buffer. This meant there was no way to store an image of the next frame of the game, all graphic instructions are written in real time (sound instructions had to be dropped in on one of the breaks). A designer or programmer could choose to restrict the visual field of the game in exchange for more time to send game logic instructions. <em>Pitfall!</em> is an example of this.</li>
<li>This means there are no pixels on the Atari VCS. Pixels require horizontal and vertical planes, but for the Atari VCS, there is only horizontal scan lines. There is no logical vertical division at all for the computational system. As the beam goes across the screen, a programmer can send a signal to one of the TIA&#8217;s register to change the color. Thus, the &#8220;pixels&#8221; are really a measure of time (the clock counts of the processor) and not space.</li>
<li>Sprites, such as they existed for the Atari VCS, were hard-coded into the ROM of the system. Programmers had five: two player sprites, two missiles, and one ball. Reworking that setup (clearly designed for <em>Pong</em> and the like) into something like <em>Adventure</em>, <em>Pitfall!</em>, or even the <em>Pac-Man</em> port is an amazing feet.</li>
</ul>
<p>The book doesn&#8217;t refrain from the technical. I could have used even more elaboration than what is presented in the book, but after a certain point the book would turn into an academic or technical tome, so I appreciate the fine line walked here. The authors succeed at illuminating technical constraints enough for the general reader to understand the quality of the engineering solutions being described. Moreover, the authors leave room to discuss the cultural significance of the platform, and to reflect on how the mechanics and aesthetics of these Atari titles have informed genres and gameplay presently.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.ibiblio.org/winget/2010/02/book-review-racing-the-beam/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Making the Water Move: Techno-Historic Limits in the Game Aesthetics of Myst and Doom</title>
		<link>http://www.ibiblio.org/winget/2010/01/making-the-water-move-techno-historic-limits-in-the-game-aesthetics-of-myst-and-doom/</link>
		<comments>http://www.ibiblio.org/winget/2010/01/making-the-water-move-techno-historic-limits-in-the-game-aesthetics-of-myst-and-doom/#comments</comments>
		<pubDate>Sun, 24 Jan 2010 19:22:37 +0000</pubDate>
		<dc:creator>walker</dc:creator>
				<category><![CDATA[Literature Review]]></category>
		<category><![CDATA[creation process]]></category>
		<category><![CDATA[creative limitation]]></category>
		<category><![CDATA[creative limitations]]></category>
		<category><![CDATA[storytelling]]></category>

		<guid isPermaLink="false">http://www.ibiblio.org/winget/?p=276</guid>
		<description><![CDATA[Hutchison, A. (2008). Making the Water Move: Techno-Historic Limits in the Game Aesthetics of Myst and Doom. Game Studies, 8(1). Retrieved from http://gamestudies.org/0801/articles/hutch
&#160;
This 2008 Games Studies article examines the effect technology (or the &#8220;techno-historic&#8221; context of a game work) has on game aesthetics. The author defines the &#8220;game aesthetics&#8221; as &#8220;the combination of the audio-visual rendering [...]]]></description>
			<content:encoded><![CDATA[<p style="margin: 0"><strong>Hutchison, A. (2008). Making the Water Move: Techno-Historic Limits in the Game Aesthetics of Myst and Doom. </strong><span style="font-style: italic"><strong>Game Studies</strong></span><strong>, </strong><span style="font-style: italic"><strong>8</strong></span><strong>(1). Retrieved from </strong><a href="http://gamestudies.org/0801/articles/hutch"><strong>http://gamestudies.org/0801/articles/hutch</strong></a></p>
<p>&nbsp;</p>
<p>This 2008 <em>Games Studies </em>article examines the effect technology (or the &#8220;techno-historic&#8221; context of a game work) has on game aesthetics. The author defines the &#8220;game aesthetics&#8221; as &#8220;the combination of the audio-visual rendering aspects <em>and </em>gameplay and narrative/fictional aspects of a game experience.&#8221; It is important to note that audio-visual aspects are included in this definition along with the narrative/fictional components. This is because the author later argues that advancing audio-visual technology will play an important role in advancing the narrative aspect of games.</p>
<p>The article begins with a comparison of two iconic computer games of the mid 1990s: <em>Myst</em> and <em>Doom</em>. Specifically the design response in each game to the technological limitations of PCs at the time is examined. Very briefly, we see that <em>Myst</em> takes the &#8220;slow and high road&#8221; to rendering and first-person immersion, while <em>Doom </em>adopts the &#8220;fast and low road.&#8221; As the author explains, each response was prompted by the limitations of rendering that a personal computer could perform at the time. For its part, <em>Myst&#8217;s</em> design chooses to simply skip actual present-time 3D rendering and use only pre-rendered, impeccably crafted (at the time) images to move the player through the world. Minor exceptions exist when Quicktime video is cleverly overlaid onto these images to animate a butterfly, bug, moving wheel, etc. This overall effect very much informs the game&#8217;s aesthetic, as anyone who played the original can recall. <em>Myst</em> is a quiet, still, contemplative and mysterious world. Continuous and looping sound is crucial to the identity of the world and the player&#8217;s immersion. Nearly every visual element is important and serves a purpose. The designers could not afford to draw scenes extraneous to the gameplay. The player&#8217;s observation of the scenes available is key, and the player can generally be assured that all elements in the <em>Myst </em>world warrant some kind of attention. Hardware limitations of the time, such as the slow read time of most CD-ROM drives, serve to reinforce this slow, methodical gameplay and visual aesthetic.</p>
<p><em>Doom </em>by contrast uses realtime rendering at the expense of visual nuance and detail. <em>Doom </em>achieves immersion through visceral and immediate responsiveness, and its aesthetic is one of quick action and relentlessly urgency. The low resolution of the art and characters is compensated by the quick passing of those textures and objects, and by the near-constant survival crisis at hand. Redundancy of visual elements and spaces is not an issue: the player can face down hordes of identical opponents in similar spaces (sometimes the exact same space) and not mind at all because the dynamism of the gameplay is engaging enough to allow such repetition. Pac-Man had the same strength.</p>
<p>From this comparison the author goes on to speculate how techno-historic limitations inform aesthetics in general, and whether the increasing capacity of personal computers to render audio-visual components in extreme and realtime detail will inform the narrative/fictional aspects of games as well. One only needs a passing familiarity with games to know that this aspect of games has been widely disparaged in the media and in some academic writing. Some quotes the author uses to characterize the degenerative trend of popular media and the game industry&#8217;s complicity in the coming intellectual apocalypse:</p>
<p style="padding-left: 30px">Perhaps  lending strength to this phenomenon is a current popular culture  stylistic trend which emphasises “spectacle” over narrative and  gameplay. Peter  Lunenfeld has identified this broad movement in popular  culture generally:</p>
<p style="padding-left: 60px"><em>Our culture has evacuated narrative from large swaths of mass media.   Pornography, video games, and the dominant effects-driven, high concept  Hollywood spectaculars are all essentially narrative-free: a succession  of money  shots, twitch reflex action, and visceral thrills strung  together in time  without ever being unified by classic story structure  (Lunenfeld, 2000, p.141).</em></p>
<p>And more specifically dealing with games:</p>
<p style="padding-left: 30px">“It is a  paradox that, despite the lavish and quite expensive graphics of  these  productions, the player’s creative options are still as primitive as   they were in 1976” (Aarseth, 1997, p.103).</p>
<p>Most interesting is the observation that richer media capabilities does not necessarily translate to glossier, superficial renderings. Richer media can mean a more meaningful experience for the player. Nuance and subtlety can be introduced, more information-rich media can mean more powerfully conveyed characters and a more fully realized narrative.</p>
<p>On top of this, one can expand the definition of &#8220;story&#8221; and &#8220;narrative&#8221; as id developer Tom Willits argues in this <a title="AGDC: Storytelling at id Software: The Experience Matters" href="http://www.gamasutra.com/php-bin/news_index.php?story=20290">Gamasutra report</a>:</p>
<p style="padding-left: 30px">&#8220;If you wrote about your feelings, about your excitement, the excitement you felt when new areas were uncovered [in <em>Doom</em>] &#8212; if you wrote it well, it would be a great story,&#8221; Willits says. &#8220;People call it a &#8216;bad story,&#8217; because the paper story is only one part of the game narrative &#8212; and people focus on the paper story too much when they talk about the story of a game.&#8221;</p>
<p style="padding-left: 30px">Information, he maintains, is learned through experiences, and the experience of playing a game is what forms a narrative, by its nature. Delivering a story through the game experience is the &#8220;cornerstone&#8221; of id Software&#8217;s game design, and the key when developing new technology.</p>
<p>Whatever your opinion on what constitutes story and narrative in media, the author of this piece has made a compelling argument that advancing technical capabilities could directly inform the narrative/fictional aspect of a game&#8217;s aesthetics, and certainly has done so in the past.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.ibiblio.org/winget/2010/01/making-the-water-move-techno-historic-limits-in-the-game-aesthetics-of-myst-and-doom/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Hardware gimmick or cultural innovation?</title>
		<link>http://www.ibiblio.org/winget/2009/10/hardware-gimmick-or-cultural-innovation/</link>
		<comments>http://www.ibiblio.org/winget/2009/10/hardware-gimmick-or-cultural-innovation/#comments</comments>
		<pubDate>Fri, 23 Oct 2009 02:40:54 +0000</pubDate>
		<dc:creator>walker</dc:creator>
				<category><![CDATA[Literature Review]]></category>
		<category><![CDATA[creation process]]></category>
		<category><![CDATA[creative limitations]]></category>
		<category><![CDATA[history]]></category>

		<guid isPermaLink="false">http://www.ibiblio.org/winget/?p=234</guid>
		<description><![CDATA[Y. Aoyama and H. Izushi, “Hardware gimmick or cultural innovation? Technological, cultural, and social foundations of the Japanese video game industry,” Research Policy 32, no. 3 (2003): 423–444. 

This 2002 article (written 2001) looks at the success of the Japanese video game industry and attempts to illuminate the unique factors behind its success. Japan&#8217;s video [...]]]></description>
			<content:encoded><![CDATA[<p><strong>Y. Aoyama and H. Izushi, “Hardware gimmick or cultural innovation? Technological, cultural, and social foundations of the Japanese video game industry,” <span style="font-style: italic">Research Policy</span> 32, no. 3 (2003): 423–444. </strong><span class="Z3988" title="url_ver=Z39.88-2004&amp;ctx_ver=Z39.88-2004&amp;rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&amp;rft.genre=article&amp;rft.atitle=Hardware%20gimmick%20or%20cultural%20innovation%3F%20Technological%2C%20cultural%2C%20and%20social%20foundations%20of%20the%20Japanese%20video%20game%20industry&amp;rft.jtitle=Research%20Policy&amp;rft.volume=32&amp;rft.issue=3&amp;rft.aufirst=Y.&amp;rft.aulast=Aoyama&amp;rft.au=Y.%20Aoyama&amp;rft.au=H.%20Izushi&amp;rft.date=2003&amp;rft.pages=423%E2%80%93444"><br />
</span></p>
<p>This 2002 article (written 2001) looks at the success of the Japanese video game industry and attempts to illuminate the unique factors behind its success. Japan&#8217;s video game industry is especially remarkable given the dominance of &#8220;English language-based exportable cultural products&#8221; and the origin of the video game industry, which began in the US with Steve Russell&#8217;s programming of <em>Space War</em> for the PDP-10 and Nolan Bushnell&#8217;s subsequent creation of Atari to market and sell such arcade games.</p>
<div class="wp-caption alignright" style="width: 204px"><img src="http://www.ischool.utexas.edu/~walker/mega-man.png" alt="Mega Man, hero of the early NES platformers. The design has characteristics of the &lt;i&gt;manga&lt;/i&gt; style. " width="194" height="207" /><p class="wp-caption-text">Mega Man, hero of the early NES platformers. His design has characteristics of the manga style. </p></div>
<p>The authors give a history of the industry and observe Nintendo&#8217;s very early interest and involvement with electronic toy games. This began as early as the 1960s with the emerging popularity of shooting games with optical sensors. Nintendo was able to recruit technical expertise from consumer electronics and provided them with early successes like <a title="wikipedia article" href="http://en.wikipedia.org/wiki/Game_&amp;_Watch">Game and Watch</a> and<a title="wikipedia link" href="http://en.wikipedia.org/wiki/Color_TV_Game"> Color TV Game</a> (totally cool old ad at <a title="Color TV Game ad" href="http://gameads.gamepressure.com/tv_game_commercial.asp?ID=8140">gamepressure</a>). But Nintendo&#8217;s historic rise in the console market with both the Famicon and NES was due in no small part to its attention to quality software; the company made sure to foster in-studio works (<em>Donkey Kong</em>, <em>Super Mario Brothers</em>) and hold alliances with outside game developers.</p>
<p>After the mid 90s Nintendo falters by retaining cartridges for their games rather than the CD-ROM; this among other factors allows Sony to rise in the market. The authors continue the brief history up to the approximate time of the article, but one main point  can be drawn from the narrative: hardware and software are intricately linked and related; success frequently hinges on a deep synchronicity between the two engineering pursuits. The authors go on to elaborate this point, emphasizing Nintendo&#8217;s early collaboration with domestic electronic consumer goods firms.</p>
<p>The article describes three types of software publishers:</p>
<ul>
<li>in-house publishers of platform developers (e.g. Nintendo)</li>
<li>comprehensive software publishers with in-house capability for most development (e.g. Square)</li>
<li>publishers that act as producer/coordinator and outsource most functions (e.g. Enix)</li>
</ul>
<p><span id="more-234"></span></p>
<p>The types are distinguished by varying levels of intimacy with the platform developers. Platform developers can provide all sorts of guidance and information to game-makers: early prototypes of the platform, guidance on formats, and provisioning of development tools and platform operating systems. It&#8217;s clear then that hardware naturally informs software and that game development projects can benefit immensely from an intimate knowledge of the hardware.</p>
<p>The authors next examine the cultural landscape of Japan and how this informed its massively successful video game industry. A robust cartoons and animation industry (<em>manga</em>) with broad acceptance allowed the game industry to draw artistic creativity from a domestic source. The authors note that it is Japan that introduced human and animal characters into video games, a dramatic break from the war (<em>Space War</em>) and ball (<em>Pong</em>) games in the US, and that it was a Shigern Miyamoto, influenced by the landmark cartoonist Osamu Tezuka (the &#8220;god of <em>manga</em>&#8220;), who was inspired to create characters like a rampant pet gorilla (Donkey Kong), a blue-collar construction worker (Mario), and a captured girlfriend (Princess Toadstool). The cultural legitimacy and artistic breadth of cartoons in Japan facilitated effective cultural crossover into the video game industry. This is compared to the comics and cartoons industries of the US, which could not claim such pervasive influence.</p>
<p>The authors conclude:</p>
<blockquote><p>The developmental trajectory of the video games industry revealed a complex interplay between hardware and software technologies from its origin, and more recent trends represent a transition from hardware, engineering-driven to increasingly software-centered industry supported by artistic creativity drawn from cartoon and animation film industries.</p></blockquote>
<p>I think this trajectory is accurate, but it&#8217;s important to note that the power balance between hardware and software is always subject to change. The iPhone has emerged as an extremely capable, popular and even innovative gaming platform, and Apple has chosen to retain full control over the game software available for it.</p>
<p>Regardless however of the power dynamic between the two disciplines, they are always and inextricably related. Any game should be understood with an understanding of the hardware it was developed for and on. Narrowing the scope from industry to a single game, I think it would be interesting to understand more about how specific projects were informed by the hardware constraints of the time.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.ibiblio.org/winget/2009/10/hardware-gimmick-or-cultural-innovation/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>What Went Wrong? A Survey of Problems in Game Development</title>
		<link>http://www.ibiblio.org/winget/2009/10/what-went-wrong-a-survey-of-problems-in-game-development/</link>
		<comments>http://www.ibiblio.org/winget/2009/10/what-went-wrong-a-survey-of-problems-in-game-development/#comments</comments>
		<pubDate>Tue, 20 Oct 2009 01:48:35 +0000</pubDate>
		<dc:creator>walker</dc:creator>
				<category><![CDATA[Literature Review]]></category>
		<category><![CDATA[complexity]]></category>
		<category><![CDATA[creation process]]></category>
		<category><![CDATA[creative limitations]]></category>
		<category><![CDATA[difficulty]]></category>
		<category><![CDATA[industry]]></category>
		<category><![CDATA[videogame]]></category>

		<guid isPermaLink="false">http://www.ibiblio.org/winget/?p=204</guid>
		<description><![CDATA[Fábio Petrillo et al., “What went wrong? A survey of problems in game development,” Computers in Entertainment 7, no. 1 (2, 2009): 1-22.  
 
This February 2009 article from the Computer in Entertainment magazine of ACM takes a look at the game industry and compares its difficulties to the larger software industry. Specifically the [...]]]></description>
			<content:encoded><![CDATA[<p><strong>Fábio Petrillo et al., “What went wrong? A survey of problems in game development,” <span style="font-style: italic">Computers in Entertainment</span> 7, no. 1 (2, 2009): 1-22.</strong> <span class="Z3988" title="url_ver=Z39.88-2004&amp;ctx_ver=Z39.88-2004&amp;rft_id=info%3Adoi/10.1145/1486508.1486521&amp;rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&amp;rft.genre=article&amp;rft.atitle=What%20went%20wrong%3F%20A%20survey%20of%20problems%20in%20game%20development&amp;rft.jtitle=Computers%20in%20Entertainment&amp;rft.stitle=%3Cabbrev_title%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.0%22%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.1%22%20xmlns%3Axsi%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instance%22%3EComput.%20Entertain.%3C%2Fabbrev_title%3E%0A%3Cabbrev_title%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.0%22%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.1%22%20xmlns%3Axsi%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instance%22%3ECIE%3C%2Fabbrev_title%3E&amp;rft.volume=7&amp;rft.issue=1&amp;rft.aufirst=F%C3%A1bio&amp;rft.aulast=Petrillo&amp;rft.au=F%C3%A1bio%20Petrillo&amp;rft.au=Marcelo%20Pimenta&amp;rft.au=Francisco%20Trindade&amp;rft.au=Carlos%20Dietrich&amp;rft.date=2009&amp;rft.pages=22&amp;rft.issn=15443574"> </span></p>
<p><span class="Z3988" title="url_ver=Z39.88-2004&amp;ctx_ver=Z39.88-2004&amp;rft_id=info%3Adoi/10.1145/1486508.1486521&amp;rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&amp;rft.genre=article&amp;rft.atitle=What%20went%20wrong%3F%20A%20survey%20of%20problems%20in%20game%20development&amp;rft.jtitle=Computers%20in%20Entertainment&amp;rft.stitle=%3Cabbrev_title%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.0%22%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.1%22%20xmlns%3Axsi%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instance%22%3EComput.%20Entertain.%3C%2Fabbrev_title%3E%0A%3Cabbrev_title%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.0%22%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.1%22%20xmlns%3Axsi%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instance%22%3ECIE%3C%2Fabbrev_title%3E&amp;rft.volume=7&amp;rft.issue=1&amp;rft.aufirst=F%C3%A1bio&amp;rft.aulast=Petrillo&amp;rft.au=F%C3%A1bio%20Petrillo&amp;rft.au=Marcelo%20Pimenta&amp;rft.au=Francisco%20Trindade&amp;rft.au=Carlos%20Dietrich&amp;rft.date=2009&amp;rft.pages=1&amp;rft.issn=15443574"> </span></p>
<p><span class="Z3988" title="url_ver=Z39.88-2004&amp;ctx_ver=Z39.88-2004&amp;rft_id=info%3Adoi/10.1145/1486508.1486521&amp;rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&amp;rft.genre=article&amp;rft.atitle=What%20went%20wrong%3F%20A%20survey%20of%20problems%20in%20game%20development&amp;rft.jtitle=Computers%20in%20Entertainment&amp;rft.stitle=%3Cabbrev_title%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.0%22%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.1%22%20xmlns%3Axsi%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instance%22%3EComput.%20Entertain.%3C%2Fabbrev_title%3E%0A%3Cabbrev_title%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.0%22%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.1%22%20xmlns%3Axsi%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instance%22%3ECIE%3C%2Fabbrev_title%3E&amp;rft.volume=7&amp;rft.issue=1&amp;rft.aufirst=F%C3%A1bio&amp;rft.aulast=Petrillo&amp;rft.au=F%C3%A1bio%20Petrillo&amp;rft.au=Marcelo%20Pimenta&amp;rft.au=Francisco%20Trindade&amp;rft.au=Carlos%20Dietrich&amp;rft.date=2009&amp;rft.pages=1&amp;rft.issn=15443574">This February 2009 article from the <em>Computer in Entertainment </em>magazine of ACM takes a look at the game industry and compares its difficulties to the larger software industry. Specifically the authors analyze twenty <em>postmortems </em>from the archives of <a title="Gamasutra" href="http://www.gamasutra.com">Gamasutra.com</a> to characterize the problems that plague game development. I believe Gamasutra has discontinued this series but postmortems are still published by </span>sister publication <a title="Game Developer magazine" href="http://www.gdmag.com/"><em>Game Developer</em></a>.</p>
<p><span class="Z3988" title="url_ver=Z39.88-2004&amp;ctx_ver=Z39.88-2004&amp;rft_id=info%3Adoi/10.1145/1486508.1486521&amp;rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&amp;rft.genre=article&amp;rft.atitle=What%20went%20wrong%3F%20A%20survey%20of%20problems%20in%20game%20development&amp;rft.jtitle=Computers%20in%20Entertainment&amp;rft.stitle=%3Cabbrev_title%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.0%22%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.1%22%20xmlns%3Axsi%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instance%22%3EComput.%20Entertain.%3C%2Fabbrev_title%3E%0A%3Cabbrev_title%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.0%22%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.1%22%20xmlns%3Axsi%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instance%22%3ECIE%3C%2Fabbrev_title%3E&amp;rft.volume=7&amp;rft.issue=1&amp;rft.aufirst=F%C3%A1bio&amp;rft.aulast=Petrillo&amp;rft.au=F%C3%A1bio%20Petrillo&amp;rft.au=Marcelo%20Pimenta&amp;rft.au=Francisco%20Trindade&amp;rft.au=Carlos%20Dietrich&amp;rft.date=2009&amp;rft.pages=1&amp;rft.issn=15443574">A postmortem &#8220;</span>designates a document that summarizes the project development experience, with a strong emphasis on the positive and negative aspects of the development cycle.&#8221; After reviewing the literature discussing problems present in the software industry, the authors begin to analyze the problems described in the postmortems. The games covered and the problems identified and quantified are in a table that describes the number of occurrences and overall frequency (click for larger image). <em>Note:</em> sometime in the future (the Web 2.0 future?) I would provide a link to the actual dataset rather than a .PNG  showing you a picture of the dataset.</p>
<div class="wp-caption aligncenter" style="width: 540px"><a href="http://www.ischool.utexas.edu/~walker/wentWrongTable.png"><img class="      " src="http://www.ischool.utexas.edu/~walker/wentWrongTable.png" alt="=Occurrence of Problems in the Projects" width="530" height="276" /></a><p class="wp-caption-text">Occurrence of Problems in the Projects</p></div>
<p><span title="url_ver=Z39.88-2004&amp;ctx_ver=Z39.88-2004&amp;rft_id=info%3Adoi/10.1145/1486508.1486521&amp;rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&amp;rft.genre=article&amp;rft.atitle=What%20went%20wrong%3F%20A%20survey%20of%20problems%20in%20game%20development&amp;rft.jtitle=Computers%20in%20Entertainment&amp;rft.stitle=%3Cabbrev_title%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.0%22%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.1%22%20xmlns%3Axsi%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instance%22%3EComput.%20Entertain.%3C%2Fabbrev_title%3E%0A%3Cabbrev_title%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.0%22%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.1%22%20xmlns%3Axsi%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instance%22%3ECIE%3C%2Fabbrev_title%3E&amp;rft.volume=7&amp;rft.issue=1&amp;rft.aufirst=F%C3%A1bio&amp;rft.aulast=Petrillo&amp;rft.au=F%C3%A1bio%20Petrillo&amp;rft.au=Marcelo%20Pimenta&amp;rft.au=Francisco%20Trindade&amp;rft.au=Carlos%20Dietrich&amp;rft.date=2009&amp;rft.pages=1&amp;rft.issn=15443574">The authors&#8217; categories provide a helpful navigation to the issues that arise in a game development project. As they note, this study sees the most cited problems as <em>unreal or ambitious scope</em> and <em>features creep</em>, both constituting 75% of all problems described. Notable for game archivists is a 40% frequency for the <em>lack of documentation</em> problem as well. The authors note low occurrences for <em>crunch time </em>and <em>over budget</em> (25%), both &#8220;said to be &#8216;universal.&#8217;&#8221; It&#8217;s difficult however to draw expansive conclusions from a small dataset. Moreover postmortems were not team projects or collaboratively written, rather a single participant is responsible for the postmortem. The authors usefully provide other limitations to put the data in context.</span></p>
<p><span title="url_ver=Z39.88-2004&amp;ctx_ver=Z39.88-2004&amp;rft_id=info%3Adoi/10.1145/1486508.1486521&amp;rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&amp;rft.genre=article&amp;rft.atitle=What%20went%20wrong%3F%20A%20survey%20of%20problems%20in%20game%20development&amp;rft.jtitle=Computers%20in%20Entertainment&amp;rft.stitle=%3Cabbrev_title%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.0%22%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.1%22%20xmlns%3Axsi%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instance%22%3EComput.%20Entertain.%3C%2Fabbrev_title%3E%0A%3Cabbrev_title%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.0%22%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.1%22%20xmlns%3Axsi%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instance%22%3ECIE%3C%2Fabbrev_title%3E&amp;rft.volume=7&amp;rft.issue=1&amp;rft.aufirst=F%C3%A1bio&amp;rft.aulast=Petrillo&amp;rft.au=F%C3%A1bio%20Petrillo&amp;rft.au=Marcelo%20Pimenta&amp;rft.au=Francisco%20Trindade&amp;rft.au=Carlos%20Dietrich&amp;rft.date=2009&amp;rft.pages=1&amp;rft.issn=15443574">The authors conclude that the electronic games industry does indeed suffer from problems in the larger software industry (overly ambitious plans and poor requirements analysis) as well as woes peculiar to itself: the first to experiment with new technologies, tool problems, and collaboration between disparate professionals, among others. </span></p>
<p><span title="url_ver=Z39.88-2004&amp;ctx_ver=Z39.88-2004&amp;rft_id=info%3Adoi/10.1145/1486508.1486521&amp;rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&amp;rft.genre=article&amp;rft.atitle=What%20went%20wrong%3F%20A%20survey%20of%20problems%20in%20game%20development&amp;rft.jtitle=Computers%20in%20Entertainment&amp;rft.stitle=%3Cabbrev_title%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.0%22%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.1%22%20xmlns%3Axsi%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instance%22%3EComput.%20Entertain.%3C%2Fabbrev_title%3E%0A%3Cabbrev_title%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.0%22%20xmlns%3D%22http%3A%2F%2Fwww.crossref.org%2Fxschema%2F1.1%22%20xmlns%3Axsi%3D%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema-instance%22%3ECIE%3C%2Fabbrev_title%3E&amp;rft.volume=7&amp;rft.issue=1&amp;rft.aufirst=F%C3%A1bio&amp;rft.aulast=Petrillo&amp;rft.au=F%C3%A1bio%20Petrillo&amp;rft.au=Marcelo%20Pimenta&amp;rft.au=Francisco%20Trindade&amp;rft.au=Carlos%20Dietrich&amp;rft.date=2009&amp;rft.pages=1&amp;rft.issn=15443574">On a final note, the postmortems are still available at Gamasutra, and they are really fascinating reads. It really becomes clear just how young an engineering and creative discipline digital game-making is, and how much fluctuation there is in how a game turns out. There are some great examples and stories there; the authors of this article cite quite a few of them.<br />
</span></p>
]]></content:encoded>
			<wfw:commentRss>http://www.ibiblio.org/winget/2009/10/what-went-wrong-a-survey-of-problems-in-game-development/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Video Game &#8220;Extras&#8221;</title>
		<link>http://www.ibiblio.org/winget/2009/04/video-game-extras/</link>
		<comments>http://www.ibiblio.org/winget/2009/04/video-game-extras/#comments</comments>
		<pubDate>Mon, 06 Apr 2009 17:06:39 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[News and Commentary]]></category>
		<category><![CDATA[archive]]></category>
		<category><![CDATA[creation process]]></category>
		<category><![CDATA[preservation]]></category>

		<guid isPermaLink="false">http://www.ibiblio.org/winget/?p=133</guid>
		<description><![CDATA[In his article &#8220;Toward a Virtual Reenactment of History: Video Games and the Recreation of the Past,&#8221; Brian Rejack discusses the game Brothers in Arms: Road to Hill 30 and its &#8220;extras.&#8221;  As the player progresses through the game, he or she can unlock bonus features that can be accessed from the main menu.  Similar [...]]]></description>
			<content:encoded><![CDATA[<p>In his article &#8220;Toward a Virtual Reenactment of History: Video Games and the Recreation of the Past,&#8221; Brian Rejack discusses the game <em>Brothers in Arms: Road to Hill 30 </em>and its &#8220;extras.&#8221;  As the player progresses through the game, he or she can unlock bonus features that can be accessed from the main menu.  Similar to the extras that accompany films on DVD, these extras take gamers behind the scenes to see how the game was made. </p>
<p>In the case of <em>Brothers in Arms</em>, the game developers provide side-by-side comparisons of World War II photographs showing, for example, soldiers standing next to a tank with the corresponding image from the game in order to strengthen the game&#8217;s claim to authenticity.  However, the player only has full access to these extras once he or she has completed the game.  Thus, Rejack argues, only when the player plays through the game a second time will he or she recognize those parts of the game that are based on historical truths.</p>
<p>In the months following the publication of Rejack&#8217;s article in September 2007, though, many games have provided these extras immediately to the player as DVDs do.  In fact, a large number of major video game releases are now offered in a &#8220;collector&#8217;s edition&#8221; package that includes a bonus DVD disc containing behind-the-scenes footage.  In these instances, the back of the game box, in addition to describing the game itself, will point out that the game includes bonus features; the Platinum Edition release of <em>Call of Duty 3</em>, for example, notes that a bonus disc includes the &#8220;Making of <em>Call of Duty 3</em>&#8221; feature.</p>
<p>With these bonus features becoming increasingly prevalent, we ought to consider how these videos should be treated with regard to archival video game preservation.  As we have discovered with our own project, many major developers are naturally unwilling to provide behind-the-scenes access to their programming innovations or their artistic creations, worried that competitors might steal their ideas or that their designs might become known to the public too early.  Thus, in our understanding of the creation process for a game like <em>Gears of War</em>, we may be limited  to the official &#8220;making of&#8221; features that the developers provide in these collector&#8217;s edition game packages.</p>
<p>So, should we be preserving these features in our video game archives?  When the developer is so hesitant to contribute the material creations that would normally be considered primary sources of research, do these documentary features then become our primary sources, or the closest thing to primary sources that we can obtain?  How will the archives be affected if game developers continue to commodify information?</p>
]]></content:encoded>
			<wfw:commentRss>http://www.ibiblio.org/winget/2009/04/video-game-extras/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>What Story? Reporting a MUD-Dev Thread from April &#8211; May 2000</title>
		<link>http://www.ibiblio.org/winget/2009/01/what-story-reporting-a-mud-dev-thread-from-april-may-2000/</link>
		<comments>http://www.ibiblio.org/winget/2009/01/what-story-reporting-a-mud-dev-thread-from-april-may-2000/#comments</comments>
		<pubDate>Fri, 23 Jan 2009 19:49:09 +0000</pubDate>
		<dc:creator>walker</dc:creator>
				<category><![CDATA[News and Commentary]]></category>
		<category><![CDATA[creation process]]></category>
		<category><![CDATA[creative limitations]]></category>
		<category><![CDATA[MUDs]]></category>
		<category><![CDATA[stories]]></category>
		<category><![CDATA[storytelling]]></category>

		<guid isPermaLink="false">http://www.ibiblio.org/winget/?p=82</guid>
		<description><![CDATA[From August 22, 1996 to the early October of 2004 the MUD-Dev mailing list housed a slew of earnest and lengthy discussions &#8212; technical, philosophical, design and otherwise &#8212; concerning the development and play of multi-user dungeons (MUDs). 
MUDs were developed before graphics-capable computers, originating and remaining entirely text-based. Players type commands, role-play or just socialize [...]]]></description>
			<content:encoded><![CDATA[<p>From August 22, 1996 to the early October of 2004 the MUD-Dev mailing list housed a slew of earnest and lengthy discussions &#8212; technical, philosophical, design and otherwise &#8212; concerning the development and play of <a title="MUDs Wikipedia" href="http://en.wikipedia.org/wiki/Muds">multi-user dungeons</a> (MUDs). </p>
<p>MUDs were developed before graphics-capable computers, originating and remaining entirely text-based. Players type commands, role-play or just socialize through the keyboard. Gameplay ranges from hack and slash to interactive fiction to simple chat, with all sorts of degrees of role-play in between. MUDs are often discussed as the precursors of today’s MMORPGs, and therefore an early index of the concerns and goals of those MMORPGs by at least 10 years. But MUDs are by no means a dead genre. New MUDs, and players for them, are continually coming into play.  </p>
<p><span>The MUD-Dev archive is available at <a title="Raph Koster's MUD-Dev download" href="http://www.raphkoster.com/2007/02/02/full-mud-dev-archive-for-download/">Raph Koster’s site</a> as a bundle of distinct HTMLs, or right here at the School of Information on a <a title="MUD-Dev at the iSchool" href="http://focus.ischool.utexas.edu:16080/projects/mud-archive/">single (very) large page</a> with the messages hyperlinked and separated.</span></p>
<p>I’ve taken a look at the threads “Procedural Storytelling” and “A footnote to Procedural Storytelling”, which had sprung off from an earlier discussion, “Self-Sufficient Worlds”. The topic, broadly, concerns the art of storytelling in MUDs and more typically, how to generate them automatically on a large scale by abstracting them. Instead of doing a play-by-play of the discussion, I thought a report of the salient ideas and contentions would be more digestible.</p>
<p><span id="more-82"></span></p>
<p>The first idea to be discussed is whether, in the design of MUDs and their story content, “interesting stories” can be computationally generated. It’s posited that interesting stories are not computable and no amount of computation will generate them, at least not consistently enough for actual use. The counter argument believes that it is simply a matter of computational scale.</p>
<p>From this a new idea is brought in: that automation and generation is less a problem than a toolset that allows players to interact with a persistent and consequential environment. This idea is revisited a few times throughout the thread. Posters wonder about how the history of a world could be more thoroughly fleshed out, if a model could be made to allow future events to reference or be contingent upon past events, and the consequences of a persistent world given the unpredictable nature and large number of player actions any MUD would contain. </p>
<p>The thread also concerns stories from the player’s perspective. It’s argued that a story-server would not need to generate stories <em>per se</em>, only conditions for stories. It would not need an explicit story model because it would create relationships that would allow a story to ensue <em>incidentally </em>for the player. This relates closely to another idea in the thread: <em>a priori </em>vs. <em>post facto </em>storytelling for the player. A poster reasons that post facto storytelling is typical for players in most MUDs: they have a gaming session, and construct a satisfying narrative for it after the fact. A priori storytelling, however, is the conceptual model of storytelling for both players and designers alike, where a story is pre-designed and recognized as a story before it begins.</p>
<p>Within this subject as well is player recognition of stories. It’s argued that stories rely on a great deal of context for their proper recognition and meaning, and that communicating or creating this context would be the most difficult part of serving stories to users. Tied to this issue of recognition as well is another poster’s argument that stories derive their interestingness and meaning from an emotional connection to the audience. MUDs generally invoke reward-satisfaction and excitement/adrenaline rushes through mortal-danger situations. Since this is the emotional breadth of MUDs, and since this is acceptable and expected by players, storytelling in MUDs will be very limited and difficult to introduce. It also explains the scale of drama common to MUDs: ‘great evil’, ‘save the world’, ‘escape from death’, etc. </p>
<p>Another point is the nature of goals in MUDs. It’s argued that greater storytelling will be achieved by creating goals that are not strictly individualistic. Players belong to different groups or locales, and these entities are affected by other groups and locales. There should be a consequential dialogue between a single player’s goals and his or her community; this allows for a web of individual-group tension as well group-to-group tensions. Players therefore must consider their and others’ groups in their own actions. </p>
<p>A tangential subject was the expanding computational abilities of computers, and how much that phenomenon should or can be relied upon when attempting to improve gameplay (in this case the storytelling aspect). This recalls <a title="The Power to Create" href="http://www.ibiblio.org/winget/2008/12/the-power-to-create/">Stephen’s post</a> concerning how designers create within or against these limitations. The argument is made that the computational abilities of computers has been a continually expanding horizon, and that this allows designers to repeatedly identify computational might as the fundamental mechanic by which games can become better, as opposed to focusing on problems or innovations that do not require any more computational power than is presently at hand. </p>
<p>This peek at the MUD-Dev archive gives one an idea about the mental models, assumptions, aspirations that both designers and players bring to MUDs and games in general. It would of course be excellent to hear from those involved in game creation about these concerns (and terms) in relation to their specific game!</p>
]]></content:encoded>
			<wfw:commentRss>http://www.ibiblio.org/winget/2009/01/what-story-reporting-a-mud-dev-thread-from-april-may-2000/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>The Power to Create</title>
		<link>http://www.ibiblio.org/winget/2008/12/the-power-to-create/</link>
		<comments>http://www.ibiblio.org/winget/2008/12/the-power-to-create/#comments</comments>
		<pubDate>Mon, 08 Dec 2008 19:49:17 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[News and Commentary]]></category>
		<category><![CDATA[creation process]]></category>
		<category><![CDATA[creative limitation]]></category>

		<guid isPermaLink="false">http://www.ibiblio.org/winget/?p=32</guid>
		<description><![CDATA[In a recent interview for the Wired blog, Blizzard&#8217;s Executive Vice President of Game Design Rob Pardo is asked about past Diablo games and their perceived &#8220;RAM dependency.&#8221;  The interviewer notes, &#8220;When Diablo II came out&#8230;I didn&#8217;t really feel like I got the full experience of the game running perfectly until I had something like 2GB [...]]]></description>
			<content:encoded><![CDATA[<p>In a recent interview for the <a href="http://blog.wired.com/games/2008/10/qa-blizzards-ex.html" target="_blank"><em>Wired</em></a><em> </em>blog, Blizzard&#8217;s Executive Vice President of Game Design Rob Pardo is asked about past <em>Diablo </em>games and their perceived &#8220;RAM dependency.&#8221;  The interviewer notes, &#8220;When <em>Diablo II</em> came out&#8230;I didn&#8217;t really feel like I got the full experience of the game running perfectly until I had something like 2GB of RAM.  With <em>Diablo III</em>, are we going to need 6GB?&#8221;</p>
<p>Pardo&#8217;s response characterizes one of the chief, and unique, concerns for game designers.  He responds, &#8220;One of the philosophies we have is to always try to cater to a pretty low system spec.  We really wanna make sure that as many gamers as possible can play our games.  At the same time, we want a lot of our graphics and all of our features to look good.&#8221;</p>
<p>This response exemplifies how daunting the obstacle of processing power can be in the design and creation of a video game.  As designers begin to imagine enormous and magnificent worlds populated with defined and stylized characters, they must always keep in mind the limitations placed on their work by the current PC technology available to the gaming public.  Obviously, as Pardo suggests, the designer&#8217;s first responsibility is to create a game that the majority of gamers are capable of running on their computer systems.  Essentially, this means crafting a game that can be enjoyed by gamers whose PCs run on below-average processing power.  But, the designers also have a responsibility to utilize the latest in design technology to create a game that can compete with other recent games on a visual basis.  Thus, as designers work on a game like <em>Diablo III </em>and constantly try to improve the scope and detail of the game&#8217;s visuals, they must do so remembering that their ultimate responsibility requires them to deliver a game that &#8220;caters to a low system spec.&#8221;</p>
<p>I would be interested to learn how game designers are affected by what is, essentially, a lack of resources, a creative issue for which there is little precedent.  Many filmmakers, for example, often must consider how much film they are using and how much film is left.  However, filmmakers are using that film supply for one purpose: to create a visual image.  Game designers, on the other hand, must use one supply of RAM not only to create their visuals but also to run the gameplay itself.  Thus, in navigating this difficult creative path, on which imaginative visuals will almost always be sacrificed for the gameplay, do designers often find their ideas for environments and characters being limited?  Have they become so familiar with the technology that they inherently dream up worlds and populations with processing limitations in mind?  Or do they dream big at first and scale back once the magnitude of the gameplay&#8217;s processing requirements are determined?</p>
<p>I would imagine that this is a particularly prevalent problem for MMORPG designers.  In creating game worlds where anything can happen, where any number of player and non-player characters can come together in one place, designers must ensure that the graphics that animate these worlds and characters do not soak up so much processing power that the gameplay runs slowly or perhaps ceases to run.  Thus, considering the requirement of creating an environment that can process a large number of gamers at all times, these game designers are necessarily limited in their power to create visually impressive landscapes and lifelike characters.  I would argue that, because of this limitation, MMORPGS will always be a step behind many other genres visually, and I would be interested to know how designers of these MMO experiences feel about working in a genre in which their visual imaginations must always be kept in check.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.ibiblio.org/winget/2008/12/the-power-to-create/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Beyond Video Game Preservation</title>
		<link>http://www.ibiblio.org/winget/2008/11/beyond-video-game-preservation/</link>
		<comments>http://www.ibiblio.org/winget/2008/11/beyond-video-game-preservation/#comments</comments>
		<pubDate>Fri, 07 Nov 2008 16:44:42 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[News and Commentary]]></category>
		<category><![CDATA[creation process]]></category>
		<category><![CDATA[project]]></category>
		<category><![CDATA[video game preservation]]></category>

		<guid isPermaLink="false">http://www.ibiblio.org/winget/?p=29</guid>
		<description><![CDATA[Creating video games means establishing virtual worlds. The creation process involves stories, communications and networks – a series of actions that are much more complicated than meets the eye. In exploring and documenting this dynamic process, researchers must go beyond preservation and also consider the emotional and psychological aspects that went into designing a game. [...]]]></description>
			<content:encoded><![CDATA[<p>Creating video games means establishing virtual worlds. The creation process involves stories, communications and networks – a series of actions that are much more complicated than meets the eye. In exploring and documenting this dynamic process, researchers must go beyond preservation and also consider the emotional and psychological aspects that went into designing a game. Researchers must also consider the cultural and societal impact the games have on the groups of people and individuals that play the game. For example, to the user, playing a massively multiplayer online (MMO) game it is not just playing a game; the MMO becomes a meeting place for people to gather and the games themselves become a community.  </p>
<p>The game preservation project not only becomes a landmark digitizing and archiving endeavor, it also takes the form of a pioneering effort to experiment with and establish methodologies for the preservation of digital content and new media art. By embarking on this journey, the archivist is challenged by questions such as: How will we preserve virtual worlds? How do we collect new media art? What are the best ways to make what we collect accessible to others? The answers to these questions will have a substantial impact on the future of digital preservation, especially the future of preserving MMOs.</p>
<p>This preservation of the creation process of video games project presents an opportunity to record the psychological and emotional aspects of developing and playing MMOs. Designers, developers and engineers in the video game industry are an extraordinarily creative group of people. A key challenge in this research will be to successfully interpret and understand what they were thinking during the video game creation process. For example: What inspired a game designer to incorporate specific attributes of a lead character?</p>
<p>Recently, the process of recording and collecting user data has become more pertinent than ever. Developing the best methods for handling information archives is also of paramount importance. In preserving and archiving the video game creation process, researchers need to develop systematic creation methods and establish user data management systems and processes that can be easily passed along to and replicated by future researchers.</p>
<p>The ethnographic research approach will serve as a highly effective method for the successful documentation and preservation of video game development histories. A key to the success of the project, for example, will be to accurately record the creation process with a series of visualizations. Conversations, observations and physical records must be collected and collated in a holistic fashion. In employing the ethnographic approach, another challenge will be to successfully integrate the information and establish clear connections between each of the elements of the creation process.</p>
<p>While taking on this important task, it is necessary for researchers to create a new design system that takes into consideration a video game’s long-term influence on a user. While it is essential to determine the factors that influence the game creators’ behavioral processes, the project should also endeavor to go beyond preservation and record the emotional and psychological aspects of creating video games.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.ibiblio.org/winget/2008/11/beyond-video-game-preservation/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

