One feature of Simple Sudoku is that it automatically shows the candidates for a square. This takes away the tedium of having to manually eliminate the obvious candidates, like 9′s in a row that already has a 9. Still, the candidates sometimes look like a mess.
Simple Sudoku solves this with a feature called candidate filtering. What it does is highlight all squares that might be a particular number, e.g. all possible 9′s. This makes it easy to see, for example, when there’s only one possible 9 left in a column.

Candidate filtering is good for slightly more advanced deductions, as well. Let’s say you have one 3×3 cell where all the possible 6′s are in the same row. You can eliminate 6 as a candidate from the rest of the row. Or, visually, you can do this:

There is an advanced Sudoku technique called coloring or linked candidates. It involves forming a chain of candidate squares where you know that some of the squares contain the candidate, and the rest do not. However, which set of squares contains the candidate is unknown at the start. The technique involves “coloring in” the candidate squares in an alternating pattern, e.g. with blue and pink. If any pink square contains the number, then all pink squares will contain the same number, and all blue squares will not. The reverse is true as well.

The technique can be difficult to understand from a description, but in Simple Sudoku, it’s really easy to do. Filter candidates so that, say, all 5′s are shown. Find a place where there are only two 5 candidates in a row, column, or large cell. Color one of the squares pink, and one blue. Then continue the chain as long as you can find links where there are only two 5′s. If you see two pink neighboring each other, then the pinks don’t have 5′s and the blues are the ones with 5′s.

Coloring turns a painstaking deduction problem into a simple pattern-recognition problem. Going through the chain of logic step-by-step takes a while and can be prone to error, but marking squares as colors is easy. And on the computer, it’s easily reversible. I’ll often start coloring squares even when “simpler” deductions can be made because in Simple Sudoku, coloring is a simple deduction.

In general, as you get better at a type of logic puzzle, you start recognizing common sequences of deductions. Internally, you formulate a series of rules: “If this, then do that.” What Simple Sudoku and other good puzzle interfaces do is 1) Make it easier to notice common deductions, and 2) Make it easier to spot the “If this” part of your rules.

Anyway, I’ve finally gotten around to trying flixel out. I cast around a bit for a game idea that I thought would suit flixel’s strengths. It’s a game with 3 tracks where rocks come at you and you have to switch tracks to dodge them.

Play the Sideliner prototype

Unfortunately, it’s not really fun. The graphics were also a pain. Rocks I can do; the drill took me at least twice as long.

Changes in this version:

1. Fixes bug where the upper-left turret is unclickable
2. Fixes bug where sometimes the red enemy square is unclickable
3. Fixes bug where on very high levels, the level never starts
4. Turns off debug flag so turret layouts are randomized between 4 choices instead of just one
5. Background music now loops

So what caused the unclickable-things bug, and how did I track it down?

With the help of debug output, I discovered that when a turret or enemy was unclickable, it was because something else on the screen “stole” the click event. In the unclickable upper-left turret bug, the click event was going to the flare display in the upper-left. In the unclickable enemy square bug, the click event was going to an object with a name like SpriteXXX. XXX was a number that was larger the later in the game the bug appeared.

The object name was my biggest clue. The number meant that it was a sprite that was created every level. The turrets are created anew every level, but they show up as TurretXXX. So I combed through the code until I found a sprite that was being created every level.

The sprite I found was the little explosion graphic that shows when you click on the enemy turret. In my competition-driven haste, I’d written code that created a new sprite every time the explosion went off, and didn’t bother to make it unclickable, or remove it from the stage afterward.  To fix the bug, I modified the code so that it created the explosion sprite only once and reused it every level, and I made sure the sprite was unclickable. That fixed the bug.

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/10/git-on-dreamhost/ http://selenetan.com/2009/10/git-on-dreamhost/#comments Wed, 14 Oct 2009 08:43:00 +0000 selene http://selenetan.com/?p=51 Though my website is hosted on Dreamhost, these days I mostly use them for version control hosting. So I was very happy when they set up git on their servers.

Casper Fabricius’ Keeping git repositories on Dreamhost using SSH has some instructions and a handy script for automating the process. Thing is, I tend to create the folders and files for a project before I set up the git repository. Casper’s script assumes you want to create the folder and repository at the same time.

So here’s my version of the script. If you call it without arguments, it assumes you want to make a repository for the current directory.

Note: both Casper’s and my scripts still work if you call them with a directory that exists, e.g. dreamgit dir_that_exists. You’ll see mkdir spout an error, but the rest will execute.

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.