Wild Physics: Design on the Outskirts of Town -- Brian Boigon
Full Citation and Summary Boigon, Brian. `Wild Physics: Design on the Outskirts
of Town'. Log, no. 26, Fall 2012, pp. 77 - 85.
This article, published in Log 26 alongside articles surrounding the themes of
science fiction and virtuality in architecture, explores the potential of game
engines as architectural design tools. Boigon expands upon previous trends in
digital design which stress the simulation of physicality in the design process
(ie. BIM), the appropriation of animation techniques for architecture, and the
necessity for architecture to grapple with the flatlining of digital and
physical spaces.
Notes
- Brian argues for the necessity of "architectural engines" as a means of
dealing with the "incoherence of living in the randomness of day-to-day (pp.
77)
- Stresses that these engines shouldn't be thought of as technically superior
but rather form their own design world or environment (pp. 78)
- Game engines come with their own simulations of the physical world, "Wild
Physics" (pp. 77)
- "Wild Physics" = a wild version of the logic of the world which regulates the
relation btwn game objects
- Come with a set of "middleware" which regulates the relation btwn the engine
and its components (physics engines, rendering engines, etc.)
- Current design software is too stiff to respond to the physical world (pp.
78)
- No "tactility," modelling happens through a layer of software procedures and
routines
- "In the time it takes to change a vector coordinate and then extrude it
through a twisted extraction, the game-scape is riddled with the digital
debris..."
- "...are alas unable to mimic such a random reality and instead become
systematically routinized by the very tools that make it look easy to craft a
form..."
- Outlines the "gamer's reality" (pp. 79)
1) The "game tag" (address of the digital proxy, one that is "anonymous"
through the choice of tag)
2) The wireless headset (vocal-aural interface with the game world; operates
on the terms of the proxy address)
3) The "virtual cellphone" (the digital client which enables in-game
communication)
4) Two avatars
4a) The "out-of-the-box avatar wardrobe" (this is the visual, visible render
of the character: what the gamer looks like in the game world [allied to
rendering engines])
4b) The "avatarial avatar used by the gamer to move through the game" (this
is the backend which allows the gamer to interact with objects in the game
environment [an object of the physics engine/main game engine and will deal
with collision detection, animation rigging, rigidbody physics, etc...])
5) Youtube channel playing on a physical phone (interface through a different
kind of proxy to a different kind of media)
6) "mild texting and social network chatter" on the physical phone (interface
through a different proxy as well, one that is more symmetrical to the gamer)
7) "Real breathing and food intake" (involves leaving the gaming environment
and interfacing with or operating a series of appliances; there is no proxy
which affects this interface)
- Brian proposes that the above is a "totalizing storage depot" which organizes
a series of disconnected elements into a continuous environment (pp. 79)
- Not a real totality, but a series of clients that allow the environment to
become "total" in some way or another
- Hints that this condition (separate media environments interfacing into one)
as the contemporary condition the game-engine-as-design-tool is able to deal
with
- "transitional objects" (adapted Donald Winnicott) as what emerges from design
with engines (pp. 79)
- Concept responds to responsive architectures and computational (smart)
environments
- Transitional objects are: portable and discrete, tangible, eternal, no
attached to one specific environment (pp. 79), "a vehicle for the progression
toward experiencing" [an interface], dependent on the game engine's regulation
mechanisms [how it sets up the world] (pp. 80)
- To achieve this, the game engine must:
- Regulate two different kinds of reductionism (binary data flow of hardware
simplicity of user-end interface) (pp. 82)
- This relation is affected by a middle position of complexity (the algorithm)
(pp. 82-83)
- Be modular for the sake of efficiency (only the necessary elements need be
present at any given moment) (pp. 82)
- Be both consistent (non-contradictory, no bugs) and low latency (the backend
complexity must remain as close to invisible as possible to preserve the
emulation of real experience "reality is always the goal" (pp. 85)) (pp. 83)
- Provide for interoperability between engine substrates so many kinds of
engines may work in the same space, on the same environments (knowledge
transfer, compatibility, the ability to produces many different kinds of
experience) (pp. 84)