Orbit by Noah Ratcliff
Connect planets to solve puzzles. Feel good about yourself.
Known bug: if you click a button on the menu before the fade in is finished, state changing will break and you'll have to reload the game. Sorry about that.
From the in-game howto:
Click on a green body to select it.
Click anywhere in space to manipulate the body with your tractor beam.
You can not manipulate orange bodies, or the body you are orbiting.
Your tractor beam will not work when a body is blocking it's path.
Known bug: if you click a button on the menu before the fade in is finished, state changing will break and you'll have to reload the game. Sorry about that.
From the in-game howto:
Click on a green body to select it.
Click anywhere in space to manipulate the body with your tractor beam.
You can not manipulate orange bodies, or the body you are orbiting.
Your tractor beam will not work when a body is blocking it's path.
Ratings
| Coolness | 58% | 3 |
| Overall | 3.39 | 372 |
| Audio | 2.81 | 482 |
| Fun | 3.25 | 376 |
| Graphics | 2.94 | 663 |
| Humor | 2.21 | 636 |
| Innovation | 3.64 | 205 |
| Mood | 3.18 | 395 |
| Theme | 3.86 | 115 |
Running 64bit version on my 64bit Linux didn't work, but running 32bit worked.
Also, nice work getting so many puzzles finished in such a short time period! :D
It can be unclear at some times whether I've solved a puzzle or failed it, as both transitions are the same. This delays the feeling of satisfaction from beating a puzzle to after the fade completes. My suggestion for making this clearer is to have a correct solution fade the screen to white, and a failure fade to black. This would eliminate the wait to see if you'd succeeded, and allow you to immediately celebrate or prepare yourself to try again, respectively.
It can sometimes be difficult to see why exactly you failed a puzzle, due to the fact that your only visual feedback prior to the fade is that of an incorrectly matched orbit turning red. When a body has already been paired correctly, its orbit path disappears and will no longer turn red if another body begins orbiting it.
Sometimes it feels like the tractor beam is detecting a body between it and its target where that's not actually the case. This was most noticable in levels 15 and 16, where I could have a clear line of sight but the beam wouldn't activate. It seems like in some cases attempting to use the beam and failing will permenantly disable it.
Clicking on the home button or other menu while a transition is active can cause a soft-lock. In-game it can be cleared by pressing space, but at the main menu screen it put me in a state where I couldn't activate anything.
Overall I really liked it! I beat all the levels but 17, which I'm convinced is bugged (or maybe I'm just bad).
First, the planets are pulled towards the cursor, yet a line is shown between the planet and the little orbiting ship (this would make more sense if the controls were pull to/repel from the ship, and that would also make the ship's position a bigger element in gameplay rather than just "wait until I can move this planet").
Second: Puzzles start out with the planets having way too much momentum already towards.. the largest planet I assume? So some puzzles only give you about 2-3 seconds to get certain planets out of the way before you fail and have to start over.
For the very same reason, some early puzzles basically solve themselves with no player input.
Having a level select screen with previews is very nice, although it would be nicer still to see which levels I'd already beaten.
Finally, there's no visual or audible distinction between completing and failing a puzzle, though this isn't a major problem by any means.
The minimalistic sounds are quite nice, same goes for the graphical style. If the starting pace wasn't so high, it would be a great relaxing puzzler.
This might sound pretty negative, but my overall impression of the game is actually quite good.
Music would help a lot, too. ^^"
1. The player has no way of knowing how much energy the tractor beam has for a level until trying. This should be part of the interface. Related to the second point, this causes me to restart more often than I should (and I'm already restarting frequently).
2. The control scheme is spread across two devices. Why? The primary mechanic in the game uses the mouse (the tractor beam) and the menus are also traversed with the mouse. It seems arbitrary to me that the space bar is used to restart the level. For something like this, it makes no sense. It is inevitable (at least in my case) that the player will want to restart the level -- likely frequently. It should be local to the device they are already using to interact with the game.
3. I don't know if this was wholly intentional, but the removal of an orbit line once a body has sunk into orbit removes valuable information from the player's view. I want to know where that field goes when the body I've thrown into it influences the larger body's position. I want feedback that will tell me how to change my approach when I fail (and I am likely to fail the first time I try a level). I can watch the bodies and make adjustments, sure, but I can't *really* see how far off I am from the mark. I prefer to not make specific suggestions, but I would point out that you could even add information to orbit lines by changing their representation when a body falls into it. In the jam build, however, changing the representation won't be very valuable as there are not too many orbits to keep track of.
All said, the only thing I felt was *missing* was music.
Contrary to ViliX, the x86_64 binary worked on my Ubuntu 14.04 system.
I concur with jacobalbano in regards to screen transitions being unclear. You could, however, make it more clear just by means of sound. I also concur with tacospice about the tractor beam. It paints the wrong picture.
Completion: all levels.
Nitpicks:
- Level difficulty is inconsistent. Also, I didn't have to use my tractor beam on one level.
- As mentioned above, separation of controls. That said, good work on using the primary input device on the menus. Too often I see non-primary controls used *only* for menus.
- Linux archive does not retain the executable bit. This is a minor fuss, but nothing us Linux users can't handle. We do, however, appreciate archive formats that make less work for us. (If you have no idea what I'm talking about, don't worry about it.)
P.S. Regarding the menu state bug: I don't think anyone would raise a fuss if you made a new release to fix it. Bug fixing is permitted in the rules.
I enjoyed the game. I found it a little hard to understand how the game worked but after I got it, it was nice. I just feel like some missions needed more polishing.