This is the first of a series of posts I've been planning to write on my current task: create a game that expresses your findings in the language of the medium you analysed. I've been working on "computopia: the game" for quite a while now and I can tell you, its tough.
In the following posts, I'm hoping to explain my approach (in a nutshell: FPS-based game created with Unity, programming in C#, trying to avoid investing in graphics and design and instead focusing on the idea and the mechanics) and my game idea in more detail as it develops (being secretive about it hopefully makes you more curious). For now, I'll leave you with some impressions of my first contact with contemporary state-of-the-art game design software.
There are several ways to approach such a project and several dimensions to take care of. In an ideal scenario, I would 1. learn a lot about how to set up such project, 2. plan it carefully, 3. have a good grasp of what I want to do, 4. acquire the necessary programming skills, 5. be part of a team rather than in individual. Since none of the above is really the case, this is a project that develops "en route", meaning that I'm trying to adapt to the obstacles as they appear. Surprisingly, this method is relatively successful (I can say this now, since I don't know the outcome yet) if you are resilient to temporary frustrations. Just to be clear: successful here is meant to say that I am making fair progress so far, considering that I wasn't equipped with the necessary programming and conceptual skills in the beginning. This observation, together with a recent review of Lev Manovich's Software Takes Command (2013) I wrote for the soon to be published Asiascape: Digital Asia 1(3), got me thinking more about the environment and conditions contemporary digital media offer for creative engagements. Based on my current experiences, I'd say that with enough "frontier spirit", many things are possible, because (1) roadmaps are ubiquitous (2) it is likely that somebody was there before you and left directions. Unfortunately, accidents and road blocks are never far...
(1) roadmaps
I remember my first programming experiments in Pascal and Assembler (I'm still frightened) as a high school student. Back then, there was some documentation of the languages, but since the Internet was not as fast and ubiquitous as it is now, I mostly relied on books about programming and specific languages. Programming in Unity now feels decisively different, since most solutions to taks I want to accomplish or problems I encounter can be found online. This doesn't mean that programming becomes copy-paste really, since most of the time the solution to a problem needs to be adapted to specific need. It does, however, mean that all necessary information is never much more than a click away if you know what you're looking for. What is more, Unity (and other development environments) offer tutorials for their most basic functions, including some scripting. At times, I almost had the feeling that youtube is the new bible for game design (aware that this comparison is somewhat lopsided). So recently, I find myself "learnwatching" C#.
(2) traces
Most problems have been experienced before. Others have had the same ideas, made the same mistakes, or have as little knowledge as I of the things I'm doing. It is not only comforting to find somebody asking the same (simple) questions, it also often leads to the solution, because that somebody or maybe somebody else has put some effort into finding and explaining a solution. I admire and salute the many volunteers who share their knowledge and experience online patiently and often without making fun of the amateur. Humanity is still not completely lost, or at least in forums and do-it-yourself videos it seems that way.
That all said, it probably testifies to my ignorance that I still get stuck from time to time. Risking to sound old-fashioned, I think this is because the short explanatory snippets and specific examples cannot really offer a cure to the lack of systematic knowledge of the matter at hand. I'm very willing to admit that I should probably refresh my programming skills and knowledge on a more fundamental level, starting with a more detailed understanding of object orientation etc.
But then again, I'm not a programmer. The real challenge for me and many other academics who work on digital media, it seems, is whether and how much one can really intervene actively the creative digital sphere without switching professions. This means accepting a patchwork of solutions and rudimentary graphics as sufficient, knowing that this is not ideal. But maybe even these adaptations are not enough? In a way, my current project may thus be an exploration of the boundaries not only of my own capabilities (which are quite limited), but of the academic context out of which I started it, in which practical engagements are rarely a first priority even when we deal with something as practical as digital media.
There are several ways to approach such a project and several dimensions to take care of. In an ideal scenario, I would 1. learn a lot about how to set up such project, 2. plan it carefully, 3. have a good grasp of what I want to do, 4. acquire the necessary programming skills, 5. be part of a team rather than in individual. Since none of the above is really the case, this is a project that develops "en route", meaning that I'm trying to adapt to the obstacles as they appear. Surprisingly, this method is relatively successful (I can say this now, since I don't know the outcome yet) if you are resilient to temporary frustrations. Just to be clear: successful here is meant to say that I am making fair progress so far, considering that I wasn't equipped with the necessary programming and conceptual skills in the beginning. This observation, together with a recent review of Lev Manovich's Software Takes Command (2013) I wrote for the soon to be published Asiascape: Digital Asia 1(3), got me thinking more about the environment and conditions contemporary digital media offer for creative engagements. Based on my current experiences, I'd say that with enough "frontier spirit", many things are possible, because (1) roadmaps are ubiquitous (2) it is likely that somebody was there before you and left directions. Unfortunately, accidents and road blocks are never far...
(1) roadmaps
I remember my first programming experiments in Pascal and Assembler (I'm still frightened) as a high school student. Back then, there was some documentation of the languages, but since the Internet was not as fast and ubiquitous as it is now, I mostly relied on books about programming and specific languages. Programming in Unity now feels decisively different, since most solutions to taks I want to accomplish or problems I encounter can be found online. This doesn't mean that programming becomes copy-paste really, since most of the time the solution to a problem needs to be adapted to specific need. It does, however, mean that all necessary information is never much more than a click away if you know what you're looking for. What is more, Unity (and other development environments) offer tutorials for their most basic functions, including some scripting. At times, I almost had the feeling that youtube is the new bible for game design (aware that this comparison is somewhat lopsided). So recently, I find myself "learnwatching" C#.
(2) traces
Most problems have been experienced before. Others have had the same ideas, made the same mistakes, or have as little knowledge as I of the things I'm doing. It is not only comforting to find somebody asking the same (simple) questions, it also often leads to the solution, because that somebody or maybe somebody else has put some effort into finding and explaining a solution. I admire and salute the many volunteers who share their knowledge and experience online patiently and often without making fun of the amateur. Humanity is still not completely lost, or at least in forums and do-it-yourself videos it seems that way.
That all said, it probably testifies to my ignorance that I still get stuck from time to time. Risking to sound old-fashioned, I think this is because the short explanatory snippets and specific examples cannot really offer a cure to the lack of systematic knowledge of the matter at hand. I'm very willing to admit that I should probably refresh my programming skills and knowledge on a more fundamental level, starting with a more detailed understanding of object orientation etc.
But then again, I'm not a programmer. The real challenge for me and many other academics who work on digital media, it seems, is whether and how much one can really intervene actively the creative digital sphere without switching professions. This means accepting a patchwork of solutions and rudimentary graphics as sufficient, knowing that this is not ideal. But maybe even these adaptations are not enough? In a way, my current project may thus be an exploration of the boundaries not only of my own capabilities (which are quite limited), but of the academic context out of which I started it, in which practical engagements are rarely a first priority even when we deal with something as practical as digital media.
