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:

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

Screenshots

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:

• Ebitengine for low level graphics and input
• Oto for sound.
• tmx for parsing Tiled tile maps.

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:

• Design levels so that conflicting geometry is never on screen.
  • In other words, when transparently teleporting in order to move the player past a portal, a screen-sized environment of the source position must always match a screen-sized environment of the destination position.
  • This approach is simple and very immersive and has already been used in the original Super Mario Bros. game on the NES.
  • It however is not very flexible as any impossible geometry has to be rather large and behave fully Euclidean on every screen-sized environment around positions the player can visit.
• Hide anything that has no line of sight to the player.
  • This actually matches the approach used in first person 3D games
  • With this approach, the game needs to be consistent with Euclidean geometry only in small environments around each object.
    • In this implementation, the consistency requirement is that an 1-tile environment around every portal must match, and that the same "screen tile" cannot be reached by a 1-tile environment around a line of sight through two different sets of portals at the same time.
    • As this game demonstrates, this can yield rather interesting while still obvious non-Euclidean topologic properties.
  • This is the approach has been explored in this game as well - but very likely for the first time in a two dimensional game.

License

This project is released under the Apache 2.0 License.

Disclaimer

This is not an officially supported Google product.