Posts Tagged game

Design roundup #1.

articlesheader Design roundup #1.

Whenever I sit down to write an article about some aspect of game design, I always do a bit of research first. Often I run into works that already cover the topic, usually more extensively than I would have, so I scrap it. That doesn’t make these existing pieces any less valid, though, so I’ve decided to periodically highlight them.

Also, there’s a lot of information out there that isn’t specifically aimed at videogame design: neuroscience, prose, psychology, etc. Articles that discuss these topics can still be quite useful for a designer, so I’ll try to include them as well.

, , , , , , , ,

No Comments

How I got art for my game, part 3.

cipactliheader How I got art for my game, part 3.

Having decided to move away from pixel art, I returned to ConceptArt.org to search for higher-res artists. Although my preference was for a style resembling Alice’s, I was open to other interpretations. After all, the characters would have to take on more deformed proportions to properly fit the dimensions, so there was no point in disqualifying CG renders, sketch-animations, etc.

aztec3 How I got art for my game, part 3.

Warrior concept by Daniel Hansen.

The requirements for the job stayed about the same:

  • 1 background, 1280×720, with some decorative objects that could be moved around.
  • 1 “unit” type consisting of 4 different colour versions, with each version comprising 8 angles (3 of them simply flipped) and 4 animations per angle.
  • 4 different enemy types, with 4 animations per enemy and one or two special animations.

I kept the $800 as the initial offer for this work. I was prepared to see this figure fluctuate based on the utilized style and its requirements, but I also thought it was good starting point.

As I found out prior to making my post, ads that pay more than $500 have their own section on ConceptArt and require a $50 fee to be posted. Since I previously had a positive experience with the site, I decided the price was worth it. Our IncubatorGames profile, though, listed us as a group, and I made the payment under my name, Radek Koncewicz. As a result, there was some confusion over the post and it didn’t initially go up, but the matter was quickly resolved after I contacted some of the forum administrators.

All in all, the ad generated about 50 responses.

aztec1 How I got art for my game, part 3.aztec2 How I got art for my game, part 3.aztec3 How I got art for my game, part 3.aztec4 How I got art for my game, part 3.
Animation mockups by Jesus Garcia, Tom Garden, IMGNATION and Decebal Tache.

Now the thing with pixel artists is that most of them create tiles, objects, animations, etc., as a matter of course. However, with illustrators animations are much more of a specialty. Lots of submissions showcased amazing background and character work, but very few contained examples of animations. This had me a little concerned, so I decided to request some mock-ups. Not wanting to alienate any of the artists, I offered $20 each for a simple animation test. It wasn’t a lot, but it was better than nothing. From our point of view, it also quickly added another $120 that we had to spend (although one of the artists was nice enough to actually send the money back when we didn’t choose him).

This turned out to have been a very good idea. The results were varied in style and quality, and really helped to showcase each individual’s ability to interpret and produce based on our directions. I realize that extra mockup payments might not always be feasible, but I highly recommend this extra step if things seem uncertain.

In the end, we decided to go with IMGNATION, a Brazilian art studio that had worked on videogames in the past. They accepted the $800 fee, with the only “extra” being a request to be credited in the game (which I was going to do anyway for all the contractors involved).

finishedbackground How I got art for my game, part 3.

The finished background. I ended up playing around with it in Photoshop to create the 7 different backgrounds we had in the demo.

The people at IMGNATION who worked on Tribes of Mexica were Marcus Severo de Moura, Rafael Batista Sarmento and Orlando Fonseca Jr., the studio’s project director. I only ever talked to Orlando, and initially he broke down the tasks as follows: background, 30% of the work, units, 20% of the work, and enemies, 50% of the work. Eventually the workload proved to be closer to: background, 20% of the work, units, 30% of the work, and enemies, 50% of the work.

Working with an actual studio meant that it was a bit harder to play things by the ear, but it also meant that — as a business — they’d work hard not to miss any deadlines. Gearing up for our own deadline, it was definitely nice not to have to worry about art deliverables being late.

The final background we received was great, and the animations were nice despite relying a lot on transformations (movement, scaling and rotations that are the staple of Flash “tween” animations). Granted IMGNATION was working on these animations while we were putting together a rough system to play them in the game, so things were not as optimized as they could have been. Hopefully this process will be improved in the future as we develop and fine-tune more tools.

With the core and concept art out of the way, we had all the vital components. However, there were still plenty of other visuals missing, which I’ll cover in the next entry.

Next Tribes of Mexica post.

Previous Tribes of Mexica post.

, , , , , , ,

8 Comments

Early prototyping lessons.

tomprototypeheader Early prototyping lessons.
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.

tomthreewaves Early prototyping lessons.

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.

    tomnewunits Early prototyping lessons.

    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.

, , , , , , ,

6 Comments

How I got art for my game, part 1.

tomart1header How I got art for my game, part 1.

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.

Read the rest of this entry »

, , , , , , , , , , , , , , , , , , , , , , ,

37 Comments

Tribes of Mexica, the beginning.

tomcoverheader Tribes of Mexica, the beginning.

I’m making a game. Here’s a video of the tech-demo/proof-of-concept:

The basic premise of Tribes of Mexica evolved from kicking around a few ideas that dealt with creating gameplay mechanics from radial menus. I have a couple different takes on it, actually, but the one I’m currently focusing on is a classic match-three approach. The reason for this is that it’s a relatively simple and intuitive concept, but it still provides me some room to be unique.

Of course the fact that match-three is almost a genre unto itself means that I’m not going for 100% originality. And that’s OK, too. Very few developers seem to be willing to point out their inspirations, and it’s a silly phobia. Also, too many titles are credited with being original when they simply use an existing formula with a new element or two. Instead, I’m committed to creating this game all the while calling a spade a spade.

tlalocconcept Tribes of Mexica, the beginning.

Concept art for Tlaloc, one of the more significant gods in Aztec mythology.

So what’s my inspiration? Well, I think Puzzle Quest will draw the most comparisons, and that’s fairly accurate.

Soon after prototyping the ring-rotation, though, I realized that it’d be tough to make a pure puzzle game out of ToM. The interconnected nature of all the coloured elements meant that it was virtually impossible to visualize ahead more than a move or two. Typical links/chains/combos were possible, but they were usually a result of luck, not skill. The radial design also imposed various limitations that are not an issue with static, grid-based puzzlers such as Bejeweled. Still, I was fond of the core concept, so I decided to build on top of it and turn it into a combat game of sorts.

Much like Puzzle Quest, each attack fills up a colour-coded “spell” (currently indicated by the Xbox 360 controller’s face buttons), but I think that’s where the similarities end. ToM is a real-time game, requiring constant analysis and input. In fact, I think it’s more akin to Patapon than anything else; it’s an abstraction of an RPG battle system coupled with an interesting input mechanic.

The one-on-one nature of ToM also allows it to draw upon some elements found in traditional fighting games, and I’ll try to incorporate more of those as the title progresses.

Also, until we give the Incubator Games website an upgrade, I’m going to chronicle the whole experience here on Significant Bits. It’ll allow me to talk about the evolution of ToM’s design while bringing up a couple of other topics such as contracting and promotion. Too often such talking points are relegated to sentiments of “You should do it, and it’d help if you did it well,” though, and that’s not very helpful. Instead, I’ll strive to provide hard numbers and some personal opinions on the overall experience. Hopefully you’ll all find it interesting.

Next Tribes of Mexica post.

, , , , , , , , , , , , , ,

7 Comments