[Starkly-illustrated, physics-driven indie platformer Feist has generated a lot of attention, and in this new Eric Caoili-penned interview, creators Adrian Stutz and Florian Faller explain their thoughts and process.]

The sidescrolling platformer Feist quickly struck up attention in the game development community when screenshots, video, and a temporarily-available demo surfaced last year. Its striking silhouetted visual style and physics-driven gameplay immediately stand out.

Developed by Adrian Stutz and Florian Faller, two graduates of the Zurich University of Arts' game design program who started the project as a senior thesis, Feist was a Student Showcase winner and Excellence in Visual Arts nominee at this year's Independent Games Festival.

In this interview, Stutz and Faller explain the driving ideas behind the game, discuss its development process, and reflect on the state of the larger game industry:

What development tools did you use?

Florian Faller & Adrian Stutz: We used Unity as our game engine, which was also great for prototyping and building levels. For content creation, we also used Cinema 4D for modeling and Photoshop for texturing.

Can you explain Feist's title? The game doesn't see to have much to do with any "belligerent mongrel dogs" of any sort.

FF & AS: "Feist" is a seldom used German word meaning cheeky, brazen and fat. We think that all of those meanings fit our game. There's also the English word "feisty," which we also found fitting. We didn't think of any dogs when we came up with the title.

Why did you decide to present Feist with silhouettes?

FF & AS: Suggestion can be more powerful than spelling something out. We wanted to take advantage of that and create a game that uses suggestion to create a striking image. And because we love classic graphic design, we were looking for a way to find some kind of graphical abstraction. So we took the idea of a hazy shadow or puppet theater as inspiration for the visual design.

That also lent itself to mix 3D and 2D objects and to add and remove depth to the visuals during the game. Feist is actually not a pure silhouette game. Depending on the lighting of a scene depth is added to the front, especially visible on the ground.

What exactly is the creature in Feist? And why does it always seem to have a smokey trail behind it?

FF & AS: The identity of the lead creature in Feist is up to the player to establish. We deliberately only want to leave its identity open and avoid any clear associations. Though there were specific traits the we wanted to bring out clearly, like the fragility of the creature to bring the player to care about it and to feed it.

The trail pronounces the movement of the player and encourages to try to move gracefully. That almost turns the creature into a brush and allows the player to paints figures in the air while playing.

The controls and movement are a bit "floaty" -- was this a conscious design decision?

FF & AS: We wanted the movement to be rewarding by itself. The player cannot fall down in pits or be instantly killed by touching an enemy. Instead, we wanted to create a movement that allows the player to get into a flow. This floaty movement, with some training, allows to pass through the levels smoothly and we liked how that made it fun just to jump from tree to tree. This kind of blurry control also matches the visuals and game mechanics -- Feist is an analog game, in a sense.

Additionally, the player is another physics object, like any other object or NPC in the game. It's controlled by applying forces and handled by the physics engine. The player is physically part of the world and equally subject to inertia and friction. This also contributed to the floaty movement because the input doesn't immediately take effect on the player's movement.

What specifically influenced your choices behind the designs for the enemies? The mountain and forest setting? The background colors?

FF & AS: We didn't do any paper drafts but instead did all our drafts directly in the engine itself. We weren't influenced by what looked good on paper but rather could directly see what would work in the engine and the final game.

Finding a look and setting for the world consisted of watching lots of independent animation clips and looking at contemporary character design, but also of experimenting with the engine and seeing what interesting things we could draw from it.

As for the mountain and forest settings, we wanted to create a world that would be discomforting and appealing at the same time. The world should express the dangerous unknown but at the same time make the player to want to explore it. From a cultural and historical point of view, both forests and mountains have both those sides as in being part of nature and beautiful but at the same time home to unknown and dangerous inhabitants.

You've mentioned that you'd hoped to create dynamic/emergent gameplay with Feist -- how so?

FF & AS: There are only a few objects in Feist that only serve a specific purpose. We rather created objects that can be used differently depending on the situation. Stones, for example, can be used as weapon, as a weight or to loosen objects not reachable otherwise. Those functions are also not limited to the player but also open to the enemies, they can theoretically use objects the same way as the player. All objects in Feist are treated equally; the same rules apply to all of them.

The modularity of the Unity engine was a big help in that regard, and we also created a modular object-oriented groundwork, which is very open for additional objects or creatures. The player and the enemies share most of the code, which means that implementing something for the player makes the function also easily accessible for the enemies.

We tried to create the groundwork of Feist in a way that allows games with different kinds of goals to be integrated. We wanted to create more of world that an specific kind of game, where the inhabitants and object could interact with each other and be a stage for a game to work in. All that, the physics and the autonomous NPCs should all contribute to a dynamic gameplay.

So in a sense Feist is more like narrative toy than a game. In contrast to other platformers Feist doesn't encourage the player to go through the level quickly or to hunt points. Instead, it wants the player to explore and to linger in the world. We believe that it therefore has a good replayability.

As a result, Feist can become a bit chaotic at times and we're trying to find the balance between openness and directed gameplay. It's a much fun to create new elements, put them into the game world and to see what they create for possibilities and how they change the game. It's like a working in a laboratory which sometimes collapses or explodes in your face.

What were some of the elements that you experimented with but didn't make it into the final game?

FF & AS: To take an example: We originally wanted to add eating as a more general part of the game, where the player could not only eat the food himself but feed it to the enemies, which would then mutate and change behavior. It turned out that the limited scope of the camera and the mutations didn't work well together. The player usually already moved on before the mutation took place and it would seem just as if a new enemy appeared out of nowhere. We liked the idea conceptually but it turned out to be badly comprehensible for the player.

You've mentioned that you designed Feist with the intention of attracting casual gamers and even non-gamers. What steps did you take to make the game more appealing to those audiences?

FF & AS: In terms of usability, we decided to use simple controls with only a few control parameters and only a very flat and minimal menu structure. That is because we believe that people who don't play regularly don't want to engage with tasks not directly inherent to the game, like character selection and customizing, story, or tuning the game rules. Hardcore gamers may like that complexity and control. Other gamers need to be taken in by the game quickly and are deterred by a complex menu structure or a long-winded introduction.

We tried to question a lot of things we have become accustomed to in games and may have their value in terms of tradition and custom. Instead we tried to find out what non-gamers in our surrounding find attractive in games and what is disincentive to them.

We have completely resigned to using an in-game GUI and also to many purely abstract game elements like winning points by collecting items. We also tried to find a look which isn't associated with games and to bring the engine to create a look that would be appealing for non gamers.

If you could start the project over again, what would you do differently?

FF & AS: We started with a very open design process and hope that had a positive effect on the game, though today we would define our concept and goals more precisely. That's also what we have done and how we will continue for finishing the game.

Do you have any plans to expand on the beta released so far? If so, how are you looking to add onto it?

FF & AS: The term "beta" didn't really fit what we released back in September of last year. It contained the groundwork and many elements that will be in the final game but it was also far from feature-complete, as the term would imply. There will be many additional game elements and levels with varying environments in the final game. Many of them are already implemented or will be soon.

We are also working on a simple narrative setting, which should communicate the goals of the game, structure the levels more clearly and motivate the player. However, rather than a story that seems grafted to the game, this should possibly be told in-game and be perceived as a part of the world. Conversely, the story should also be continued in the game itself. That is to say, what happens to creatures and objects in the game should be seen as a continuation of the story.

What do you think of the state of independent game development, and are there any other independent games out that you currently admire?

FF & AS: The game industry wants to expand its target audience. With increasing production cost of big AAA titles and a saturated market they also have to. But apart from maybe the Nintendo Wii, which manages to attract a wider audience with many titles targeted at families and females, many big studios struggle to reach new audiences.

Interestingly, it's especially the indie games that manage to expand their audience. Some of the interdependent games are targeted at the core gamer market, such as Dwarf Fortress, but there are also titles that show it's possible to make games for a wide audience -- Samarost, flOw, Line Rider, etcetera. That's also remarkable because all of those games feature their very own style and are appreciated by many.

The big studios have possibly ogled too long at Hollywood and thought reaching the masses could only be achieved by uniformity. But it is just that uniform identity that deters many people from playing games. The future of the gaming industry can only lie in diversity and the recent focus on independent games makes this clear.

Apart from the games mentioned above, we are also very fond of many other independent games like Crayon Physics, Gesundheit, Fez, World of Goo, or Mount and Blade, just to name a few. Of course we also like good big titles like Half-Life 2.

What have you two been up to since graduating last spring? Has winning the IGF Student Showcase and two Unity awards affected your careers?

AS: I've always had some software projects running and currently I'm trying to make MPlayer OSX the video solution it ought to be. I'm also head of programming for a local anime convention.

FF: I am currently working on a serious game project in the field of rehabilitation. It is a game for a walking therapy that uses a robotic device to help children whose ability to walk has been impaired learn to walk again. I recently did some electronic music for the lovely label interdisco and since last summer I am working at the Zurich University of the Arts.

A&F: As for our career, we are still waiting for a call from Valve.