next »

[a-k-]

.

[a-k-]

For the last years, games of the genre enable the player to experiment with multiple solutions for a level by providing separate save slots, usually 3. For some reason I overlooked that when I started this project, and instead have developed a different approach. Basically, the player can place all their solutions together and just change the starting cell. Cells that are not reachable appear dimmed and do not affect the solution's score:


(3 solutions for a level, actual commands are obfuscated)

That was actually supported since the beginning, but only recently have I added those yellow dimmed "start cues" that show the player alternative starting cells that will lead to past solutions. Since I already represent all solutions in some canonical form that is independent of how solutions look, past solutions are identified even when their layout on the grid change.

A somewhat-related feature is a screen that displays the best solutions for all the levels. Here's how it looks like for the generated C++ code of the previous 3 solutions:


(2 solutions out of the 3 are considered best and therefore shown, the 'fastest' and 'simplest' labels are given automatically)

[a-k-]

I thought it would be cool to have control flow diagrams in the game. I looked for free C/C++ libraries for drawing graphs but everything seemed to be GPL'ed except GraphViz that's mostly used as an executable. So I looked into degenerating its monolithic code base but decided quickly that I would have more fun implementing the algorithms I needed from scratch.

Well... I've read some 10 papers in varying levels of detail (fortunately others were paywalled), implemented selected parts and additionally algorithms of my own. Now I'm eager to finally get something on the screen. A few more algorithms to go and then I'm looking back at the option of chopping some functionality from GraphViz...

Next step: assigning X coordinates for basic blocks (Y will have to wait for yet another paper...)

[a-k-]

A working version of control flow diagrams:



I may revisit some parts of this later, most probably will want to smooth the curves and maybe also spread the incoming arrows. The former issue is simply the raw output of pathplan, a library for routing b-splines around polygonal obstacles:



That pathplan is the only 3rd party code that I'm using for the layout, it's actually part of the larger GraphViz but I've found it encapsulated enough to integrate into the game. I guess there's something better for the task since their paper is from 20 years ago, but by now my itch for algorithms has already been relieved. And I really need to get back to the big picture...

[a-k-]

Have just introduced simple gradients by passing true/false on every draw call, occasionally also supplying start/end coordinates to make the gradients continuous. I actually prefer the flat look to the left, but I guess adding an option to turn it off just for me is not such a great idea...

[nathy after dark]

I'm into it. I've been re-embracing my coder nerd identity so this should be cool.

[a-k-]

I'm into it. I've been re-embracing my coder nerd identity so this should be cool.

Thanks, that's very nice to hear! One needs to play to one's advantages, and what's more nerdy than a bunch of numbers?

... Introducing the profiler:



The numbers are typically displayed for the slowest input, but sometimes one input can't cover all the commands (e.g. if a block is executed only on some boundary case). So I calculate a small set of representative inputs using a greedy algorithm and the player can switch between them.

[a-k-]

A puzzle game whose state space is 100% discrete; developed like an application without any engine nor concept of sprites or tweens; a developer that initially didn't plan to add any animation.

Floatization: the process of converting discrete state variables to floating-point numbers in order to display smooth transitions upon changes in state. Example: whether to draw a button as enabled or disabled.

Cascading floatization: same as above, but buttons have gradients only when enabled. Now you also need to convert the boolean indicating whether to draw gradients to a float. But then, the functions making a color darker or lighter need to get one too. And so on.

Hyper-floatization: same as above, but state changes need to take effect immediately without waiting for the transitions to finish. Example: a button becomes clickable at once although it may still look more disabled than enabled. Now instead of replacing the boolean with a float, you add a float.

Encapsulated floatization: same as hyper-floatization, except that the floats are hidden deeply in the infra or a different layer. Example: your view model represents state with booleans while your view manages the transitions using floats.


Example of two states that require transition:

[a-k-]

After playing with a few animations, I've converged on the following:

Buttons:

• No transitions for most buttons (e.g. editor & debugger ones such as undo/redo)
• Simple interpolation for toggle buttons and for buttons that advance the game flow:
  

In general:

• Transitions between states that differ by color, opacity etc. - simple interpolation
• Transitions between states that differ considerably (e.g. different text, graph etc.) - some effect that does not show more than one state at a time (e.g. fade out followed by fade in, as shown above)

The last one will enable me to add all those animations quickly without making the views more complex just for the sake of supporting them.

[a-k-]

Game difficulty: (major gap)

• Added a few levels to smooth the learning curve
• More levels are gradually unlocked, so some can be skipped (see below)
• Solutions that exploit cheat mode are granted a special score instead of 0 (scoring method changed for the n'th time...)

(8/15 levels solved, some were skipped)

Fonts:

• Got rid of a keyboard font that had unclear licensing terms (instead, displaying keys with normal text)
• Script that scans the code for required glyphs and trims all font files using FontForge (saved ~1 MB after zipping)
• Web demo: had fun debugging blurry text in Firefox, got canvas sizes in pixels that correlated with the zoom level instead of the actual window/screen sizes; then I recalled I had enabled privacy.resistFingerprinting a few months before...

(Does it impact other games too?)

[a-k-]

Added support for achievements, currently having 20. They are all based exclusively on the player's solutions, which makes them easily verifiable by the server and enables re-calculation upon game upgrades.


(achievements for completing an area)

I also avoided achievements that are temporal, such as finding two competing solutions for a level (i.e. that are optimal along different axes). The player can later find a third solution that is more optimal than both, and then we are back with only one best solution for the level. While achievements like this are simple to support, they can encourage "bad" initial solutions (e.g. by artificially adding commands, then removing them).

Problem is, these constraints (server verifiability, re-calculability and "monotonicity") eliminated all the cool ideas I initially had, and what's left now are progress-related achievements that do not contribute much. For achievements to add a new layer to the gameplay, I will need to give up on something. Still need to think about it.

[a-k-]

The game is now localized to 4 languages:



As part of this work, I have extended the code generation algorithm to emit more 'if' statements so that there are fewer occurrences of 'goto'. For now, the player can choose any of the languages in the settings screen, but I'm considering an option that all languages will rotate randomly, perhaps on a level by level basis.

[a-k-]

Game difficulty has been an issue for a long time. Besides adding intermediate levels and so on, I also tried to address it with cheat mode, where unpermitted commands can be used to solve a level, and making that a legitimate option to advance in the game (including scoring). Unfortunately cheat mode can help only in some levels, and especially the beginning levels, where the basic techniques are developed and fewer commands are needed, cannot benefit much.

In order to fill this gap, I have recently introduced hint levels. These do not stand on their own - each hint level corresponds to a normal level, but the player needs to achieve a simpler, intermediate goal, that is a step towards the goal of the original level. In terms of UI, clicking "?" in a level brings up a "hint level unlock" screen, and confirmation leads to the hint level:


(The budget is pretty generous - not a real limiter. Just to make players think before unlocking...)

Combined together with the previous mechanisms, here you can see the availability of each one for the first levels:


(?? = tutorial; ? = hint level available; cheat = cheat mode available)

In general I would have wanted to add hint levels for more advanced levels too, but it was not easy to find intermediate goals that did not lead to specific solutions, which is something I prefer to avoid. Later levels are more open for different strategies, why impose my own? I will leave them as is for now.

----

Achievements: I have decided to go the easy route and not validate achievements in the server, so now only solutions are verified. This enabled me to add new achievements that are triggered by arbitrary events in the game (including "anti-achievements"), for a better overall variety. A few of those:

[Flatgub]

This is incredibly intriguing, Keep up the good work!

[Devilkay]

will it be for mobile?

[jctwood]

This looks excellent!

[a-k-]

This is incredibly intriguing, Keep up the good work!

This looks excellent!

Thanks a lot! Will do my best.

will it be for mobile?

Initially PC, but tablets may be considered in the future. Performance should be OK but the UI will need adaptation. We'll see!

[a-k-]

The quest to add translations continues:


(a contrived example illustrating goto, break, multi-level break and continue. sensible solutions don't look like this.)

That was more involved this time - my code generator was built to output lines of code, but this language required a post-processing step that would be easier to write over syntax trees. I preferred not to overhaul everything, so ended up outputting temporary lines that are later removed or search-replaced with the correct content.

Still need to do a few things: fuse related sequences of commands to one-liners, and decide what to do with the non-idiomatic indentation. The last one is tricky - I'd like to keep the variable-width font, so indentation needs to be handled during display. But then it's not clear how to indent during code transitions, especially transitions between languages.

[a-k-]

A new addition - the genre-ubiquitous histograms:



The server is now hosted on the Internet behind a reverse proxy. The HTML5 version connects through HTTPS while the PC versions simply use HTTP. No authentication is required: the client sends a solution (new or existing one) and the server responds with the histograms (after verification, if needed). This takes place while the end-of-level animation is playing, so everything seems to be running in real time.

Small gap: desensitizing IP addresses in server logs for GDPR compliance.

[a-k-]

Work on level histograms has continued a little, with the highlight being a separate histogram for # of conditions, a metric that has significant impact on scoring.
Additionally, I have introduced a new experimental metric, "modifications". While it correlates with cycles count in most levels, there are cases where it has its own merit, so it may even deserve a histogram as well.


(a classic cost-cycles tradeoff; the small arrows mark the current solution.)

I still need to decide which histograms to show for cheating solutions. The options are:

• Aggregate only cheating solutions in the histograms, thereby excluding players that did not have a cheat. This is what I do now, however even for the same player, a cheating solution may be inferior to a normal solution, so the histograms may not represent the overall players' achievements well.
• Aggregate both cheating and normal solutions, taking the best of both for each player. This is more correct, but may reveal part of the metrics distribution of normal solutions whenever the player cheats.

---
And a new translation:



Wanted: non-mainstream languages with some form of 'goto'...