As I previously stated, Tribes of Mexica is not intended to be wholly original. Of course most games build on top of their ancestors; the gameplay analogues are fairly easy to spot. However, that doesn’t mean that most games are devoid of creativity. For example, Braid took existing elements such as platforming (very refined) and time travel (somewhat new), and combined them into a unique experience. With ToM, I aim to do something similar.

RPGs and fighting games matched what I had in mind for ToM — i.e., combat-heavy gameplay with a variety of tactics — so I browsed through their toolboxes for inspiration. From these, I could safely assume that stunning an enemy or implementing recharging spells wouldn’t be a problem. My match-three core mechanic, though, relied on rotating concentric rings, which was a bit more unique. As such, it was a key focus for prototyping.

Programmer art of three sets of matched units rushing in to attack the enemy.

Granted as soon as I got this idea, I was flooded with visions of various units performing distinct animations that matched their respective Aztec gods. This sort of stuff was fairly rooted in aesthetics and not gameplay, though, so I had to set it aside and concentrate on cold, hard mechanics.

Here’s a bullet-point overview of those early prototypes:

• I started off with 4 main colours on account of wanting to associate four major Aztec gods with the face buttons of the Xbox 360’s controller. This is a relatively small number for a matching game, but adding more didn’t seem to make sense. I wanted to maintain the relationship between the gods’ “spells” and the face buttons, and throwing more colours into the mix just broke this symmetry.

  I did briefly experiment with more unit types (the coloured circles) to see if I could add non-attacking troops. In Puzzle Quest: Galactrix, for example, the blue hexagons simply fill up your shields, but this muddled things up. It seemed confusing that some units didn’t directly attack the enemy, and any benefits they granted could simply be implemented via a regular yellow/red/blue/green spell.

• Most colour matching games only need 3 or more consecutive colours to register a match, and that seems like a magic number. If it’s 4 or more, then it takes a significantly longer time to spot a possible match, and it makes randomization of the game board that much harder to balance. Because of this, I decided to go with 3 rings of units (at least for the core mechanic). This also had the added benefit of making it quicker to select any single ring, i.e., the player was always only one click away from selecting his desired ring.
• 6 units in the first ring is pretty much the minimum possible number. Any fewer, and the player doesn’t have enough parts to perform the matching mechanic in any satisfactory fashion. I didn’t use any more units than that, however, as they’re humanoids that take up more physical space than your typical gems or spheres. They also need to be recognizable and exude some personality all the while accommodating for lower resolutions (for possible PC/Mac/Linux ports and the TV Safe Area issue), but I think I’ll further experiment with this number when I get the final animation sets.
  

  I'm rather fond of using gradients and Photoshop's cutout filter when creating placeholder art. It's not the prettiest, but it's a hell of a lot easier to look at than MS Paint scribbles.

• Each ring contains double the amount of units as the ring that preceded it, i.e., the first one has 6, the second one 12, and the third one 24. This gives us a total of 42 units, which isn’t quite as many as Bejeweled’s 64, but we also only have 4 colour-types instead of 7.

  To give the game more symmetry, I tried putting the same number of units in each ring, but that didn’t work out very well. It greatly reduced the total number of “matching parts” and made the area around the enemy seem a bit barren. All in all, I think it stands to reason that the further the ring is from the enemy, the bigger its circumference, and the more units it can house.

• When a match is performed, the three units rush to attack the enemy, disappear upon contact, and get replaced by three new units that run in from an off-screen area. At first, I kept these fully randomized, but this created scenarios where the player couldn’t always perform his desired match. For example, if he saw two green units aligned in the second and third ring, he’d naturally look for a green unit in the first ring. If the first ring contained no green units, the player would feel a little cheated and would have wasted time seeking out the third green unit.

  Since the player’s spells fill up as their unit counterparts perform attacks, this also meant that — at times — the player simply wouldn’t be able to execute certain attacks. A lot of intended strategy of the combat is picking specific spells from a common pool and casting them at desired intervals, so I had to make sure that each ring had at least one unit representing each of the 4 colour types.

• A lot of matching games rely on planning ahead and visualizing the game board’s arrangement following a move. This is used to perform multiple matches at one time, or to plan ahead cascading matches, i.e., when 3 blue gems are matched and disappear, the gems above them may fall in such a way that 3 more yellow gems are matched automatically.

  Since the units are all attached to the rings and don’t move within them, this sort of planning was very limited and difficult to visualize. Furthermore, due to the controlled nature of the randomization, the player couldn’t know what new units would run onto the field until a match was actually executed. The ring alignment basically prevented planning “combos,” so I ultimately decided against making them an integral part of the gameplay.

• Making sure that each ring had at least one unit type also increased the amount of accidental matches. Unless these led to infinite loops, though, I was fine with them. They presented a quick reward that the player understood visually, and resulted in the player feeling like he got a lucky break.

Next Tribes of Mexica post.

Previous Tribes of Mexica post.

| | | | | |