On Making a Pizza Delivery Game
I recently finished up working on a prototype of a small pizza delivery game called Andiamo. You can play it here: http://cdm.jordanorelli.com/games/andiamo/
Although I've finished working on it for the time being, it's just a prototype, and not really a finished game. I feel that for the time being, I've learned enough from the project for me to move on from it.
I made Andiamo to explore a few themes from my grad school readings and my independent academic reading. I'm very interested in the spatiality of video games and the design of video game spaces, especially as it relates to architecture and urbanism. Just as buildings and cities are constructed spaces, the environments in video games are, too, constructed spaces.
For this game, I wanted to try my hand at building a small settlement. I guess we could call it a town, although it lacks many real town-like features, is entirely devoid of people, and only consists of roads, a pizzeria, some houses, and a few monuments. The principle attribute in settlement design that I was looking to investigate is the notion of imageability, as described by Kevin Lynch in The Image of the City, a seminal book on elements of urban design. The image of a settlement in this context is not a photograph or a map, but a mental image; a way in which a person understands and mentally visualizes an environment. A settlement is described as being imageable as follows:
that shape, color, or arrangement which facilitates the making of vividly identified, powerfully structured, highly useful mental images of the environment.
Lynch observes a few cities, interviewing various residents, observing what design elements of cities make them legible to their occupants. We'll return to these elements and their expression (or lack thereof) in Andiamo.
For a game, it is not always enough to have just an environment; absent any goals, what motivates the player to explore the environment? What purpose is served by an image of a purposeless environment? For this project, I wanted to give the player a reason to need to image the town, and I wanted to reinforce a behavior that is often unexplored or implicitly devalued in games: navigation. The player should not be rewarded based on their driving skill, but on their ability to navigate the environment. I came into the desire to express and reinforce this skill in players as a result of playing many hours of Grand Theft Auto 5, a game with a sprawling but illegible city that, after some 80 hours of play, I could barely describe. What was it about Los Santos that made it so difficult for me to navigate without the assistance of GPS and turn-by-turn directions? Additionally, limits on time and my own level of experience preclude setting more complicated player goals.
I decided on a pizza delivery scenario as a means of exploring these themes. A delivery driver must navigate their environment in an expedient manner, lest they deliver a cold pizza. Of course in real life, a driver would likely have a GPS-capable cell phone giving them turn by turn directions, but I would argue that these tools are actually maladaptive for the goals of acquainting a person with their environment. In a time before Google Maps, a driver would often be told an address and maybe a cross-street; any directions given would be verbal and constructed by another individual. These ad-hoc directions are themselves a distilate of another individual's image of the settlement.
After delivering a pizza, the driver must navigate entirely on their own to return to the pizzeria. A driver with perfect recall driving on entirely two-way streets may simply reverse their outgoing route, thus reinforcing their experience of the environment, and viewing every visited juncture from multiple perspectives.
In addition to Lynch's descriptions of imageability, I found Roger Caillois's attempts to categorize types of play in Man, Play, and Games, as particularly interesting, as it seems to it seems to attempt a broad categorization of games that excludes orienteering as a form of play. Caillois was writing in a time before virtual environments, so it is natural that he would not analyze the virtual environment extensively. Caillois does describe disorientation itself as a form of play; this he describes as ilinx:
for a disorder that may take organic or psychological form, I propose using the term ilinx, the Greek term for whirlpool, from which is also derived the Greek word for vertigo (ilingos).
Broadly, Caillois uses this device to describe acts that produce dizziness or adrenaline. What then is the sensation of being lost, if not an expression of ilinx? I wanted to explore this sensation of being lost and of finding one's own place through navigation. Enjoying disorientation and playing at avoiding disorientation are both forms of ilinx; being lost and finding one's way are extensions of this form.
It is through forming an image of our environment that we learn to navigate the environment. Both as an agent existing in real space and as a player in a video game, our sense of orientation is distilled from of our image of our environment. Through this image we come to terms with our current state; not just our literal location but our own state of safety, of familiarity, and of belonging. In this way, our relation to our environment and our knowledge of the environment helps us construct our own sense of self in real life, and by extension, a sense and an understanding of our player character in a game world.
In Touching Games, Aubrey Anable's examination of affect theory in gamespace mirrors Lynch's view of how we relate to our physical environment. On the topic of the screen itself, Anable states:
we might figure the screen less as a stable boundary between the computational and representational, the digital and the analog, or the subject and object and more as a porous βzone of contactβ through which each term is always potentially in contact with and causing changes in the other.
While Lynch says the following on the topic of building an image of an environment:
Environmental images are the result of a two-way process between the observer and his environment. The environment suggests distinctions and relations, and the observer -- with great adaptability and in the light of his own purposes -- selects, organizes, and endows with meaning what he sees.
Anable was interested in how interacting with games, especially via a touchscreen, affects the player emotionally and logically, while Lynch was interested in how interacting with the environment affects the individual emotionally and logically. In real life, a city's form is fact; an extant object not caused into action by the viewer. In a video game, the city is purely imagined; it is in a sense only an image, and that image is expressed through the screen only at play time. As Baudrillard says in Simulacra and Simulation:
The territory no longer precedes the map, nor does it survive it. It is nevertheless the map that precedes the territory β- precession of simulacra β- that engenders the territory.
As video game designers, we in a sense make only the map; the territory itself only exists during play. The territory is a runtime construct, called into existence as a consequence of the player electing to play the game.
Much in the way that we as residents give meaning to our environment, we as players give meaning to the gamespaces that our characters inhabit. In both instances, we are in turn changed, as we record and are thus embued with the knowledge of the space, either real or virtual.
From these perspectives about environment and play, I decided it would be best to equip the player with the following information:
their current location, expressed just as a street name
the address of their destination
a written description of how to navigate from the pizzeria to their destination
The player is never equipped with a map or turn-by-turn directions; these elements must be imagined. It is hoped that through this curated set of information, the player is encouraged to learn the layout of the settlement autonomously. In some sense the player is given less information that other games; no map, no turn-by-turn directions, no guide. In another sense, by naming every street, we encourage the player to not only interact with and make use of the meanings and identities of the elements of the game world.
What elements, then, assist the player in forming their own image of the virtual settlement? We return to Lynch's categorization of the elements of a city's image: paths, edges, districts, nodes, and landmarks.
Paths are quite literal; they are the traversable elements of an environment such as roads, sidewalks, and literal paths. In Andiamo, the player is entirely restricted to navigating on paths. The player is always on a path. I decided very early on that every street in the game should be named. In so many games, the streets are either unnamed, their names are not known to the player, or the names are not useful to the player. Andiamo expresses the path identities by naming every path.
Edges are the boundaries between elements; an edge may be an actual barrier such as a wall, a mountain, or a coastline. An edge may also be an imagined separation between elements; a sudden chang in road quality, in building architecture, etc. Andiamo does an admitedly terrible job of expressing edges.
Districts are as literal as paths; they are the zones of the whole that have individually identifiable characterstics. This may be expressed through architectural styling, specific repeated elements such as lamp posts, paving quality, or materials. Districts may also be expressed through the people inhabiting the district; the signage changing languages, the sudden near-ubiquity of a particular style of dress, or other cultural markers. Andiamo attempts to render districts as different styles of building; in one district, all houses are of a saltbox shape. Another district uses steeper roofs on their houses with overhangs; in some cases a district dictates that all houses will have their gables facing the road (i.e. a front-gabled district), while in another district all houses may have their gables perpendicular to the road (i.e. a side-gabled district). The expression of districts in Andiamo exists but is quite subtle. It's likely that most players won't notice the subtle signifier of a gable's directionality, but the area of the town having all curved roofs is particularly easy to spot.
Nodes are large areas that a person can enter, providing perspectives on multiple surrounding elements. An intersection is a node, as is a square or clearing. The piazze of Italian towns and cities are particularly iconic city nodes. Andiamo does an awful job at expressing nodes.
Landmarks are notable single points in an environment that provide a point of reference for navigation. Any notable building, statue, monument, large, or very distinct object can be a landmark. Expressing landmarks in video games is particularly easy, and Andiamo has three: an obelisk, an archway with a floating sphere in it, and a huge sword sticking out of the ground. Like the Pizza Hut model, the sword was a model that I made some weeks ago and reused for expediency. These monuments are completely unexplained to the player, but are used in delivery directions (e.g. "head towards the obelisk on Main Street").
It was interesting and striking to find that the elements of city imageabiliy that were easily rendered in gamespace were different than that in real life. As a game designer, I have the ability to create the space exactly as I want it. In real life, a city is the organic result of many independent agents, each with their own goals, sometimes in conflict. Erecting a giant monument is incredibly easy in a video game world; just make a large 3D object and plop it down where you want it. In real life, such an act would require enormous construction costs, as well as requiring substantial political legwork.
Designing to these texts was an interesting exercise and helped structure the game's rules and UI choices. Since I was pressed for time and have only limited gamedev skills to draw from, having a small set of concrete design goals was incredibly helpful in figuring out which few features would help me express my idea most expediently. There are a number of other elements that I wanted to include, such as scoring the player based on how hot the pizza was when they delivered it, the player having to manage buying gas and making money from deliveries, temporary changes to the environment such as construction causing unexpected detours, etc.
It also became very quickly apparent that I have no idea what size things are in real life. I hadn't really considered how big a block should be, so my blocks are absolutely gigantic and largely empty. My car is just one meter wide, when a real car is twice as wide. My streets are three meters wide because I figured a street should be about three times the width of a car. As it turns out, streets in the town that I grew up in are 34 feet wide; nearly four times as wide as the streets that I made. This means the relationship between the width of the car and the street is such that my streets are about half as wide as they would be in a proportional American suburb. With more time I would iterate on the plan of the town more, but with the time I had, I laid things out essentially in one shot, never revisiting old layout decisions.
I only had time to make a limited set of 3D models, so I made a set of street segments each contained in a 20m by 20m square that I could use as repeating tiles. The street system is constructed using just four models. This made it easy to lay things out, but restricted me from exploring a few design areas. Streets that meet at right angles are highly legible, as are streets that are perfectly straight. Streets that curve slowly make it difficult for the occupant to undersatnd their interrelationships; I didn't have any such streets because of time and resource constraints. I would have liked to have made some areas of the game be intentionally difficult to image, to provide areas of differing levels of difficulty.
Although I had a model for a street on an incline, I never made it to the point where I learned how to create terrains with inclines. This would have opened up a huge design space to explore.
The destinations are very haphazard and are selected at random instead of ramping up in difficulty. I didn't do a particularly great job of designing a course that would tour the player of the settlment and assist them in building a progressively more useful image.
The car itself has very sloppy driving mechanics. Technically it has no brakes, and its easy to get stuck in the curbs. It was my first time trying to make a car, and I stopped working on that element of the game almost as soon as I had something somewhat driveable, to ensure that I would actually get around to building an environment. I don't regret how I prioritized my time in the slightest, but it did leave me with a somewhat frustrating game to play.
Overall, I'm very pleased with the amount I learned in this project. By no means will this be my last virtual town; I hope it is to be just the first of many, and that I will be revisiting these design problems again and again until I've created a great many virtual spaces for players to explore.
