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)