Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(+1)

A fairly well jam entry on a technical level, surely. There is a simple system, minimal gameplay loop, good stuff for a couple days of jam. I did mistake assets for stock kind at first but they do have a charm.

But I did feel that I didn't really enjoy playing after a while. Rather, didn't enjoy moving, exploring. The simplest explanation would be to complain that the horizontal thrust don't allow you to tap quickly enough, making you wait and mash and wait and mash. From a bigger view of things, having read postmortem, it's because levels didn't have the right amount of air currents in right spots to make it interesting and sometimes it would send me to deliver package to the very very close destination where I was willing to go up or down all the way through map and was stuck just thrusting horizontally. But of course horizontal thrust, in a full would be project, would need to have a different feedback or mechanic limit to make it more obvious that it's more of an exception.

Talking of postmotern, it was only there I realized that the levels were randomly generated. At first I kept pushing, in hopes of increased difficulty that will challenge me to appreciate the core idea, as well as not to disappoint dev that I haven't finished the game before making an opinion. Then after level 5 I met a layout awfully similar to what I had in level 1 and I figured that, due to seeing no big changes, the game was simply looping between five levels like old arcade games. Having found out more about project, I think that in hindsight it should have had 3-4 hand-made levels show off the core intent better. After all, the generation was not needed as game doesn't have enough replaybality value and good generations would have taken too much time. Albeit it's, of course, good coding practice.

Main menu behaves a bit weirdly when using both keyboard arrows and mouse. Perhaps game should set the "current choice" for keyboard control to the line that mouse had hovered over. But of course it's fine for a jam jam.

I also was not aware that game had dynamic music system, haven't noticed, having read postmotern. Perhaps dying was too rare. I can agree with composer that music was a bit too static. A level with simple color overlay to make it look like a dawn and some more mellow melody could break it apart, perhaps something cheap in workflow. Maybe. But of course it's merely a jam contribution.

On a cute side, I, for some reason, really liked how the vertical gauges on HUD looked, especially the second one, for vertical movement. The bubble in the middle made me a bit of nostalgic at gauges and tools that I would find at dad's room, ha. The game was polished for what it is and time being too.

(+1)

Hi! Thanks for your detailed thoughts and kind words!


But of course horizontal thrust, in a full would be project, would need to have a different feedback or mechanic limit to make it more obvious that it's more of an exception.

Actually, I'll likely remove the horizontal thrusts entirely so that navigating via air streams is the only way to get around (potentially bringing them back as an unlockable upgrade). I would have removed it in the most recent patch, but I'd already gone over the time that I'd allowed before I got to that.


Perhaps game should set the "current choice" for keyboard control to the line that mouse had hovered over.

Hmm, I hadn't thought of doing this. In just about every GUI application/toolkit that I can think of, hover and focus are intentionally two distinct and separate states. My impression/experience is that conflating them presents an accessibility issue.

In one of my other games, I did something similar to what you suggested (rather than a menu, it was a grid of gameplay elements that could be navigated with mouse or keyboard), and a blind player ended up with focus unexpectedly moving around because they unknowingly had the mouse cursor over the playspace.


Perhaps dying was too rare.

In general, I think I'm OK with the music changes being subtle - even if a player doesn't realise that it's tied to their actions, so long as it changes across the play session, that's what matters. Dying isn't an essential part of experiencing that, I don't think.

In a larger version of this game, I think we'd have new music (and new time of day) once you moved to a new level, which might go a long way to giving some of the variety that I think players would want for a session that lasted more than 5 or so deliveries.


On a cute side, I, for some reason, really liked how the vertical gauges on HUD looked, especially the second one, for vertical movement. The bubble in the middle made me a bit of nostalgic at gauges and tools that I would find at dad's room, ha.

That's the sort of feel I was hoping to evoke! Ideally, I would have liked to have given them a more painterly look and feel to match the rest of the game, but I didn't have time to paint them properly and the quick vector placeholders I put together ended up staying in the game.

Initially, the height of the liquid changed position in the altimeter to represent how far away your neutral buoyancy point is, but a couple of players interpreted it as a resource that needed to be replenished, so I added the "spirit level" type bubble in the last patch to try and make it harder to interpret that way.

In one of my other games, I did something similar to what you suggested (rather than a menu, it was a grid of gameplay elements that could be navigated with mouse or keyboard), and a blind player ended up with focus unexpectedly moving around because they unknowingly had the mouse cursor over the playspace.

Thanks for sharing this experience, I actually didn't quite think it through. I will need to pay more attention to how other games do it. It still feels a bit off in Cloud Courier main menu for me personally but now I am not sure how exactly it should be.

(+1)

After having a poke around this morning, it looks like I've also worked on games with fairly large audiences that give focus to whatever the mouse has hovered over (such as Day of the Tentacle Remastered or Hand of Fate) and I don't recall anybody having trouble with those, so I don't think that any negative impact is likely to affect a wide range of people (that said, I haven't come across anybody who's had problems with the sort of thing I did here in Cloud Courier before either).

In the game where I had a blind user experience problems (the Bonesweeper prototype), I added an option to disable mouse input and set a couple of other blind-friendly settings all at once, but I think the broad conventions of keeping focus and hover as separate states for normal GUI widgets is important - in general, a lot more usability/accessibility research goes into general GUI toolkits and standalone applications than games, and that feels like a good lead to follow :D