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)

SEEK*TOR Voting page

Incidentally, I’m annoyed with Audacity because it added an initial silence to all the mp3 files I encoded with it. So all the sounds come in late. Also, I just realized that I forgot to have the background music loop…

(Cross-posted from Ludum Dare) ]]> http://selenetan.com/2009/12/finished-my-first-ludum-dare/feed/ 0 http://selenetan.com/2009/07/efusjon-rad-game/ http://selenetan.com/2009/07/efusjon-rad-game/#comments Sun, 19 Jul 2009 01:21:03 +0000 selene http://selenetan.com/?p=128 eFusjon RAD is a game promoting the eFusjon energy drink, launched in July 2009.

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.

The goal was to make an online version of the game show with new songs available every week. In addition, the game would allow players to upload videos of themselves performing the songs featured for that week. The video upload functionality was provided by Brightcove.

I was responsible for the overall structure of the code, as well as implementing the initial framework and several of the sections. This included the main game interaction of listening to the song and inputting the answer.

Play the game

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.

The goal of the project was to design and create two variants of a game in order to test gender preferences. We decided to look at the violence/destruction vs. gathering/nurturing split. We created a space shooter with two modes. One mode is a typical space shooter. In the other mode, you gather ore and dodge asteroids.

I was responsible for the graphics, music, and final game balance.