Osmos

Eddy Boxerman - Hemisphere Games
Who are you and how are you involved with Osmos? I'm Eddy Boxerman, the chief cook and bottle washer on Osmos. I'm a programmer by day -- specializing in physics and animation -- and a game designer by night. I've done the lion's share of the work on Osmos, but a few friends have really helped out.


What sparked your game development flame? I've had a penchant for inventing and modding games since I was a kid. In parallel, I started programming in Basic on my TRS-80 and on my brother's Apple II+ by the time I was ten. At the age of twelve, Dungeons and Dragons really opened my mind to game-rule systems. Since then, it's been an on and off hobby for me; and it's been "very on" these days.

It's an activity which allows me to be both creative and logical at the same time. At the outset, everything is completely open and undefined, much like a blank canvas. But the final goal is to create an elegant, logical system that is novel -- and enjoyable to play with! So sometimes I get to geek out on math, and sometimes to express myself artistically. What's not to be on fire about?


Where and when did the concept for Osmos originate? I think the idea as a whole hit me while I was doing the dishes. Or was I in the shower? In any case, it was the culmination of years of background thinking: courses on spacecraft dynamics and deformable modeling...Asteroids and Lunar Lander... eye of newt and toe of frog...


Over the course of development, what was Osmos's most serious issue and how was it resolved? The trickiest aspect, design-wise, was introducing the player to the basic mass-propulsion navigation mechanism. Most people are familiar with the action-reaction concept: it's like a rocket. But for some reason no one expects it. If something comes out of "your ship", it must be a bullet, right? Well, most people "got it" within a minute or so, but there was always this initial confusion. I wanted the game to be as smooth and intuitive as possible; it's supposed to be zen, or ambient, after all.

At this point however, and after much experimentation, I think I've converged on a good set of tutorial levels in terms of layout, wording, and pacing. It's surprisingly subtle. And that initial Newton quote seems to help a great deal. Most people seem to naturally "get it" now.


What's one thing you did wrong that you feel could have been avoided? It definitely would have been more efficient to purchase an inexpensive (say... $100) engine, and have saved myself and my friends hundreds of hours of work. When I tally what that means my/our time was "worth"... ugh. But that said, I/we learned a lot. I think. Right guys? Guys...?


How long was Osmos in development? How much development time remains? I started on the initial prototype almost two years ago. Since then it's been mostly part-time, with a couple of heavy bursts for the IGF deadlines. (We submitted in 2007 as well.) At this point it's steady work, and I believe we'll have something worthy of publishing in about five months.


What was used to make the game and what tools aided in development? It's a home-rolled engine built upon openGL (yay for NeHe), openAL, Freetype, and libVorbis. Big, big thanks to the open source communities! We also use Beanstalk and TortoiseSVN for source control, MSVC 2005 Express, Photoshop, Fraps, OggDrop, etc.


What's the main thing you think makes your game fun? He ain't got no distractions
Can't hear those buzzers and bells
Don't see lights a flashin'
Plays by sense of smell
Always gets a replay
Never tilts at all
That deaf, dumb and blind kid
Sure plays a mean pinball


Is there anything about Osmos that you would like to reveal to other developers? The levels in Osmos, besides a few special mote placements, are all generated procedurally; and it uses tweaked curves to handle the difficulty progression from level to level. In general, I'm a big fan of procedural content, especially for prototyping. I'm currently in the process of adding more procedural goodness to the visuals, and if I had more time, I'd go even further with it.

And oh yeah: save time for tweaking. It's all about the tweaking.


What's next for you? Well, I'm moving to the wilds of British Columbia in a few months: to a beautiful little town called Nelson. I admire Jason Rohrer's simple lifestyle, and hope to move a little in that direction.

Besides that, finishing Osmos is going to keep me busy for a while yet. After that... hopefully a little hiking, paddling and backcountry skiing. And after that... I have a couple board games waiting in the wings, as well as a few other video-game ideas up my sleeve.



Mightier

Lucas Pope - Ratloop
Who are you and how are you involved with Mightier? Hi, my name is Lucas Pope. I was a designer, programmer, artist, and musician for Mightier.


What sparked your game development flame? My parents were a bit behind the curve when I was a kid and waited until the late 80's before buying the family computer, a Mac Plus. It came bundled with this great application called "HyperCard" with a built-in scripting language that first exposed me to graphics and logic programming. I had a lot of fun making little programs with that. I've always had an interest in art, music and technical stuff, so the natural combination of all that is games.


Where and when did the concept for Mightier originate? The idea that it would be cool to draw something and have it come alive is not original. In 2001, I built a tech demo called "Ink" based on this concept that let you draw a character with the mouse, press a key, and watch it spring up and animate in full 3d. The effect was pretty neat, but drawing with a mouse is not very intuitive and there was no gameplay. I tried for a bit to turn it into a fun game, but couldn't come up with anything cool.

"Drawn to Life" on the DS implemented a similar concept a few years later. Their focus was in the platforming though, and I was interested in something were the drawing was more important to the gameplay.

In late 2007, Sony R&D released videos of their user-generated content system that captured paper drawings on a web camera. This was the perfect solution to the problem of drawing with a mouse. Why draw on the computer at all if you can just throw it down on a piece of paper? I immediately started adapting the "Ink" tech for a paper interface. I don't know the details of Sony's capture system, but I wanted something relatively foolproof. By requiring a printer and printing 5 red dots, I can detect the exact position of the page without much trouble for the player.

Once the printer was involved, we realized we could print other stuff on the page to make a drawing-based puzzle game. I sat down with a notebook every night and sketched out random ideas for a few weeks before coming up with the height markers and platforms concept. We prototyped it pretty quickly and got a good sense that it might be fun to play.


Over the course of development, what was Mightier's most serious issue and how was it resolved? We had a nice buffet of technical challenges, but the most serious issue was more philosophical. With Mighter, we really wanted to focus on the player's physical interaction with the paper. Our original plan was to use the printer/paper for the majority of the game's interface. Instructions would be printed and we'd have several non-drawing puzzles involving folding and/or cutting the paper. The visuals would all be augmented-reality style as an overlay on the webcam view and the game would start by printing a letter of acceptance welcoming you as an engineer to Team Mightier.

At some point we realized it was all a bit crazy and scaled back to a more game-like presentation with printed drawing puzzles and a single, final, cut-out puzzle. But by scaling back, we also opened the door to an interface mode that didn't require the paper at all. The game's reliance on a webcam, the slow speed of printing the puzzles, and people's general reluctance to use ink and paper convinced us that we needed an alternate way to play the game.

Adding the in-game mouse drawing mode was a tough decision, but it made the game so much more accessible that we felt it was worth it. In the last week before submitting to the IGF, I redesigned the interface to work with either the printer+webcam or the in-game drawing tablet.


What's one thing you did wrong that you feel could have been avoided? One of our big mistakes was waiting too long before testing for compatibility. We started out gameplay testing pretty early, but our compatibility testing was limited to buying a few webcams and playing the game on 10 or so computers. For a peripheral-based PC game, we should've been more focused on testing multiple cameras and video cards. We had trouble with both our video-capture code and our rendering code that we could've caught with more testing.


How long was Mightier in development? How much development time remains? I spent a few weekends getting the webcam tech working before [my partner] Keiko and I started putting all our free time into the game. In all, we spent about 6 months of evenings and weekends on Mightier.


What was used to make the game and what tools aided in development? We used 3dsmax, Photoshop, and Visual Studio. The game is written in C++ using DirectX and the build tool and level editor are in C#.


What's the main thing you think makes your game fun? I think the puzzles are satisfying; the progression and introduction of new elements keeps things interesting. Keiko is a big fan of drawing the characters and seeing them run around. I think it's gratifying to see that the gameplay itself is fun, beyond the cool-factor of drawing on paper and capturing with the webcam.


Is there anything about Mightier that you would like to reveal to other developers? Hmmm.. We didn't really do anything particularly novel while developing Mightier. Probably one thing I can suggest is that if you're considering writing your own exporter for 3dsmax or Maya, take a look at Feeling Software's "Collada" first. We were able to write some stuff pretty quickly in C# to parse Collada files exported from 3dsmax. That saved us a few weeks of boring exporter work.


What's next for you? We're focused on our day jobs right now. Keiko and I both work in the industry full-time. We set a goal for ourselves last year to finish Mightier and release it as freeware. The IGF due date was the perfect deadline and the nomination took us by surprise. We have some long term plans for Mightier, but nothing immediate.



BrainPipe

Rich Carlson - Digital Eel
Who are you and how are you involved with BrainPipe? Rich Carlson. I helped design the game and I created sound effects and most of the music for it.


What sparked your game development flame? Making amateur Doom and Quake levels, tweaking paper games, working on big budget games --and meeting co-conspirators, Iikka and Phosphorous, of course.


Where and when did the concept for BrainPipe originate? At home, Kirkland WA, a suburb of Seattle, in early summer of 2008.


Over the course of development, what was BrainPipe's most serious issue and how was it resolved? Finding a way to reward players for playing farther and farther into the game and give them a sense of progress. We originally desired a very smooth unbroken run through the game, level-less, but we felt progress really did need to be indicated and that some kind of reward would help as well.

Phosphorous suggested collecting trophies, and the way the game speed ramps already suggested levels --up, drop (new level), up a little more, drop (new level), up even more, drop (new level), etc., so that was the basic solution


What's one thing you did wrong that you feel could have been avoided? The way obstacles and trophies are "randomly" placed --and paced...this was always tricky, right up to release. I think we made it given the constraints of how the game works inside but I think it could be better too.

Well, I always think "the next one's going to be better", right? That's the name of the game. Actually, Brainpipe's the name of the game. ; )


How long was BrainPipe in development? Maybe 5 or 6 months working part time.


What was used to make the game and what tools aided in development? For the most part, free sound and music software, "found sounds", a couple of synthesizers, ancient versions of Photoshop, a couple of Wacom tablets and good old C.


What's the main thing you think makes your game fun? It's immersive. I know that's an overused sort of word but Brainpipe really does suck you in, and you want to stay there. Art, music and real simple gameplay combine really well to accomplish this. Also, it starts out mellow, which is comfy, and then gets more intense and very fast the farther you go into the game --this has a giddy and very addictive effect.


Is there anything about Brainpipe that you would like to reveal to other developers? Other than the fact that Brainpipe is actually an insidious mind control program originating from some distant alien world disguised as a harmless videogame? No. The rest is, and shall remain, a total mystery.


What's next for you? Perhaps more work on the sound engine Iikka developed as an alternative to OpenAL, and possibly a sound and music creation application to go with it.

Also, there are more games we'd like to make with one in particular in the prototype stage. But you never know. I mean, WE never really know. : ) Whatever strikes us as being fun to work on when we get the urge to do it I guess.



The Maw

Michael Wilford - Twisted Pixel Games
Who are you and how are you involved with The Maw? My name is Michael Wilford and I am CEO and co-founder of Twisted Pixel Games. My role on The Maw was producer, but I also contributed code to our engine's renderer and other parts of the game.


What sparked your game development flame? A little game called Doom. It gave me my first taste of game development and I made hundreds of modded levels that I shared with my friends. I was so addicted to creating levels and trying out new ideas. I easily spent more time modding and playing Doom than I have with any other game. Since then my career path always seemed clear to me.


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? That's a terrific question. Opportunities for indies have been on the rise for several years now, and I think the industry has already been significantly impacted by innovative indies. It's not groundbreaking to predict that indies will continue to shine in 09'. But in general, I think smaller, more agile companies that are passionate about doing quality work should view recessions as opportunities to stand out from the crowd.


Where and when did the concept for The Maw originate? Josh Bear (CCO and Director) and David Leung (Art Director) began brainstorming one day and were inspired by the excellent two-character collaboration in Ico, and wanted to make an action/adventure game with a lot of humor and personality to the characters. The leash mechanic was inspired by an old Shiny game called Wild 9. With the overall priority being personality, the concept just kind of grew from there.


Over the course of development, what was The Maw's most serious issue and how was it resolved? Honestly, the biggest challenge was just the sheer amount of work that had to get done. We started from scratch, with no engine, no tools, nothing, and we were taking on an ambitious 3D action/adventure project. Starting on October 1, 2007, the first day of full production, we just began building our asses off. The problem was solved only by the unwavering dedication of the team. We worked mean hours. We did some art outsourcing, but Dave Leung was our only artist, so the vast majority of every model, animation, texture, shader, and visual effect you see in the game is his. When we first scheduled out his workload he was booked through 2012. Somehow he made magics happen.


Given the hardships of starting from scratch, what made you guys decide to do so? Necessity, really. When the project was greenlit with Microsoft we hired the team full-time and started working. Frank Wilson, our CTO and co-founder, did a lot of research on virtually every 3rd party technology solution in existence and ultimately we ended up licensing a couple key pieces of technology like Granny 3D, which is what allowed us to cram 2 GB worth of data into 150 MB. But for the most part, we didn't have much of a budget to buy technology, so Frank built a lot of it from scratch. He's a bearded mad man.


What's one thing you did wrong that you feel could have been avoided? Thankfully, nothing really serious went wrong during development. If it had, our near-impossible project would have become a truly impossible project. There was so little room for error in the budget or schedule. One thing that peripherally went wrong though is that after our game launched we decided to announce that we have been working on DLC for the past few months since the game entered certification. Apparently that was a mistake because some gamers accused us of intentionally cutting levels from the main game in order to charge extra as DLC. We thought people would be excited to hear that more content was coming, but next time we'll keep our mouths shut until closer to the DLC's release date.


How long was The Maw in development? How much development time remains? We finally launched The Maw last week on Xbox LIVE Arcade. Development time was about 9 months.


What made you choose to distribute via XBLA? Were any other platforms considered? We went after all of them! Our decision was made when one of them picked us up! David Edery at Microsoft saw the potential in our studio and in The Maw, he knew the niche it would fill in the XBLA portfolio long before the niche existed, and we worked hard to not disappoint him!


What was used to make the game and what tools aided in development? We started with nothing. So we scrambled to cobble together an engine using as much existing and proven 3rd party tech we could find. We considered every option and talked to virtually every vendor and ultimately settled on using Granny 3D as the basis for our engine. We knew that our ambitious character-driven game would have a lot of animations, and Granny's lossless compression ratio couldn't be beaten, especially within our indie budget. So our CTO Frank Wilson lead the charge and built a pretty amazing engine using Granny, Fork Particle, Lua, LuaBind, FX Composer, and several other cheap but powerful tools. Frank also built an editor using C# that is by far the most full-featured game editor I have ever seen. For 3D art we use 3D Studio Max, and everything came together really well.


What was the most important lesson you learned during development of this game? That invention is 1% inspiration and 99% perspiration. The Maw started as a great little idea for a new game, but the only thing that turned it into a great game was the sweat of the team. We are very fortunate to have such an amazing team and they did a bang up job.


What's the main thing you think makes your game fun? Probably the personality and humor in the characters. Low-budget games generally need to be innovative with witty gameplay mechanics, or simplistic art designs, or some other way. It's hard to attempt something with high production values on an indie budget, but we knew that if we pulled it off it would set us apart. The team worked really hard at giving Maw a lot of personality, and I think they nailed it. We tried to be smart about the gameplay design and pacing and everything else, that's why there's no death in the game or any persistent heads-up-display (HUD) elements on-screen. But I think what people will really notice are the characters.


Is there anything about The Maw that you would like to reveal to other developers? I would say that it's rough making a game like this starting with nothing. It took months before we even had a level up and running. Just when we started to hit our stride and had all the tools necessary to build deeper levels, it was time to tie it off and add as much polish as possible because we were running out of time. The only reason why this project was even possible was the team. We had 7 close friends, all with an impressive gameography under their belts, who had worked together in the past, and were 120% dedicated to do whatever it takes. I wish we had a more interesting secret ingredient than that, but it comes down quality peoples.


What's next for you? Now that The Maw has made a nice splash for us, and given us a fantastic engine to build from, we're looking to one-up ourselves with a much crazier idea. The dream is to keep making our own stuff, so that's what we're going to try and do.



Retro/Grade

Matt Gilgenbach - 24 Caret Games
Who are you and how are you involved with Retro/Grade? I'm Matt Gilgenbach, and I'm the fungineer at 24 Caret Games. I do both the design and gameplay programming.


What sparked your game development flame? When I was 6, my parents bought me a Nintendo Entertainment System. At the time, I had no idea what it was, but I quickly discovered how much fun games could be. Then at age 9, my parents got me a Mac Classic II. I learned BASIC to start programming games, and I haven't stopped making games since.


Where and when did the concept for Retro/Grade originate? The concept of Retro/Grade actually evolved from a demo that we were putting together. In order to tune gameplay, I put in a debug mode to back up time to repeat sections that I was working on. Then Justin Wilder, our engine programmer, mentioned that it'd be cool if we made gameplay where players had to do some task while time is reversing. We talked about it for a bit and couldn't figure out how to work reverse gameplay in our original idea.

After working on that demo for about two months, we decided to switch gears and work on something that would have a smaller budget should it get turned into a full game. I revisited the idea of making a game that is playable in reverse. I figured that the best way to do reverse gameplay is to have gamers line up their actions to things that happened previously. The problem with that is that arbitrary positioning and timing would be difficult to match, so I thought that we should constrain motion to a series of rows and match the timing to music. A top down shooter seemed like a good style of game that would match these constraints and add an action packed twist to the rhythm genre.


Over the course of development, what was Retro/Grade's most serious issue and how was it resolved? Probably the most serious issue was determining the placement of the enemies. Because Retro/Grade is a rhythm game at its core, I wanted to be able to create and modify the rhythms of the player's actions rapidly. Since the gameplay is matched to the visuals of a shooter going in reverse, this requires enemy ships flying around and behaving in interesting ways. In order to accomplish this, I created a complex enemy director that determines the appropriate placements and movements of enemies in order to match the pattern I've come up with for the gameplay.

Although this might seem like it is straightforward, it quickly became a big undertaking in order to get it working well. Enemy ships must either implode or take damage from the player's lasers, and they need to be in place to receive their lasers when they return. The final algorithm involves creating a schedule with all the movements and locations of the enemies over time. The placement of the enemies is determined by many heuristics in order to get the best arrangement based on the pattern of the song. They are spawned and moved around in order to create the most visually exciting space battle while matching the gameplay.


What's one thing you did wrong that you feel could have been avoided? Since creating effects that go backwards is tough, Justin created all of his effects so that they would be completely stateless giving us the ability to render them at any time offset. That way, he could tune the effects to look amazing going forwards, and we can evaluate them with a negative time delta during the actual gameplay. After he did a few effects, he suggested that we should take advantage of the fact that we could reverse time again, since the visuals are reversible. After a bit of thought, I realized giving players the opportunity to back up time and replay sections they messed up would be a great feature for a rhythm game. Sometimes when playing a guitar game, my hand shifts such that my fingers are over the wrong buttons, and I screw up an entire section. Other times, there are particular sections of a song that I foul up, and I want the opportunity to repeat them in order to practice without playing through the whole song. Allowing the user to back up time with the Retro/Rocket power up in our game addressed these frustrations and also makes the player feel like they are a DJ playing with a record because we slow down the game before reversing rather than instantaneously switching directions.

However, that meant that the enemy director had to be refactored to allow time going forward as well as the typical backwards flow. This required changing the enemy director to evaluate the entire level at once and build lists of actions per enemy rather than telling each enemy what to do when the time came and only looking ahead a certain distance. This was quite a lot of effort since the enemy director is a complex system, but after playing the game with the Retro/Rocket power up, it was totally worth it. It really is a great new innovation for rhythm games that I hope other rhythm games adopt in the future.

The lesson I took away from that is to try and brainstorm about the features you might want and keep them in mind when doing the initial coding. As a gameplay programmer, I have to constantly refactor, redesign and just plain throw out code, so I am always cautious about gold plating and supporting a bunch of features that I may not need since that can unnecessarily complicate systems and also lead to time wasted should a system get redone or features never used. However, time should be spent when designing a system (especially a mission critical one) to making it as flexible as it can be without adding much time to the implementation. Obviously it's a tradeoff, but in this case I erred on the side of quick initial implementation at the cost of time in the long run.


How long was Retro/Grade in development? How much development time remains? It's been in development for four months. We spent two months on our initial demo and building technology before we started on Retro/Grade. The time remaining depends on what platforms we end up releasing the game on, but we expect to finish it sometime in 2009.


What was used to make the game and what tools aided in development? We use Visual Studio 2005 for coding, Maya for modeling and Photoshop for texture work. We are using XACT for audio as well.


What's the main thing you think makes your game fun? Retro/Grade is an innovative fusion of the action packed thrills and over the top visuals of a shooter and the broad appeal of a rhythm game. This combination brings a whole new level of excitement to rhythm based gameplay. The enemy shots that the player must dodge (in addition to lining up the more standard rhythm game beats) put pressure on the player to make split second decisions and require lightning fast reflexes thus creating an entertaining and challenging experience.


Is there anything about Retro/Grade that you would like to reveal to other developers? I imagine that they might be wondering who did our great retro-themed music. We contracted Skyler McGlothlin, a Texan musician who has put out several amazing CDs as Nautilis. He's one of my favorite musicians and has put together some really great tunes for Retro/Grade, so we have been very fortunate to work with him.


What's next for you? More work on Retro/Grade! It's amazing that we've gotten such a positive response already for the game because it's pretty early in development. We plan on adding quite a few more cool features before it is released.