#chris deleon

❖

Which game engines/game making tools do you use for your games? Did you build your own? If you have used different engines/game making tools, which one is your favorite and why?

Chris: This response varies by which years of my work we're referring to, and why the work was being done, so in order to answer the question adequately this will be a bit of a project bio.

When I got started in the mid-90's, I was playing with modding tools for Doom, Command & Conquer, Descent, and Quake. I built levels, retuned gameplay balance, and made/replaced in-game art and audio assets.

When I made the leap a couple of years later to programming games of my own, I had no engine or game making tools. I began by copying assembly and C routines from assorted programming books to set monitor resolution, plot pixels, draw lines and other basic shapes, import custom image and audio (beep bloop, system speaker kind of stuff), and all that mess.

I did that for my first 9 or 10 completed graphical games before I switched over to using the Allegro library with C/C++. Allegro was started by Shawn Hargreaves, who later went on to work on Microsoft's XNA. Allegro solved issues for me like setting monitor resolution, loading common image file formats, and playing wav sounds or midi music.

I was still writing all of my engines (referring at this stage to level formats, level editors, interface code, sound channel management...) from scratch in C/C++. Each project taught me a lot, and each new game began by stripping down an old game to its bare functionality then mashing in new approaches to organizing my code or streamlining my content process. I stayed with Allegro for the next 6 years, creating and leading a bunch of games with it for the game club I helped establish as an undergrad at Carnegie Mellon: the Game Creation Society. As a senior I began dabbling in OpenGL, via AllegroGL, to take advantage of hardware accelerated graphics and learn about the abstractions involved on OpenGL, and messing around a little with 3D terrain/models.

I helped out on those game club projects in a variety of support roles: artist, level designer, sound person... whenever I wasn't the lead and programmer. Teams differed in choice of library, engine, and tools. Some games used DirectX, several were built on SDL, a few were made using Java (which, to this day, I wouldn't really recommend to anyone), one even used Adventure Game Studio. A similar pattern has continued in the game club I started at Georgia Tech in 2010, though instead the common platforms are now Unity, ActionScript 3 with Flixel, plus some uses of Game Maker, XNA, and SFML.

In the Game Creation Society at Carnegie, indie tools weren't as far along as Unity is today, so we frequently found ways to leverage existing software to tune or develop our game content more efficiently. For example Battleship 88's levels were tuned from a .csv (commas separated value) file, a simple spreadsheet edited in Excel. One of my favorite clever cases came up for Shotgun Debugger, a game led by Matt Sarnoff, which imported XML files made in Inkscape, a freeware alternative to Adobe Illustrator. The game used the polygonal data and meta tags to set walls, doors, colored lighting, triggers and switches and such when loaded into the game engine. Sarnoff wrote a parser in Python or Perl at the time that translated the XML into a format the latest version of the engine expected. Of course, XML parsing libraries and functionality are so common today that such a result could probably be much more easily achieved. The use of Inkscape was all Sarnoff's idea and code, but I designed levels for the game, and being able to rely on that existing tool's abilities to create, transform, modify, tag, group, and otherwise manipulate shapes had a big impact on my ability as a level designer to create spaces that were differentiated not only in functional layout but also in a sense of mood and place.

Unrelated to those game projects: every year my fraternity (anti-stereotype disclaimer: I don't drink, it was a fairly nontraditional, high GPA/overachievers, no hazing and no pledging fraternity) needed a game project for our spring "Booth." Booth was/is a temporary structure built along some common theme to hold a plot at the school's annual fair for students and the public. For those games brothers in electrical and/or mechanical engineering broke apart joysticks, gamepads, running mats, or other input devices to rig their parts for specially crafted controller mechanisms connected to chair swivels, sliding bars, external LEDs, interactive picture frames, and other unusual gizmos. This was an exciting opportunity for me, as I got to design games around custom input hardware. The games were still programmed in C++ with Allegro. The carnival booths also set me up to design for a completely different player context than my usual audience:(people of all ages and gaming abilities, each looking for a short play session, and unlikely to play again due to long lines, So coming up with these games was more like an arcade novelty than a PC or console game, except it had to be kept pretty easy since replay was impractical. I wrote more about that experience here if any reader's curious for more detail on that, including when I semi-recently remade one of the games in Unity.

For that matter, I wrote a free EBook/PDF summarizing those first ten years of projects, available here with more platform and design details.

In the summers of 2005, 2006, and 5 months in 2007 I worked at Electronic Arts on the Medal of Honor project, switching to Boom Blox for the last few months of that time. MoH involved design and a bit of programming experience in Unreal Engine 3. Boom Blox was made atop a proprietary engine, though I created the isometric level editor that I and a few coworkers used on PC to crank out levels with mouse and keyboard. (The Wii-based editor that shipped in the game wasn't ready for use until later in development).

In late-2007 when I joined ZipZapPlay to help create PlayCrafter.com, a (now closed) web-based game making tool for teens, I switched to ActionScript 3. I also used AS3/Flash for the 7 months of daily experimental gameplay projects, since I figured if I was going to make tiny things they'd better be playable via URL without requiring download/configuration/uninstall, and ideally cross platform. I never used the Flash animation tool though, I just compiled at command-line with mxmlc, which I've written a few tutorials and example code for getting started with.

After a year at ZZP, I left and developed about a dozen iPhone/iPad games and entertainment apps over the next few years with Objective-C and OpenGL - a handful with publisher involvement, and the rest self-published. I got started extremely early in iOS development, shortly after the App Store opened, so this was before Cocos2D was very far along. Or, I suppose if it was ready for prime time by then, I wasn't aware of it. Either way, I was writing all of my own core graphical and audio functionality by remixing, extending, and troubleshooting Apple's example code.

When I returned to school in 2010 to work on graduate degrees at Georgia Tech, I switched back to ActionScript 3 for student projects. Besides removing the business-side and platform-specific issues of mobile development, I knew that web games greatly improved our player reach, and more players trying our games could be useful in getting incoming students to take the group seriously. I've pivoted along with many of the club members toward more Unity projects, since many students want to work on 3D games and/or games that can be easily ported to play on iOS/Android.

In graduate classes and research I've been using ActionScript 3 (for help with the Game-o-Matic rapid microgame generation engine), Unity (for Relativity Runner, an Escher-based minigame I wound up showcasing at the Hammer museum in LA), XNA with Kinect, and PHP/SQL/HTML5/JS for web-based applications including a simple interactive story engine.

In a couple of business arrangements that both got up to playable demo before halting, I also did a bit of design work for a Lua-scripted PlayStation 3 game and C programming for a game on Sifteo cubes.

As for which is my favorite and why, see my later reply to "What programming language do you prefer developing your games on? Why do you choose it over others?"

Do you use the same development process for all of your games?

Chris: As alluded to earlier I've done plenty of switching languages, team sizes (about half of my games I made alone, the other half on teams of 3-12), project durations (from 4 hours with Interaction Artist up to 18 months, but typically around 2-4 months), and rethought my process a lot over the years.

My process is generally some variation on:

1) First I need to decide what it is that I'm trying to make. This is an iterative, exploratory process, often digital from almost the very beginning, playable in some form within a week of jotting down initial ideas. I start rapid prototyping, focusing first on player control and world structure, expecting that in the process of doing it, playing it, and rethinking it everything may change. I build as a way to investigate questions I'm uncertain about, to inform the decisions that will shape the next version built as the exploration continues.

1.5) If others are involved with the project, I'll get everyone involved in step 1 from as early as possible. How early depends on the context it's being made for, and how team members wound up on the project. In the game clubs, where people volunteer for projects that they're excited about based on the pitch, they need to hear to hear some fairly clear direction early on to get an idea of what they're signing up for. On the other hand for a class project, where we get assigned groups, everyone will be helping to decide what kind of thing we're making, since the choice of which project they'd like to work on wasn't made available. If I'll be paying people for assistance on a commercial project, then I'll need to get the project far enough along that I can give clear requests for what I need done, with high certainty that I know it's exactly what I'll need or be able to use, to keep my costs low and to be fair to them in the use of their time and talent.

2) As a next step, just before making the first playable prototype or as a part of that process, I make a mock-up screenshot of how the game might look in action. I include interface elements, player character on-screen, if applicable, some indications of how the level structure might look (with implementation in mind: maybe tile based, or polygons, or built from reusable chunks... not just open-ended concept art). I make the mock-up screenshot at the same resolution/size/proportion of the game, since that influences how I lay things out on the screen, what size I wind up using for characters, font choices for the in-game interface, and so on.

On a team the fake screenshot helps get everyone on the same page about what kind of game we're going for at first, and while it's obviously up for discussion/debate it means we're at least discussing or debating clear, situated ideas based on a concrete case we share an understanding of. Even when working alone I still do this fake screenshot though, as I like that it forces me to be clear about assumptions I'm making about scale, structure, interface, and perspective. It's amazing how quickly and naturally trying to do a mock-up screenshot brings questions to the forefront that I wouldn't have thought of as clearly in written or programmed form, and in the process of making the screenshot I don't just face the questions but I have to form tentative answers to them as I go ("how big is the character on screen?" or "will the game's level spaces have purely decorative elements? collectibles? doors? ladders?").

3) I then basically program to bring that mock-up screenshot to a playable state, even borrowing art assets from layers of the mock-up so that I don't get bogged down by changing gears frequently between programming or generating art assets.

At this point it's analogous to what the pinball industry refers to as a "white wood" stage in gameplay development, which for pinball refers to the earliest playable form of a table's layout, yet undecorated, put together based on the initial CAD/drafting thoughts, still rough and intended for rapid iteration between playing with it. In the white wood stage they'll flip the ball around a bit, reconsider angles or positions of play field parts, drill some new holes, move components around, and so on. I'm the same way with my early rapid digital prototype(s): I don't care that it's rough around the edges (no animations, pieces slide/hope around, no particle effects or sounds), in fact that's better because it makes it easier to move things around, cut parts without losing much work, or change it up. If the game only has 1 enemy type so far and I fundamentally change how enemy code works, that's easy at this step, but had I filled in a bunch of enemy types it would harder to pivot so freely.

Character sizes may change, the player's control scheme may change, I may come up with other ideas for features to try in the engine, and so on. If it's a game with levels or puzzles I'll begin generating a bunch of variations and attempts to play around in as a way of searching for which patterns come out well, and also to inform how I might improve my tools or iteration and workflow for the project.

4) Once I've got one level/area come out OK in a way that I feel happy with, in a form that might eventually wind up in the middle of the game (i.e. I'll later tackle building up to it with easier challenges, and nor should be end-of-game complexity - it's just proof for me that it has potential to fit together in a playable way), the project is ready to "go wide."

Going wide marks the shift from all attention on a central question, what is it that I/we want to make, to the action of making it, which shifts from exploration toward production, and can be made parallel much easier if multiple people want to make levels or animations at the same time, etc. This approach, getting core gameplay working in an isolated but realistic (as opposed to contrived demonstration) test level before committing all attention to full production is a process that Mark Cerny of Marble Madness coined long ago as the "Cerny Method", though it's now a fairly common practice that companies and teams have their own names and adapted stages for.

At this point the team meetings, if it's indeed a team project, become less discussion oriented, which made sense when first feeling out direction on the project, and more task-oriented. Meetings focus at this next stage on coordinating who is working on what, one week at a time, to keep everyone involved, avoid collisions of redundant or conflicting work, and unblock or improve workflow for other developers on the team as soon as possible.

If it's a solo project, then at this phase I swap out my creative director hat to instead gear up and work more like a software engineer, level designer, or high quantity, consistent-quality artist (I can't "draw" well at all, but what I can do is churn out dozens of recognizable small images in a night that match - for rapid, small-scale game production that matters more). My todo list changes from a set of questions and options to consider to instead be a prioritized checklist: get this feature working, make the art needed for that item, generate some design guidelines or themes to adhere to and create example levels that abide by them, etc.

It's time to tentatively accept the answers arrived at earlier in the process for the big questions, like what genre is this game, what does the player control, and what's it about, to instead zero in on burning through tons of detail questions as I go, like what color are the projectiles, how long does reloading or recovery take between actions, and how is collision handled. This is about trusting decisions made earlier, at least enough to pivot and act on them, since too much rethinking of the foundations after going wide results in a bunch of thrashing and wasted content. Companies that need to think about profit may have a valid reason to do that big shift sometimes, and people's salaries sort of pay them off to just suck it up and keep working doing as they're told, but wasted work causes a morale and momentum hit that can be harder for an unpaid freeware/hobby/student team to weather.

5) Tune to wrap it up and tie off loose ends. When the game feels about half to three quarters done in terms of content, or if on a set schedule when we're somewhere between half and three quarters through our allotted project time, I shift modes of myself or the team from churning out new things to instead properly filling out and fixing what we've already got, filling in any glaring gaps. I/we make a list of what needs to be addressed before the game is ready to be played without requiring developer explanation, prompt, or immediate support. This often includes in-game instructions or tutorial, an ending sequence if applicable, save/load functionality if logical for this game type and not yet implemented, main menu screen with logo, all that stuff besides core gameplay or in-game content that needs to come together for the game to look and feel done.

Once that minimum list is identified, the list is only allowed to shrink. No adding to it, no making anything new that would grow the list by increasing player expectation. Watch out for symmetry/pattern - for example if one weapon gets support for an Alt Fire mode players will expect other guns to have an Alt Fire, too. If some loose end implies we would need a bunch more time or work to support a previously planned or started feature at this point it's generally better to just cut that feature. To continue that previous example: if only one gun had an Alt Fire mode implemented, and you're running low on time so the energy would be better spent on tasks other than adding Alt Fire to every other weapon, just remove it from that gun that has it.

Unless you were careless with announcements during development (don't paint yourself into a corner with public promises you may not keep!), players won't know what you cut. That's the point of addressing unfinished features in this way of either filling them out or pulling them out. Nothing about the game should appear to have been still partway under construction when released.

When done wisely scope compromises and cuts at this stage in the process can help focus a game on and around what worked best during development, carving away the potential distractions of incomplete or incoherent ideas that weren't fitting together as well.

6) Depending on the genre and size of the game, ideally some testing for feedback and observation can take place earlier in development. At minimum, this step is when play testing is absolutely critical though. After release to the public, the developer can't be there watching over people play to help clarify confusion, so that needs to be spotted and patched up ahead of time.

For this step the game gets put in front of someone that hasn't seen it played before and has not been told how to play. I and/or others that worked on it observe the players and take notes, especially watching for snags or dead ends. Snags are times when the player is confused or annoyed by something distractingly rough, which has their attention on a perceived flaw instead of on the gameplay (even if you disagree that it's a flaw, at least accept that it's a distraction, and find a way to change it or set it up so that it won't be perceived as a flaw). Dead ends refer to what my former coworker Josh Leyshock called "Shelver moments," meaning someone would by so bothered or stuck as to stop playing, take the disc out, put the game box back on a shelf, and forget it exists. Warning: remember that a browser game or PC game is even easier to "shelf" than a console cartridge or disc, people have a lot of other free web games or already owned PC games competing for their attention and time.

It often helps to have the tester speak out loud what they're thinking and why they're doing what they're doing as they play. This helps surface the gap between how the game has set them up to see things, in contrast to your knowledge as developer of what's actually going on, and usually that disparity should be repaired or somehow avoided, within the game. Confusion comes up, things that seemed obvious during development turn out to need to be better highlighted or explained, etc. Interpret the feedback after - don't argue with testers of course, but on the other hand you don't need to address issues in ways they proposed, since you know the game's insides and intentions you may have another approach to try that you think is somehow more appropriate or resourceful but can still prevent the complaint from reappearing during the next test.

Address whatever notes arise from that testing, then test with a new, different person to uncover a new and different layer of roughness that was previously buried under the former issues. Repeat until the feedback received is sufficiently minuscule or subjective ("I don't like helicopters" -not helpful).

7) With the game polished, including some late fixes to art or interface, it's now ready for video. Here I make a short gameplay trailer focused on conveying what the gameplay is like without getting overly descriptive. Many players Google for a video to see what a game is about before tying it, to decide whether it's worth getting into, while others who are curious to see the game may not have the time or skill to get deep into it. Don't let their searches turn up empty, and don't count on whatever haphazard video some stranger on the web might throw together, even if you get lucky and have some players or reviewers do that, they're a lot less invested than you are in showcasing the best the game has to offer.

I typically use Fraps in Windows or Screenflow on Mac to capture a full play through of the game, or 20-30 minute of play if it's multiplayer, capturing sound effects audio with in-game music disabled (to avoid butchering music while video editing, without losing sound effects). I then edit that down to 1.5-3 minutes of footage and find a suitable Creative Commons Attributes song (or one composed for the game, if one of the songs fits) to use with it, ducking the sound effects a bit so that they're present but not competing with the music. If the music isn't from the game, I add the credit for the composer to the video, so that if it gets viewed as an embed etc. the credit is still visible.

8) Finally I make the game available to others online, or on the App Store, or whatever channel I'm targeting for release. If it's a Flash/AS3 game I add a MochiBot to it for stat tracking purposes and upload it to Newgrounds and Kongregate (the MochiBot lets me know how much it gets played on other sites after it inevitably gets lifted and reuploaded elsewhere), If it's a club project I take screenshots and add a download link to it on our club site. If it's a personal project I'll put it on my portfolio site, share links to it via social media, and maybe write a blog entry about it at HobbyGameDev.

What programming language do you prefer developing your games on? Why do you choose it over others?

Chris: I keep returning to ActionScript 3. Flash player is still very widely supported and consistent across browsers and major operating systems, and though tablets and phones don't run it well or at all these are keyboard and mouse games that don't translate easily to multitouch anyhow. HTML5 is replacing Flash for dynamic websites, and is also great for writing in-browser menu/turn-based games, but as far as I've seen (or at least the last time I checked) for a number of reasons it's not quite ready to replace Flash for real-time action games of the types that I like to work on.

I have no strong preference in terms of any language's technical features. I pick up programming languages purely as a matter of what's going to be able to reliably reach players and give them a relatively smooth, consistent, trouble-free experience playing the game. I look for languages, tools, and frameworks that other finished games have already been made with, that I'm able to play without any special hassle (minimal or no fighting with missing DLL's, if special libraries are required and not common then the installer needs to detect and address that, etc.), and that perform smoothly enough to feel like a "real" game to be taken seriously.

I used to make Windows games because such a large percentage of computer users had Windows. I've since converted to browser games but it's still important to me that they work in Windows (and Mac, and ideally Linux), since that's still where so many users are. Microsoft's security defaults have shifted over the years though to make downloading and running an unofficial .exe file an event woven with scary warnings and admin permissions, to the point that I'm a little wary of even trying to distribute a Windows game on Windows anymore. When people can get to the game via URL, play it, then close the browser and not need to uninstall or clean up, that's a much smoother experience, and an easier one to be excited about sharing with others.

Do you use third party tools (map editors, sprite managers, animation suites etc) or you build your own?

Chris: The third party tools I use are Photoshop, Maya, and Audacity. For level editors I tend to write my own, though one of the games that I'm currently helping design levels for is using TuDee for tile map editing.

Which tools and applications you usually use when developing a game (favorite IDE, text editor, do you use static analysis tools, revision control system etc)?

Chris: I use TextWrangler on Mac to edit my source files, For version control it varies by project: for tiny solo projects I'll lazily just periodically zip the project folder and copy the dated zip to Dropbox or FTP. For larger, longer-term, or team projects this semester I've been using Assembla/SVN and GitHub.

Is there any specific library, framework that you always use on your games?

Chris: For my old PC freeware games it was Allegro for many years, for a few of my ActionScript 3 projects I've used Flixel. For the non-Flixel AS3 games I write my own engine layer atop Flash's core functionality. Of course when doing Unity projects I lean on the features that come with it.

What is your computer setup? Do you use Mac or PC? What specs? Do you have a dual monitor setup?

Chris: For my first decade or so I developed on a PC desktop, switched to a large PC laptop in college, then when I started developing iOS games in 2008 I changed to a Mac laptop. I have stayed with Mac laptops for Unity and AS3 development, even though I could of course do either in Windows just as well. I fairly recently upgraded from a large MacBook Pro to a MacBook Air, with the high end spec options, to reduce how much weight I'm carrying in my backpack. I occasionally connect it to a second monitor, though more often I'll just prop the laptop up so the screen is eye level, then plug in a mouse and USB keyboard to save myself from slouching over the screen or bending my wrists oddly while working for long periods of time.

Do you have any photos from your working environment & a screenshot of your typical development setup?

Chris: My working environment changes frequently - I have two work desks set up in my apartment (sometimes a third) that I rotate between, I'll sometimes work in a Starbucks or library or academic building, and generally I take good advantage of the laptop's mobility by working in different places as often as possible. No photo at the moment; my usual work desks are currently in disarray while my apartment is temporarily modified for video recording. It's just an ordinary desk though, with a laptop and office chair, a few piles of books and some spare pinball parts laying around.

Likewise, no screenshot of my development set up seems necessary, if that's alright. It just amounts to having a few windows of TextEdit open, each with several source files in the workspace, plus a few folders with the assets, recompilation script, and where the swf compiles to. Or it's just Unity and the assets folder open, probably with Photoshop and/or Maya open as well.

Which games inspired you the most? Do you have a favorite developer from the games industry (indie or not)?

Chris: Bubble Bobble has been my favorite game since a very early age. Over the years allusions to it have crept into a handful of games I've worked on, some references being quite overt while others are very subtle. MTJ was the character designer and gameplay designer for Bubble Bobble, though admittedly none of his other work appeals to me so I don't really think of him as my favorite developer. For favorite developer I'd probably say either Vlambeer, whose work I consistently enjoy, or John Nesky, who I've had a number of opportunities to work with over the years, I've always been impressed with his versatility and ability.

What’s the single piece of advice that you would always give to someone, and what is something that you will absolutely avoid/never do again?

Chris: My usual piece of advice is something that came up earlier in describing my process: don't write a big design document, instead keep it 1-2 pages of important notes plus a mock-up screenshot or two, then allow the game to evolve from there by iterating and exploring variations during early implementation.

In case that's too much like the earlier comments, the other advice I give developers, which I haven't mentioned here yet, is to practice all aspects of development (programming, game/level design, art, audio, writing, production), both the software tools and the processes or different ways of thinking, to the point of functional fluency. The point of this is to never get stuck waiting for someone else. Being able to unblock yourself by creating or adjusting placeholder assets or functionality is extremely freeing in setting up a developer to bring his or her own gameplay ideas to life, making them testable for iteration, to then refine them to a point to be presented in a compelling way to others.

Something that I will absolutely never do again: allow a business person to talk me into leaving something out of a contract that they insist, based on any kind of verbal assurances, doesn't need to be there. I've had a couple of negative experiences based on differences between what I was told verbally versus what I could get the other party to include in writing - a terribly naive error on my part made when I was just beginning my transition from freeware to doing paid contract work - and now at the first sign of laziness toward contract discussion or sketchy "just trust us" behavior I promptly cut off all business relations before they advance any further.

What is your opinion on the rise of free game development "suites" like Unity, UDK, CryEngine etc? Given that you already use Unity for your latest projects, is it safe to assume that you will use it for your next projects, or you will switch to an in-house engine?

Chris: Unity is outstanding for what it is, in terms of providing a fairly generalizable 3D engine with editor, support for virtually all common asset formats, and a great deal of scripting flexibility. There are certain types of high-end games that it's probably not the best choice for, but especially on small teams with limited resources it opens up a lot of possibilities that before were out of reach.

UDK, from my experience with it, makes much more sense than Unity for a large commercial team with enough experienced specialists on the team to put all of its power to good use.

I haven't worked with CryEngine.

Some of the projects that I'm on are being built in Unity, some are being built in AS3/Flash, one is on iOS in Objective-C using Cocos2D - I'm currently involved with more than a half dozen projects, and don't anticipate settling on any one suite.

Generally I still find it much easier to get people to play my AS3/Flash games (by the hundreds of thousands, sometimes millions) than to play games that I develop with Unity (hovering in the hundreds), potentially owing to the difference in people's willingness to install the Unity plug-in vs already having the Flash player installed. Although, alternatively, maybe I'm just more experienced in developing the types of 2D games that I continue to make in AS3/Flash, as compared to the dabbling in 3D that I do in Unity, which also reflects the relative bottleneck of populating a 3D game with appropriate art and animation. I tend to try to avoid or minimize that issue through resourceful style choices. At their best many of my games tend to reflect mid-90's gameplay, which was a time of fairly polished 2D games coexisting with rather rough, primitive 3D games, and that seems like it may be the same growing pain that I and some other small-scale developers are working through.

What are your future plans? What games are you working on right now?

Chris: I'll still be a PhD student in Digital Media at Georgia Tech until (estimating) around 2016. I anticipate that both the game industry, indie platforms, and academia may shift so much between now and then that I'm currently playing it by ear for what I might do after.

The games I am working on right now:

Ms Vision by Proxy: AS3/Flash, 2D platforming puzzle game. I did the programming and most of the level design. We released this game at the end of last month, and I'm still working on further promoting it and getting it in front of more players.

Black Oak Manor: Unity, 2D overhead networked action horror game. I'm doing a bit of level design and the weapon icon art.

Tibidabo: Unity, 3D Galaga or Starfox-esque game. I made explosion special effects, but otherwise haven't had much to do with this one.

Num Noms: iPad/Objective-C, a counting game for children. I'm helping with programming and art.

Fragile: Unity, 3D exploratory puzzle world. I'm designing puzzles as part of an open world level, and contributing a little in-game art.

Dreamwalker: Unity, 3D ghost game. I'm with this team to provide programming support, but haven't been needed much yet. I anticipate being a bit more involved near the end during debugging and polish.

Mesmerize: AS3/Flash, built using the Flixel library, in which a bunch of small humanoid characters swarm and interact on a playing field (core concept TBA). On this project I'm doing much of the engine programming, as well as helping with in-game art and core gameplay design.

Infection: Unity, 2D overhead, virus versus blood cells RTS-lite type of action. Here I'm just helping with sound effects and visual effects.

Unannounced #1: AS3/Flash, a friend is starting work on an overhead sci-fi action game that I may be doing art for.

Unannounced #2: iPhone/Objective-C or HTML5/JS, early design involvement for part of a research project that's in early concept, I can't say anything more about this just yet.

Unannounced #3: Unity, 3D navigational space puzzle, something I'm tinkering with on the side that's on hold until I wrap up some of these other projects.

Unannounced #4: AS3/Flash, for a tiny art game that I'm anonymously designing and programming for an East Coast artist.

Thanks so much for this interview!

Chris: Thank you!

❖

Stay tuned for the next episode next week! :)