Now that Lowrezjam 2022 is over and rankings are out, I thought it was time to recap a bit on what’s been the story and the process behind Aztec. I will also give some hints on the near future for it, but let’s start from the results.

Ranking

Globally, Aztec did great in terms of results… Ranked 11th in global scoring (out of 430 entries), with the best score in Graphics, ranking 5th in that category. See the results and voting distribution:

In terms of voting, the game got quite some attention, leading as most voted entry the whole ranking window and ending with 92 ratings. Rating distribution follows:

Analyzing the results, and based on the feedback received on the game, the main crippling area was gameplay, mostly dragged down by two elements: Jump mechanics and Savepoint mechanics. I will dig into the game design decisions further down this post.

The Story of Aztec

When lowrezjam themes showed up I really did not have any particular idea on what I would be making, and frankly, the themes did not feel soo inspiring. Rummaging about them all, “The Sun is the Enemy” brought the idea of the Sun as a God or powerful being and the need to fight against him. The Sun’s been considered a deity in many cultures, and something that rang a bell directly was the Aztec’s Sun Gods… Gods who sacrificed themselves to become The Sun God, who were feared and had obscure myths around them. It was time to dig some documentation…

Tonatiuh, the 5th (and last…) Sun God felt like a good pick, a warrior god demanding sacrifices to placate his wrath under the threat of retiring his ligh if angry. The Tonatiuh Cualo, name given to eclipses and with a rough translation close to “the eating of Tonatiuh” was a feared moment where Tonatiuh battled The second Sun in his era who turned into the moon after dying. There probably were rites to favour the God and focus his wrath on his enemy so he could come back and bring the light back with him. bingo, I had a story there I could use to frame the plot of my game, but what that could be?

Long time ago (over a year…) I had built a small prototype for a platformer in pico8, with almost the same palette I have used with Aztec. The plot was pointing towards a temple, and that brought in the idea of Prince of Persia (just because lately I’ve seen a lot of work around a demake of PoP for Pico8) so I guess it all just popped together. I would build a PoP-like platformer, inside an Aztec temple.

Game Design

When I had my mind set around PoP-like platforming I set in stone the core decision that would frame the whole style of the game. I wanted a realistic approach to platforming (cinematic style) with natural proportions and getting away from speed-running platformers like Mario. Challenging… really challenging at 64x64 resolution!

The game would include precission jumping, falling damage, ladders, and puzzles… some of the mechanics I had in mind where pushable blocs, levers, pressure plates, crank pulleys… and I was somewhat decided to go away from “magical” elements you find in platformers, like floating platforms and such. Keys were also out the list because locks were not a thing for the Aztecs, but in favour of some challenge I added the jewel locks. The game would require some saving points, but I did not want the game to become too easy due to those.

Good, I had a draft of what I would be needing, time to get things moving.

Implementation analysis

Even if I had done a small platformer prototype, Aztec was my first serious attempt to platformers… and that proved to be a big challenge. The first thing I built was a crude physics engine that would apply to all moving objects in the game… that would apply gravity pull, friction, acceleration and move the object through the world, considering any collisions. Coordinating animations and physics turned the game entities, and particularly the main character, into an extremely complex state machine with quite a few flag modifiers. You could be landed, jumping, flying (needed for objects not pulled by gravity), falling and climbling, but some of those states had substates, like the player being landed could also be in a “landing” state for when a high jump forced you to land heavily in the ground… physics applied as a landed object, but character animation and responsiveness needed to be adjusted, or pushing that affected animation and speed… All that code grew organically and not so organized through the jam time and needs a huge clean-up and refactor.

Savegames were promptly discarded… the amount of data to put into the save was so big and complex I just did not have the time to even think about it for the jam, so those needed to be treated like checkpoings/respawn points only. That part was easy, but then difficulty dropped too much if you could just die from some sloopy jump and respawn to try again, and again, and again… One of the probably worst decisions in gameplay came in there… the mirrors will need to recharge before being used again, so a respawn was a “miracle” you could not enjoy so often. The implementation for that was kind of hurried and buggy, sometimes the mirror was still “flashing” but could be activated while others it just worked fine… and I could not also put a too long recharge time there if those were to be useful at all so this ended as a patchy solution, forcing the user to wait for the flashing to die and recover the checkpoint.

Another of the implementation nightmares were the ladders. Some race condition in the order of the checks have the player doing funny climbing detaching and reattaching to the ladder when jumping (to be fixed…). Also, given the nature of the collision checks, ladders don’t collide with the moving entities, so the physics engine needs to determine if they are at the top of a ladder and prevent them from falling through. That also ended a bit buggy for fast falling objects and needs some polishing in the collision detection to prevent the hitbox simply misses the checks.

Jumping was another of the gameplay nightmares according to the feedback. Not having air-control during the jump si so against what you can call “modern” or “standard” platformers that users simply fight against it. Add to it the implementation has a noob error… it requires precise button-press ordering, no easing around that, which ends up requiring the user to be really skilled on how the jump works to press in the right order and to learn how long a jump-press to maintain to control distance. This whole thing needs a revisit: easing button press ordering with a few frames bubble that improves responsiveness feeling, and maybe some minor air control (that could be explained as balancing and weight shifting while jumpling) to improve distance control on tight jumps.

Some of the planned mechanics did not make it into the game, due to time and to cart space (PICO-8 has heavy limitation on how much you can put into a game) like the crank pulleys or adding more variety to levers than just remove a wooden platform to drop an object (it was planned those would also open hidden walls, move ladders… to increase the number of available puzzle elements)

Graphics and Music

I was quite sure I wanted to reuse that palette experiment from my platformer prototype, and I refurbisehd some of the tiles there for this project, but I needed a temple look. Looking for some inspiration I came around this wonderful tileset (for bigger resolutions) and thougt about reinterpreting that for pico-8 and for the target resolution

I also wanted a custom font that gave some Aztec/Mexica vibes, and I think the one I put up, lightly inspired in Ambages font did the trick.

Animating Guatemoc was probably one of the hardest challenges… at a base size of 10x12/10x13 achieving a fluid and anatomically correct animation took many many hours, but I think those hours paid off.

Somewhere in the middle of the jam, VavMusicMagic offered up to help with some music. As he had no experience with PICO-8 he initially offered to check on some ppl to see if he could find someone who wanted to help, but finally, and using PICO-8’s educational version, he created a couple of wonderful tracks and a few SFX to add to the ones I already had in place that really took the game to a totally new and far superior level of quality.

Conclusion

All considered, I am really happy and proud of how much went into the game in just 2 weeks. A big part of the time was used for graphics and finding my way around building a platformer… There were bugs, mechanics to fine tune… but the result is probably one of the best games I’ve been able to put up.

Post-jam Aztec is going through a severe rewrite… I need to organize and clean-up the mess around the platforming states and the physics engine so I can make some space for fixes and improvements. Apart from what I already commented through the post, a proper ending game sequence with Tonatiuh Cualo happening was in the to-do list, and a much bigger map with more puzzles and challenges. Let’s see if I can put all that up in the following months!