jacobalbano.com

Infrequent ramblings

Navigation Menu

Gender interpolation in Flash

Posted by on May 14, 2014 in Programming | 0 comments

As a developer, I can’t help but deconstruct any game I end up playing. RPGs are a special fascination of mine, and I’ve often wondered how script writers handle games where the player can choose the main character’s gender. There are so many factors to consider beyond simply replacing occurrences of “his” with “her” and so forth; when you throw nicknames, honorifics, and insults into the mix along with all the various pronouns, there’s a huge number of variables to consider.

Today I was hanging out on the Flashpunk forums and the topic came up. Suddenly it occurred to me; you don’t need to have two defined lists of gender-appropriate tokens; just a consistent format for representing each possible option within the text itself.

For example, instead of doing this something like this:

Armitage: This is {var: player_name}. {gendered: subjective_uppercase}’s looking for a job.

The same could be written like this:

Armitage: This is {var: player_name}. {gendered: He/She}’s looking for a job.

It reads a lot better, for starters, and it avoids the need to maintain gendered tokens in a separate location than the script data. Granted, inline variables are harder to change in broad strokes at a later date, but on the other hand it’s harder to accidentally break lots of text by changing something global.

Here’s a little function I wrote to handle this in Flash. It’s not as flexible as the contrived example above, but it does what I set out to accomplish and I’m happy with it.

Let me know if this helps!

Read More

Level count isn’t everything

Level count isn’t everything

Posted by on May 7, 2014 in My games | 0 comments

I’m quickly approaching gold status on Iridescence, and with all foreseeable technical work finished, I’m deep in the throes of level design. Originally I had planned to ship with 100 levels, but today I decided to cut that in half and target 50 instead.

Why am I doing this?

I’ve been stuck in this stage of development for a while, actually. Slide had 16 levels when I released it, and I was intent on having significantly more for Iridescence, being as it’s going to be a commercial release and I want people to feel they’ve gotten their money’s worth. 100 seemed like a nice round number and I assumed that reaching it would be fairly straightforward.

This is the part where I was wrong. Designing puzzles is actually really hard. You want them to be challenging but still fun, subversive but not unfair, and most importantly they have to mesh with one another as a cohesive whole. On top of all that, the puzzle designer has to learn to work backwards from an interesting solution to a starting state that doesn’t make the goal obvious.

The whole process is very creatively-bound, and it’s impossible (at least for me) to sit to down and just crank out new levels up to a set quota. It’s been hard to keep a steady pace, and the constant awareness of how much more work I have in store hasn’t helped.

While considering all this, I realized that I was coming at this whole process from the wrong direction. In all my favorite puzzle games, the number of levels is irrelevant; the game goes on until it runs out of meaningful things to do, and then it stops. My number one goal in Iridescence’s design is that each level provide some way of stretching the player’s mind; whether that’s by introducing a new system, or subverting assumptions to cause misdirection. This is in direct conflict with having to fill a set number of levels. Some puzzle games are based on a small set of mechanics which are then used in levels that are more about going through the motions than finding something new each time.  There’s nothing inherently wrong with that, of course, but it goes against the philosophy I’ve been building Iridescence around.

In the end, I’d rather make a concise game that does what it sets out to do and nothing more, than a long game that’s full of repetition and filler.

Read More

Hypothermia is now on itch.io!

Hypothermia is now on itch.io!

Posted by on Apr 5, 2014 in Games, My games | 0 comments

 

A while back I made a little game called Hypothermia for Experimental Gameplay‘s “Temperature” challenge, a game jam of sorts that ran for a week during November/December 2013. It got reviewed by Indie Impressions and Indie Statik, and some guy from China did a Let’s Play of it.

Based solely on download count, it’s my most successful game thus far, but I never managed to find a hosting site for it that was a good fit, so despite it being a flash game anyone who wanted to play it had to download an archive containing the SWF and a web page. Thanks to itch.io, I now have a place to upload it without having to worry about it being blammed by people who don’t understand game jams. ;)

Play it here!

Read More

Stuck Scripting overhaul

Posted by on Feb 28, 2014 in Games, Programming | 2 comments

Early on in the development of Slide (before Iridescence had come to be), I added support for small script files to allow levels to contain more complicated puzzles without running into false positives that caused the reset button to show up while the level was still perfectly solvable. I was using C# at the time, and options for proper scripting languages on the .NET platform are shamefully limited, so I rolled my own.

Here’s a sample of what it looked like:

The use-case for stuck scripts is extremely specific, so the language itself didn’t need too many bells and whistles. All I needed to do at any time was compare the number of game objects of a given color, and check if pawns had a valid path to their targets. The snippet above basically translates like so:

The puzzle is unsolvable if any of these are true:

there are more red pawns than blue
there are more green pawns than blue
there are more blue pawns than green, unless all blue pawns can reach a target
there are more blue pawns than red, unless all blue pawns can reach a target

Needless to say, it’s as ugly as it is functional, and adding new features proved difficult. The inflexibility of the original design meant for some truly impressive hijinks as I tried to implement more complex behaviors with only the original syntax.

Today I stripped the whole system out and replaced it with a new one. Since I’m using Haxe for this remake, I was able to take advantage of hscript, a subset of Haxe that allows for runtime interpretation. Now, the script above looks like this:

Much better.

The original scripting system was designed as a black box, with a minimal number of inputs and outputs. By keeping the interface consistent between implementations, I was able to completely change the underlying code without changing any other aspect of the program. It’s nice to be able to change something so integral to the gameplay without worrying about side effects.

Read More

Menu work

Posted by on Feb 20, 2014 in Game design | 0 comments

This week in development on Iridescence I’ve been focusing on menus, settings, and save data. Here’s what I’ve implemented as feedback when the player tries to open a level that hasn’t been unlocked yet. The animation is inspired by WordPress’ login window, and I think it’s pretty clear what’s going on.

Read More