Languages and Libraries

• Fluent: Flash Actionscript 2/3, Python,
• Familiar: C++, SDL, Panda3D, OpenGL, PHP, HTML, CSS.

Concepts and Principles

• Adept: Object-oriented programming and design.
• Familiar: User interface design, artificial intelligence.

Education

Master of Entertainment Technology

Carnegie Mellon University, graduated May 2008

An interdisciplinary program encompassing technology and the arts, with an emphasis on interactive media.

Bachelor in Computer Science

Harvey Mudd College, graduated May 2006

Client Work and Employment

Senior Web Developer, Web Developer

Illusion Factory, Jan 2008 – Sept 2009

Developed websites and Flash games for clients from existing specifications and graphic designs. Wrote specifications and documentation to clarify client requirements and aid development. Led development of several projects. Coworkers frequently consulted me for assistance with software design and programming tasks.

Graduate Associate, Creative Development

Disney Interactive Studios, June-December 2007

Developed game concepts for new and existing Disney properties, and created pitch presentations for them.

Endo Patrol: Immunology Video Game

Regenerative Medicine Partnership in Education, January-May 2007

Designed and implemented the user interface for a video game to teach 9-14 year-olds immunology. Done for a semester-long project course at Carnegie Mellon.

Object-Based Storage Device Simulator

Sandia National Laboratories, September 2005 to May 2006

Designed and implemented the load generator for a supercomputer storage device simulator in C++. Done for a year-long project course at Harvey Mudd College.

Elixir Vitae

Professor Elizabeth Sweedyk at Harvey Mudd College, May to July 2005

Programmed an adventure game to teach college freshmen about protein synthesis. Used the C++-based Adventure Game Studio engine.

Course Work

Building Virtual Worlds

September to December 2006, Carnegie Mellon University, Building Virtual Worlds

Created small virtual worlds in two-week rounds. Primary duty was sound and music designer. Also acted as producer and secondary scripter. Worlds included Predator vs. Alien, Prisoner of War, ArtZooka, Treasure Quest, and Turtle vs. Crab.

Astral Schism

April 2005, Harvey Mudd College, Gender in Game Design

In a team, designed and created violent and non-violent versions of a side-scrolling game. My duties were composer, artist, and game balancer.

Available: Astral Schism

PyMotion

October 2004, Harvey Mudd College, Harmony of Sound and Light

Designed a system using Python SDL to create John-Whitney-esque visual music. Wrote a short piece using the system.

Available: http://selenetan.com/portfolio/pymotion.html

Awards

Bully Pulpit Games Owlbear Game Design Challenge

Second Place, August 2006

National Novel Writing Month

Winner, November 2004, 2009

One feature of Simple Sudoku is that it automatically shows the candidates for a square. This takes away the tedium of having to manually eliminate the obvious candidates, like 9′s in a row that already has a 9. Still, the candidates sometimes look like a mess.
Simple Sudoku solves this with a feature called candidate filtering. What it does is highlight all squares that might be a particular number, e.g. all possible 9′s. This makes it easy to see, for example, when there’s only one possible 9 left in a column.

Candidate filtering is good for slightly more advanced deductions, as well. Let’s say you have one 3×3 cell where all the possible 6′s are in the same row. You can eliminate 6 as a candidate from the rest of the row. Or, visually, you can do this:

There is an advanced Sudoku technique called coloring or linked candidates. It involves forming a chain of candidate squares where you know that some of the squares contain the candidate, and the rest do not. However, which set of squares contains the candidate is unknown at the start. The technique involves “coloring in” the candidate squares in an alternating pattern, e.g. with blue and pink. If any pink square contains the number, then all pink squares will contain the same number, and all blue squares will not. The reverse is true as well.

The technique can be difficult to understand from a description, but in Simple Sudoku, it’s really easy to do. Filter candidates so that, say, all 5′s are shown. Find a place where there are only two 5 candidates in a row, column, or large cell. Color one of the squares pink, and one blue. Then continue the chain as long as you can find links where there are only two 5′s. If you see two pink neighboring each other, then the pinks don’t have 5′s and the blues are the ones with 5′s.

Coloring turns a painstaking deduction problem into a simple pattern-recognition problem. Going through the chain of logic step-by-step takes a while and can be prone to error, but marking squares as colors is easy. And on the computer, it’s easily reversible. I’ll often start coloring squares even when “simpler” deductions can be made because in Simple Sudoku, coloring is a simple deduction.

In general, as you get better at a type of logic puzzle, you start recognizing common sequences of deductions. Internally, you formulate a series of rules: “If this, then do that.” What Simple Sudoku and other good puzzle interfaces do is 1) Make it easier to notice common deductions, and 2) Make it easier to spot the “If this” part of your rules.

Changes in this version:

1. Fixes bug where the upper-left turret is unclickable
2. Fixes bug where sometimes the red enemy square is unclickable
3. Fixes bug where on very high levels, the level never starts
4. Turns off debug flag so turret layouts are randomized between 4 choices instead of just one
5. Background music now loops

So what caused the unclickable-things bug, and how did I track it down?

With the help of debug output, I discovered that when a turret or enemy was unclickable, it was because something else on the screen “stole” the click event. In the unclickable upper-left turret bug, the click event was going to the flare display in the upper-left. In the unclickable enemy square bug, the click event was going to an object with a name like SpriteXXX. XXX was a number that was larger the later in the game the bug appeared.

The object name was my biggest clue. The number meant that it was a sprite that was created every level. The turrets are created anew every level, but they show up as TurretXXX. So I combed through the code until I found a sprite that was being created every level.

The sprite I found was the little explosion graphic that shows when you click on the enemy turret. In my competition-driven haste, I’d written code that created a new sprite every time the explosion went off, and didn’t bother to make it unclickable, or remove it from the stage afterward.  To fix the bug, I modified the code so that it created the explosion sprite only once and reused it every level, and I made sure the sprite was unclickable. That fixed the bug.

Screenshot of older version of SEEK*TOR

The best thing that happened for the game occurred when I sent my Saturday prototype to a friend for feedback. He told me two very important things:

1. He had the most fun figuring out where the hint circles intersected
2. He wanted to know why you had to aim and fire to reveal the map instead of just placing light bulbs around the “platforms” (yellow diamonds)

So I made the hints persist but fade over time. That means you can see the hint circle intersections, but the screen doesn’t become overly-cluttered with old hint circles. It also means the aiming mechanic is important, since if you take too long, the previous hint will have faded away. I also changed the theming of the game so that the portals became turrets and you selected a turret to fire from, rather than teleporting between them.
Sunday was mostly a day of polish. The big feature changes were implementing multiple levels, scoring, and flare limits. I also added the start, game over, and between-level screens, made the graphics, (such as they are–hooray for GlowFilter!) composed a background track, and created the sound effects.
In the end, I was successful in terms of having a pretty-much finished game at the end. On the other hand, seeing some of the other entries, I kind of wish I’d done something a little more ambitious…
Things that worked out:

1. Using abstract glow-y vector graphics instead of trying to draw. (I spent about 20 minutes attempting to draw a single turret before deciding my time was better spent elsewhere.)
2. The game selects from 4 (hand-crafted) turret layouts and randomizes the enemy and player locations. That turned out to be enough randomization that I didn’t need to make a turret layout generator. In fact, I only just realized that I left the game in debug mode where it always chooses the same turret layout.

Things that didn’t work out:

1. When I started, I implemented everything in one file just to see if the core mechanic would work. I made such a mess of my code that I spent hours late Saturday night moving code around so I could add levels. Spending hours working on code without actually adding new functionality–even regressing at times–was very hard on my morale.
2. I spent too long trying to make my git history tidy. I’d keep forgetting to add a file to the commit or not commit for a while and wind up with a gigantic commit that involved 3 features and all the source files. Then I’d try to figure out how to break up or revise the commits. (And how to use vim, since that’s the default git editor…) Given that I never had to revert to a previous version, it was kind of silly of me.

Tools and Libraries Used:

1. FlashDevelop
2. TweenLite
3. git
4. ACID Music Studio
5. Free VSTi soft synths: Crystal, LazySnake, and ErsDrums
6. Audacity
7. sfxr

(cross-posted from Ludum Dare)

In RAD you control the Efusjonaut, and must absorb eFusjon to neutralize free radicals while avoiding toxins. The Efusjonaut is controlled with the mouse, and can switch between an offensive toxin-eliminating mode and a passive free radical-neutralizing mode.

I came up with the gameplay concept and led the project. A graphic designer came up with the look and feel for the menus and an animator/artist created the main game art and sprites. I incorporated everything into Flash, set up the overarching code structure, and programmed the gameplay and scoring. Other developers worked on the leaderboard score submission, some of the menus, and the instructions. After some testing showed that people were confused about how to play, I came up with and implemented the idea of adding pop-up tutorial messages in-game explaining things.

Links:

• eFusjon Gaming is the official game website, including details about the promotion
• eFusjon RAD is the page where you can play the game. Registration is required because the game is part of a contest.

When you code scan something, it adds a page to the book that describes the object and shows its “codes”. Codes are blocks of different shapes and sizes that represent various qualities, such as Fire, Snake, or Justice. The codes are arranged on a grid (the “mental map”), and you can “rewrite” the codes by swapping them around.

The Sword page and the 4 hot-swap code slots.

You’ll find item bases scattered through the game, and you modify them by swapping codes. The above picture shows the Sword base with one Fire code, making it a “Fire Sword”. There are also recipes for specific items, e.g. the set of codes you’ll need to make the Sword into a “Champion Gladius”.

Making the recipes is a painstaking process. You have 4 slots of “holding” space to transfer codes between pages — all other codes have to be on a page. So if you decide you want that Champion Gladius, you have to:

1. Look through all of your pages to see if you have enough codes to make it
2. Empty the Sword of codes not in the recipe and dump them on other pages
3. Transfer the desired codes onto the Sword, 4 at a time

Like I said, painful. I wound up entering a list of all my codes and their pages into a spreadsheet with columns for code type, size, and which page it’s on. Basically, a database. For step 1, I sort the columns by code type and size, and look through them to see if I have sufficient codes. Then comes the transfer process.

There are two issues with transferring: keeping the database synchronized, and locating the pages referenced in the database. The first is just tedious. The “proper” way would be to update the database for each transfer between page and hot-swap bar, but I usually skip recording the transfer to the swap bar and just change the code’s location from source page to destination page.

When attempting to locate pages, I often find myself wishing the book were a densely-linked website.

The Table of Contents

There are a few ways to navigate the book:

1. Click on either of the bottom corners (where the page numbers are) to turn the page in that direction. Hold down the corner to make the pages keep turning until you let go.
2. Click on one of the labeled buttons at the top of the screen: “Index” goes to the table of contents, “Player” goes to the player info page, “Data” goes to the save/load screen, and “Map” goes to the map of the current area.
3. The Table of Contents page has a list of links to broad sections, like “Monsters” and “Weapons”. The first page of each section is a table of contents with links to sub-sections, e.g. “Sword” and “Bomb” for Weapons.
4. The four colored buttons at the top are “Spirit Bookmarks” which you can place on any page that doesn’t already have a bookmark. Clicking the button will take you directly to that page. By default the Spirit Bookmarks are placed on the pages of their respective spirits.

Some issues:

1. When holding down a corner to keep flipping pages, the pages don’t load until you let go — all you see is a blank page. I can understand not loading all the information, but at least loading the page titles would have been helpful.
2. There’s no button to go to the section table of contents from a page.
3. Pages don’t indicate which subsection they’re in. This is largely an issue with the monsters, since it’s not immediately obvious whether something like the “Wood Bone” monster is a “Construct”, “Undead”, or “Humanoid”. (The number of monsters doesn’t help.)

So what would my ideal user interface for this system look like? There would be more views of the data, for one:

1. Text-only lists of pages (items, codes, monsters, etc.), with options to sort alphabetically or by page type. Entries would link to the page.
2. Lists of available codes, sortable by code type, size, or assigned page. A bonus would be small images of the code blocks, since they have different shapes.
3. Breadcrumbs or tree-style navigation, so you can always see what category a page is in and quickly navigate up and down the hierarchy.

Here’s a mockup of one way to make code browsing more pleasant:

An item page with an added pop-up code browser

This is an item page. I’ve added a window with a scrollable list of available size 3 Silver codes. Breadcrumbs let you go up to search for a different size of Silver codes, or a different code type altogether. Each entry in the list states what page it’s on, and shows the shape of the code. The idea is that you can drag a code straight from the list onto the page you’re viewing. There’s still a swap area so you can rotate the code before placing it.

As for browsing, I think the game would benefit from (at least) one level of “go back”, so you can always return to the page you were just looking at. With that functionality available, clicking on a page name in the code browser list should take you to the page. This is useful if there’s more than one code of a particular type on a page and you’re wondering which one to take. Then you can just click the back button and go back to the page for the item you’re trying to assemble.

And here’s a mockup of page browser:

I’ve added a page browser window that pops up like the code browser. It’s a simple, scrollable tree-style navigation list. There are headings for the major categories; double-click one of them, or click on the “expand” icon next to it, and the list will expand to show the subcategories. Double-click a subcategory or click its “expand” icon, and it’ll show a list of pages. Click on a page name to go to that page.

This strays pretty far from the book interface model that Avalon Code is trying to use, but you do a lot of things with the Book of Prophecy that you would never do with a real book. If I did want to stick closer to the book model for browsing, just two improvements would go a long way:

1. Alphabetize the pages within categories. Dictionaries and encyclopedias are easy to browse because they use a well-known, easy-to-remember ordering. You know if you open a dictionary to the middle you’ll be in the M’s. I do wonder if the pages have a similarly meaningful order in the original Japanese, that wasn’t carried over during the localization.
2. When flipping pages by holding down one of the corners, show page titles. The flipping-pages action is similar to “leafing” through a book, but with no information during the page-flipping, it’s like leafing through a book with your eyes closed. Sure, you might get to the right page if you’re lucky, but it’s more likely you’ll have to stop and peek several times.

In the end, Avalon Code has some pretty neat game elements, but I can’t help but wish for a better interface.

The most common way I’ve seen to make a game with story “replayable” is to limit the amount of content you can see in one play-through. Multiple endings, multiple character choices, branches in the story — these are all ways to restrict available content. Of course, games usually limit the impact of such choices, making the replay basically the same as the original. And some gamers don’t even bother with a second run, wasting the effort that went into producing the replay content.

I think the issue is that games with stories tend to have a lot of fluff — not exactly filler, but activities that are only interesting because of the crumbs of story interspersed. Sometimes even the crumbs are boring the second time through, so new content has to be added to entice people into replaying the game.

On the other hand, people re-watch movies and tv shows, and re-read books all the time. (I’ve certainly read my favorite books more than once.) Sometimes there’s new content, e.g. an extended edition of a movie, but usually not. There are two reasons this is more common:

1. It takes less time to re-watch a movie than it does to re-play a game.
2. You can skip to the good parts.

Number one I’ve seen addressed a few times in RPGs. The most common method I’ve seen is the “New Game+” mode, where you start the game over but keep your items, experience/levels, and/or abilities from your initial run-through. Since most of your time in an RPG is spent in combat, this speeds up the replay pretty well. In Chrono Cross there was even the ability to speed through cutscene text. (Although at that point I started to wonder why I bothered.) In adventure games it would be nice to have a “solve this puzzle” button available on a second play-through; I haven’t seen that implemented. I suppose walkthroughs fill that role.

Inability to skip to the good parts is what makes the time factor such a big deal — few people are willing to play through 4 hours of game just to get to a single 2-minute cutscene. To some extent you can get around this by making multiple saves; I know I had a lot of saves in Final Fantasy VII just before cool cutscenes or bosses. One issue with this method is that you don’t necessarily know before going in whether a section of the game will be worth seeing again later. Another issue is that it can take up a lot of space, although this is less of an issue now that modern consoles have more than 1 MB/15 slots of space for savegames.

Some games have skipping to the good parts built in. In the recent Half-Life games, once you’ve completed a section, you can choose to start playing from that point. You’re given a standard set of equipment/ammo, and the checkpoints are frequent enough that you can pick almost any part of the game you want to play again. Games in general seem to be getting better at this kind of replayability — Mirror’s Edge and Saint’s Row 2 also make it easy to re-play specific missions. Unfortunately, the games that really need it (i.e., RPGs) don’t seem to bother.

Replayability of the more-content kind is nice to have, but replayability of just-the-good-parts goes a long way towards encouraging me to revisit a game.

Let’s Shooting Love is a Geometry-Wars-style arena shooter about a lonely robot looking for a girlfriend. It was created in Multimedia Fusion, which we decided to use since one of the team members (Sebastian Jansiz) was an expert in it and promised even faster prototyping than Flash.

I was responsible for designing and implementing the enemy behaviors. I brainstormed a lot of potentially interesting behaviors and played other arena shooters for inspiration. Then I had to figure out how to implement them in Multimedia Fusion, which I had never used before the Game Jam.

I created both enemies and enemy generators, setting them up so that Sebastian could easily adjust parameters such as speed, hit points, and generation frequency. I made a wide variety of enemies, including ones that travel in V formation, ones that circle-strafe the player while firing shotgun bursts, and ones that break apart into smaller enemies when defeated.

Links:

• Gameplay Video
• Official Website
• Download

The goal of the Real Video Gaming project was to create an interactive Flash prototype of a casino interface for a handheld touchscreen device (the Samsung Q1 UMPC). The intent was to allow casino patrons to continue gambling away from the physical tables.

The prototype presents three games: baccarat, roulette, and a slot machine. In baccarat and roulette, bets can be placed by dragging and dropping chips onto the appropriate locations. After the bets are placed or the slot machine is started, a video plays showing a casino dealer playing out the game. In roulette, the user can use the “Languages” menu to change the dealer to one speaking the appropriate language.

I was lead developer for the project. I researched and wrote specification documents, and created the class framework for the program. I also programmed the bulk of the project, excluding the slot machine and drinks menu.

The prototype can be viewed here.

Play The Admirer’s Secret (Be patient–the SWF file is 7.5 MB, and there’s no pre-loader since it was meant to be played locally)

The structure of the piece is basically a choose-your-own-adventure. Players choose which of the five suspects to visit, and after visiting them all, the culprit is revealed. There are five endings.

Implementation Notes

Streaming

This was my first experience with streaming media in Flash. There’s a lot of audio and video in the project, and I didn’t want to have to wait to load all of it at the start, so streaming was the obvious solution. It does make it a little more difficult to move the files to different directories, since the directory the SWF file is called from has to be the same as the one all of the media files are in.

Templates

Since the structure for each of the suspect visits is the same, I decided to create a single template with slots for suspect portrait, description, audio, and transcript. I used a naming convention and the eval() function to pull the correct files and movie clips in when requested.

Ending Mechanic

The ending a player receives is determined by which suspect the player visits first. Since the ending is revealed only after all suspects have been visited (with one exception), most people have forgotten who they visited first and the identity of the culprit comes as a surprise. On the other hand, it means that anyone trying to systematically get different endings by varying the order of visits will take a long time to see them all.