ARC 481c Communicating Design Data · PART 7
"School is NOT a game, young man!"
During the final weeks of the semester, the course focused on creating
interactive walk-throughs using game engine technology. Essentially, students
learned to take an off-the-shelf computer video game called "Unreal
Tournament" and modify it to suit the needs of architectural design
visualization. Oscar Blazquez, who has taught me a lot about digital media over the years,
has been exploring this technique with his students at the U of A Landscape Architecture Deparment.
The process is straightforward: First, remove the weapons, monsters,
and mazes. (That’s the easy part.) Then, using a 3D modeling package and
the game’s built-in editing tools, you can create a new game maze that
resembles a real building or design. This is something I've been experimenting
with since the Quake engine came out in the mid-90s. Back then, the graphics
were quite limited, but over the years the technique has become more compelling:
Today’s game engines are remarkably sophisticated.
They are capable of generating very realistic imagery, and can convincingly
represent building materials, lights, shadows, reflections, water, vegetation,
and vehicle traffic, all in real time.
The act of interactively walking through such
a rich environment can provide a compelling, visceral simulation of being
in a space.
Since these games are designed to be played by
multiple people over the internet, it’s very easy to publish and share
building walk-through simulations. All the users can see one another as
they walk around. Newer games even provide built-in voice communication,
further enhancing the experience. That is quite a lot of technology for
$39.99.
There are drawbacks, however.
Creating content for game engines usually requires
a deep technical knowledge of the engine system. This can take quite a
while to learn, and those hours are mostly non-billable.
Even once you learn how, creating content is tedious
and error prone. The game engines are oriented towards game industry requirements,
which are often incompatible with those of architectural design. This
is somewhat ameliorated by the fact that architects almost never require
the same level of hyper-realism to convey a building design as a modern game does to tell a story.
The game authoring tools are geared towards implementation,
not exploration. That means it's much harder to try out tentative ideas
inexpensively, an attribute that's critical to a design tool.
Here again, SketchUp came to the rescue. Before, creating a game level
for Unreal involved learning an entirely new CAD system. By integrating
SketchUp into the game level creation process, students were able to author
faster, explore further, and achieve a higher level of quality.
Although these really have to be experienced to be appreciated, below
are some screen captures of student projects as they are taken from SketchUp
into the game engine:

(Model by B. Bularca)

(Model by A. Poole)
One thing that really amazed me during this part of the course was that,
on occasion, I still needed to prod students to participate in class!
Sure, it's normal to encounter a spectrum of student attentiveness, but
we were using video games for college credit, for crying out loud. Oh
well, I guess presenting something in a classroom transforms it into a
chore, no matter the nature of the subject. (I'm reminded of the classic
scene in "Monty Python's The Meaning of Life," where a spectacular
demonstration given by John Cleese fails to hold his students' attention.)
Conclusion
Overall, I'm pretty happy with the way the course went. I'd like to
thank my students for hanging in there with me, the faculty at the UofA
for allowing me to contribute to the curriculum, and the @Last team for
allowing me to take time off to teach. I certainly hope that it was a
valuable experience all around.
Note: This report was originally published in the SketchUpDate
newsletter.
|