Auriea Harvey, Michael Samyn - Tale of Tales
Who are you and how are you involved with The Graveyard? We are Auriea Harvey and Michael Samyn. We are the designers, directors and main creators of The Graveyard. We came up with the concept, we modeled and textured the 3D assets and we did all the programming. We were assisted by Laura Raines Smith who animated the protagonist, Kris Force, who produced the sound effects and Gerry De Mol who composed the music.
What sparked your game development flame? We had loved playing Pac Man and Space Invaders for all of our lives. So when we turned 50, we decided it was time to make such games ourselves.
Where and when did the concept for The Graveyard originate? Izegem, a small town in West-Vlaanderen, Belgium.
Over the course of development, what was The Graveyard's most serious issue and how was it resolved? There was too much colour in the game. This was resolved by making everything greyscale. Which turned out to be a good thing because it gave us the idea to pretend that The Graveyard was art.
What's one thing you did wrong that you feel could have been avoided? We forgot to add gameplay. And the avatar moves way too slowly. We should have added the ability for the avatar to jump. Then we could have used the graves as platforms and allowed the player to jump from one to the next. When you would have reached the highest grave, your cane would be upgraded to a butterfly net which could then be used to catch the birds. If you catch 10 birds, the birds would be upgraded into eagles that you could jump one to fly through The Graveyard. This would unlock the multiplayer part of the game in which every player plays an old lady who flies around on an eagle above the cemetery. They would use their butterfly nets to push each other off of the eagle. If you fall and you aim for the bench, you get to try again. But if you miss the bench, your corpse is immediately covered by a grave and you have to force quit the game and reinstall it if you want to play again. To make all of this more exciting, there would not be a quicksave function.
How long was The Graveyard in development? How much development time remains? We worked on The Graveyard for three months. It is finished now, apart from the input of the players, of course. Many lifetimes remaining.
What was used to make the game and what tools aided in development? We imported lots of little people from an underexplored continent and we used whips and chains to encourage them to program the game for us.
Sometimes we also gave them food. But that didn't always work. They died before the game was done. But we released it anyway. This is why it's kind of boring.
What's the main thing you think makes your game fun? The fact that there's so many dead people in them. Other games are inferior because most characters start out being alive. And then the player needs to do a lot of work to make them all dead. The Graveyard starts with a lot of dead and buried people already. So players can get to the fun part immediately without having to do all that work. The one remaining living person, can easily be killed to. By simply paying 5 Dollars for the full version of the game. Call it micro-transactions.
Call it the Korean model. It just works. We're millionaires! Because our games are fun!
Is there anything about The Graveyard that you would like to reveal to other developers? The Graveyard is a strictly rules-based game with a challenging goal that is difficult to achieve. But we market it as a hippy art game in order to sell more copies.
What's next for you? We are considering making a sequel to The Graveyard. This version will be darker, more mature. The old lady will be a real mean bitch and she just doesn't want to go to The Graveyard anymore. She's sick of it all and can't stand all those dead people anymore. But as a player you will show her that it's not that bad once you unlock the ability to turn back time. It's a little bit creepy but it's a really ingenious game mechanic that we maybe shouldn't tell you about since it's so original. Basically you wind back time all the way until the people come out of their graves and then, then you, then it's easy to solve the puzzle! It's very mature and artistic.
Anthony Flack, Alex Amsel - TunaSnax
Who are you and how are you involved with Cletus Clay? Anthony Flack - Project Director, lead designer and lead artist.
Alex Amsel - Project Producer and gameplay programmer.
What sparked your game development flame? Anthony: I owned an Amstrad CPC at a time when everyone else had a Commodore 64. Since I couldn't pirate games like everyone else (I had trouble even finding shops that stocked CPC games, let alone people I could swap games with), I started programming my own ones instead. I'd go into an arcade and spend my two dollars, then go home and hack together some nonsense on the computer that was loosely inspired by what I'd seen. I used to draw up sprites on bits of graph paper and code them in. This was back in the '80s, when games magazines had programming features and code listings in the back. I collected all the feature articles that showed you how to do nifty things like raster splits and fast sprite blitting and speech sampling from the datacassette input, and put them to use making stupid little games. Programming resources were a lot harder to come by in the days before the internet so those magazines were really my only source of information.
Alex: I grew up with the BBC Micro, a somewhat peculiar British 8-bit machine. It wasn't great for games but did spawn the wonderful Elite from David Braben. It was a wonderful machine to learn to program on and games were much more interesting to write than whatever we learned in school. A few years later I persuaded my dad to buy an Amiga because, "it will be educational." Of course, what I actually meant was, "I can play lots of games." The Amiga was inspirational but not just because of some great games; there was no better way to learn to code than to write demo scene effects.
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? Alex: Most publishers are retreating into a world of retail and licenses more than ever before. Some have tried to innovate with mixed success, but the truth is that they overspend on new products then act surprised when they don't usually go on to be a major hit.
Indies can afford to try new things, to grow more organically. Platforms like Xbox LIVE Arcade, WiiWare and PlayStation Network, for all their faults, are still good for commercially minded independents. The large publishers are backing away from them because they don't understand how to make games for these audiences.
Outside of console the PC and web environment will continue to be an amazing area for innovation in 2009.
Anthony: To me, the most vital element of indie game development isn't innovation per se, it's the ability to be idiosyncratic; to express the individual personalities and proclivities of their creators. I think we're now moving beyond the point where game evolution is principally defined by technological advances, it's becoming much more about what you choose to do with the medium. And there are now so many more games to choose from, being blatantly individualistic is a good way to differentiate your games from everybody else's. As well as being a good thing in general.
This is the point in games' evolution where games go off to university, get a funny haircut and start experimenting with drugs and reading philosophy paperbacks. And some of them will get terribly pretentious, but that's part of the process of figuring out what games in the 21st century are supposed to be like. I don't know how the economic situation will impact on any of that, but I feel like that is where we are at, artistically. Indie games will continue to be provocative and challenge our assumptions.
Where and when did the concept for Cletus Clay originate? Anthony: Actually I did create something vaguely similar on the CPC many, many years ago. Well, I say similar, but it wasn't really a proper game - it was just this animated sprite of an old farmer with a shotgun and he was going to be shooting aliens but I never got that far - back in those days I'd just start and stop things on a whim; it didn't really matter since nobody else ever got to see any of it. And then years later, when I was kicking around ideas for my next game, for some reason he came to mind and I just decided to go with it. I guess I still do things on a whim, but these days I try to see them through to completion. It takes forever though... a spur-of-the-moment decision that leads to years of commitment. It could have just as easily been something else. I'm not really a "big concept" designer, for me it's more about the craft.
Over the course of development, what was Cletus Clay's most serious issue and how was it resolved? Alex: Other than the obvious - how to create an action game using stop-frame animation, it's actually been very tricky technically. Anthony wanted to give the visuals some depth so we've spent a lot of time working out how to achieve that without taking away from the gameplay or the photos which are essentially used for all the artwork. Somehow we have to keep the visuals in sync and this has been tremendously difficult, particularly where many background elements are meshed. For example, games use real time shadowing and lighting but we have a combination of this and the shadows naturally found on the model photos.
Where did the idea to do stop-motion clay animation, of all things, come from? Anthony: I always liked the look of it. I did a bit of stop-motion animation while I was at university, and later I worked freelance for a while, doing stop-motion TV commercials on ludicrously tight budgets and deadlines. It was pretty dispiriting work. I also had an interest in game development, so I decided I would rather use animation to make games than crummy TV ads.
Was the stop-motion clay animation capture done entirely via traditional methods or did you have to do things a bit differently (besides extrusion Anthonyter the fact) for video game use? Anthony: The animation process itself is pretty much the same as making stop-motion animation for film, although you have a few extra things to consider: the animation is non-linear, for example, which means that you have to make sure that all the different animation sequences you make for a character link into each other smoothly. There are a few key frames in the animation of any character, like the standing frame and crouching frame, that the other animation sequences branch out from and must return to again at the end. Since everything is shot separately, we also have to make sure that all the elements look unified when we assemble them together - keeping the lighting consistent is particularly important.
However, shooting everything separately also means that I only have to deal with one element at a time, and I don't have to worry about the background. When doing animation for film, you creep around in constant fear of accidentally bumping something in the background that's not supposed to move - or worst of all, the camera itself. A single careless elbow could ruin a whole day's work. Shooting every element individually isn't quite as scary, although it still feels like a high-wire act at times.
What's one thing you did wrong that you feel could have been avoided? Anthony: I would have spent more time looking into ways to get the 2d photographs extruded into 3d. I probably should have learned to use proper 3d modeling software to build the assets, instead of just going with the ratty little editor I built to test the concept with. But time was short and I was scared that Alex was going to insist we do the sensible thing and make it a more conventional 2d sprite game. I really wanted to take it further than that, so I was all like, "We can't not do this. We'll fix any problems as we go along and make it work". And of course there have been problems, and extra stress and extra work, but it looks so much better than it would have done in flat planes, so I'm not sorry.
Alex: Sticking to a flat 2d game would definitely have been much easier and quicker, that's for sure. I love the look we have now, but I think the audience will have to decide if it was the right thing to do. If we get an audience that is! It has certainly made development of an already long-due project even longer.
How long was Cletus Clay in development? How much development time remains? Anthony: I started the game in my spare time as a hobby project, and I chipped away at it for about four years. It got to the point where people were starting to take an interest in it, although by then the market had changed, and it was apparent that the game's natural home was as a downloadable console game. But it wasn't multiplayer, it wasn't high-definition, it wasn't coded in a language that could easily be ported across to other systems, and it was going to require some major remodeling. I teamed up with the Tuna people and we re-worked the whole design and basically started again from scratch. It was a hell of a lot of work, spending years polishing what turned out to be just a prototype, but I guess it proved that I was capable of doing the job.
Alex: I've been working at it in one form or another for 2 years. We still have a few months left but we've got the core work behind us. Most of what we're doing now is about gameplay and polish.
What was used to make the game and what tools aided in development? Alex: Clay, clay, and more clay. Other than that, we've used various custom tools and a custom level editor. The game is written using C++, tools sometimes in C# or Blitz Basic, and Anthony's original work was all Blitz Basic.
What's the main thing you think makes your game fun? Anthony: I wanted to make a platform game that was really fast-paced, straightforward, and with lots of action. One with a freewheeling quality, where you are forced to improvise with whatever is on hand, picking up, using and discarding weapons as you go. A proper arcade game that encourages score-attack and time-attack. A funny game with a ridiculous scenario and over-the-top cartoon violence. Beautifully polished, but also deeply stupid as only a video game can be. The game is kind of at the assembly stage right now, and you can never be completely sure if it will fire on all cylinders until you can really get in there and play it properly, but with any luck it's going to be one big, anarchic pie fight.
Alex: I've worked on a lot of similar games before, some good and some not so good. The best one was Alien Hominid; it was a real pleasure to work with Behemoth on that. Like their awesome follow up Castle Crashers, I'd like to think that Cletus is a game for almost anyone; a game that you can just have fun with, laugh out loud at the visuals or that you can go for broke on. Also, as Anthony knows, I'm enjoying the two player action on Cletus immensely. I'm quite intent on Cletus and Emmett not seeing eye to eye on everything. Even co-op mode can be competitive...
What was the most important lesson you learned during development of this game? Anthony: This is my first time developing a game as part of a team. When you're working alone you can pretty much get away with making it up as you go along; you can work on whatever part of the game you feel like, and follow it wherever it leads you. Working as part of a commercial team I've had to take a much more structured approach, and that's no bad thing. I could probably do with more of it. But I think I'll have a much better idea of how that process works next time I try to write a design document.
Is there anything about Cletus Clay that you would like to reveal to other developers? Alex: Yes. Making games out of clay is ridiculously hard and takes far too long. Don't do it! Although, I must say that it is a lot of fun too.
What's next for you? Anthony: Some money, with any luck. And then I'll get to pick a new stupid idea to dedicate myself to.
Alex: Sleep followed by a long overdue holiday. Then another ridiculous clay project I hope ?
You Have To Burn The Rope
Kian Bashiri - mazapan.se
Who are you and how are you involved with You Have To Burn The Rope? My name is Kian Bashiri and I am currently studying game programming at School of Future Entertainment, in Karlshamn, Sweden. I designed, programmed and made the graphics for the game You Have To Burn The Rope while my friend Henrik N?mark composed the music and gave me lots of invaluable feedback.
What sparked your game development flame? I don't think there were any one thing that sparked my interest. I started with HTML when I was around twelve and even made a few games with it. (I made this rpg with lots of rooms, and whenever you altered the world, by finding a key or something, you were moved to a new folder with a copy of the world. Needless to say, the game wasn't very long.) Then I got introduced to flash in 1999 and while I haven't stopped 'flashing' it was a smooth ride from there to Java to C to C++ and DirectX. So game development is something I have always been doing. For many years it was just a hobby, it wasn't until recently that it hit me that I might want to do it professionally.
Where and when did the concept for You Have To Burn The Rope originate? Me and a couple of friends went to see National Treasure II. After the movie we discussed adventure games, puzzles in games and the nature of games versus movies (National Treasure has this nice flow because Nicolas Cage's character has such expertise knowledge and, more importantly, because each moment in a movie is completely designed that these incredibly hard puzzles are always solved in a way that keeps the movie interesting).
Another friend called us directly after the movie, and as a joke we spoiled the whole thing for him. These two things fitted well together; to spoil an experience and the simplification of puzzles or challenges in games. I thought there was great humor in it. One can imagine a game where there's a series of choices, but then the game tells you which one to choose, or even worse; a game where there is no real choice and yet the game tells you what to do. Sid Meier once said 'A game is a series of interesting choices' and I agree, but many games give you the illusion of choice and are really quite linear. So in the sign of humor, YHTBTR asks the question 'is a game without (meaningful) choices still a game?'. I don't think so, to me YHTBTR isn't really a game.
Over the course of development, what was You Have To Burn The Rope's most serious issue and how was it resolved? You Have To Burn The Rope is of course technically very basic, but we did spend a long time polishing it and thinking about how players would perceive it (and how we would manipulate that to make it funnier).
It got increasingly more difficult to look at it with an unbiased mind so we got friends and family to try it, tweaked it a bit and repeated.
What's one thing you did wrong that you feel could have been avoided? I wish the game would have been more focused on the theme of interactivity and false choices. It was never our intention to turn the game into some kind of meme, and I regret encouraging it with the game manual, the walkthrough etc.
How long was You Have To Burn The Rope in development? I started on it sometime in January 2008 and it was released in late march, but of course I did lots of other stuff in between. I'd say maybe three weeks of effective time was spent, most of it was polishing.
What was used to make the game and what tools aided in development? I used Adobe Flash 9 and FlashDevelop to write the code. Graphics were done in Flash and Mspaint and I used Dr Petter's Sfxr for sound effects. Henrik used Reason for the music.
What's the main thing you think makes your game fun? I'd like to think that it's smart humor.
What's next for you? I haven't got that much going on. I'm still studying so right now it is more important for me to learn as much as I can. So while it's fun to make games, there are parts of the process where you don't learn so much and that's time better spent learning new shader techniques for instance. Although I have got a few personal projects that I work on during my spare time. Petri Purho (Kloonigames) has inspired me to start prototyping, so I've got a few (hopefully) interesting games in the works.
Carlos Bordeu - ACE Team Software
Who are you and how are you involved with Zeno Clash? Hello. My name is Carlos Bordeu and I am a co-founder of ACE Team and one of the game designers and producers of Zeno Clash.
What sparked your game development flame? I think my interest in games comes from way back when my family got a Mac Plus (our first computer) in the early/mid 80's. The computer came with this incredible game: 'Dark Castle'. Shortly after playing the game countless times I would find myself drawing my own levels with a pen and paper. I was still too young to be able to make anything that worked on a computer, but I still think of those drawings as my first incursion into the world of mod making (which ended up being the path through which I got into the industry).
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? I certainly hope so. But I think the main thing to look for is more diversification in the industry. The big budget titles will still sell, and people will still buy them. The fact that we are releasing Zeno Clash in the middle of today's chaotic economy is just a coincidence.
What we can look forward to is that hopefully more publishers will look at indie teams as good prospects for investments. In the end games are about having fun and enjoyable experiences. If we play too many similar games we tend to get bored of them, and I think independent game developers are definitely doing the most novel games these days. Braid and World of Goo are great examples of games that have challenged the AAA gaming scene.
What are the advantages/disadvantages to developing games in Chile? I think the most obvious advantage is the cost of producing a game compared to doing it elsewhere. The cost of life in Chile is cheaper than in USA, Europe or Japan. Taking this into account and considering that this is our first title (and it is self-funded), means that our budget was significantly lower compared to the figures you hear of in the rest of the industry.
The biggest disadvantage would probably be that in Chile there are no more than a handful of game developers and only a couple of game development studios. It's a very rare job here and establishing business relationships is always more difficult when you are far away from your contacts.
Where and when did the concept for Zeno Clash originate? Zeno Clash was born after a game prototype that we built many years ago using Lithtech's Jupiter System (engine used for Monolith's No One Lives Forever 2). The game was called Zenozoik and it shared many similarities with Zeno Clash. We built the demo hoping it would be our first commercial project, but despite our efforts we tried to make a game that had too many features which lacked a solid core design for both art and gameplay mechanics.
This prototype was a great experience and it helped us greatly because we could look back and start work on Zeno Clash analyzing what we had done well and what we had to improve or re-work to do a more solid game.
What led to the focus of melee combat over ranged combat, which is more typical of first-person games? Several reasons: First it was different... and we didn't want to do a game that looked unique but played like everything else out there. Second; it was a great challenge as very few developers have tried to do melee in first person and it was a great opportunity for us to innovate. Third would be because it was great for the story, since a family conflict is the central theme of the plot, and what can be more personal than fighting up close against your brothers and sisters?
Most FPS's have awesome character models and enemies, but when you are fighting with machineguns and sniper rifles, most of the time your opponents are small figures very far away in the screen. If we were going to produce several unique and visually compelling characters it was counter-producing to make them always fight from a great distance.
How many people use sniper scopes to look at the hi-res texture resolutions of the dead ragdolled enemies in FPS games because it's the only moment when they can take the time to have a paused look at them? At least that's what I do!
Over the course of development, what was Zeno Clash's most serious issue and how was it resolved? I think the thing that needed most iteration was how the melee combat mechanics would blend with the far combat (shooting) mechanics. We had a cool melee system but it was very hard to get our enemies to behave correctly considering that they have to swap their combat modes from regular FPS shooting and taking cover to a 1 on 1 melee combat with the player. All this system affects almost all aspects of our game's design and implementation; from AI to level design to animations. We had to rework a lot of things to get body awareness right. Every change could potentially impact several areas of the game's development so this was probably the hardest issue of development.
What's one thing you did wrong that you feel could have been avoided? Our biggest regret is probably finishing the gameplay mechanics too far into the game's development. I think we should have prototyped the levels a bit more before producing the art. We ended up having some beautiful polished levels that just didn't feel right in gameplay. This meant we eventually were forced to hack them and do a very large amount of rework on those because all the lighting and modeling was close to final but the structure of the level needed to change. I think this problem can be minimized with prototyping but it's a problem that I suppose happens to teams that have experimental game design and a larger art team than a programming one. I would definitely restructure some things for future development but I'm confident that with Zeno Clash's core design functional, things will be much easier for any future projects or sequels.
How long was Zeno Clash in development? How much development time remains? If we deduct the time we spent working on the first prototype build we sent to Valve then the game would be in development for close to two years. Before we decided to go independent and started working on the project full time we spent a lot of time working on a prototype with the Source Engine, but basically as a mod (using all the open community tools). We did this in our spare time and I would estimate that we worked on the prototype for more than a year - but should we have done it as part of a full time job, then I think it would have amounted to about 4-5 months.
Only a month or so of development time is left. Then we still have to do some final QA, but we're talking about weeks. This is our first full independent project so planning and scheduling hasn't been one of our greater strengths. The game was originally due for late 3rd quarter of 2008, but I think that date was unrealistic for a small team like ours.
What was used to make the game and what tools aided in development? As I said we started off with the same tools that were open to the Half-Life 2 community scene. Later on as licensees we would get access to all the additional stuff from the Source engine, which was great. Source has also been updating itself through the years and we have incorporated things such as HDR as they have become available. The facial expression tools of source have been invaluable for our project. Moving from bone based facial animations to Source's 'faceposer' tool was a great step forward.
An interesting note is that Zeno Clash was in design before Half-Life 2 was released, so we prototyped some models and early tech with the Doom3 engine (mostly for normal mapping). We used orb (open renderbump tool) for all our early normal mapping work and tested out a lot of material properties in Doom3 model viewers. Obviously a lot of this changed as we got access to new tech, but when we started out we used a lot of open tools for our experiments.
What was the most important lesson you learned during development of this game? In terms of what we would have liked to do better; it was probably planning the scope and length of the development cycle. For a small team creating a big game like this, it was very difficult and I think we could have done a better job of prototyping and planning the game's features. It is something we will definitely do better from now and on.
In terms of what we feel we did well was simply following our design & vision and avoiding to adopt any existing trends. By separating ourselves from the current gaming scene, I believe we have given ourselves a greater chance of success.
What's the main thing you think makes your game fun? The atmosphere, characters and story are so different that a lot of media has expressed that the game is worth checking out for just the art itself. But I think the gameplay mechanics are also innovative and I think a lot of people will really enjoy the game for its melee combat. The whole combination makes a game that is very different from others in the market, and I think that is something great to look forward to in any title of any genre or platform.
Is there anything about Zeno Clash that you would like to reveal to other developers? I would encourage developers (especially smaller studios) to look at other forms of art and media when designing projects. In our team we get a lot of inspiration from paintings and I cannot see why games cannot be as visually compelling or exciting as any other art form. In many genres games tend to look at Hollywood and other competitive games for sources of inspiration - and I think that works fine for many titles - but I think that in todays race for photorealism smaller developers may find themselves having a really hard time catching up with the bigger studios.
What's next for you? With a little luck and a good reception for our debut title we hope to continue exploring the unusual world of Zeno Clash and other strange and unique game ideas.