What Does Pain Look Like?

April 16, 2012

The challenge of how to visualize the internal world of the human psyche through artistic efforts has been one of the key endeavors in the art scene for centuries now. The question is both artistically and philosophically intriguing since it deals with the ultimate subjective experience instead of one based on our senses we all share. Sure, we can and should empathize with the feelings of others, but we can’t really feel what they feel in the same sense we can see or hear what they see or hear. That’s just not possible.

So the feelings we go through every day are extremely personal and usually beyond description. However, most of the feelings, such as fear, joy, anger, or sadness, to say a few, we can provoke somewhat collectively through simulated experiences by watching a movie, reading a book, or, say, playing a video game. There’s one psychological state, though, that cannot be simulated only by watching, listening, or reading a piece of art, which is physical pain.

There’s hardly any question about whether pain is something produced solely by one’s mind, even if it’s mainly an effect of a physical contact imposed by an external force. Consequently, physical pain is simply unfeasible to simulate with “fake physical contact” like, for example, joy, sadness, fear, or even antagonism that are quite straightforward to arouse using fictional narrative. Fiction indeed can touch a person, but not, thank God, hurt one.

The problem, then, in the video game realm is that many of the titles are nothing less than based on the premise of inflicting violence on others in order to progress, and at the same time avoiding getting hurt oneself. Violence is such a fundamental mechanic in a myriad of games that dealing with pain the player is supposedly experiencing seems inescapable.

Now, this all comes back to the initial question of how to illustrate a psychological phenomenon so abstract, subjective, and irreproducible through simulation as pain is in a video game of which narrative is based on avoiding it? Okay, one could argue that the health bar, which is now partly obsolete due to the regenerating health, was there to visualize pain to some degree by altering the length as the player got hit, but that was more like a pure statistic than a visual representation which is under discussion here.

I believe Doom (1993) was one of the first notable games to use flashing red tint indicating the hurt caused by bites and bullets coming from the enemy. And it seems that red has ever since been the color of choice depicting pain, for the reason, I guess, that it’s an abstraction of blood, which itself is something of an epitome of hurt and violence, if there is one.

On that note, Call of Duty: Modern Warfare 2 (2009) received a notable amount of flack and ridicule for using somewhat photorealistic blood for that purpose, in addition to the blurred vision. Mostly people complained about the blood “pouring from one’s eyes” being unrealistic as if there was a realistic alternative available in the first place. Granted, the blood effect was a bit excessive at times, but, as said, I’m positive it was never meant to be realistic but rather symbolic in nature.

Personally I liked what Mass Effect 2 (2010) did with this issue from the aesthetical standpoint, which was to use imagery resembling retina blood vessels whenever the death was nearing. The solution in question grasps quite elegantly the fact that pain comes down, more than anything, to the workings of the human nervous systems, and that pain can be conveyed without splattering blood all over the screen. Interestingly, this approach received a surprising amount of whining in the forums, too.

However, the way Kane & Lynch 2: Dog Days (2010) dealt with pain was one of the most peculiar ones to date. As K&L 2’s visuals were based on simulating a low fidelity digital camcorder, the bullet hits manifested as various glitches and artifacts distorting the image accordingly, giving it a very gritty and dirty look.

In the end, there’s no “realistic” way depicting pain, or any other phenomenon of the human psyche for that matter. Developers just have to use their artistic intuition to find a way to visualize something that abstract, but at the same time very real and graspable.

Speaking of Engine

March 30, 2012

One way of comprehending the software side of the real-time image is to divide it roughly into two basic components or layers. The first layer can be seen consisting of art assets, such as 3D models, textures, sprites, and so forth that populate the virtual space. The second, perhaps more fundamental, or even metaphysical, layer covers the collection of algorithms, popularly referred to as the graphics/game engine, which deals with simulation of space, light, and motion, and in the end, puts everything together. Put differently, the former layer deals with the static, and the latter with the dynamic.

The above dualism comes actually down to the earlier post regarding the dichotomy of algorithm vs. design, which was about the idea that algorithms cannot produce genuine design structures in and of themselves, but that dictated by a set of rules. For instance, a physics engine does produce an unlimited number of different outcomes, which is the beauty of it, but which all are deterministic and thus predictable in nature. The same goes with everything else produced algorithmically, like shading, perspective, post processing, or even fractals. Therefore, sure, an engine can provide a solid foundation upon which to build a modern high-end video game, but overplaying a specific engine in marketing as a certification for quality is usually just that: marketing.

Still, I believe the relative importance of engines in general has exponentially increased over the time as the technology behind the games has become more sophisticated. If we look at the dawn of the real-time image, such as Pong (1972), there wasn’t that much either design or complex algorithms involved. It was the era of Commodore 64 and the likes, when we really started to see actual art direction emerging in games, such as Andrew Braybrook’s Paradroid (1985) and Uridium (1986), which both had a distinct visual style to them.

However, if we scrutinize the said games merely through still images, the engine being used really contributed nothing to the ultimate look of the games. The art assets, such as sprites and background elements, appeared on the screen just like they were initially designed pixel by pixel in a paint program or what have you. Here, the visual impact of the engine came to play only after the piece like Uridum started to move and became dynamic. And, like said, in the end it’s the engine what makes things dynamic in the realm of real-time imagery, which meant in the C64’s case basically little more than moving art assets along the x- and y-axis.

In the C64 era no one talked about graphics engines. It was only after the art assets started to traverse along the z-axis in a massive scale in games like Wolfenstein 3D (1992) and Doom (1993) when the serious engine-discourse started to take place, I believe. Now the engine did contribute fundamentally to the overall outcome of the real-time image, which came across even through still images. Indeed, art assets no longer displayed on the screen as is, but went through algorithmic processes, like simulation of perspective (i.e. space) and/or illumination, before hitting the player’s retina.

Now marketing departments and people in general started to evangelize all of a sudden about the Doom engine, Build engine, and let alone Quake engine(s), which led to a plethora of derivate games coming to existence through engine licensing. The more sophisticated technology behind the games became, the more it made sense to license it instead of developing one’s own from the ground up, it seemed.

Yet, the most relevant developers today generally don’t use off-the-self graphics engines, but propriety engines instead, or at least heavily modified licensed ones. I guess it’s fitting here to adapt the famous saying of Alan Kay: People who are really serious about their games should make their own engine.

Except for the physics engine, that is. There’s still no better physics engine than Euphoria in the market.

Fixed

March 19, 2012

Today I came across with this image on the Internet that reflects the popular myth of graphics as a trivial aspect in gaming, which is, of course, wrong and dishonest on so many levels.

So, I prefer my edited version instead:

One can ask oneself, which element has seen more evolution over the decades: the visuals or the stories?

The Princess is still in another castle.

CGA Hell

March 7, 2012

Before the millions of colors today’s hardware is able to push on the screen, we, as consumers of real-time imagery, have had to put up with a number of far more modest color configurations, starting all the way from a palette of two distinct colors.

It seems that the more limited a color palette is, the more recognizable look and feel it tends to produce to a given image. For instance, the Commodore 64’s 16-color palette is so iconic that I, for one, can quite easily single out C64 screenshots from other platforms with similar specs. And besides playing games with the system, the C64 palette burned somewhat permanently onto my mind through extensive use of paint and animation software, which were the cases that made me realize of how restricted the 16-color palette really was.

Little did I know, though, that the 16 colors of my C64 was luxury in comparison to the palettes found in PCs of that era. Back then PCs meant strictly business so they consequently lacked everything that even remotely had to do with producing aesthetic pleasure, both visually and aurally.

Personally, the PC palette I found the most appalling at the time was the 4-color CGA variant that consisted of cyan and magenta as primary colors in addition to black and white. The games using the CGA palette were almost insultingly horrible looking, and to combine that with the screeching sound of the PC speaker, it seems now like a miracle that people, me included, willingly played such games in the first place.

So basically my animation is a study, if you will, of something about which I wrote a while ago, that is using medium specific artifacts as a means for artistic expression. The animation in question adheres indeed not only to the now obsolete CGA color palette, but other technical characteristics and limitations (listed under Content) of that era as well.

On top of that, the animation utilizes the idea of an additional medium through which the imagery is presented, which renders, as I wrote, the content in some cases more authentic and credible. In this one, I decided to simulate a CRT monitor of which parameters are broke down under Simulated Screen. To me, the CRT look just fits perfectly with low-definition computer imagery, which is why I mainly prefer using a scanline filter when playing older games on a TFT screen.

And finally there is the Actual Screen on which the imagery is displayed to the viewer, which is, of course, beyond artistic control. For what I know, someone could be indeed watching my animation even with a real CRT monitor, which would be interesting setting considering the animation attempts to simulate one.

The end goal was to create an exceedingly “mediumized” piece of animation, and as such, I’d consider it a reasonable success. And now, in 2012, I find the three decades old CGA palette actually not that appalling anymore when using it by choice, and not because the technology says so.

Playing Beautifully

March 1, 2012

It could be said that my central argument here and in my thesis is that the real-time image as a medium is ultimately about the question of what is achievable in terms of definition and simulation in real-time.  So, it doesn’t come as a surprise that I, for one, am a sucker for tech demos in general, but those in particular that fundamentally alter the said paradigm drastically for the better.  As in, “there’s no going back” better.

Also, I love when a demo is presented before a live audience of which audible reactions contribute to the overall atmosphere. In fact, those kinds of presentations are often most effective and convincing ones, as there is immediate feedback from the supposed end users. This is, of course, something infomercials exploit unscrupulously with their hired audiences, but when the positive cheers and gasps are born out of legitimate excitement, the presentation becomes that more powerful and spectacular. One has only to reminisce the introduction of the iPhone back in 2007 to see where I’m going with this.

So, to find a live demo of equally epic proportions from the realm of real-time imagery, I would argue one strong candidate would be the Half-life 2 demo at the E3 2003 expo. In retrospective, it’s extremely fascinating to watch the presentation to unfold as the excited audience eats and swallows everything that is fed to it, trying at the same time to interact casually with the Valve representative with awkward jokes and giddy remarks. It really is demos like this that turn adults into kids, professionals into enthusiasts, and most importantly, the reason why I follow the industry in the first place.

Besides the mere technology that was briefly showcased at the beginning of the demo, I found, and still find, the gameplay portion itself quite interesting, not only for the visual content per se, but the elegant fashion the game was played. Indeed, the demonstrative gameplay wasn’t by any means a realistic portrayal of how people actually play such a game, but rather an ideal concept of how playing HL 2 should look like at its best.

This kind of “aesthetic gameplay” was achieved by carefully choreographing the hypothetical player to act far more spectacularly, or cinematically, if you will, than would’ve been necessary from the pure game mechanics standpoint. The overly stylistic and smooth camera movements, extensive use of cover, impressive utilization of various physics based objects and overall pacing all made the demo seem, in some sense, more like a machinima than genuine gameplay. It becomes even more evident when playing the finished product oneself that some things the supposed player does in the demo indeed don’t make any other sense than look cool.

Which raises the essential question of what other reasons there are to play video games other than to make cool looking things happen on the screen?

The charm of real-time image is that in the end it is what the player makes of it. One can choose to burst through the game as efficiently as possible, like they do in so-called speed runs. Or, to play the game like a musical instrument, with care and thought, and perhaps even fantasizing an audience to which the gameplay is purportedly being presented. Like in the HL 2 live demo.

So, what I’m trying to say here is that perhaps one should play video games more like an actor on a stage, than, say, an athlete on a 100m dash.

Necessary Evil

February 20, 2012

Every creative person can affirm with ease the fact that a work of art is only rarely an exact manifestation of the author’s initial vision, but oftentimes very much about dreadful trade-offs and compromises. Which is especially true with pieces pushing new boundaries in terms of technology. It is what it is, and to accept that reality as early as possible helps to deal with the frustration later on if and when the finalized product falls short of the expectations.

From the perspective of the end user, there are basically two kinds of compromises, or at least in the realm of real-time imagery which is by nature very much about trade-offs. Ones that are reasonable obvious to the spectator possessing general knowledge of the medium, and ones that become evident only when additional, specific information of the product is provided by the developer.

Let’s first examine the former variety of compromises that are indeed fairly noticeable from the surface. An apt example of such can be found, for example, in a polygon-based racing game called Stunts (1990) that featured a rather compromised bitmap backdrop.

Indeed, due to the peculiar algorithm that handles the rotation of the bitmap milieu, the solution begins to fall apart the more the view is being tilted. The way the backdrop is dealt with is a rather odd one as the algorithm doesn’t actually rotate the bitmap at all, but rather skews it quite crudely. The backdrop is clearly divided vertically into 10 pixels wide strips which are then moved individually along the y-axis in order to create an appearance of rotation. And when the screen tips over a certain point, the backdrop vanishes altogether.

One can only speculate the reason for such a bizarre algorithm. Perhaps it was genuinely best what the developer could come up with given the hardware limitations at the time. Or they just didn’t know how to code a proper algorithm for bitmap rotation within the time frame they had. In any case, the developer had to make a call to either include the inconsistent and unstable solution into the game, or simply leave the whole feature out.

Since the backdrop performs most of the time reasonable well, I believe the pros ultimately outweighed the cons. However, it’s quite obvious that the developer wasn’t particularly proud of the solution, as the horizon indeed disappears, I would argue, by design, when it really starts to disintegrate.

Another more recent instance of a compromise that comes across quite noticeably is the Gran Turismo 5’s (2010) particle system that, for some reason, gets exceedingly blocky when viewed from certain angles. Frankly, I’m not completely sure what’s going on there since other games with similar particle effects chiefly don’t do that. However, I’m positive there’s some valid trade-off involved considering the super-ambitious developer, Polyphony Digital. Perhaps the particle system was put in place to future-proof the graphics engine for the next generation of hardware, since the smoke and dust perform beautifully in the Photo Mode.

As said, the above two cases are instances of compromises evident to the spectator simply by experiencing the product as is. To recognize, then, the second form of compromise requires indeed specific information of the production process itself and the original vision, dreams and hopes of the developer.

One example of such is the production of Alan Wake (2010) that initially was very much hyped for its supposed open-world structure. The end result, however, was a purely linear experience which made the game seem like a compromise, even if true, to those who had followed the production from the outset. But people without such knowledge saw Alan Wake merely as a kick-ass action thriller, which it was.

In the end, compromises are what actually get things done. In fact, one could argue that the whole concept of design is at its core about dealing with compromises and trade-offs. More than anything, though, the art of compromise is to be able to step back and evaluate the big picture, to see the forest for the trees, and then doing the right thing for the product as a whole and everyone involved.

Lost in Translation

February 10, 2012

As long as I remember, I have had this particular fondness toward arcade games (and I mean the actual coin-operated ones), especially when growing up. Obviously we are now living in the post-arcade era where sophisticated home systems made arcades finally obsolete, but fortunately at least classic arcade games continue to live on through collectors and, of course, emulation.

What made arcade games so special back then was that they offered, in a way, a window into the future of consumer real-time imagery, as in, what could be possible in home environment somewhere down the line. In fact, for me they acted like windows quite literally since I rarely had resources to actually play the games, but awkwardly hang around them. Watching other people play was almost equally exciting nevertheless, which made me a rather lousy customer for the local arcade as a juvenile.

Even though arcade games by and large came from a variety of developers, one publisher was and, in a way, still is in a league of its own: Sega, and particularly the Sega AM2 team led by design genius Yu Suzuki. I’ve yet to encounter an entity that has broken ground in video game graphics as ambitiously as Sega has, with games that continuously redefined what the real-time image can do.

The closest games to my heart out of the Sega’s overwhelming portfolio are the ones released in the 80s using so-called Super Scaler technology. These are the titles that simulate 3D space by algorithmically scaling the bitmap art assets creating an illusion of traversing along the z-axis. The effect was nothing short of staggering and light years ahead what home systems could do at the time. Games, like Out Run (1986), After Burner (1987) and Thunder Blade (1988), to name but a few, all used this Super Scaler system, and the whole charm of them, I would argue, was ultimately reduced to the smooth scaling effect.

As said, the above-mentioned arcade games ­represented the absolute high-end of the gaming spectrum at the time. The commercial success of them naturally created financial pressures to bring the arcade experience to the home systems, such as the Commodore 64, as well. The problem was, that the C64 represented virtually the direct opposite end of the spectrum with its lackluster hardware in terms of screen resolution, color palette and computational horsepower in general.

Of course, that didn’t stop money-grabbing publishers, such as Ocean and U.S.Gold, bringing Out Run and the likes to the low-end home systems. The issue was that, for instance, Out Run was not so much about the gameplay per se, but the spectacle of driving smoothly through the colorful scenery filled with eye pleasing details. When those things were stripped off in the low-end versions, such as the one on the C64, there wasn’t that much, if anything, conveyed from the original experience anymore due to the hardware limitations. All that there was left was a really bad game, even by the C64 standards.

The original Out Run was indeed a rock-solid fusion of software and hardware that carried through the visual concept Out Run was built on gracefully with no hiccups whatsoever. The game ran beautifully at high and steady frame rates, contained striking transition effects when driving from one section to the next one, and offered vast variation in terms of visuals in general. I’d say Out Run was best the year 1986 had to offer for real-time imagery which the everyday audience had access to.

However, the way the C64 version was constructed was completely backward. The exercise here was to shove the concept of Out Run into the system in any way possible regardless the inherent hardware limitations. There was indeed nothing – not a single chip – inside the C64 that would’ve warranted or justified the ludicrous idea of porting a game like Out Run to such a weak system. Which is painfully obvious just by glancing at the end result, especially in motion.

In the end, everything comes down to the fact that the real-time image as a medium can’t be separated from the hardware platform that it’s on; the real-time image is the software and the hardware. I can only imagine the level of disappointment of someone who actually paid real money for an arcade conversion like the C64’s Out Run and thought having nearly the same arcade experience at home. It was like buying Star Wars: Episode IV on DVD and getting Star Wars Uncut instead.

It goes without saying that in the end the logic of such endeavors had got to do more than anything with the power of Intellectual Property and the “fraudulent” financial leverage that came along with it. In fact, all this makes me think of fast food joints where the pictures of the burgers above the counter represent nothing of the actual products people are shoving, rather happily, into their faces. What they are doing is consuming the simulacrum of the Big Mac, not the Bic Mac depicted in the marketing materials.

The problem of horrible arcade conversions wasn’t the poor target hardware in and of itself. There were quite beautiful games on the C64 at the time, like, for instance, Uridium (1986) that utilized even the awkward shape of the C64 pixels for its advantage. The problem was the completely backward and corrupt creative process. And I’m using the term creative very loosely here.