FEIST

Florian Faller and Adrian Stutz - Filthy Grip
Who are you and how are you involved with FEIST? We're Florian and Adrian, the co-creators of FEIST.


What sparked your game development flame? We studied game design at an art school in the department design and liked that our studies weren't limited to game design but also included art an design with people from other fields of study. We are not so much interested in game design because we like games but rather like it because it encompasses many different fields that can (and should) potentiate each other in the form of a game.


With so many publishers and big studios struggling in today's economy, do you think this is a year where indies and small teams will really shine in terms of innovation and impact in the industry? We believe that Indies are always an important innovative force in all creative industries. They are able to work on smaller projects, take greater risks and therefore innovate more than big studios are able to.

At a time when the big studios struggle and innovate less, they give indies a competitive edge they can use to advance new ideas. It's also the indies and small teams that can push gaming to new grounds - like the many flash game developers that engage people with gaming that don't think of themselves as gamers at all.


Where and when did the concept for FEIST originate? FEIST started out as our final thesis for our Bachelor degree at the Zurich University of the Arts. We decided to form a team in January 2008 with only a very vague idea of what kind of game we wanted to make. We then fleshed out a concept of how we wanted to make the game rather than of what the game should end up to be. We wanted to be flexible in the process and to be led by experimentation. We ended up creating a lot of groundwork that wasn't exposed when we turned the game in for the thesis but we were then able to work on in the time since.


Over the course of development, what was FEIST's most serious issue and how was it resolved? Our biggest issues where with conceptualization of the game mechanics and figuring out which parts worked and which didn't. The experimenting nature of our development process allowed us to make discoveries we didn't anticipate but also meant that we only had an idea of the game that was difficult to express. We needed a lot of time to concretize that idea and to focus the game after all the content we created.


How does the visual art style lend itself to the game and where does it come from? For example, does it express something about the game or affect the gameplay directly? We believe that the sum of all parts that make up a game should be more combined than just the sum of each other. The visual style of FEIST wasn't created isolated from the gameplay but created together at the same time. We wanted to create an attractive world which invites the player to explore and experiment. Suggestion can be more powerful than actually showing something and so we took the idea of a hazy shadow/puppet theater as inspiration for the visual design.

In the beginning we also used a lot of independent animation clips and illustration magazines as inspiration.


Does the title stand for anything, or is the all-caps an aesthetic choice? Feist is actually a German word meaning fat, brazen or cheeky. We liked that meaning and also found that the word looked more crude when written in all-caps, looking a bit like it could have been put together with planks.


What's one thing you did wrong that you feel could have been avoided? Looking back, the development process could have been a lot shorter, of course, if we'd knew exactly where we were going. But it wasn't the aim of our project to most quickly reach a predetermined goal but rather to experiment and to react to our findings. In that regard the experience was really valuable and there's nothing that we feel should be avoided if we did the project a second time.


How long was FEIST in development? How much development time remains? We started conceptualization in January 2008 and worked on FEIST until graduation at the end of March 2008. We've been working on it off an on since then, investing about the same amount of time again. We hope to finish the game sometime this year.


What was used to make the game and what tools aided in development? We are using Unity3D as our game engine and Cinema4D / Photoshop for the Artwork. Unity, with its modular structure and encouragement to write reusable code was a great fit for our project and we found that it was much easier to create good looking visuals with Unity than with other engines we had used.


What was the most important lesson you learned during development of this game? You can always try to brute-force a result but if it doesn't work out, the result will be suboptimal. There's often a better way to achieve something similar with a lot less effort. And sometimes your findings can even lend themselves to something great that you didn't anticipate at the beginning.


What's the main thing you think makes your game fun? We want to make a game that has an appeal beyond regular gamers. We studied at an art university and found that there are not many games that were attractive for the people we worked with. We wanted to create a game that would be appealing to those people and other non-gamers we know. FEIST doesn't feature a clear-cut goal or a stats-loaded interface but rather wants to leave room for the player to explore the game himself. We want to create a game that leaves room for the unexpected and therefore invites an explorative and experimenting gameplay. People who look for a challenge and a high-score based game will not find that in FEIST. Others who want to explore a new world and are open look for their own way through FEIST will hopefully have a great time.


Is there anything about FEIST that you would like to reveal to other developers? We didn't do any conceptual sketches for FEIST but instead sketched the game directly in the engine. That took more time than the traditional approach but allowed us to to find out what works best based on it's final outcome. When doing paper sketches first, they often end up looking good on paper but then translate badly to the game, especially if they're adapted with too much respect for the draft. Huge parts of FEIST's look are due to the fact that we were able to discover what the engine is good at and to turn that into striking visuals.


What's next for you? We want to finish and release FEIST next. We don't know yet what we'll be doing after that and are open to any opportunity that might open up.



IncrediBots

Ryan Clark - Grubby Games
Who are you and how are you involved with IncrediBots? I'm Ryan Clark, and I am the designer of IncrediBots.


What sparked your game development flame? When I was very young, my family had an "Intellivision" and an Apple IIe computer. Some favourite games were Microsurgeon, Frog Bog, Spy Hunter, Karateka, and Below the Root. I played games as often as my parents would allow me to!

I think I was around 6 years old when I started learning to program on our Apple IIe. My Dad helped me, and I copied a lot of code line- by-line from books and magazines! My friend (and now co-worker) Mike Lee would sometimes read the code out loud while I typed it in


Where and when did the concept for IncrediBots originate? The idea for IncrediBots actually came to me while I was investigating physics libraries for another (cancelled) project. During my search I came across this website.

I had a ton fun driving that little tank around, but I was left wanting more! I wanted tanks with arms and hands, I wanted space ships, I wanted walking machines... I wanted IncrediBots! And so, with the help of the amazing Box2D physics library, the game was born.


Over the course of development, what was IncrediBots's most serious issue and how was it resolved? Our biggest problem has always been dealing with traffic. We have administered databases before, but never under such heavy loads! We tried our best, switching from a small server, to medium, to large, but it wasn't enough. We aren't DB admin pros, by any stretch of the imagination.

So, after many outages and angry fans, we finally migrated our database to Amazon's scalable "SimpleDB". We've had no problems since making the switch! And IncrediBots players are now much happier


What's one thing you did wrong that you feel could have been avoided? I'm not sure if it could have been avoided, but when we introduced a few "pay-to-use" premium features, we had quite a backlash from the community. But without the revenue from those features, there's no way we could afford our server costs, and the costs of ongoing development, so I think it was definitely a necessary step.


How long was IncrediBots in development? How much development time remains? I think it was about 7 months from start until v1.0. The game is now "complete", but we hope to continue updating it via sequels.


What was used to make the game and what tools aided in development? The game was made with Flash AS3. We used Flex Builder, which made things quite a bit easier. And, as mentioned before, the game's physics are based on the open source Box2D physics library


What's the main thing you think makes your game fun? The players themselves. On its own, IncrediBots isn't really a game... it's just a tool. It's the imaginations of our community of players that make IncrediBots great! Just take a look at some of the "featured" robots and replays within the game and you'll see what I mean.


Is there anything about IncrediBots that you would like to reveal to other developers? Just that Box2D is an amazing library (it is also used by IGF winner "Crayon Physics Deluxe"), and that Amazon's various web services are very useful if you're expecting a lot of traffic


What's next for you? IncrediBots 2, then 3, and all the way up to infinity, we hope!



Snapshot

Kyle Pulver - SnapshotGame.com
Who are you and how are you involved with Snapshot? I'm Kyle Pulver, and currently I'm half of Snapshot. So far I've worked on the game design with my partner Peter Jones, and I programmed and built the current prototype version of the game.


What sparked your game development flame? Pete and I had to work on a project for our big Senior Thesis presentation at Clarkson University. We decided that our project would be a prototype or a proof of concept game demo.

Our specific idea of doing Snapshot didn't come until a week or two after. I seem to always have a game development flame burning, and Pete has a pretty strong passion for games as well, so we decided to put those two elements to work and get credit for them.


Where and when did the concept for Snapshot originate? Pete came to me in a Biology class where he told me about this crazy dream he had where he was getting chased by a monster and he had a disposable camera for some reason. When he took a picture of the monster, it was gone as if it disappeared into the camera. We spent the next hour in Biology sketching up the initial designs of the game, and got to work immediately after.


Over the course of development, what was Snapshot's most serious issue and how was it resolved? The game is pretty early along in development, so we haven't run into any big issues yet. The one thing we struggled with for awhile though was exactly how the photo mechanic would work and affect the game world. Ideas for having the camera be able to take pictures of anything, even background collision masks, was tossed around but proved to be a challenge not only to put together using the tools we had, but also from a design perspective. Balancing the player's freedom, or perceived freedom, with level designs that contain puzzles with relatively set solutions is always challenging.


What's one thing you did wrong that you feel could have been avoided? The game is pretty early along, so hopefully we're able to spot what we're doing wrong and correct it before we dig ourselves too deep!


How long was Snapshot in development? How much development time remains? Snapshot development so far has been a total of 10 to 12 weeks from our initial ideas to the prototype build we have now. We're seeing what happens at the IGF this year to decide what Snapshot's fate will exactly be, but right now we're hoping to develop the game for about a year and shoot for a release date Spring or Summer of next year.


What was used to make the game and what tools aided in development? The prototype build of the game is made in Multimedia Fusion. Aside from that, we used a handful of Adobe products for most of our art related work.


What's the main thing you think makes your game fun? I think the idea that players will be able to essentially deconstruct and rebuild their environment through the element of photography will make the game fun for a lot of players. Our expanded design of the final game has a lot of elements in it to try to please as many types of players as possible, but for now I think the tight level design and use of the photos in our prototype build is what currently sells it.


Is there anything about Snapshot that you would like to reveal to other developers? Hmm, not yet! We still have awhile to go. We're staying somewhat hush hush about our bigger plans.


What's next for you? Snapshot development! I expect to be working hard on the project for a good year after Game Developers Conference, and I'm pretty excited. I've worked on some games before, but this feels like my first "real" game project. Other than that, I'll probably be teaming up with some other indie developers for small game projects over the course of the year, as well as work on my own personal games in whatever is left of my free time. Games, games, more games. Hopefully I'll also have time to eat and sleep.



Cortex Command

Dan Tabar - Data Realms
Who are you and how are you involved with Cortex Command? My name is Dan "Data" Tabar, and I'm the development director and general evil mastermind of Data Realms. I did all the programming on Cortex Command, save for the GUI library and Mac porting, which were done by Jason Boettcher and Chris Kruger, respectively. I coordinate the different team members who are all spread out over the world, from Sweden to the USA to Argentina. None of the almost dozen team members have ever met in real life - except for myself and the musician Danny Baranowsky, who happens to live in the same city (Phoenix, AZ)


What sparked your game development flame? Playing Commodore 64, Amiga 500, and PC games while growing up in the 90ies. Games gave me some of the most joyful experiences of my childhood. The anticipation to play, and then the immersion into the little worlds that games create gave me delirious bouts of enjoyment as a kid. That sense of wonder over being able to create a small world and everything in it, even its own laws of nature, led me to learn programming and game development on my own. I ordered books from Amazon.com and read what I needed to learn in order to finish the small projects I set out to finish.


Where and when did the concept for Cortex Command originate? Cortex Command started as one of those self-learning projects which I vowed to myself to finish someday. That was about eight years ago, and the game is still being made! The concept of disembodied brains in bunkers stems from my long obsession with cybernetics and where it will take us. Gameplay and perspective-wise, Liero, an old real-time clone of Worms, was the initial inspiration. Graphically, it was Metal Slug.


Over the course of development, what was Cortex Command's most serious issue and how was it resolved? Doing a physics simulation where every pixel in the terrain had its own material properties and acted accordingly, and having larger rigid bodies fly around and sink into the terrain was by far the hardest technical challenge to overcome. Since most physics sims are polygon-based, and Cortex Command required everything to be pixel-based, there wasn't much previous work to refer to when I was programming the engine. I had to use what general info I could find and figure out the rest on my own. Also, every character's footsteps are simulated as physical objects pushing against the ground and therefore generating the forces to move the character forward. Getting this to move smoothly enough to not be very frustrating for the player has been an ongoing challenge as well.

Building all this was a super learning experience with many frustrating times of getting things to behave properly. For these reasons, I'm glad I spent the years making the custom physics engine, but I probably don't want to make another one in my life!


What's one thing you did wrong that you feel could have been avoided? Not taking so damn long to make this? It has been a learning project though, growing organically and sometimes being on the backburner as I had other full time jobs in the "big" (non-indie) game industry.


How long was Cortex Command in development? How much development time remains? The project was started over eight years ago, and has been worked on full time and put the back burner on and off. The last two years it has been a full-time occupation for me though. It has at least another year to go before we have the full campaign and all that content in there. The current version is available to download and play from our website though!


What was used to make the game and what tools aided in development? Microsoft Visual Studio 6.0 to .net 2009 for the programming, Photoshop and Graphics Gale for graphics. A bunch of in-house tool pipeline apps to process the sprites.


What's the main thing you think makes your game fun? The extremely detailed physics simulation adds so much more fun and possibilities than we as designers can deliberately build in or even predict. Even when a player fails to land his drop ship in the game, for example, it usually fails in such a spectacular and fun way that it's rewarding in itself.


Is there anything about Cortex Command that you would like to reveal to other developers? Don't ever give up on a project you're passionate about. Just keep at it and it will see the light of day sometime.


What's next for you? More games, of course!



Musaic Box

Alexander Porechnov - KranX Productions
Who are you and how are you involved with Musaic Box? I'm Alexander Porechnov, original idea author, game designer, programmer and musician of this game. To be honest, I was rather a "jack-of-all-trades", because I should perform some artist work (animation and visual FX), producing, project management...


What sparked your game development flame? I suppose that I'm still a child . All my life I'm trying to make games from everything. There were some kind of tasks named "creative dues" in my school. So, if my task was to make "keyboard typing trainer" then I've done it as a mini-game. There wasn't allowed to play games in computer class-room, but I started creating my own game as homework. So, scholars in a class-room said to teacher "we are beta-testers!", and he allowed them to play my game during the session .

Up to 2003, I programmed business software. So, I wrote unique mini-puzzle game and inserted it as Easter Egg for corporate time-tracking tools. All the employees were happy!

And in early 2003, I was hired by K-D LAB and participated in creating Perimeter, a real-time strategy game based on terraforming. Now I'm working with Kranx Productions. Making games is my profession now .


Where and when did the concept for Musaic Box originate? I have a music degree in piano. And I've played with midi-sequencer a lot and once upon a time, I was looking at my screen with full of channels - the idea of breaking this screenshot into pieces like a jigsaw puzzle came to me.

I can't say I was inspired by a specific game. I have played "Lumines", "Meteos", but I suppose "Musaic Box" is first logic puzzle game with music as a real part of the gameplay, player should both "hear and think".


Over the course of development, what was Musaic Box's most serious issue and how was it resolved? In a middle of production I have had to rewrite code of sound part, which was programmed in playable demo, because of gaps become audible between pieces.

Some players call "Musaic Box" as a "casual sampler", so in other words, I didn't found sound middleware for making precise sampler without low-level programming unfortunately.

I used bars' splitting into odd and even notes in several songs, but focus testing revealed that this is a good idea only for "The Entertainer" and "F?r Elise." Other tunes with this presentation were extremely hard and not fun at all. It was the only time I redesigned finished puzzles.

There was only one issue in game design - I used bars' splitting into odd and even notes in several songs, but focus-test revealed that this is a good idea only for "Entertainer" and "Fur Elise". Other tunes in this presentation were extremely hard and not funny at all. It was the only time I redesigned finished puzzles. However, thus was created "Buffalo Gals" song level with its unique task.


What's one thing you did wrong that you feel could have been avoided? Nothing. "Musaic Box" was completed according to plan, with a very creative mood. However, it was too hard to take so many roles by one person and, in further projects, I hope to avoid at least project management and spend all my time on more creative tasks.


How long was Musaic Box in development? How much development time remains? I created the playable demo by myself in two months. The final game was made in 10 months.

Here screenshot of first created melody puzzle in this demo and how it looks in final game now:




What was used to make the game and what tools aided in development? First of all I was searching for a midi-sequencer with scripting abilities, because I was supposing a huge work on splitting tracks by bars. I've found one and then wrote a sophisticated script. But in production I was splitting tracks by hand, because it was faster.

I used skeletal animations for puppet-musicians in music box windows, so I coded a plug-in for a 3D-Max and animated the musicians myself.


What's the main thing you think makes your game fun? I suppose many people want to compose their own songs, and the gameplay of "Musaic Box" is a process in which people can imagine them as composers. When I gave the demo to my friends, I found that after some time, they forgot the goal and just arranged their own combinations with enthusiasm. So, I put an additional "creations" mode into final game, something like sampler, and now players can produce very funny combinations. Some player said "I have had so much fun, so many smiles at familiar melodies...", so I think well-known tunes are part of fun too. And... music is big part of our life, so I don't surprised when read "Each time I solved a puzzle, I would do a little happy dance in my chair while the music played" or "I have chronic pain... my pain level actually decreased to my amazement! Hurrah for this game and may there be many, many more!".


Is there anything about Musaic Box that you would like to reveal to other developers? I observed some psychological converse effect: first focus-tester, which has a musical background, exclaimed: "OMG, it is polyphony! I'm not a Mozart!". Other players (without musical background) just started to solve without doubts. And both have solved puzzles with ease .

To compose music suitable for creating puzzles, I devised a task for musicians (Vadim Chaliy and me) that sound like: "You should compose a combinatorial music. Music is very repetitive and you should tend to compose as many different bars as you can. And you should compose your own original second voice for every melody if you can". But, to be honest, it wasn't possible in all cases.

So, some melodies appeared to me as aren't suitable for creating interesting puzzles, for example because of many identical bars. But after some experiments - weakness becomes an advantage - puzzles from such tunes had found their own design, where "many pieces transpositions sounds good, but only one fits the music stand form".

As a result there are several different mini-tasks among 27 melodies. For example, task to arrange tune without original sample. Player should find and place a few pieces using geometrical considerations first, then hear the beginning of the tune from already arranged pieces.

Another example, I presented a second voice (not a lead melody) as original sample for "Buffalo Gals". Result was more challenging.

Next, there is a single piano instrument track in "Entertainer", so challenge is like simple putting together splitted tape there. But I've obtained one more channel by splitting every bar into odd and even notes.

In addition, have to say that music dictated geometrical forms in most cases.


What's next for you? I have several new ideas how to create gameplay with music - we have successfully prototyped one of them, and it will be one of the mini-games in our next title.



Dyson

Rudolf Kremers and Alex May - DysonGame.com
Who are you and how are you involved with Dyson? R: My name is Rudolf Kremers, a Dutch game developer living in the UK, and I am the design person although I take on other tasks as well when I can. I also design the levels for example and help with some of the audio. Because the game is solely made by Alex and myself, with Brian providing music and sound we end up working in multiple disciplines. (Alex takes the cake in this regard though he is like an indie Leonardo Davinci or something. Homo Ludis Universalis )

A: I'm Alex May, just a guy despite what Rudolf might tell you (he's under hypnosis to be my loyal designer slave ahuahua). I'm the programmer on Dyson. I've done all the art too; it's procedural so you don't get to see my shoddy drawn or pixelled artwork Procedural art is largely mathematics-based, so it's easier for programmers to get going with than traditional art. Rudolf and I regularly discuss the game design too, so I have input on that. Likewise, Rudolf has input on the art and visuals.


What sparked your game development flame? R: The atari 2600 and arcade cabinets in the late 70s early 80s. I was completely obsessed with these fantastic virtual worlds to play in and always had to get my name in the high score slots. Then my school introduced computer classes (this was in the early 80s) and I made my first game (and the first game programmed at that school) by hacking out a dubious game called "Nuke the Mouse" in PASCAL, an ancient programming language. To this day all my gamemaking efforts are fuelled by my childhood obsession with creating imaginary worlds.

A: Apparently I was walking past a computer shop with my dad when I was 5, looked in at the Commodore VIC-20 in the window and was mesmerised. I always typed in listings from magazines, and dabbled in programming on every machine I had until I finally got into it properly on the PC during my time at university. Essentially, I've always been into it.


Where and when did the concept for Dyson originate? R: It was a number of things happily coinciding in the TIGSource procedural game competition. I have been obsessed with certain aspects of the work of Freeman Dyson and John von Neuman, specifically the concept of Dyson Trees and Astro Chicken. They cover subjects like terraforming, space exploration, and self-replicating robots and to me are endlessly fascinating. Alex was already looking into procedural generation for his own game Deadrock and the competition was therefore absolutely perfect for us as a collaborative project. (We blogged the background of the game in more detail here)

A: Procedural content is a pretty vast subject and we tried to apply it to as many aspects of the game as possible to keep in with the competition theme. The visuals of the game came from wanting to do a vector-style game in the retro style, which was an easy way to get content in there without having an artist on board, but being sick of the usual glowy-vector-on-a-black-background stuff you see in so many games. So I decided to invert the palette, and took inspiration from games like flOw and Blueberry Garden to make the game look different to other games. I was also greatly inspired by a game called Circle, which is still in development, and jph wacheski's brainTooth.


Over the course of development, what was Dyson's most serious issue and how was it resolved? A: During the original competition it was the fact we'd both grossly underestimated the amount of time we had, or overestimated the amount we could achieve, or (most likely) simply not estimated at all. I'd spent far too long on graphics and tree code, for instance. In the end we had to rush to get an actual game from what we had.

R: Yep Alex is right, although it was mostly me overdesigning things full of enthusiasm but not tempered by scheduling prowess :-) Dyson is all about minimalism, getting the most out of the least amount of mechanics, and we often have to hack at the ideas until we are left with something that fits the theme. We tend to solve this by abstracting what it that we want from the game and re-applying those goals brutally to proposed designs. They can almost always be simplified.


What's one thing you did wrong that you feel could have been avoided? A: Aside from timing, which is definitely the biggest thing and something we work very hard to avoid mistakes with now, for me I guess one big thing would be bad organisation of game data. It's still a mess and it results from having rushed the initial game. Next time it would make more sense to make some time for planning out data and logic a little instead of ploughing headfirst into the mud and trying to force a trough through the field

R: I made level2 of the game in version 1.08 ROCKHARD. Which is somewhat off-putting for a game with such a gentle atmosphere. Having said that, most of the levels were done in a day and a half so I don't feel too guilty.

A: Another example of our collective silly-timing silliness.


How long was Dyson in development? How much development time remains? A: Original time to get a game out was one month, the duration of the competition. That was in May 2008. Since then we put in a bunch of time to get the game out to the IGF in November 2008. Now in Feb we still have about 6 months of part-time work to get the game into a state where we'd be happy to sell it.

R: It isn't always easy to grasp the time needed or spent on the game as we both have other professional responsibilities. I do sometimes wonder what we can achieve if we were able to work on the game fultime.


What was used to make the game and what tools aided in development? R: Word, Notepad, Soundforge and the intarwebs. What really makes the difference though is the great tools that Alex has provided within the framework of the game. Fantastic graphs and variable tweaking at my fingertips means that I can iterate changes really fast which is essential.

A: Visual Studio Express is the IDE used. We used a bunch of open-source libraries to make this work - SDL, OpenGL, LibPNG, LibVorbis, and bindings to C# (SDL.NET, Tao Framework). The game itself is built on a C# game library a couple of friends and I have been developing for a couple of years now.


What's the main thing you think makes your game fun? R: It is a few things working in tandem I think, but the basis of most of the fun in the game for me personally is the addictive quality of combining exploration with conquest. There is a certain Pokemon like quality to the game where you pitch you creatures against the opponent's ones and that the winner of a fight gets rewarded with another asteroid for their empire. The levels may take a while to play, but there is a whole lot of of short term rewarding going on. Plus: growing trees that grow creatures that you can send flying about is fun in its own right. :-)

A: I think scale has a big influence on the game - the number of seedlings flitting around and being able to observe them from a great distance is quite engaging.


Is there anything about Dyson that you would like to reveal to other developers? R: Dyson is the least commercially motivated game I have ever worked on yet it is also one of the most successful ones (relatively speaking) Certainly in artistic terms. I think there is a point somewhere in there....

A: Watch Kyle Gabler's Global Game Jam keynote. I think there's a lot of value in there relevant to what we did with Dyson. The core design concept behind Dyson is very simple, but the game itself can be quite compelling. Also, let the computer fill in the gaps for you, see Introversion evangelising procedural content here


What's next for you? R: Dyson II: The DYSONING! (Joke) Next is to make Dyson in the best game it can be for its commercial release later this year. We are hard at work on this and have some really exciting features to add.

A: "Dyson Harder" is gonna rock your faces off next fall!!! Next up I'd really like to work with Rudolf again to make another interesting, different game. Personally, I'd like to examine exploration games. I'd also like to continue work on my procedural zombie survival game Deadrock. I guess in my spare spare time, as that's probably a less commercially-viable game - it depends on whether we can make going full-time indie a reality.



Machinarium

Jakub Dvorsky - Amanita Design
Who are you and how are you involved with Machinarium? I'm Jakub Dvorsky, founder of Amanita Design studio and designer and director of our upcoming game.


What sparked your game development flame? I grew up on early 8bit computer games, I owned Atari 800XE and later I had my first PC 386. Of course I loved to play all that great games. Later on grammar school I started doing my own games with some schoolmates and we were enjoying it a lot. My first game called Asmodeus was published 12 years ago.


Where and when did the concept for Machinarium originate? My interest in robots come from old science fiction books and films (Stanislav Lem, Jules Verne, Karel Capek, Ray Bradbury, Stanley Kubrick, Karel Zeman ...), I started to think about using this theme in some illustrations, film or game a long time ago but the definitive vision of Machinarium world started to form 2 years ago.


Over the course of development, what was Machinarium's most serious issue and how was it resolved? As this game is our first full-length game there's of course many challenges. The most serious issue for me is puzzle design. I know it wasn't the strongest part of our previous games so I wanted to improve the puzzles significantly. Everything is more logical and the player really has to think about the puzzle before he is able to solve it. No more brainless clicking:)


What's one thing you did wrong that you feel could have been avoided? Next time I should discuss everything with programmer before I finalize the level designs. We had some unnecessary troubles which could have been avoided easily.


How long was Machinarium in development? How much development time remains? We have been working on it for 2 years and about half a year still remains.


What was used to make the game and what tools aided in development? Our tools are pencils and paper, digital camera, tablets, PC's, Photoshop, Flash, Rebol, sound recorder, some musical instruments and who knows what else.


What's the main thing you think makes your game fun? I believe it's a couple of things: Exceptional 2D hand-drawn graphics and cut-out animations, original soundtrack and sounds, logical puzzles which are funny and also good for brain training (especially for children and seniors), funny characters and humorous story, peaceful gameplay without stress and shooting.


Is there anything about Machinarium that you would like to reveal to other developers? Well, it's really a lot of hard work:)


What's next for you? At the moment we are focused only on Machinarium so we don't think about any future projects yet, but we'd like to continue in producing independent games - that's for sure.



CarneyVale Showtime

Bruce Chia - Singapore-MIT Gambit Game Lab
Who are you and how are you involved with CarneyVale Showtime? I'm Bruce Chia and I was the lead programmer for the game.


What sparked your game development flame? I started playing video games from a very young age and they had always seemed very magical to me as I did not understand how they worked. During my teenage years, I started to take interest in programming and decided to venture into the field that some of my friends called "Martian language". In the beginning stages, I still could not see how programming could bring to life such a complex thing as a game and being a logical person, it spurred my interest to unravel the mystery of the magic behind games. When I finally got a better understanding of how a game works through some experiments in Flash, I felt extremely satisfied by the experience of having the computer do as I commanded through the programming languages and decided to pursue this onwards. Till today, I still have much to learn about games and I believe that there will not be a day where games will have lost their magic; There will always be new things to learn and play with!


Where and when did the concept for CarneyVale Showtime originate? The theme of CarneyVale: Showtime was based on a previous game that was developed under the Gambit internship in the summer of 2007, called Wiip. In that game, you played as a Ringmaster, trying to tame your animals by whipping them. We decided to develop this game early 2008 in the same wacky circus world, but instead based on acrobatics. This led us to the idea of using a ragdoll as the acrobatic main character named Slinky and we tried out various ways to make the ragdoll perform tricks and stunts including gaining points by crashing into the surrounding environment. However, the original idea did not turn out to be very fun and we decided to invert the controls so that the player controls the environment instead of directly controlling Slinky.


Over the course of development, what was CarneyVale Showtime's most serious issue and how was it resolved? The most serious issue was the game design. As mentioned previously, the game goal was set around the theme of failing and you had to crash the ragdoll into as many things as possible to fail spectacularly and gain more points. This was partially inspired by Burnout: Paradise's Showtime mode. However, we found through testing that this idea was a failure itself and it was not intuitive for players to pick up and play. In order to resolve this, we had a few very long meetings to analyze what went right what went wrong. We brainstormed many ideas on how to improve the game without too much sacrifice of work. We originally had a hard time settling on a idea as we were scared that we were going to go downhill with the game but when we finally came up with the environment control concept, everything else came into place naturally. We then had to throw out a lot of assets and code to reconfigure the game to the new goals which you see in the game now, but the sacrifice proved very much worthwhile to do.


What's one thing you did wrong that you feel could have been avoided? That would probably have to be a lack foresight for localization. The game right now is probably going to be a pain to localize as there are many assets that have to be changed if we wanted to localize this game to another language. The text strings were also set all over the code so there would not be a single easy location to change if we needed to translate the text. Furthermore, our map editor allows for people to set a name to the map and we did not account for that to be done in any language. All these could have been avoided if we had better foresight on the game, but they are good lessons learned nonetheless.


How long was CarneyVale Showtime in development? How much development time remains? The game was in development originally for 4 month for the Dream-Build-Play 2008 entry. We have since then stopped development on it, only working a week or two to publish it on the Xbox Live Community Games. This is because we're currently working on another title now. We're considering porting the game to other platforms and also developing the game further. At the moment, we aren't sure how much time remains but an rough estimate would be between half a year to a year.


What was used to make the game and what tools aided in development? The game was made completely in Microsoft XNA Game Studio 3.0. The only engine we made use of in the game was the Farseer Physics engine. In terms of tools, the art was mostly done in Adobe Photoshop CS3; the code in Microsoft Visual C# Express 2008. We created our on tools in C#, including a ragdoll editor tool for the artist to set the poses, a math generator tool for optimization purposes and of course the map editor, which we included in the game.


What's the main thing you think makes your game fun? I think the main thing is the ragdoll. It never fails to amuse people when it gets thrown into awkward places and does really funny poses in the air. I think people enjoy the sensation of giving life to a lifeless doll through their actions with the environment.


Is there anything about CarneyVale Showtime that you would like to reveal to other developers? In our initial stages with playing the ragdoll, it used to be the case that it would be able to fly so fast that it could actually get say an arm stuck across a thin brick. This was because there is no continuous collision going on and the ragdoll's physical properties were not set right. In some occasions, a brick would even get stuck in between the head and the body and it looked really awkward that we didn't know whether to laugh or feel sorry.


What's next for you? Right now, I'm looking forward to going to GDC for the first time. I'm also graduating from my local university this summer and will look forward to working on more great games after that! For Gambit, we're currently working on a new PC title and also planning further development for CarneyVale Showtime.



Coil

Edmund McMillen - From The Depths
Who are you and how are you involved with Coil? Edmund McMillen, I'm the designer and artist for Coil.


What sparked your game development flame? Coil was inspired by the death of my father and my terminally ill grandmother, but that sounds like a weird response to that question. The prettier answer would probably be, Coil was inspired by the loss of a loved one, I was confused about the feelings I had about the situation and the idea of death so I wrote about my feelings in game form.


Where and when did the concept for Coil originate? Coil's design started in mid 07 after I finished working on Triachnid. I was intrigued by the amount of emotion I was able to express through Triachnid's design and wanted to see if I could design a more abstract and autobiographical piece that played around with those emotional aspects.


Over the course of development, what was Coil's most serious issue and how was it resolved? The only serious issue we ran into was caused by Florian's mandatory army duty, the game was put on hold for 6 months. Coming back to it was a little difficult because my feeling had changed slightly, but I was able to take it in another direction and finish it shortly after Florian came back.


What's one thing you did wrong that you feel could have been avoided? The Title screen puzzle was something I thought was extremely important, but I didn't put into consideration that a player might solve it without knowing how they had done it or even realize it was a puzzle. I used this "movement puzzle" between each level break and I found that a lot of people assumed they were loading screens. If I would have tested the game more I could have found a way around this, but I was too eager to get the game into the hands of the public. The problem wasn't ever fixed because I'm lazy.


How long was Coil in development? How much development time remains? Not counting the break we had to take, Coil took about 2 and a half months to finish. Coil is done.


What was used to make the game and what tools aided in development? Flash.


What's the main thing you think makes your game fun? I can't say that everyone would find Coil "fun" but I think a lot of the lack of hand holding and emotional theme create a magical non-game experience that can be very enjoyable. Personally I think the best thing about Coil is the fact that it not only gets you thinking and questioning things but also feeling things that wouldn't normally be felt by playing a video game.


Is there anything about Coil that you would like to reveal to other developers? There was an 8th phase that was cut from the game due to self imposed time constraints, it was a 2nd conception stage that came before the final phase of the game, the stage was very graphic... its too bad I couldn't add it in time, but 7 feels like a better number anyway.


What's next for you? I'll be working on my 3rd a