The Journey

Our thesis goal was to experiment on the classic point and click adventure with indirect manipulation of NPCs through thoughts.

In the first iteration of our thought-manipulation mechanic, we went with a more traditional point and click approach, involving a playable character and an inventory. NPCs could have multiple thoughts in their heads at a time. These thoughts appeared one-at-a-time and cycled through. The player would swap entire thoughts with those in the inventory. An NPC needed to have the correct combination of thoughts in order to progress through the puzzle.

Because the player was dealing with full sentences, there was too much text on the screen and too much information for the player to process. In order to lessen the amount of text onscreen, we only displayed an NPC’s thoughts when the playable character was standing nearby—but this turned out to be an unnecessary burden for the player, requiring him to use the arrow keys to walk back and forth in order to see and solve the puzzle. Also, the cycling of thoughts required the player to do a lot of sitting and waiting for the thought they needed to cycle through.

In order to reduce the amount of text the player had to read, we switched from a sentence bank to a word bank. Each NPC only had one thought at a time, and that thought was divided up into pieces that the player could swap out. This led to two problems: first, the player could create nonsense sentences, and two, players often misinterpreted the meaning and effects of the words. Also, we removed the playable character entirely; the player now clicks on an NPC to see their thoughts.

In order to minimize misinterpretation issues, we removed the word bank and replaced it with icons. Through playtesting, we found that this actually made the problem worse.


In the final mechanic iteration, we removed the thought inventory entirely. Each thought has one section that can be swapped out—the player drags objects from the environment into an NPC’s thought to change the mutable thought section. The player still doesn’t know exactly what the result will be, but we leveraged this ambiguity for comedic effect.



We learned quite a bit from this project:

– Iteration is necessary for all aspects of game development.

– Player feedback is invaluable for refinement.

– We each held ourselves accountable for the things we specialize in.

– Teamwork made it all possible.

Publishing in sight

Our goal was to publish the game this Tuesday, but problems on all fronts prevented us from achieving it. Bugs (on my end), publishing MXML trouble (on Sean’s end) and unfinished logos (on Shane’s end) stood in our way this week. Shane and I are staying up till the early hours of the morning every night to crank through as many bugs and polishes as possible.

Because Box2D was not working well for the airduct animation, Shane tried to use 3DStudio Max to animate it that way–and ran into the same physics problems that I did. We have accepted defeat and have animated the tube falling by hand (which is not much of a defeat–the keyframed feel of the current animation fits much better with the style of the game).

I have been working night and day on many small, nitpicky bugs, like shifting art assets by 1 pixel or bringing a movieclip up a layer. “Bugs” such as these are a welcome relief from the more urgent bugs (such as Emma’s make it so button refusing to work in the second puzzle), and I try to fix a few small bugs in between each serious one as a bit of a break.

Optimizations, bug-fixing and polish

I spent a great deal of time this week working with Hailin to optimize the cutscenes, which are causing significant lag. Because the solar flare tween was the main culprit, we broke the tween up into individual frames (all the same flare image with different scales on each frame). This actually worsened the problem, and we decided to try using a different image for each frame (scaling in Photoshop rather that in Flash to save Flash the computations at runtime). Because this would require Shane to scale and save the solar flare ~120 times, I wrote a Java robot program to do the Photoshop work for him. While the robot worked beautifully, the resulting flare frames did nothing to solve the performance problem, and we have reverted to the tween we started with. We ended up lowering the rendering quality to bring the cutscene’s framerate up to an acceptable level.

We want to run the iOS build in GPU-accelerated mode (which provides a significant boost to rendering speed), but this mode does not support Flash filters, including the green glow we are using as part of our core mechanic. To solve this problem, Shane has rendered the glow for each object in Photoshop instead.

We have also polished up the solar flare cutscene (and others) with fun comicbook-style onomatopoeias.


We now have many new NPC emotions in the game, which add a great deal of polish and emotion. Adding these emotions has necessitated the reworking of the mouth movements for each NPC so that the mouth images (which previously included part of the NPC’s eyes) do not obstruct the eyes of each emotion image.

Ryan has finished the monkey, which turned out very, very well. I am very excited to see the game become richer and richer. My time was spent this week animating steam from coffee, working with Box2D to animate the tube, working with particle effects for the food printer, and bug fixing.

The tube physics are not going well. Because of how Box2D works, it is difficult to start the tube in the 90 degree angle in which it needs to start. I am not certain that I will be successful in this endeavor. In case Box2D does not work out, I have invested a little time in animating the keyframes of the tube’s motion by hand as a stand-in.

The ending cutscenes are in the game now, and, to take a little weight off Shane’s shoulders, I have animated them. Everything is coming together beautifully.

Monkey puzzle

This week has been spent on implementing the monkey puzzle (the one I designed) and adding in Shane and Ryan’s art (as well as bug-fixing, as always). Sean has decided that the game will consist of five puzzles–of which mine is the fourth–because we are running low on time. Sean has altered my puzzle very little–it serendipitously meshed very well with an airlock-cracking puzzle he had in mind–and we are quite happy with it.

Building the game to iOS has revealed some performance problems. Hailin has been tasked with optimizing the code, and I am spending quite a bit of time explaining optimization techniques to her. The main problem we are having is with the cutscenes, particularly the ones involving images converted from 3DStudio Max to pngs (the issue being that a new image is loaded every frame, and the images making up the cutscene have overlapping redraw regions).

We are preparing for EAE Fest, in which our game will be displayed at the end of the semester. Our feature lock is in three days, after which we will only be bug-fixing (both in terms of code and in art) and not adding anything new.

My puzzle

This week was spent implement the puzzle I designed for the game, which involves a monkey, a bowl of oatmeal, and a cracked airlock. When designing the puzzle, my goal was not to add anything that would require new art assets, but the puzzle ended up requiring art for the three objects mentioned above. The team, however, was enthused enough about the puzzle to agree to the additional work. For the falling airduct, Shane and I are hopeful that we can use a physics engine (Box2D) to animate the tube for us to save animation work. We don’t have monkey art yet, and so I have provided a stand-in.

Since next week is spring break, this week’s deadline is today (instead of Monday).

The problems with Hailin last semester are resurfacing. She has spent a maximum of 5 hours a week on the game, and so the level editor she was tasked with building has taken all semester instead of the two weeks it should have taken. As such, all the levels have been built, and there is no longer a need for a editor. I explained this to her and asked that she switch to working on the iOS build of our game. She refused, and had to be repeatedly asked and cajoled before she finally agreed to do any work. No amount of talking could convince her to stop work on the level editor, even though it is now useless to us. I am very unhappy to see that she has learned nothing from the events of last semester.


The Game Developer’s Conference in San Francisco is going on this week. Everyone on my team (excepting myself) is currently at the conference showing off our game. I was not able to go, which turned out to be advantageous to the team–have been able to provide support and last-minute bug fixes in case of problems during the conference.

Thus far there have not been any major glitches, for which I am very glad. I hope that our game is well-received.

JenJen, one of our producers, has an appointment with Double Fine, and will be presenting our game to them in the hopes that they will publish it under their indie label.

Writing my own puzzle

This week was spent fixing more bugs, including the following:

1) side bunk missing
2) starfield appears past the ship
3) the glow popup box breaks the game
4) menu gear under the background

Because my load was light this week, I also wrote my own puzzle for the game. I intended to write a puzzle that required no additional art assets, but the puzzle I ended up with requires an additional character: a monkey. Luckily, the team liked the puzzle and is willing to spend the time required on the additional art.