It’s been a long time since I used Haxe — my last commit to the Iridescence repository was over six years ago, and I haven’t been back to it ever since. When Flash finally reached its end-of-life and my old Flash games suddenly became unplayable, I realized that this would be a perfect opportunity to get back to it, see what had changed, and do a bit of digital preservation work while I was at it.
Continue reading →Tag / My games
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:
Iridescence released!
It’s been a long time coming, but I’m very happy to announce that Iridescence is finally out!
[iframe src=”http://itch.io/embed/578″ width=”552″ height=”167″ frameborder=”0″]
You can also download the fantastic original soundtrack on Loudr!
For press-related inquiries, check out the presskit here.
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.
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!
Iridescence art overhaul
With core mechanics solidly in place, I thought it was high time to give Iridescence’s art some attention. Here’s what I’ve been working on today.
Beta release – The Heroes’ Tourney
There comes a point in the life of every creative person where you create something that feels like the culmination of your craft. It’s your magnum opus, and you’ll never make anything better.
The Heroes’ Tourney felt that way for me. It’s a “couch multiplayer” game for 2-4 players in which you try to punch your friends off of platforms or into environmental hazards.
It started in a 24 hour game jam held by SNHU, a college here in New Hampshire. Chris, Mike, and I had decided to make a local multiplayer game and had the basic groundwork up and running. At some point around 12 hours in, Chris and I woke Mike up with our laughter over the absurdity of a certain bug with the physics, and we decided to build the rest of the game around that. The rest is history.
The 24 hour deadline rolled around and our game was a smash hit, despite being nowhere near finished. About a week later, we all met up again at a game jam at NHTI and somehow decided to continue work on THT instead of creating a new game from scratch. This new version included a powerup system that added a whole new dynamic to the gameplay. We had a mini tournament during the wrap up session and it was incredibly rewarding to see other people laughing and taunting each other while they played.
I’ve done some more work on the game since then and we still plan to work on it in the future, but I think it’s finally ready to be thrust out into the world to see how it fares. You can download it here. Make sure to read the readme, and yes, controllers really are required.
PS:
Here are some action shots from our post-thanksgiving dinner tournament.
https://vine.co/v/hPmYBYZqJFA
And here’s my little sister playing against my cousin’s girlfriend.
https://vine.co/v/hPmY32Y5UTz
Swappers
It’s always fun to add a new system to a game, minimal and naive, with a blissful ignorance of the bloated monster that it might someday become.
Color/Shift input woes
When I released the Color/Shift demo, one of the main issues that were being reported was that dragging the pawns around was really difficult. This confused me as I had spent a lot of time painstakingly tweaking the controls so that sliding pieces felt natural and responsive, but it was obvious by watching people play that there was something seriously wrong. I made some changes to try to make it better, but the result was still pretty bad. The pawns would slide around loosely in any direction they wanted until crossing a grid line, at which point they would snap to an axis and move along it, It didn’t feel good, and it introduced all kinds of new problems including the possibility of phasing through objects or traveling in two directions at once. Worst of all, it still didn’t address the issue entirely.
Yuck. 🙁
I let it be and moved on to other things, planning to come back to fix it later. There was probably a little bit of hubris involved, if I’m being completely honest with myself; if I didn’t have a problem controlling the game, other people shouldn’t either, right?
A few days after leaving the issue behind, I was working on my laptop (most of Color/Shift’s development has been done on my desktop computer) and suddenly started having the same problem as my testers. Pawns were moving sideways when I wanted to move up, and sometimes they wouldn’t even move visibly before smacking into a wall to either side. What was going on?
As best as I can figure, the input issues had to do with the sensitivity of the mouse being used for control. My desktop has a high DPI gaming mouse with the sensitivity cranked way up, and my wireless mouse and laptop trackpad are much less precise. Armed with this new information, I set about making things right.
Here’s a visualization of the way I’m handling input now. When the user presses the mouse button, the pawn remembers where the pointer was when it was pressed. In the image above, it’s right in the center of the piece.
At this point, no dragging is actually done yet. The mouse must move 7px in any direction before the pawn will move at all; this is represented by the circle cutout at the center of the transparent fans.
When the mouse has moved far enough from its original position, its angle to that position is checked. If the angle is within 30° of an axial direction, the pawn is then allowed to move on that axis. If not, no movements are made.
The angle is relative to the mouse click position, so it’s possible to start the drag by clicking anywhere.,
I still need to stress-test this to make sure it works for everyone, but it feels much better with all of my mouse devices and I have yet to move a piece in a direction I didn’t intend since improving this mechanic. Feedback is important! Listen to your testers!
Color/Shift demo 1.01
The Color/Shift demo has been updated due to feedback. Notable changes:
- Pawns may now be dragged freely until they cross a grid line, at which point they snap to the axis on which they have moved the furthest.
- Neutral walls are no longer the same color as the grid lines.