IGF 2010: Krystian Majewski
game trauma development games photos time first
The IGF Awards take place on the evening of the third day of Game Developers Conference, and are a major celebration of the best in indie gaming, with thousands watching the award presentation before the Game Developer's Choice Awards are presented. The 2009 IGF Awards, including custom interstitials from Mega64, are available for online viewing. All GDC visitors can attend the awards. [From IGF about page]
TRAUMA tells a story of a young woman who survives a car accident. Recovering at the hospital, she has dreams that shed light on different aspects of her identity - such as the way she deals with the loss of her parents. TRAUMA lets you experience those dreams in an interactive way, reminiscent of Point-and-Click Adventure Games. It builds upon this established formula by introducing agesture-based interface, real-time 3D technology for dynamic level layouts, unique photographic visuals and a level design philosophy that focuses on creating a rich experience rather than an elaborate puzzle challenge. Combined with the unconventional story, it is aimed to be a compact and deep game for a literate and mature audience. [From IGF info page]
Interview with Krystian Majewski
Who are you and how are you involved with TRAUMA?
I'm Krystian Majewski, a designer from Cologne. I did pretty much everything for TRAUMA. The only exceptions being music and sound effects, which were done by my colleague Martin Straka.
How did you become interested in game development?
I've been developing games since the age of 10 or so. Playing my first games on an Atari 130XE I was always very eager to improve them somehow.
So I basically sat down, read a couple of books my parents bought me and learned how to program by myself. I made a lot of cool experiments but rarely finished games. It continued like that through high school.
Afterwards I had a short peek into the industry but I decided to study design pretty soon.
How and when did the concept for TRAUMA originate?
TRAUMA was originated as part of my final thesis. The initial idea was to create an autobiographical adventure game using photos. I went on to do a comprehensive analysis of the history of adventure games and the current state of related popular genres. Based on that I took elements from different sources to construct a new type of adventure game. During that process, the game changed many times but the result is still faithful to the initial intention.
Was the process a constant iteration of ideas or did you ever hit walls that forced you to say "this just won't work" and force you to back up a few steps?
Oh, I hit plenty of walls. Game development often feels like steering a car out of a parking garage blindfolded.
One particular wall I remember quite well was the first level I started creating. I went out for a long photo session and came back with over 300 photos. And I thought wasn't even quite finished with that location yet, I had to quit early because of rain. But I began constructing a level out of them. It took a considerable amount of time. After playtesting it became evident that the level was just way too large. Players got lost quickly and took too long. They missed a lot. The level lacked focus. I ended up throwing away 250 photos to tighten things up. It seems like a waste but this lesson was a quite vital part of the process.
Over the course of development, what was TRAUMA's most serious issue and how was it resolved?
Surprisingly, there were not many technical issues. The game is pretty simple. The most serious problem was the frame rate but I was pleasantly surprised when I found out that it's simply because my development workstation is outdated.
I think I had the most difficulties with creating the assets. Using photos you just have a lot less control about the layout, content and dramaturgy of levels.
What were some of the issues with obtaining the photos? Did you need to research photography techniques? What about getting permission to photograph certain areas?
Obtaining the photos was one of the most difficult challenges.
A big part of the development was figuring out how to shoot the photos and how to construct the levels out of them. I did a lot of experiments there. For example, one of the things I experimented with were spherical panoramas. You need to stitch a series of photos together to get them.
Shooting at night means you need to use a tripod and take your time due to long exposure times. So I went ahead and even built a robotic tripod with LEGO Mindstorms to shoot panoramas automatically. It worked but while the photography was awesome, the panoramas didn't provide interesting interaction. At least nothing you haven't seen already in other titles. So I had to abandon that experiment.
Permission was a problem too. I remember my first shooting was at a subway station. I was immediately approached by the ticket inspectors. They asked me to leave when I told them I had no permission. That was quite demotivating. At this point I was still experimenting so I didn't want to go through all of the hassle of getting a permission just to find out that the location is of no use for me anyway. So I started focusing on more deserted locations where the chances of meeting people, who ask for permissions are lower.
But then there is still the problem of finding the right location. I was looking for places that are visually striking. It's one thing to find ONE interesting shot like in movies or in photography. Finding a place that would be still interesting when you look at it from different perspectives introduces a whole new level of difficulty. And the place doesn't only need to look exciting, it also has to work spatially as a level. So you end up doing level design for a video game in the middle of the night while trespassing at some abandoned creepy factory.
What's one thing you did wrong (individually or as a team)that you feel could have been avoided? How?
One night I was out on an abandoned railway bridge doing some scouting. I accidentally stepped in a puddle of diarrhea. That made me wish I had at least some sturdy footwear. It was also disgusting and scary at the same time.
Other then that, the only recurring problem was my tendency to hopelessly under-estimate the time required to hit my milestones. But on the other hand, maybe I wouldn't have started the project in the first place if I was more realistic about how much work it is.
If there was one thing you could look back on during development and say "that was really cool" - what was it and why?
The development involved a lot of little victories, it's hard to tell by now. To pick one: it blew me away how quickly I was able to put together a first working prototype. Starting from scratch I was navigating through my first batch of photos within a day. Of course, that initial progress is always deceiving, but it ignites a tremendous amount of enthusiasm for the project.
How long has TRAUMA been in development? How much development time remains?
I wrote the first abstract in winter 2007. I began work in spring 2008. After my thesis was finished in summer 2008, I went on hiatus periodically to get some other projects done. I'm estimating something about 1,5 years of development right now.
There is only very little left to do. I ought to be able to present a complete version at this year's GDC.
What was used to make the game and what tools aided in development?
I used only Flash CS3 for coding. For graphics and animation I used a wide variety of different programs. The photos were shot with an old Sony F-717.
What resources (eg: Websites/Books/etc) do you use to aid development on your game?
As for the technical part, I already had some experience in Flash development so I didn't need anything except Google to look up some syntax and examples.
I read a lot theory to flesh out the concept: "Non-Places" by Marc Augé, "Image of the City" by Kevin Lynch and the excellent "Space Time Play".
Otherwise, the project is the culmination of my design studies at Köln International School of Design and the years of my personal research into computer games.
What's the main thing you think makes your game fun?
I don't think the word 'fun' applies to TRAUMA. Actually, TRAUMA is very un-fun. But this was one of the things I wanted to challenge. We already take it for granted that other media don't have to be fun in order to be interesting. I don't think games are different. One of the IGF Judges called TRAUMA "engrossing and captivating" instead. I was very pleased with that.
I believe the main thing that defines TRAUMA's experience are the environments and the narrative embedded in them. They create a unique atmosphere quite difficult to put into words. It's gloomy,mysterious and somber but also melancholic and relaxing.
Besides the IGF, what else have you done to get your game before players? Whats worked the best?
Since the game is not out yet, I didn't do too much to create any sort of hype. I often find that my own motivation dwindles when I'm confronted with other people's expectations. That phenomenon is actually even one of the topics of the game.
But one of the things that I believe brought in a lot of attention was simply the fact that I used photos. That alone made quite a few people interested in the project, especially the kind of people that wouldn't be interested in games otherwise. Of course, that was the reason I used photos in the first place. But it is affirming to see that it actually worked.
Is there anything about TRAUMA that you would like to reveal to other developers?
I would like to encourage other developers to be more daring about their projects but also to be more responsible. For me TRAUMA was an experiment to try both. The fact that I was successful with it is gratifying and inspiring. I think we have an intelligent audience that will accept a more mature approach to games. We need to seek them out.
How does "mature" relate to this game? Is it in the content? The mechanics?
It's both. Content-wise, I think we should seek out ways on how to address scenarios that are closer to life. If we keep on slaying dragons and flying spaceships, games will have a hard time being recognized as something more than trivial escapism.
And while the mechanics in TRAUMA may be nothing exceptional, they follow a certain general strategy. TRAUMA is not a game for the obsessive and time-consuming exploitation of minute, technical details in a comprehensive system of complicated rules to overcome an almost endless series of difficult but meaningless challenges. Many games seem to follow this strategy and while I myself enjoy losing myself in such tasks, I can totally understand how most people aren't prepared to invest that much in a single activity. This is especially true if there are no insights to be gained from doing so.
TRAUMA is not wasting the player's time like this. It requires some patience but respects that this patience is not infinite. It respects that the audience may have little time and more important things to do than playing games all day long. The mechanics are simple. The challenges are easy. And even though experience is over quickly, the time is well spent.
How did you feel about the judges feedback for your game?
I thought the feedback was excellent. It was very detailed, well thought-out and carefully worded. It wasn't just all positive either.
The critique helped me with some important decisions about how to finalize the game.
What's next for you?
I just want to finish the game and get people to play it. I'm working on this too long now. I want to finally hear from players what it means to them.
Based on your experiences to date, what advice would you give to other game developers who aspire to be in the IGF Finals?
I think you need to do two things:
First, you need to do something different to attract attention. Look at all the other entries from previous years and go in a direction that is as far form anything you've seen as possible. Try to come up with something that stands out even at first sight. If it doesn't generate intriguing screenshots, you will have a hard time.
But then you need to live up to the expectations. You need to develop a reason for you game to exist in the first place. Come up with something people will take away form playing your game and reverse-engineer the actual game from there.