Tìngäzìk: a Retrospective – ep. 0 Game Structure

This article was published over 2 years ago. The information mentioned may be changed or developed.

この記事は 2 years前に書かれたものです。記載された情報は変化した可能性があります。

Tìngäzìk is a puzzle game I designed in 2020, heavily inspired by Project NANO after I solved it with my teammates. When the first team solved the puzzle, and sent me their write-up on the journey tackling it, I felt like I should also write a retrospective series of blogs reflecting on the game design, and sharing some details behind scene.

The game is now in answer mode and open sourced, but you can also choose to give it a try if you want, without visiting the hint pages. Otherwise, this will be the first (or 0th) article of the series. Enjoy!

At the beginning of this series, I would like to talk about the generic game design.

The most basic part of the game is the presentation of question and judging answers. I directly taken the design form Project NANO (hereafter PN): put answer as a path name, and throw 404 when the answer is wrong. I like the design very much, as it is very simple and straightforward. It can be hosted on any static web hostings trivially without a need of server side scripts.

But I don’t particularly like the way PN presents hints. Although the majority might like it, I simply sometimes find them too obscure and hard to understand. When I was solving PN, I was sometimes frustrated by the time when I just can’t figure out what is hidden in the game as hints, and how to interpret them.

So, in Tìngäzìk, I decided to use sample questions and answers as hints. They are simple and obvious. By a look, you know the pattern of such questions, and how the answers are expected to look like. Moreover, it would be much easier to find out the direction to solve the problem, i.e. what was expected to do to reach the answer.

Frankly, the hints can obviously be inserted as links to the question statement itself, but I feel like that would be too easy for people to reach out to hints for help. I hope challengers would take a better look at whatever is given to them at the moment. When they actually concluded that it is not possible to solve the question, they would then reach out for hints. So, I added a bit of obscure for getting the hints: hash all the hexadecimals found in the web page source as answer for hints.

As I believe getting hints plays a crucial role in the game, I started it with a detailed description with how to calculate the hint hash, and the way to used. URL to the first stage is only visible if you calculated the hash to the tutorial correctly. With this, I can ensure that whoever reached the first stage should have a good knowledge of getting hints.

Since most page contents are hashed for hints, I was a bit concerned with 2 pages that has the same hex sequence in the entire page, thus causing a hash collision. I included the page URL and a CRC32 of it at the footer to lower the chance of collisions. That could be somewhat confusing to some challengers and they might mistaking it as hints. I could have included them in a HTML comment or metadata tag to make it less distractive to the challengers.

Apart from that, server access log was also being monitored for looking at the progress of the game, and to stop potential bruteforcers. This, too, is copied from PN, where one of whose maintainers shared this piece of information with me.

Again copied from PN, dummy questions are also there as a second layer protection against bruteforcers. Details of such questions will be introduced in a later episode.

In the next episode, I’ll talk about the first few stages of the game and their designs.

Posted

in

by

Tags: