Home

Awesome

AAAAXY

AAAAXY is a nonlinear 2D puzzle platformer taking place in impossible spaces.

Although your general goal is reaching the surprising end of the game, you are encouraged to set your own goals while playing. Exploration will be rewarded, and secrets await you!

So jump and run around, and enjoy losing your sense of orientation in this World of Wicked Weirdness. Find out what Van Vlijmen will make you do. Pick a path, get inside a Klein Bottle, recognize some memes, and by all means: don't look up.

And beware of a minor amount of trolling.

To reach the end, a new player will take about 4 to 6 hours, a full playthrough can be finished in about 1 hour and the end can be reached in about 15 minutes.

The game is available for the following platforms:

PlatformDownloads
AndroidF-Droid, Google Play
HTML5 (slow)netcup
iOSApp Store
LinuxFlathub, GitHub, Itch, Snap Store
macOSGitHub, Itch
WindowsGitHub, Itch

Available languages: Arabic, Belarusian, Chinese (Simplified), Chinese (Traditional), English, German, Japanese, Latin, Portuguese and Ukrainian.

Screenshots

shot1 shot2 shot3 shot4 shot5 shot6 shot7 shot8

More Resources

This documentation is intended for developers; user-centric documentation is available on the game's website.

Notable Libraries

This game is based on the following libraries:

Compiling

This game has been successfully compiled on Linux, FreeBSD and Windows, and will likely compile just fine on other unixoid systems as well. For other platforms some minor porting may be required so save games and settings can be retained; in particular see vfs/state_*.go.

To build the game for yourself, install git, golang, graphviz, imagemagick and pandoc, and then run:

git clone https://github.com/divVerent/aaaaxy
cd aaaaxy
git submodule update --init --remote
make

NOTE: On FreeBSD systems, use gmake instead of make to compile.

To update and rebuild, run:

cd aaaaxy
git pull
git submodule update --remote
make

You can also immediately compile and run the game using:

make run

Editing

In a Source Checkout

Use Tiled on the included aaaaxy.tiled-project. The map is in assets/maps/level.tmx.

If checkpoints were changed, run make assets-update to regenerate the checkpoint map.

make run will use the modified data.

On a Release Binary

Run the game with -dump_embedded_assets=/path/to/folder/for/editing. Download the mappingsupport pack from the release and extract it to that same directory. Tell Tiled to use the included `objecttypes.xml.

Running the game with -cheat_replace_embedded_assets=/path/to/folder/for/editing will then use the modified data.

Changing checkpoints is not supported this way.

Mathematical Notes

This game does not take place in the Euclidean space you're used to - instead, you are experiencing the universal cover of a massively twisted space, which feels like a space with a locally-Euclidean topology and geometry, which however violates some of their axioms globally (e.g. the shortest path from one point to another modulo the equivalence relation is not necessarily a line, and parallels are not always unique).

For some added confusion, the space is occasionally reconfigured by turning portals on/off at runtime, further violating expectations.

This is rather similar to seamless portals, but yields stronger immersion and is generally an interesting approach I wanted to try out. In particular, gravity behaves consistently across portals, and objects are entirely glitch-free around them. The player is only ever visible once. On the other hand, this approach can not sensibly support multi-player games; a more traditional portal based engine would be more appropriate there, where the same object may be seen multiple times on the screen. Sadly that approach would appear rather confusing in places where this would cause the player themselves to show up multiple times at once, which is why I did not go with it.

In 3D games with transparent portals/warpzones, immersion is usually achieved by treating each portal as a dynamic texture surface which shows a view out of a camera projected to the other side. An open source implementation of this can e.g. be found in Xonotic. The reason why this works is that only those parts of an object are shown that have a line of sight to the player - as expected in a first person game. Implementing a third person view that way is already a bit more tricky but usually one can work around the view origin mismatching but being close to the player origin; however what is usually not possible with transparent portals in a top-down or other 2D-ish view, as conflicting (e.g. self-overlapping) geometry may need to be rendered to the screen at the same time.

There are however two approaches to solve this:

License

This project is released under the Apache 2.0 License.

Disclaimer

This is not an officially supported Google product.