Hi and welcome to my project portfolio, there's a lot I'm excited to share with you!
I have a lot of energy and enthusiasm for making awesome stuff!
If you have questions about any of these projects or just want to
say hello feel free to drop me a line.
Self-Published Game: Starships Assembly
Starships Assembly is my most-polished, biggest project yet taking nights and weekends spanning 7 years. It all started with a challenge I gave myself:
Can I make a fun, interesting strategy game using as few parts as possible?
The crazy thing is, right from the get-go, I had some idea of the game using exactly 20 cards with the captains, the ships, the middle of the card being reused for damage, and all of those elements are in the final design. So what took 7 years???
The introduction video gives a quick summary of the game:
I poured a lot of love into this project! If you try it out and have thoughts, comments, good-bad-whatever, I would love to hear about it!
Self-Published Game: Legacy
Legacy is a strategy game for any number of players. Flip a card that shows a number, each player adds that number to one element of her legacy: her Empire, her Garden, or her Opus. After all players have chosen where to place the number, flip another card. Cards with a star are called journeys, and the game ends when you flip over the third journey.
The three elements of your legacy have different structures and scoring systems. The Opus is a string of numbers that alternate high-low, sort of like musical notes; the score of the Opus is the 1's digit of the numbers in the high position minus the 1's digit of the numbers in low position. The Empire requires numbers to alternate even-odd in a grid-like pattern where you want to build the biggest closed rectangle before time runs out. Finally, the Garden has a root and branches, where numbers that branch up must be lower than the number they branch from, so use a good solid trunk.
Legacy was reviewed favorably in the November 2012 issue of GAMES magazine, and later that year Legacy made the "Abstract Strategy" category of the 2012 traditional GAMES 100!
Multiplayer Maps for Existing Games
I LOVE LOVE LOVE when a great game comes with a great level
editor. Designing scenarios and competitive head-to-head maps is
something I've poured serious effort into! Below are some maps I've
made that are all available for download. I hope you find one for a
game YOU love!
Counter-Strike's bomb defuse game type, always the type used for competitive play, requires an ingenious blend of skill and strategy for players to master. I designed a bomb defuse map called "de_rio."
This was a big ~4-5 month project building a complete 3d map using Valve's Hammer editor.
Compared to the main competitive
defuse maps, "de_rio" is medium-small and fairly open. I tried to bring something new to the defuse design
by giving the bomb sites new and interesting approaches, and doing something different with the middle
of the map. Read an overview of the map's interesting features or
Starcraft II Melee Maps
I made many maps for competitive Starcraft 2 and shared my best with the community. Of the maps, Triangle Love Moon was a Top 5 finalist in Map of the Month #4 and you can see it in action in Mr. Bitter and CatsPajamas casting sixjaxdde vs. ROOTDdoRo. And Axis of Industry was customized for the USD500 : US & SEA : VISTA Cataract Cup : Malaysia tournament.
Warcraft III Melee Maps
The multiplayer side of Warcraft III broke new ground for RTSs. Neutral creeps are a resource for your offensive units to "gather." Armies teleport around the map, so attacking a base is usually a raze-one-building-and-split sort of effort. I like the feel of it, so here are some competitive multiplayer maps for the normal melee mode that I've tried to do something new with.
See a comparison to Blizzard ladder maps.
Before I discovered the competitive Starcraft scene via TeamLiquid.net, I mainly played Starcraft with my brothers and friends, none of whom were interested in head-to-head competition. So we played together allied against bots, always trying to add more to see if we could still win. So many of the maps I made for Starcraft were designed for humans to team up for a comp-stomp!
Warcraft II was my first RTS and it came with a simple but perfect map editor! What's really interesting about designing single-player scenarios for this game is the lack of triggers and objectives. You cannot program arbitrary enemy behavior. You simply win by eliminating the enemy buildings. But that doesn't mean the levels have to be boring! Some tricks I used to spice up these maps:
Tool: Starcraft 2 Map Analyzer
Starcraft 2 Mapping Community
Making maps for games I like is fun and a great design exercise, but for Starcraft 2 I got sucked into the online map-making community and made quite a few contributions to the scene.
Blizzard's tweet of my SC2 map concepts that I made before the editor came out were reposted at TeamLiquid.net and the high quality of the content and threads really got me engaged. There are just a lot smart people analyzing a game we all love and offering free content to this community, just as a labor of love. Maybe a modern Irish blessing could be, "May everyone find their corner of the internet." I definitely found mine!
Sharing SC2 Map Analyzer
Always my goal for making a competitive map for any game is to (1) do something new and (2) use analysis to ensure there are as few elements that break or bend the game as possible. And the latter is most definitely the hard thing. Some examples for SC2,
I wanted to make really good, competitive maps that were also solid when thoroughly analyzed. So I wrote this open-source tool (mentioned above) the SC2 Map Analyzer and shared it with the community. This turned out to be a big contribution and 5 years later and long after I stopped supporting it, the tool is still being used to analyze new maps and is called out in the ongoing TeamLiquid map contest as useful info to with a submission, where that content's goal is to produce new Blizzard-recognized maps for pro play.
My TeamLiquid post of the map analyzer has 60k views.
I wrote some articles to help the mapping community,
The biggie guide though is when I used my analyzer to pull data for the Blizzard ladder maps and summarized my findings for the community, Rush Distance Comparisons. This post has 25k views and is of interest to mappers but also directly to players that wanted to know the properties of the ladder maps to improve their competitive play. I made several major edits when the pool of ladder maps changed, and made this one off graphic to summarize the spectrum of rush distances across major maps,
A Founder of Map of the Month Contest
For over a year after release Blizzard did not include any community made maps in the ladder pool, and pros had no incentive to use valuable practice time on new maps that were unlikely to be featured in any given competition. The main problem with not experimenting with the map pools at top-level play is we could only speculate when a game issue might be fixed with new map elements.
A lot of folks in the SC2 map community desparately wanted to crack Blizzard and get them to accept community maps, so I joined a group to found the Map of the Month contest. Our goal was to galvanize the community, promote really good new maps that could make the game we all loved better for everyone.
Interview With Korean Mappers
Korean Map Makers
20k views at TeamLiquid.net
Part of understanding competitive Starcraft and it's communities is to realize that its heart is in Korea. Long after Blizzard stopped actively patching Starcraft: Brood War did the professional Starcraft scene really get going. And this was an interesting crazy thing where players rediscovered and revolutioned strategies within a static video game, practically unheard of today where all major eSports are constantly tweaked by the developers. Sorry for the digression, but the cosmic success that broodwar was after the designers moved on is something that will always amaze me!
Anywho, while almost no one in the world except some Counter-Strike players were organizing professional tournaments centered around networked video games, Koreans had whole professional teams competing on TV. Korean players destroyed the rest of the world at Starcraft, and it turned out that the first community made maps to make it into the Blizzard map pool came from Korean mappers.
This was bonkers-awesome news to the SC2 English-speaking map making community, so I got this crazy idea to reach out to them and with some help from my friend monolab to translate, I interviewed the most successful mappers coming out of Korea.
The mappers were very cool about it and some fun info and stories came out of it. Thanks again to those mappers for the their time and the great maps they made for us!! Here are their introductions from the interview,
Program Analysis and Compilers Research
I earned my Master's and PhD at the University of California, Irvine. In collaboration with my advisor Brian Demsky and my colleague Yong hun Eom I worked on a static heap analysis called Disjoint Reachability Analysis that supports a new, simple parallel programming model called Out-of-Order Java.
There are 71 citations to my research as of August 2015.
It is common for a program to process a large collection of things, and when those things are simple groups of bits like pixels, existing techniques can really do a wonderful job of processing them in parallel. It gets a lot harder when you build heirarchies of objects, and some objects are sharing children objects; these programs can be parallelized by hand but it is very difficult to automatically determine where the opportunities for safe parallelism are.
There has been a lot of research into automatic parallelization. One way to divide this large body is into program analysis that can run really fast (points-to) and so you can drop it into commercial compilers and get some benefits, but only so much. So for example, in a program with many complex heap objects that could be processed in parallel, a very speedy points-to analysis might conclude "I can't tell if there are separate groups of objects for parallelization, or if all these things are fully linked together." On the other end of the spectrum are analyses that visit and revisit the code under analysis to build up rich, very useful facts that could parallelize almost any program that had parallelism; if you're willing to wait for a result.
I'm proud of the new contribution we made here. We went for a heavier analysis, but not looking for the perfect answer. The property we wanted was, "All of your A's can reach at most one B, so there's no sharing of B's by A's, and therefore it is safe to process all A's in parallel." We don't care what the actual shape of the heap is, just the "reachability" of all things relative to the key top-level things that your big--hopefully parallel--loops are processing. That first part is the disjoint reachability analysis. The second piece of the puzzle is exactly how to use that for parallelization; we call it Out-of-Order Java. We said, first write a single-threaded Java program which is easy to test and get correct. Then use our one new keyword, "task", to tell us where your top-level loops are, and we will automatically parallelize the program as much as we can, AND the answer from the parallel version is guaranteed to be exactly the same as the single-threaded version. That last part is what could be very attractive. If you are an expert programmer and regularly write and debug concurrent code, you can probably do a fine job without Out-of-Order Java. But for someone who is not an expert, go ahead and tackle the single-threaded version and get that working, and we'll give you what parallelism we can for free.
Key Result 1: Disjoint Reachability Analysis
I developed disjoint reachability analysis with my advisor Brian Demsky. Our work (PDF) was published in the Compiler Construction track of the 2011 European Joint Conference on the Theory & Practice of Software (ETAPS). Saarbrücken, Germany hosted the conference; I had a nice time exploring the downtown area.
Disjoint reachability analysis is a static program analysis, specifically concentrating on the reachability relations between objects in the heap. There is a ton of research in heap analysis, a continuum from very scalable pointer analysis to heavy-weight shape analysis.
Our analysis is closely related to shape analysis in that they both use a richer abstraction than the basic points-to graph from pointer analysis or access paths from alias analysis. Shape analyses commonly abstract the heap as a set of heap regions (like in a points-to graph) and choose to summarize objects into a heap region if they share a heap shape (the same pattern of references coming in and out). Shape analyses can determine when some set of objects form a valid binary tree, or a linked list, or other heap shapes.
Disjoint reachability extends a points-to graph, like many shape analyses, but it adds a different abstraction. In our analysis we maintain a mapping of heap regions and abstract references to reachability states. A reachability state for a concrete object specifies which other objects in the heap can reach it via some heap path. We propose a reachability abstraction in terms of heap regions and an abstract count of objects from the region (0, at most 1, or any number).
Use in Parallelization
Our motivation for developing disjoint reachability analysis was to employ the analysis results in our parallel programming model called Out-of-Order Java.
Pointer analysis, alias analysis and related work generally compute sharing in the heap in terms of variables. Disjoint reachability analysis computes reachability (and can deduce the absence of sharing) between unbounded sets of objects. We believe a critical pattern in parallel computing is repeating a task over a collection of disjoint data structures; if you can prove parallel tasks operate on disjoint data, then the tasks are safe to execute in parallel.
Key Result 2: Out-of-Order Java
OoOJava is a parallel programming model and parallelizing compiler that relies on disjoint reachability analysis. I collaborated on both works with my advisor Brian Demsky and my colleague Yong hun Eom.
Our motivation comes from the current challenges in developing parallel software. Even experts make mistakes, and the bugs in parallel software are often hard to find and fix. It is more important than ever to develop parallel software because computer architectures are trending towards including more and more cores. The way to harness the power of additional cores is to extract the parallelism from programs cheaply so its concurrent tasks can keep more cores busy.
The goal of Out-of-Order Java is to start with a single-threaded model, like Java without any explicit threads, which is much easier to reason about and debug than current explicitly parallel programming models.
Consider the following program fragment in which the
Even though the call to
We simply wrap the line with parallel work in one task, and the line with a loop-carried dependence in another task. The power of OoOJava is that it will perform a program analysis during compilation and determine the dependences of the tasks automatically. Then OoOJava will generate an executable to execute the program in this manner:
In this example we expect that OoOJava will generate a binary that quickly executes every iteration of the main loop, issuing an instance of task a and task b for each loop iteration. The instances of task a will be ready and begin executing whenever there are free cores. The instances of task b have two dependences: they must wait until the instance of task a from the same loop iteration retires, and the instance of task b from the previous loop iteration retires.
So what's the gain from OoOJava? A parallel implementation that preserves the observable behavior of the sequential program. Once we've developed the sequential program to our satisfaction, we can obtain a parallel implementation for a relatively low development cost compared to explicitly parallel models.
What about related research? There is a large body of work concerning automatic parallelization and compiler-assisted parallelization, and deterministic parallel programming models like OoOJava. The primary contributions of OoOJava are
The primary drawback of OoOJava is that it relies on static analysis. Some programs, like those with irregular parallelism, do not have any parallelism to extract from our static analysis facts. Additionally, it is an open research problem how to scale OoOJava to very large programs; it currently handles programs with tens of thousands lines of code.
Bottom line? OoOJava is a best-bang-for-your-buck point in the parallel programming model design space. It allows you to write programs in a way that is easy to reason about, and it can deliver parallel implementations for programs amenable to OoOJava's static analysis. We believe this type of parallel programming model is essential for a future of mainstream parallel programming.
I worked for about 5 years at Northrop Grumman (NGC), most of that time on the Rocket Systems Launch Program (RSLP). I worked on the independent verification and validation of flight computers and software that guided rockets into orbit.
These are some of my mission patches. It was very interesting work; for example I worked regularly with guidance navigation & control (GNC) engineers, propulsion engineers, RF engineers, electrical engineers, so many other kinds of engineers. And I once had the good fortune to attend a launch!
Other Game-Related Projects
Crossword Puzzle in The New York Times
My dad and I got a crossword puzzle published in The New York Times on January 3, 2004. I devised a mind-tickling rebus-like theme. Dad did the grid fill, which is very hard even with software assistance to get a satisfying grid. Nothing's worse than a 90% wonderful puzzle and a corner full of Q's, A's and U's. Dad also wrote yummy tricky clues!
Will Shortz posted on the Times crossword forum that it was the most difficult puzzle he had ever published to that date.
The puzzle is not ours to distribute, but Dad came across an explanation of our puzzle on this blog with this mission to spread crossword love:
I've worked an average of just over one crossword puzzle a day since 1972. During that time I've learned a thing or two about crosswords, and I've even gotten a few of my acquaintances hooked on them. I want to hook you.
The author calls our puzzle "fiendishly twisted" and goes on to give us this huge compliment!
When was the last time -- whether in the field of crossword construction or any other -- that you came up with an idea this clever?
In the end, speaking on all the puzzles mentioned, this author found our work to be what we hoped it could be: the right balance of challenging and fun to make a memorable experience.
These rare puzzles -- the ones with a wickedly hidden theme that requires you to strain your imagination just to figure it out -- are by far the most enjoyable.
Pop Culture Website: XtremeWailing.com
Wailing is a kind of awesome scream-singing, and Xtreme Wailing is clearly what everyone wants to wake up to in the morning... if your day should be filled with katana blades and car chases.
That explanation of "Xtreme Wailing" is pretty much the tone of XtremeWailing.com, this nutty pop culture website my friends Rich, Drew and I founded in 2004.
Over several years we posted 100+ pop culture articles.
We didn't even really try to market the site! But we didn't care much, it was fun just sharing our articles with each other and making the podcast. Also, the site's message board is still up and collecting bots, probably all but 7 of the 6,620 registered users, so it's still interacting with the internet in some capacity.
Also, always remember to
Essay: "Board Game Design Informs Video Game Design"
After designing board games and video games for some time I've come to the conclusion that good board game design informs good video game design. The short explanation is that a board game experience has more deal-breaking design constraints. There can't be too many rules, or too many numbers for players to track or too many game pieces to update, nor can one sitting take too long. When a board game violates any of these maxims players quickly drop the game for good. There are many other facets to a good game's design that video games and board games share, but board game designers must take extra care to pare down to what is most necessary and effective because players, not a CPU, have to conduct the experience.
An analogy would be how good sketching informs good painting. Sketching in pencil has less degrees of freedom than painting, e.g. lack of color. However, an artist can refine shading techniques and experiment with monochromatic images while sketching and then apply those valuable lessons to the more vibrant realm of painting. Similarly, I offer three concrete examples of how principles drawn from the extra constraints of board game design can inform good video game design.
A common theme in board game design is to include a reference card for remembering rules, or to print action-reminder symbols on the board or playing cards. There is no computer to enforce board game rules; players may intentionally or accidentally make invalid moves if the rules are not clear to all players at all times. If players read the rules once and encounter effective reminders as they play then confusion and intentional or accidental invalid moves are minimized. It takes some clever thinking and many design iterations to craft a set of effective rule reminders, but it can make all the difference in getting a complete group of new players to understand and enjoy a board game together.
The idea of crafting rule reminders is clearly applicable to video game design. Video games are able to strictly enforce rules so that players cannot play invalidly, but that doesn't mean the experience will be fun--every video game player has experienced frustration when a game won't let them do something they perceive to be legal. Rather than learn this lesson the hard way, a video game design is better conceived by imagining, like a board game, that the player will likely try invalid actions constantly. How do you communicate the rules and remind the player of them during play? By considering this perspective during design a video game will evolve into a better experience.
Depth Without Complexity
The effort of designing a board game without simply heaping on complexity is often thankless. It is exactly like an audio engineer mixing sound for a movie; a well-mixed audio track sounds completely natural and goes unnoticed as the audience concentrates on absorbing the movie's content. But a bad sound mix is noticeably distracting. Likewise, a game with unnecessary complexity can confuse or tire players. A simple game draws players in easily, and if it also has depth they will stick with it.
The principle of depth without complexity applies to all games, and to video games in particular. Consider this: making a board game more and more complex puts immediate burdens on the players like having to remember 200 pages of rules. A board game designer usually gets instant feedback from players when added complexity is no longer improving the game experience.
With video games this feedback is harder to extract. The processor can do computations for the player, menus and information displays can be constructed to appear contextually; in short, unnecessary complexity in a video game can be mitigated with the power of interactivity, even though the fundamental design is not getting better.
A common example of unnecessary complexity in video games are the statistics of characters in a traditional role-playing game (RPG). RPGs typically feature eight or more characters that the player can assemble into an adventuring party, and each character is scored on various scales: intelligence, strength, magical power, etc. The unnecessary aspect of these designs is that the absolute stat values are unimportant. Does it matter that the level 4 knight has 31 strength and the level 4 mage has 12 strength? Not really, the numbers are arbitrary. What matters is that the knight always has more strength than the same level mage does, and if a weapon improved by strength is discovered by the player, it will be most effectively wielded by the knight.
So how could RPG stat design be improved? If an RPG were converted into a one-sitting board game, asking players to keep changing six or eight stats for each character at every level would be cumbersome. How about creating a reference card with a row for each stat, and a graphical icon of the characters appears in their relative ordering by that stat? So if we look at the row for strength we see a picture of the mage at the low end and a picture of the knight at the high end. There are no numbers and no calculations. We still retain this idea that there are several facets by which a character is measured, but we eliminate the unnecessary complexity of tracking details that are too fine to be of use. It is tempting to add all sorts of complex systems behind the scenes of a video game. But--a designer should ask herself if simply reducing the complexity will result in a more streamlined but equally deep experience.
Good balance in video games can be improved by balancing the "board game version" first.
Reflexes are usually irrelevant or much less emphasized in board games than in video games. Many board games, then, offer a slower, more deliberate thinking experience. With this difference in mind, let's suppose we take a fighting game like Street Fighter and make a board game out of it. Conceptually, it is like accelerating the players' reflexes to the absolute max, where they are able to block or dodge every straight-forward strike. In a board game like this, players must out-think opponents, instead of out-twitch and out-think.
To successfully balance this fighting board game each fighter must have a move set that allows for a variety of strategic options against every other fighter. If we analyze the move set and discover that Guile's moves allow an undefendable sequence when playing against E. Honda, then the move sets must be altered. This is an easier task with a board game than in a video game with reflexes in the mix.
Of course, video fighting games combine the strategy of out-thinking the opponent with reflex skills required to execute moves. I contend it is a mistake to start a design-implement-test cycle for a video fighting game without considering the "board game version" first, where every player has limitless reflex. If history teaches us anything, some players will overcome almost any reflex challenge to achieve undefendable move sequences or other game-breaking effects. Therefore, imagining the design of a video game as a board game first can provide a balanced foundation to build reflex-based elements upon. For example, video fighting games often feature stronger characters that require more difficult move execution--in this case we want to be certain that players who master such a character (i.e. become a player in the "board game version" with practically limitless reflex) cannot find literally unbeatable move sequences.
Video games, in comparison to board games, have an almost infinite design space. There are so many single- and multiplayer experiences that could never work as a board game. However, the principles that make a board game good can help zero-in on the best designs in the vast space of possible video games.