Hello, apologies for the late update.

Unfortunately, I have no visuals to show off, even though I made progress.
I have been working on the back end.

Games on Hive

With Ehon, we want to make best use of Hive's technology.
One of the best features of Hive is that it allows us custom_json.

Whenever a player makes a move in EHON, they sign and transmit a transaction on Hive.
Much like when we first introduced the voting tool for EGOV-holders.

However, when operating a game or a voting service, our job as a game master is to keep track of these moves or votes. Turns out, this is not a trivial task.
A while ago, @inertia described it like this:

Getting access to the data isn't particularly user-friendly (requires nerds). You have to remember the transaction id and/or the block number. So it's not like a database where all you have to do is issue a SELECT statement.

In fact, if you don't keep track of the index, you will have a hard time finding the data later on.

source: @inertia/hive-is-the-minecraft-of-blockchains

During design, I tried to come up with a game that does not require many single moves.
Still, I need to store all player's moves in my own database.
Then, I need to allow every player's client to access that data, so they can review their moves.

All moves are stored in the blockchain, but finding them could take a very long time and would make our game unplayable.

'normal' game	Hive game

can read and write	can only write, but reading is complicated

To solve this issue, we will operate our own database, which 'streams' all Hive transactions and stores all relevant moves.

This way, we can use Hive to sign transactions and can find all important transactions quickly.

HAF

@mickiewicz/what-is-haf

This problem is pretty much as old as this blockchain and HAF does pretty much, what I describe above. We still decided to code up our own version of it.
That way, we have full control over what's going on.

Our DB needs only a fraction of the space, since we only store transactions relevant to EHON.
It's easier for us to customize our endpoint and its outputs.
It's easier to maintain a backup and to restart, should it ever break down.
We don't have to rely on third party software.

Crawler

Keeping our data 'healthy' (up to date and accurate) is not as easy as it might seem.
We created a 'crawler': It reads every block that is being produced and sends the data to our database.

This 'crawler' is finished and we will begin extensive testing soon to find any bugs.

The original idea was to feed data from Hive and data from Hive-engine to our DB at the same time.
This turned out to be much more difficult than I first thought and I wasted many hours only to come to the conclusion that it is not possible for us at this time.

Data was asynchronous, and made our DB unreliable. (among many other problems... dm me if you are interested)

Endpoint

To allow our users to read data from the DB, we created an endpoint (built on FastAPI).
To secure this endpoint, only logged in users can use it. To log in we require a Keychain signature.
The endpoint then allows our clients to read all relevant data quickly and reliably.

This 'endpoint' is finished and we will start testing it along with the crawler.

Next steps

1. Homepage

While the back bone is being rolled out and tested, I will work on the page next.
As mentioned above, I will include Keychain-login again.
As soon as that is finished, I hope I can come up with a version, that lets our users sample and play with at least the back end of our game, so they can actually experience the progress we have made.

2. Graphics

As some of you have noticed, the graphics we have presented were bought assets.
They were made with Unity and a custom tool called SPUM.
When I took over the project, I decided against them.

While it's absolutely possible to create EHON in Unity and load it into our web-service as webGL and connect it to our back end, the truth is: I can not.
Editing and creating custom animations in SPUM would take me way too long.

I decided to go with simple spritesheets and a custom engine built on HTML5 canvas, only.
I should be able to finish it in a reasonable timeframe and we can always review it at a later point to improve or completely rebuild it with different technologies.

For now, the focus is to get the first version of this game out the door.
If the game is good, graphics are secondary.

3. Web-client

As the final step, we will teach the client (webservice) to interpret that data and to tell our graphics engine what to display.
This will finish the first version of the game.