[-empyre-] game creation is game deconstruction

Mon Mar 24 23:34:59 EST 2008

..on or around Sun, Mar 23, 2008 at 07:14:06PM -0700, Jason Nelson said:
> All,
>    
>   Before the month is up. I do want to bring up the topic of game creation or 
>   roughly put:  how does an artist (or scholar, meaning why cant game interfaces
>   be used for scholarly work?) create an art game?  what are others experiences?
>    
>   where are some good resources in terms of advice, personal narratives, code, oh yeah
>   and code, where can we find more lovely game code?
>    
>   but most importantly...how is the process different?   where does the future live for the
>   art game creator?

hmm, this is a big topic and certainly something i have a lot to say
about! before writing far too much here i'll get it out of the way and
point you to a couple of papers i've written about this, largely dealing
with the problem of using prioprietary game engines in artistic game
development projects, now proving difficult for the artist wishing to
distribute their work and academics wishing to build a sustainable
code-base on which to experiment. 

the first was written several years ago and was called 'Developers in
Exile', for the Melbourne DAC and published in quite a few journals now.

a better paper however - one that looks more at tools, techniques and
strategies in the artistic process - is one i wrote for Daphne's
festival Mediaterra06. it also covers more of the theoretical problems
surrounding building a practice around code written by entertainment
corporations, it's legacies and limits etc:

    http://selectparks.net/~julian/share/text/The-Game-is-not-the-Medium_Oliver-2006.pdf

to speak from a practical perspective, a core problem is the lack of
mutability in proprietary engines: the ghost of the commercial game,
it's genre, ever present with no amount of deconstruction ridding it of
this this haunting. 

artistic games, either actively or inadvertently, are thus almost always
a conversation about the original, un-modified form.  in an attempt to
work-around it they describe its shape, in an effort to un-write it,
they reveal it. this is fine if your work seeks to converse on this
level but those with a interest in the pure possibilities of the medium,
as a plastic intersection of a great many media-types, quickly find
themselves looking elsewhere. 

it's perhaps worth mentioning this is often a personal struggle, one
implicating a personal sense of artistic integrity, that many audiences
are otherwise unaware of. it's a struggle so ineluctably bound up in the
process however that it's difficult to talk about artistic game
development, as a practice, without addressing this (technical and
opaque) problem.

anyway, this issue often results in the would-be game developer into
taking things into their own hands, looking for high-level solutions
that abstract over alot of the grisly guts while still affording them
plenty of flexibility. they're in search of that elusive 'neutral'
toolkit, a studio in which they can mix their own colours. 

this is a long way of saying that if you want flexibility, want a
plastic base with which to build any sort of game, you need to look
beyond the bulk of the first-person titles so famous in the artistic
game development scene as they will always contain a legacy you will not
be able to rid it of.

this often means giving up the luxuries of level-editing (producing new
environments for an existing game) and modding (manipulating game-code
or even engine code if available to you). instead you're into
programming, often lots of it. 

secondly, it means choosing an engine which will give you the right to
continue development unhindered, distribute the results and invite
collaborators. this implies an open-source license (LGPL,GPL,BSD etc).
many uni's are slowly waking up to this necessity.. (we learnt this
lesson with AcmiPark the hard way, now being no longer legally able to
work on our own engine, one we spent a good two years writing).

the choices you have at this stage are either to choose a game-engine
(wise) or choose a 3D/2D engine and write all the game code yourself
(hard but sometimes fruitful). after this point the decisions are
between the quality of the documentation, the platforms it runs on, the
features it has, the language it's written in and the scale of the
user-base.

a good case for consideration is Processing, as Christian points out.
it's far from a game-engine. it has no event management, very little
animation management, little or no support for complex networking let
alone a very capable 3D renderer, and so on. it's also Java, and as such
runs in a Virtual Machine, making it much slower than if it were
object-code run natively by the operating system. however, it does have
a large user-base, great docs, and runs on all popular operating
systems and is open-source. Java is also pretty easy to learn and write.

consider the fabulous Soya3D however: fully written in the interpreted
(scripting) language Python, open-source (GPL) very capable 3D renderer,
great event management, networking code, animation management,
sound-engine and even physics. it has a small userbase (it's young) and
the docs are a little shoddy.

for rapid prototyping and teaching i use the Blender game engine. it has
a Python Application Programmers Interface, is fairly quick and very
flexible. it has a decent user-base and pretty good docs. much of the
development can interfaced directly with art created all in the GUI
using 'logic bricks' and the remaining game-code can be written in
Python. i've written networking code for the Blender GE wrote code to
interface a WiiMote, third-party sound servers etc, proving its
flexibility. it is howver not at all suitable for big projects. that may
change with the new Project Apricot, which proofs Blender integration
with the fully capable game engine Crystal Space)
<http://apricot.blender.org/>, the idea being that you make art in
Blender, build logic using the GUI and or Python and run your game
directly in this engine, with the click of a button.

other good open-source game-engines might be Crystal Space, Sauerbraten,
Delta3D, Irrlicht  (in that order of preference). Languages interfaces
will differ heavily.  if you want to work strictly in a first-person
mutli-player context i'd most certainly look at ioQuake3, the
open-source, community-maintained version of the Quake3 engine. it's
super and has the advantage of a massive user community inherited from
Quake3 along with a high-quality level editor and a well trodden
art-pipeline. it's naturally very 'quaky' but is fairly hackable. i use
this alot, most recently for my 2 player Second-Person-Shooter (which i
need to make a project page for at some point).

for 3D engines intended for use in games, i'd look at Ogre3D (really
super engine, we used it with http://fijuu.com), G3D, Irrlicht.

all the above engines give you right of distribution and sale as long as
you comply with the license terms, most commonly that you need to make
your source-code available at the point of distributing your binary
project.

here are some lecture notes with links and plenty more information
regarding engines and their features. it's an HTML subsite, just use
your browser once unzipped:

    http://selectparks.net/~julian/share/text/oliver-transistor-session_07.zip

here's a Blender manual i wrote, for those wanting to have a peak. i
have yet to write the game-engine part but will at some point.
nonetheless, this is a good place to get started:

    http://flossmanuals.net/Blender

thanks for reading my one-page, badly edited book,

julian

> 
> Melanie Swalwell <melanie.swalwell at googlemail.com> wrote:
>   Hi Ilias, and thanks for your thoughtful post.
> 
> Your comments make me think of private collectors. I have found it
> intriguing to collaborate with collectors of games in recent years.
> Often collectors have been pathologised in popular discourse (*why*
> would they want to do *that*?)... but I find the activity deeply
> interesting. Those I have worked with are far sighted people, who
> work out of genuine interest in, and valuing and love of, these
> artefacts.
> 
> I think quite often of Walter Benjamin's claim that while 'public
> collections may be less objectionable socially and more useful
> academically than private collections, the objects get their due only
> in the latter'. Benjamin was a keen collector of books.
> 
> In another essay, he juxtaposes the attentions of the art lover and
> the reviewer, directing us to the attention received by these objects
> by those who have a passion for them:
> 
> '
the paid reviewer, manipulating paintings in the dealer's exhibition
> room, knows more important if not better things about them than the
> art lover viewing them in the gallery window. The warmth of the
> subject is communicated to him, stirs sentient springs. What, in the
> end, makes advertisements so superior to criticism? Not what the
> moving red neon sign says – but the fiery pool reflecting it in the
> asphalt.'
> 
> Digital games are not books that can just sit on collectors' shelves
> for very long periods of time, being sometimes taken down and looked
> at lovingly. Institutions will have a role, I think, in the
> multidisciplinary challenge of making these complex objects work. I
> think that digital games have a similar mimetic charge to the neon
> advertisements of which Benjamin wrote -- that they will continue to
> stir the senses of those who play them, who will not only be those who
> "know important things" about them.
> 
> Melanie
> _______________________________________________
> empyre forum
> empyre at lists.cofa.unsw.edu.au
> http://www.subtle.net/empyre
> 
> 
>        
> ---------------------------------
> Looking for last minute shopping deals?  Find them fast with Yahoo! Search.
> _______________________________________________
> empyre forum
> empyre at lists.cofa.unsw.edu.au
> http://www.subtle.net/empyre

-- 
julian oliver
http://julianoliver.com
http://selectparks.net
messages containing HTML will not be read.