In-World Photography (Final Project)

We will discuss all of this material and talk about where to find some of these gameworlds if you don’t already have any at your finger-tips, on Monday and Tuesday.

Final IMS211ab/c Project

Context: Pictures at an Exhibition

Why do we take pictures? Earlier in the semester, I suggested that human beings were very bad at thinking about technology, because we insist on thinking about technology as alien, artificial, and distinct from ourselves. I suggested (following a line of thought that is often associated with scholars like Marshal McLuhan, Fr. Walter Ong, SJ, and Greg Ulmer) that we are inextricable from our technologies. From the sonograms that see into our mothers’ wombs, to the blankets we are swaddled in, to the coffins in which we are buried, technology is part of our Lebenswelt – our “lifeworld.” We are, all of us, cyborg.

The question, then, isn’t “Why do we take pictures,” but “What are we doing when we take pictures?” And the answer is this: We are offloading our memories; we are creating “save” points.

But we are doing more, because we aren’t just preserving the past, we are filling the present with that past. We are reshaping the “real” world in which you and I live by filling it with images of events that look like they are happening now, but which are really just records of luminance, wavelength, and the orientation of matter.

So: Photos extend us and allow us to offload our memories. And photos are configurations of the past which become part of the present whenever we see them.

So: What happens if we start “taking photos” of the virtual worlds and game worlds in which we dwell? Or, more to the point: Why don’t we already take photographs of our adventures in virtual worlds? Disneyworld is not real – but we covet the photos we take of our visits there. Do those photos really just function as “offloaded memories,” or do those photos also contribute to the “realness” of Disney?

What happens if we take photographs of “ourselves” in Skyrim, or Zelda’s Hyrule, or Stormwind, or Liberty City, or Minecraft, or wherever? What happens if we bring those photos back to this world, print them out, and exhibit them?

Project Overview

This course has emphasized thinking about games and game-worlds in non-conventional ways. We’ve argued that seeing games as “consumer goods” – certainly the most popular contemporary approach – is perhaps the most simplistic, most dismissive way to think about games.

For the final project in this class, you are asked to think about game worlds as authentic sites of human activity – as a “real” experience worth preserving, worth communicating. We’ll accomplish this by creating and exhibiting (in Laws Hall) a modest photo gallery that bears witness to our being in-game-worlds.

Your responsibility is fairly narrow: For this assignment, you will turn-in three photos taken from inside one or more videogames. In each case, the photos will include your comments, captions, and/or game data attached.

The photos and associated captions, etc., are due to me, via Canvas, by Noon on Monday, 13 December (this is a non-negotiable deadline). We will discuss particulars in class, including how to caption them, whether or not to Photoshop them, and (most importantly) how to create them.

Some useful technical explanation, details, and suggested readings follow below.

Technical Overview

Aside from NVidia’s recent experiments with their Ansel Engine (which draws on the hardware particulars of NVidia’s graphics cards to facilitate in-game photography across a range of game worlds), there is no standard way to create a photo from inside a game. This is an important observation, because it will have a direct impact on how you approach and complete this project: In addition to selecting the most scenic, humorous, appealing, or provocative sites to serve as subject matter in your photos, the process of making the photos itself will likely require some technical investigation, experimentation, and ad-hoc invention on your part.

In sum: The solution is often non-obvious. You will need to figure it out. That is part of the project’s design.

Some games do provide an in-game photo mode (e.g., Forza Horizon literally stops the action and lets you reposition your ‘camera’, focus, set the FStop, etc.) while other games do not. Oher games, like World of Warcraft, meet you halfway by mapping the “print screen” key on IBM-style keyboards to an in-game screengrab routine (which often includes a cheesy 35mm SLR sound effect), and then stores the “photo” in a screen capture folder (often, but not always, in /My Documents). In other cases, you may find external screengrab applications to work best.

Aside: Why is there no standard “best approach?” There are many ways that a game or application can put data or images on the screen, and those approaches may or may not be compatible with any particular approach to “saving the screen” as a PNG file. Remember, the screen is really just more computer memory, made visible. Direct3D, GLide, Metal, OpenGL, QuickDraw, RenderMan, LibGCM and Vulkan are among the popular low-level 3D APIs commonly deployed. Their final output may look similar across the board, but each approaches mapping data to the pixels in your monitor in a radically distinct fashion: You need to find a screen-grab approach that looks for the data in the right place.

Technical Details

  • Photo dimensions: The format/ratio of the image is your choice, but aspect ratios common to photography include 1:1 (square, e.g. medium format camera), 5:4, 4:3, or 3:2 (e.g., 35mm film).

  • Photo resolution: Resolution matters more than aspect ratio. The resolution of your photo (when you first take it) should be as high as you can set it: e.g., 3000×2000 pixels. A resolution of 1080×720 is really not sufficient, and should only be used when other choices are exhausted. Just like with real-world photography: The higher your initial resolution, the more options you preserve in the long run. You cannot recover data that was never recorded in the first place.

World Choice

You already understand the difference between a “game world” (a synthetic world, a virtual world) and a “mere” video game: Both are sites of complexity and engagement, but game worlds are persistent and less overdetermined than their arcade-y sisters. Single-screen games and digital versions of boardgames, as well as platformers, fighting-games, and bullet-hells are not “game worlds” (even if they boast deep “lore”); Among others, Massively-Multiplayer Online Role Playing Games are game worlds.

One of my favorite tests: Can I steal something valuable from another player, and then put it somewhere they are unlikely to find it? If I can, then I’m almost definitely in a game world. If those acts are impossible, then it is likely some other kind of game.

Still, there are no hard and fast rules for which is which. So here is a (provisional, partial) list of video games that feature virtual worlds (useful for this assignment) and video games that do not (games not useful for this assignment).

Games with “worlds”

  • Destiny 2
  • Stardew Valley
  • Grand Theft Auto V
  • Fortnite
  • Final Fantasy XIV

Games without “worlds”

  • Tetris
  • Space Invaders
  • Video Poker
  • Zork

Again, the emphasis here (as it has been all semester) is on discovering other ways in which video game worlds are “more” than just sites for ephemeral gameplay.


“Virtual photography: Taking photos in videogames is imaging’s next evolution” (2019)

“Sick of Video Game Toxicity? Try Virtual Photography” (2021)

The point the author makes is a powerful one, and intimately related to our own considerations: Video games and game worlds are more than “just” video games. They are built environments.

FStoppers: It may be art, but it isn’t photography”

A surprising argument, perhaps, from a journalism professor, who insists, in essence: “Sure, screenshots from inside can never be PHOTOGRAPHS. You’re just making ART.”

flickr pools include some excellent images. Visit, e.g.:

Rolling hills - Red Dead Redemption 2
The Last of Us Part II (PS5)

Also interesting (somewhat dated) (note that these will open in new tabs):

A virtual photographer’s tumblr, “Virtual Geographic”

One photographer’s “Steam Postcards”

Two recommended resources: Cosplay

Below are two separate recent publications that cater to novice cosplayers keen to create their own costumes. Again, there are a huge range of skill levels and ambitions to accommodate here, so the texts may or may not actually be useful to you.

I am in the process of digging up a few additional resources and will post links to those as I am able.

NB please that these are copyrighted texts, and are made available here — as Fair Use texts — only and exclusively within the context of our class this fall, IMS211. These texts are NOT to be downloaded by anyone not associated with IMS211, nor are they to be distributed beyond our class. Please respect the authors’ ability to profit by their work.

Early iteration / demo Lunar Lander

Here’s a very early, thoroughly incomplete version of lunar lander that I’ve been cooking up. It is more complicated than it needs to be; it doesn’t yet handle crashes (or landings, for that matter); it tracks fuel, but doesn’t cut off the thrusters when fuel runs out.

Alchemical Pinball (project 4 concepts demo)

UPDATED: Here’s the fully-commented version of the AlchemicalPinball demo. Definitely look at this version (I’m leaving the other version below in the event someone needs that version, however).


UPDATED: See the commented version above. Don’t rely on this iteration.

This code is almost entirely uncommented! Sorry for that — but the code was a mess, and I spent a lot of time refactoring things for improved clarity.

I’ll share comments and explanations later today (Saturday).

Project IV: Lunar Lander

Project narrative

Land your Lunar Excursion Module [LEM] on the surface of the moon. This is a storied and much beloved game from early digital video-gaming (ca. 1969).

Here’s a re-creation of the earliest iteration of the game — text-based!

And a good overview of the game’s multi-platform history:

Project Requirements: Code

  • Make use of basic collision detection in GameMaker (esp. recommended,e.g.: place_meeting(), position_empty(), etc. For special circumstances, consider also the “advanced collision detection” functions (e.g., collision_point(), collision_line(), etc.);
  • Make use of at least two different sound effects that are synced to player or game behavior;
  • Make use of at least two cameras (e.g., one close-up and one distant; one on the game field and one trained at a control panel, etc.);
  • Make use of at least one simple particle generator (built by you, and not part of the GameMaker physics engine proper).
  • Special Aside: Your code should NOT MAKE USE of the BOX2D PHYSICS simulator in GameMaker.

Advanced Options: Code

  • Consider using procedurally-generated terrain via an implementation of Perlin Noise or Perlin’s more recent innovation, Simplex Noise.
  • Game data should be clearly and intuitively modeled for the player. While a purely numeric dashboard is a good start, for example (displaying remaining fuel, rate of descent, etc.) a graphical presentation of that information — in the form of dials, gauges, etc. — might make it more fun.

Project Requirements: Gameplay

Please consult any of the variants upon the original Lunar Lander (Atari) for game-play ideas. In essence, here’s how gameplay proceeds:

  1. Your LEM has a finite amount of fuel as it attempts to land on some lunar surface;
  2. The player guides her ship, using a main (vertical) thruster and two smaller horizontal thrusters, towards a promising surface for touchdown.
  3. Feel free to vary difficulty (randomly, or by level) by varying (1) gravity, (2) fuel reserves, (3) rate of fuel consumption, and/or (4) how rigidly you evaluate a “soft landing” versus a crash.
  4. The pleasure of this game — aside from its simulative nature — is the tight integration between our input (thrust) and the moon’s pull (gravity, inertia), as both are understood vis a vis our dwindling resources (fuel).