Tag Archives: Iridescence

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.

Dwm 2013-11-11 10-21-38-83

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.

angle0

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.

angle1

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.

Color/Shift demo

Since Slide originally came about as an entry for OneGameAMonth, I thought it would make sense for me to release the Colorshift demo as one as well!

iconWindows iconNG Get it now!

This is an early release that doesn’t add any additional levels beyond those included in Slide, so if you’ve played it already there won’t be a lot more to see here besides a bunch of bugfixes and some polish to the core mechanics. I’m still working on adding a bunch of extra features, like drag-and-drop support for custom levels and a menu to replay puzzles you’ve beaten already or resume where you left off.

I’m working on native builds for Mac and Linux, but for now non-windows users can play in a browser at Newgrounds.

Please let me know what you think! I’m still in heavy development and I’d love to incorporate your feedback and criticism.

What’s in a name?

I’ve heard it said that it’s easier to name something before it even exists than to try to sum a thing up into a name after the fact, and I believe it. For nearly every game I’ve ever made, it seems like naming the darned thing is the task which takes the longest to complete.

Slide was an exception to this. I had the name picked before I made my first commit to the source repository, and it remained throughout the entirety of development. When I released it there was no other game by that name anywhere on the internet. I was feeling pretty good about it.

Yesterday I went to make an IndieDB profile for the remake. I created a boxshot image, collected screenshots, entered all the required information…and pressed submit.

  • There is already a game listed with the name Slide on Indie DB.

Tragedy!

I checked out the conflicting entry and came to the realization that, while I had become attached to the name “Slide” in reference to my own work, it really wasn’t a great fit as it described only the most basic mechanics. In this new game, the core mechanics are all about puzzles based on ice sliding in classic Zelda and Pokemon games. It obviously has a lot of polish and has likely been in development for a while, so even though I had technically released my game first I didn’t want to be “that guy” and ask that it be taken down.

And so began a frantic day of brainstorming as I tried to come up with a new name before the rapidly approaching OneGameAMonth deadline of November 4th.

Fortunately this all has a happy ending. The name I chose (with the help of some good friends) is Color/Shift, and I’ve retroactively renamed it in all my posts about this new release. Not only is this new name more tightly related to the core mechanics overall, but it’ll also help me distinguish between the original prototype and the new commercial release. All’s well that ends well. :)