Enigmo: Explore

Me and Chance Ivey wrote a bit about the development/release of the recently-released Team Chaos zen-inducing physics puzzler, Enigmo: Explore, on game industry site Gamasutra.

When given the opportunity to work on the Enigmo franchise, we all had a small moment of personal joy, as the game has always been special to us. I recall Enigmo being my very first phone game purchase, and how much it reminded me of an extremely important game from my childhood – The Incredible Machine. With simple controls and goals, both puzzle and dexterity elements to each level, I loved everything about this game.

There’s something magical about those “old-school” puzzle games; The Incredible Machine empowered its players with something that’s been lost over time: the play-in-the-sandbox feeling. It would provide you with a puzzle, a variety of tools, and then you, are the player, were on your own to figure out how on earth you were supposed to solve the puzzle at hand given a seemingly impossible set of items with which to solve it. Enigmo was the same way; you had a puzzle in front of your face, you had your toolset, and beyond that… You have your brain.

And, as it turns out, your brain isn’t quite as trustworthy a puzzle-solving tool as you’d like to think it is. Games like The Incredible Machine and Enigmo had this way of intensely focusing your puzzle-solving efforts in one direction — thinking that’s the direction that you had to go in order to solve the puzzle at hand. When, really, one small course correction along the way would have solved the puzzle in half the time, with half the brainpower, and reassured you, as the player, that your spot in MENSA was still there waiting for you. It’s a magical quality of these types of puzzle games; no guiding hands, just the reassurance that the puzzle in front of your eyeballs can be solved. Even if you weren’t sure how.

We’re eagerly awaiting the v1.1 patch which will single-handedly remove the most-despised feature that managed to slip into our v1.0 launch: the time-dependent one star level completion.

And, beyond all that, I’ve also got a whole new game — the first that I’ve fully designed and developed on my own (in collaboration with a particularly talented Chaotic Moon Studios illustrator, Alan Defibaugh) — coming to iOS real, real soon that I’m excited to share about.


As of tomorrow, May 8th, 2012, you’ll all be able to buy your own copies of Starhawk! I think you should do this.


I’ve been working Starhawk since I left Stardock almost three years ago and moved out to Utah (and then to Austin). It’s been weird to freely talk about the game at all, but it’s even weirder to see the game in stores, ads, and the fact that people are a mere fourteen hours away from buying it and playing it themselves.

My focus on the game has primarily been mission design/implementation, cut scene design, inner loop tuning/balancing, and writing a whole lot of LUA script for our missions, tools, and other systems. All things considered, I ended up working pretty heavily on five of the missions in the campaign. I also ended up doing a final (and in some case, last) pass of refinement/camera movements/scripted sequences throughout every mission in the campaign in the final weeks of development. It’s been a great project and we’re all super proud of it and hope y’all buy at least a few thousand copies per-person in your family.

More importantly, though, is that I think our team here at LightBox Interactive has accomplished truly impressive and my coworkers are all totally ace.

Balance Source Release

Around a year ago, I released the first of what became four straight particle-only games in Unity. The game, Balance, was both my first attempt at a more rapid design and development cycle as well as an attempt to treat a game as a very focused expressive piece (kind of like a short story). Balance is also still my only attempt to make a one-button game ever and, aside from Broken, it is my favorite of the games I’ve worked on independently.

Anyway, point is: someone recently asked me if I would release the source for any of these recent games, so I am! All of the content that I think is necessary to build the game (under Unity 3.0) can be found here. I also uploaded a new build of Balance with a couple bug-fixes and an improvement to the postprocessing effects.

This release does come with the obvious caveat of: things are ugly. I treat the programming of my independent projects like one would a rough sketch; too much thought into architecture and system design generally just impedes progress when it’s late at night and you’ve been drinking, so I just generally roll with it. I don’t think this is as big an issue with Balance as, say, Broken or my current project, since Balance is a simple game, but who knows! Do let me know if there are any issues or if I neglected to include some critical file or what not. And if this actually proves useful to anyone, I’ll do similarly for Doubt and In the Wind in the future.


Broken is my newest game; you can click the above image to check it out. Alternatively: here. There’s also a Universal Mac OS X build and a Windows build.

It is, to some extent, a game I’ve been wanting to make for a long time but, well, it ended up going in a somewhat different direction than I had always wanted to take that game. Oh well. The metaphor isn’t exactly what one might call subtle. It’s a strangely personal and yet impersonal game and I’m glad I finally got around to making it. And I owe a big thanks to colleague Josh Sutphin for composing some music specifically for the game based on a prototype and some information that I passed along.

And I guess when I said that I was done with the particle-styled games I was, really, just completely lying. I just like the style too much.

Aside from the more narrative/thematic goals I had for the project, I wanted to do something to evolve the style I’ve been working with for the last year while still keeping to the fundamentals of it: abstract visuals and a very dynamic scene. This was also my first project using the new version of Unity, so I wanted to see what kind of visual effects I could work in that I hadn’t messed with before. Strangely enough, the two biggest changes I made had nothing to do with the change in platform at all, just a change in how I composed the scene. The first step was putting a 2D plane in the scene and attaching point lights to every object, then modulating the range/intensity of that light whenever I wanted to draw attention to the object (generally when it was hitting something or when the object was destroyed). The next step was creating a 7.5%-sized render target — which was a duplicate of the finalscene minus some additional post effects — and overlaying that on the final composition for the pixelated look. Without any bloom, the frame buffer acted as a new-retro-styled bloom effect, which I really dug. I then went the extra unnecessary step and added Star Trek (2009)-style lens flares to everything, though, because… Well. That one has no deep meaning. I just thought it looked good. The final real stylistic step was to also apply a noise filter to the 7.5%-sized render target to get a more dynamic background.

One of the goals I had for the new style was to incorporate more pixel art into the game, but I really only did that with the individual heart pieces (the mines are untextured 2D quads too, I suppose). I’m going to be relying a lot more on low-fidelity pixel graphics for my next project.

All things considered, I’m happier with the way the style turned out than I am the actual game systems, but the design of the thing does accomplish all of the “storytelling” goals I had for it. Those goals just happened to turn out to be far more cynical than I was originally anticipating. Still, I’m curious to hear any reactions to the game. The next project, which I’m loosely describing as a “Monster Hunter shmup” at the moment, is going to be a somewhat more traditionally-played game.

One of the experiment that came out of my visual style exploration is the following image; I think this game needs to be made:

Next Up

I haven’t neglected this site, I’ve just chosen to go from a weekly entry to writing lengthy posts on more interesting, more well-considered topics. I’ve also been working on a few new projects. The next of which is this (and, no, there are no compression artifacts in the image):

And aside from Halo Reach, ClaDun: This is an RPG! is probably going to end up being one of my favorite games of the year.

The Particle Trilogy

As a little break from Caper Corp., I finished a making a new video game this weekend. This one is called In the Wind. Much like Balance and Doubt, In the Wind’s entire visual style is driven by particle effects. Well 2D text too, but that’s only because making particles to represent text looked ghetto at the size I needed the text to be. In the Wind brings an end to the particle trilogy style of games I started back in December. This game would have been completed back in January or so, but unlike both Balance and Doubt, In the Wind was started more because I liked this color composition:

Unfortunately, that was really all I liked about the game that I was thinking about making, so it never really got beyond some movement physics, a wind effect/simulation, and the tree. My goal with the game was to always convey a “natural economy,” in that everything in the game was able to act because of the energy the center tree provided, and the player’s goal was to just feed more and more energy into the tree. It was an okay idea, but I never really had the thematic commitment to it that I did for the other two games. My goal with the particle projects was: no more than seven average days of work (so an hour or two after work and then maybe a weekend afternoon) and a set of systems which mechanically conveyed a single, coherent theme. For Balance and Doubt, I had the theme and the systems down for what I wanted to convey and, between the two, Balance is the only one that really succeeded as a fun little project (though I still have some love for Doubt, despite that). For In the Wind, I never really had that and, as a result, despite the second wind I got that drove it to completion, the game kind of waffles. The other problem was that after a night of work on In the Wind, I was already prepared to go back to work on Caper Corp., so it was this weird divided interest.

Still, I was able to get In the Wind done in a fashion very similar to the other games in the series: a Saturday after returning from a run I realized I had to scramble together all of the final elements (usually some systemic touches, audio, and a starting/ending screen), upload it to my site, post to Twitter, and get some quick feedback, incorporate those changes into a new build, and voila. New game.

Working on these three games with the self-imposed constraints under which they were worked on was a fun little endeavor. It was nice to do something a little bit different and to establish a visual style that was (hopefully) uniquely mine and explore some one-off systems. And now it’s back to Caper Corp., which should have another entry forthcoming at some point in the next week or two.

Final games in the particle trilogy (because they’re not real games if they’re not part of a trilogy):

Caper Corp.’s Got Stories (and Stairs to Connect Them)

Caper Corp. is nowhere near even approaching the mere concept of alpha, much less completion. That said, I like to write about the development of the games I’m working on from time to time. This is one of those times.

Most of the work over the last week on Caper Corp. has been to get stair connectivity working. So, as it works now, I place Stair objects in every floor plan that I make in the editor. The Job system (the Job being my script classification for a high-level caper) then determines what level template to use, and the level system generates a level from a series of floor plans that match that template. Templates being, at the moment: casinos, banks, and hotels (I’m thinking about making “Surrealist” an actual template whose jobs consist of illogical parameters too). Anyway, the level generates the entire building for a job from a series of floor plans. Each floor plan has all of its necessary objects pre-placed by the designer (me) so stairs aren’t created in super absurd areas of the floor. This will result in variations from floor-to-floor, since I don’t want to hold myself to rigid floor dimensions/standards for every floor plan, but I think that’s okay. The stairs are then generated from the lowest floor to the top. Half of the upper floor’s staircases are used for current floor (the lowest) to the upper floor levels, connections are generated, and the unused staircase on the lower level is disabled so the player never knows it’s there. The algorithm then goes up to the next floor, uses all remaining staircases to generate connections to half of the next floor’s staircases. This results in all stair objects being used, remainders being discarded, and a surprisingly simple and error-free procedural algorithm that I wrote in twenty very focused minutes of work one night.

And then an hour or two of bug-fixing the next morning because nothing ever is that simple.

Next on the list, since I’m still kind of making up the actual core game as I go along, was to start adding some of the more heist-y elements to the game to get that game logic in. I know I can do a top-down shooter pretty well since I’ve done it before in Asplode! and all of the subsequent prototypes I’ve made that I never took very far, so my goal right now is to make sure I can do the pseudo-stealth/sneaky stuff. I added a security camera and a light security terminal (and a player spawn point object, but that’s boring). I also realize, now, that I should have added a laser trip or motion sensor or something so I could setup linking triggers/objects with their security consequences. Anyway, I got those three objects in and realized I have like a nine-step process to add new object types to the game/editor, but once they’re in they’re theoretically flexible, so I’m tepidly okay with that. I was actually kind of surprised that they saved/loaded just fine when all was said and done (a revelation which, also, is somewhat concerning) and I was able to make some improvements to the editor along the way.

With the camera in, I need a way of displaying its field of view, so I’m also going to start tackling the lighting system for the game. Ideally, I won’t have to resort to tile-based lighting like most Rogue-likes (and, I think, Monaco), and can instead use the style present in the following screen shots. Problem with this style is that it’s per-pixel lighting and actual shadows are being cast/received, so the potential performance hit may be significant. I’m really hoping that the fact that none of my objects or shaders are complex allows me to use a decent number of lights without penalty. I’ve had to start adding actual height to some of the objects in the editor so that shadows will be properly cast, too, which made for a neat Unity editor shot of my test bank level:

The next development goal is to properly expound on the mechanics of some of the security objects. The first step of this is to start establishing some of the higher-level parameters of the job (the heist) and the integrity of a floor’s security (and that of the building as a whole). This will start getting into the basic logic for infiltrating a building at the beginning of the job which, from where I am right now, is probably the biggest unknown in the game’s development. I don’t really plan on having an elaborate tactics/planning stage like the early days of Tom Clancy’s Rainbow Six, but I do want to simulate that same sense of intentionality to the early portion of each job. Wen a player starts a new heist, I want the various characters involved in the job to all be on nothing more than reconnoissance duty. The gameplay goal being to scope the building out — at least the floors that are readily accessible for the ‘public’ (those whose entry won’t start requiring active infiltration) — and getting operatives in place before actively beginning the caper.