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)

At some point, I came up with the idea of showing the player a scrambled version of the correct answer. That would leave it up to the player’s skill to get the correct answer from it, so it wasn’t a guaranteed success but would still seem fair. Then I had to come up with an algorithm for scrambling words that wasn’t too easy, but wasn’t too hard for anyone to solve in the time limit.

Try 1: Scramble the whole string, including spaces.
Sample: UM  LOYDE L AYEYO HHIAS LSRT MNP OTIM NOPKATSFOHA EEFEN

This was dead easy to code and incredibly hard to solve. Scrambling the spaces in with the rest of the letters made it especially hard, since people automatically read them as word boundaries.

Try 2: Split the string into words, then scramble each word
Sample: I DEAM ITSH AHFL YPNO LAFH MENYKO MTOENSR TO SEAEPL UOY

This was much better, but still pretty hard. The time limit on answering meant that people often ran out of time while trying to unscramble the string. But then I remembered an e-mail forward I’d seen which claimed that if you leave the first and last letters of a word intact but scramble the rest, people can still pretty much read it.

Try 3: Split the string into words, freeze the first and last letters, and scramble the middle ones. (For 2-letter words, give a 50% chance of swapping the order.)
Sample: I MDAE THIS HALF PONY HLAF MEKONY MSOETNR TO PAESLE YOU

This was too easy. 3-letter words were always in order, since freezing the first and last letters left a 1-letter string to scramble. 4-letter words would stay in order half the time since their inner length-2 string got scrambled.

Try 4: This had a lot of special cases.

1. Split the string into words. For each word longer than 1 letter:
2. If the word is 2 letters long, 50% chance of swapping the letters
3. If the word is 3 letters long, scramble it
4. If the word is 4 letters long, freeze the first letter and scramble the rest
5. If the word is 5 or more letters, freeze the first and last letter and scramble the inner letters

Sample: I MEAD THSI HFLA PYON HLFA MEONKY MOESNTR OT PAESLE OUY

The results were really good! Easy enough to solve within the time limit most of the time, and just hard enough to feel good about solving. The computer science geek in me wishes there were some way to do it with fewer special cases and a continuous difficulty scale, but short words really need to be treated differently because of their length. Still, it was a pretty interesting problem. Who knew an e-mail forward would come in so handy?

(Incidentally, the phrase is “I made this half-pony half-monkey monster to please you”, which is from the song Skullcrusher Mountain by Jonathan Coulton. Check it out!)

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.

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

I had two main goals when adjusting the game difficulty:

1. The two modes must have similar difficulty levels
2. Both modes must be winnable by people who don’t play games that often

I adjusted difficulty by changing the spawn rates of enemies, asteroids, and ore/hulls, and by changing the number of starting shields.

While I managed to strike a fairly good balance for the project deadline, I feel that it could still use some work. However, there are some more fundamental design issues that need to be addressed first:

It’s possible to get stuck in the game

The way the game works, level advancement is based on how many ship upgrades you have. When you run out of shields, you restart the level with the same number of shields and the same upgrades. This means that it is possible to get to a level that is too hard for your skill with few lives. Unless you can collect enough ore or hulls to return to base, you cannot gain enough lives to clear the level.

One possibility is to always grant a minimum number of shields to the player on starting a new level. e.g., if we have determined that the third level should be beatable with 6 shields, then the level-change code will also set the player’s shields to 6 if the player has fewer than 6 shields. Any other fixes to this problem will probably require a change to the current level mechanic.

Level advancement uses an unusual mechanic

I got comments from several people that the level mechanic “seems a bit weird.” It has the bonus that at a given level, you always know the ship has a minimum number of upgrades and should therefore be able to handle things. It’s just not what most people expect.

The “boss” for the ambassador mode doesn’t fit in

The “boss asteroid” requires a method to defeat it that never shows up elsewhere in the game. I’d like to change that, although it might “spoil the surprise”. On the other hand, there’s no such surprise for the Exterminator mode.

I want a scoring mode but don’t know how to do it

Scoring for the Exterminator mode is pretty straightforward. Just count shots fired, enemies extinguished, that kind of thing. But what’s the equivalent for the Ambassador mode?

There are some statistics I could keep score on: number of times levels are played, total time spent on a level, amount of ore picked up. For all of these, lower numbers suggest more player skill, which can result in slightly weird scores.