Iridescence development visualized

Three name changes, three frameworks, and 33,697 lines of code and data — this video represents 11 months of nearly solo development at the rate of two days per second.

Each dot is a file, and each cluster represents a folder. Green lines represent new files being created, yellow for modifications, and red for deletions. Source code settles out at the bottom left, with level files top right. Audio is up on top near the levels, with an equal number of .oggs and .mp3s to support multiple platforms.

Towards the end it’s obvious that a lot of work is being done on level design, with scattered changes to source code as I fixed last-minute bugs, and a lot of new image files being added as I rounded up screenshots and promotional art.

Created with Gource. Music is “Hongdae” by Lukhash.

Get the game:

Glide update: Structs don’t work that way

Glide has seen some modest adoption despite the fact that I’ve barely made any effort to get the word out. A handful of developers have contacted me thanking me for the project and asking for help, which I’m always glad to offer. One issue in particular has come up a few times recently, and it relates to the way .NET handles structs.

Structs are passed and returned by value, not reference. This means that when you assign an instance to a variable, that new variable has no relationship to the original object; any properties set on it will only apply to that variable. This is a problem in Glide, since I have to store a reference to the tween’s target object in order to apply the transformations. Worst of all, while normally this issue would be caught at compile time, it’s impossible to detect when you’re using reflection to set values, and the resulting behavior was that the operation would appear to silently fail.

Today I made some changes that should help users realize when they’re attempting to tween an incompatible type. Passing an instance of a struct to the tweener will result in a compile-time error, and if you sneakily box your variable into an Object it will throw an exception at runtime. This still doesn’t solve the problem of how to tween these types of properties, but I’ve got you covered on that front as well.

Glide already has support for extension classes that allow you to add specialized behavior for tweening your own types, but this feature wasn’t really documented anywhere. Now it is! I’ve added a wiki to the Glide Bitbucket repository with an example showing how to tween an XNA Vector2. It should be pretty simple to modify for your own needs…maybe a StringTyper extension that causes letters to show up over time like a typewriter, or a GlitchString that fills the whole string with garbage and slowly fills in the correct letters.

Gender interpolation in Flash

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!

levelcount

Level count isn’t everything

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.

fpdev

Hypothermia is now on itch.io!

 

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!

Stuck Scripting overhaul

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.