Recent changes to tickets

#6 Level editor for Hex-a-hop

Rolf Sander — Wed, 22 Apr 2026 07:29:26 -0000

Here is an update on my level editor for Hex-a-hop. I can now modify the
levels.dat file and create arbitrary new levels. The source code of the
game remains unchanged, all you have to do is replace the original
levels.dat by the modified version. An example is attached. Please try
it! There are several new levels (all solvable), plus some dummy levels.

To create your own levels, you currently have to modify some variables
inside a Python script. If there is sufficient interest, I can make the
code available and write some documentation.

BTW: I found an Easter egg in the game. There is an additional tile
called "switch" which switches between flat green tiles and green hills.
It hasn't been used in any of the 100 standard levels, but it works
perfectly fine when you use it in your custom-made levels :-)

#6 Level editor for Hex-a-hop

Rolf Sander — Thu, 05 Feb 2026 12:15:16 -0000

Thanks for your feedback, Paul!

My approach is basically the same as what you had planned: First,
decompile levels.dat back to some readable ASCII files. Then, write a
level editor that works with these ASCII files.

So far, I've been able to locate the individual levels in levels.dat.
Inside each level, I can see the hexagonal map (more details below). I
can even change individual bytes in levels.dat and get different tiles
when restarting hex-a-hop.

What I'm still struggling with are the bytes before and after the tile
definitions. I assume they define the width and height of the hexagonal
map. Also, there must be the starting position of Emi somewhere.
Deciphering these bytes is where I mostly need help, as I cannot find
the part of the code where these bytes are read and applied.

As an example, here is the 2nd level (called "Hive"). The header is:

18 00 00 00 03 00 00 00 01 08 07 0d 01 00 00 00 0b 00 00 00 00 00

Next, the layout of the tiles:

00 00 02 02 00 00
00 02 02 00 02 02 00
02 00 02 02 00 02
01 02 02 00 02 02 01
02 00 02 02 00 02
00 02 02 00 02 02 00
00 00 02 02 00 00
00 00 00 01 00 00 00

If you flip this along the main diagonal, you can recognize the
hexagonal map of the "Hive" level (00=water, 01=gray, 02=green).

Finally, there is a footer:

00 00 89 00 00 00

If I manage to understand this syntax and write some sort of level
editor, I will of course make my code and data publically available.

#6 Level editor for Hex-a-hop

Paul Wise — Thu, 05 Feb 2026 05:15:34 -0000

I inherited the project from the original author @amuzen, unfortunately they didn't document the format apart from the source code in packfile.h and they didn't release the source level files. I have been meaning to decompile levels.dat back to some sort of source level files and then delete the levels.dat file from git, but I never got around to it.

Looking at the code, I see there might already be some form of level editor that is enabled when you define an EDIT macro, and I got it to compile and run (see attached diff), but I wasn't successful getting to do anything useful and I don't know the keyboard shortcuts for it yet.

I think it would be great to remove the EDIT macro and instead enable the edit mode when a menu option is enabled, if you would like to work on that, then I will definitely review and merge any patches you write.

Any other help you can give on Hex-A-Hop would be very appreciated.

@guillemj is the most recent person to work on Hex-A-Hop btw.

Level editor for Hex-a-hop

Rolf Sander — Wed, 04 Feb 2026 20:02:19 -0000

I would like to create new levels, and maybe write a small level editor
for Hex-a-hop. AFAICS, I can achieve this by editing the levels.dat
file. Is there a description of the syntax of this file? Any help is
appreciated!

#5 Consider uploading to Flathub

Stephan Sokolow — Tue, 20 Sep 2022 00:58:44 -0000

Is there a command-line validator tool for the format I should use?

Yes, but the upstream maintainership situation is... less than satisfactory. The fork you're supposed to use is available as:

flatpak install flathub org.freedesktop.appstream-glib
flatpak run org.freedesktop.appstream-glib validate <FILENAME>

#5 Consider uploading to Flathub

Stephan Sokolow — Tue, 20 Sep 2022 00:43:37 -0000

Please do. There is an Appstream XML file in the upstream git repo already, hopefully it is suitable for Flathub too.

It's a bit incomplete. Aside from me being a completionist and a perfectionist, I'm not sure it'll pass validation, since I think the validator wants at least one <release> element so it can surface them in the upcoming UI redesign being demo'd at beta.flatpak.org.

(I've fired off a request to relicense the release text from Tomatoes to improve its entry on that front.)

You'll probably see me offering up a patch to expand your Appstream XML out to something like this.

Sounds like Fedora might change that at some point.

https://lwn.net/Articles/897793/

Thanks for that. I really need to get back to reading LWN consistently again.

Yeah, I got access to the Tomatoes project too but never got around to
modernising the project with a VCS/etc.

Speaking of which, would you like me to add a <url type="bugtracker">https://sourceforge.net/p/tomatoes/_list/tickets</url> element to the Appstream XML for Tomatoes when I add the x-checker-data definitions I forgot to add for Tomatoes itself?

Also, if you ever do get around to it, let me know in case I have time to write a patch to add native joystick/gamepad support for people like Steam Deck users.

#5 Consider uploading to Flathub

Stephan Sokolow — Mon, 19 Sep 2022 06:58:46 -0000

Thanks for the suggestion and sorry for the delay in responding.

No problem.

Since Flatpak is a packaging system I think that the packaging files should be maintained separately to the upstream project. The appropriate location would be where separate Flatpak packaging is often stored. For Flathub that seems to be in a git repository in the @flathub organisation on GitHub.

Yeah. They have a couple of bots tied into it for automatic "bump dependencies" PRs if you define how to check for updates, test builds of PRs, and automatic deployment to Flathub.

Personally I prefer packaging systems with more fine-grained dependencies such as Debian packages, so I don't intend to work on a Flathub submission myself and would prefer that someone else submit and maintain the package.

No problem. As long as you're OK with it, I'd be willing to put together a build manifest and Appstream XML for it.

My main issue with maintainership in general is limited tolerance for new obligations showing up out of the blue and, with flatpak-external-data-checker handling version bumps and the game itself seeing minimal change meriting new releases, that shouldn't be a problem.

If you decide to submit Hex-a-Hop to the Flathub GitHub organisation, please @pabs3 in your submission so I get a notification and I can then review what you submitted.

Would you prefer I put something up on my personal GitHub account for you to review before I do the "fork new-pr on flathub, put your submission in it, open a PR, and let them review it" dance and involve a submission reviewer from Flathub?

Please note that some of the audio included in Hex-a-Hop git master is licensed under non-free licenses, so if Flathub requires licenses to be free, then you may need to strip those files out. If you are interested in helping replace them, contributions are welcome of course.

Flathub is OK with non-free licenses. As I understand it, that's why Fedora Silverblue doesn't enable it as a source by default.

The submission guidelines say:

All content hosted on Flathub must allow legal redistribution, and the license must be correctly specified in the app's appdata file. Non-redistributable files can be downloaded at install time using the extra-data source type.

...so it should be fine.

Please also forward and bugs reported, workarounds found or patches written etc back to this upstream project for Hex-a-Hop. Unfortunately that hasn't happened for other projects I am upstream for like Chromium BSU.

I'll have to ask them if they'd be willing to turn off the issue tracker and let you @ssokolow me when I'm relevant.

I can't find your ticket in the Tomatoes project, but I think the same reasoning as above applies to it too.

I e-mailed Mika Halttunen directly because the state of the SourceForge project didn't give me much confidence that I'd get a response there. I already got the "I don't have time to do this, but go ahead" and I'm now maintaining a FlatHub release of it:

https://flathub.org/apps/details/net.sourceforge.tomatoes.IHaveNoTomatoes

#5 Consider uploading to Flathub

Paul Wise — Mon, 19 Sep 2022 06:30:14 -0000

Thanks for the suggestion and sorry for the delay in responding.

I agree that it would be useful for Hex-a-Hop to be available on Flathub for folks who use immutable systems like Fedora Silverblue or SteamOS.

Since Flatpak is a packaging system I think that the packaging files should be maintained separately to the upstream project. The appropriate location would be where separate Flatpak packaging is often stored. For Flathub that seems to be in a git repository in the @flathub organisation on GitHub.

Personally I prefer packaging systems with more fine-grained dependencies such as Debian packages, so I don't intend to work on a Flathub submission myself and would prefer that someone else submit and maintain the package.

If you decide to submit Hex-a-Hop to the Flathub GitHub organisation, please @pabs3 in your submission so I get a notification and I can then review what you submitted.

Please note that some of the audio included in Hex-a-Hop git master is licensed under non-free licenses, so if Flathub requires licenses to be free, then you may need to strip those files out. If you are interested in helping replace them, contributions are welcome of course.

Please also forward and bugs reported, workarounds found or patches written etc back to this upstream project for Hex-a-Hop. Unfortunately that hasn't happened for other projects I am upstream for like Chromium BSU.

https://github.com/flathub/net.sourceforge.chromium-bsu/

I also think that the Debian packaging should be maintained within Debian, so probably the debian/ directory will get removed at some point, since the Debian games team are already maintaining Debian packaging for Hex-a-Hop.

I can't find your ticket in the Tomatoes project, but I think the same reasoning as above applies to it too.

https://sourceforge.net/projects/tomatoes/

#5 Consider uploading to Flathub

Stephan Sokolow — Wed, 07 Sep 2022 11:44:39 -0000

Also, I forgot to mention, but it's likely the reason such games have been showing up on Flathub lately is that, by default, the Steam Deck comes with a read-only OS partition and Flathub support, so uploading to Flathub is sort of like submitting to F-Droid, but for the Steam Deck.

Consider uploading to Flathub

Stephan Sokolow — Wed, 07 Sep 2022 11:17:47 -0000

Recently, I noticed that a lot of the classic "distro repo games" like Frozen Bubble, Rocks'n'Diamonds, and Enigma have been added to Flathub and, as someone who enjoys Hex-a-hop, I'd really like to see it on there too, both for the convenience and the chance to get found by new players.

(If you're not familiar with Flathub, it's the main package repository for Flatpak, which is the effort to provide a modern cross-distro package manager with Android/iOS-like sandboxing that's being taken up by basically all distros except Ubuntu, who are staying true to form and trying to get people to adopt a competing solution (with a more fundamentally flawed design but a bigger PR budget) that they control named Snap... though I can confirm Flatpak works perfectly on Ubuntu-family distros if you follow the quick install instruction on Flathub.)

If you're interested, I'd be willing to put together a set of the requisite metadata files analogous to the debian folder in your repo. It's just that their submission guide says they just want people to ask upstream to do the submitting if possible. (If you need an example of the relevant metadata, here's a set of such files that I put together for the e-mail I sent to the author of I Have No Tomatoes yesterday. The only file in that repo that isn't a "Useful for everyone. Upstream it if possible." file is the flatpak-builder JSON file itself.)