Archive for category projects
Early Prototyping Lessons
Posted by The Management in design, projects on July 13, 2009

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.
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.
- 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.
How I Got Art For My Game, Part 1
Posted by The Management in art, projects on June 23, 2009

As a kid, I used to excel at various visual arts. I enjoyed sketching, drawing, painting, etc., and some of my work was even briefly displayed at a quite silly our-children-are-the-future event. As I grew older, though, my interest in art waned and I eventually abandoned it for other hobbies. These days I can draw a stick figure as good as anyone else, but that’s about the extent of my skills. As such, I definitely needed some help with the visuals of Tribes of Mexica.
So Why XNA?
Posted by The Management in projects on June 15, 2009

Well, as the title suggests, I’m currently developing Tribes of Mexica as an XNA game. Considering the somewhat poor sales of XNA titles, this might seem a bit perplexing. After all, no matter how much one enjoys creating games, it’s nice to get paid as well.
So why did I choose to go with XNA?
Well, a couple of reasons, actually:
- An XNA game is pretty much guaranteed to be released, and consequently to make some money. This might be a small consolation, but it’s hard to get any guarantees in the world of publishing.
- Although I’ve sporadically developed PC stuff, most of my professional career has revolved around very limited devices, i.e., mobiles/handhelds. The Xbox 360 is a beast by comparison, and XNA’s entry cost is about as low as it can get. The alternative is licensing a professional dev kit, which can be quite pricey and time consuming (and never a guaranteed thing). With XNA, registration is done online and only costs $99 USD.
- The recently renamed Indie Games Marketplace is based on self-publishing, which means that you get to retain your IP and all the rights to your creation. If it flops, no one will stop you from tweaking it and porting it to another system.
- Aside from CarnyVale Showtime, Microsoft hasn’t really promoted XNA games that much. Now most of them (at least as of right now), are pretty rubbish, so that’s not really surprising. The option for future promotions is still there, though, and the upcoming ratings system might help as well. Regardless of all that, having your game available on Xbox Live! is still a great source of exposure for a brand new developer.
- Another possible reason why promotions haven’t been that prevalent is that the best XNA games have a tendency to make their way onto Xbox Live Arcade, e.g., Schizoid and The Dishwasher: Dead Samurai. Publishers seem to be keeping a keen eye on these titles and have shown a willingness to support XNA developers.
- DreamBuildPlay is a good exhibition of XNA games, and has some nice prizes to boot.
- There are 200+ games available on XNA right now, and although that might seem like a lot, it’s not nearly as many titles as there are on the oversaturated iPhone App Store. The opportunity to make a game that stands out and gets attention is still quite good, and things will probably stay that way at least for a little while longer.
Next Tribes of Mexica post.
Previous Tribes of Mexica post.









