A Faraway Dot

A Faraway Dot is a puzzle game about experimentation, the discovery of rules and their nuances and the application of knowledge to unfamiliar situations. Core puzzle mechanics revolve around arranging tiles, some with arcane symbols, according to particular criteria, which the player must discover through investigation and deduction.

I've been working on the game for a few months now, albeit at a gentle pace and around a full-time job. I'm focusing on core gameplay first, visuals later, so there isn't a great deal to show off in terms of enticing screenshots. Here's a GIF of a puzzle activating, however:

All art is placeholder at present.

I'm developing in Unity and targeting Windows and MacOS releases initially, though other platforms certainly aren't out of the question.

Features

• No written instructions - the game will subtly guide players non-verbally but ultimately they must deduce what is required of them
• Nuanced puzzle rules to discover
• Island/archipelago setting
• Non-linear puzzle order - it may sometimes be necessary to seek out simpler puzzles that teach symbol meanings before tackling more complex ones

Update 1

So, what have I been working on? For the past week or so it's been puzzle activation sequences, by which I mean how one puzzle might activate or deactivate another. At its simplest, solving puzzle A might activate B and solving B could activate C i.e. A -> B -> C. However, A might actually also activate D and E, but E might need to be activated by both A and C. In other words, puzzles may activate multiple puzzles and may need to be activated by multiple puzzles. This puts me in mind of many-to-many relationships in a database.

When a puzzle is solved it "triggers" each downstream puzzle once. Each of those puzzles then counts the number of triggers it has so far received and, if that number is greater than or equal to some threshold, it begins its activation animation. As you can see from the GIF above, this comprises several moving parts that must be coordinated in sequence.

Where things get slightly trickier is that as well as being solvable, all puzzles can also be unsolved. When this happens, exactly one trigger is removed from each downstream puzzle and if the number of triggers for each is below the activation threshold, the puzzle deactivates. This throws up some complications because, for example, a player could, in quick succession, repeatedly solve and unsolve a puzzle, hence activating and deactivating downstream puzzles, which must respond and animate accordingly.

My first thought was to queue up activation and deactivation events such that, when a puzzle finishes its activation animation, it might immediately start deactivating if such an event is on the queue, and so on. The problem with this approach, however, is that activation and deactivation events could be queued up far more quickly than they would play out and so puzzles could become locked in a near endless animation cycle, making them unusable until they've finished. Not good.

Far better would be to allow animations to be 'interrupted' midway through, with the new event simply replacing the old one, rather than queueing up. This means, however, that I need a way of cancelling all the scheduled animations and indeed reversing them part way through.

I managed this firstly by ensuring that all translations are to fixed coordinates, rather than relative, so that an animation started from part way between the usual end points can still proceed. The time taken for the animation is still fixed, however, so the parts can appear to move slowly, which isn't perfect. Altering them to be speed- rather than time-based may help resolve this. Secondly, I placed all animations on a queue that can be cleared at any point, so the entire sequence can be replaced with a different one. Here's the result:

What's Next?

The animation queue currently has a callback system to allow stuff to execute when a particular animation finishes. To avoid some kind of nested callback tree of death (is that a thing?) it'd be nice to replace this with something similar to JavaScript's Promise system instead. This undoubtedly already exists but I think it'd be kinda fun to write my own. Not as full-featured, certainly, but something that'll fit my needs.

Apart from that, I need to throw another spanner into the activation sequence by adding the complications of bridges and islands.