Posts Tagged XNA

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

Tribes of Mexica DreamBuildPlay contest entry.

dbpheader1 Tribes of Mexica DreamBuildPlay contest entry.

It’s finally done, and none too soon either.

The idea behind that splash-page is stolen from the Xona Games guys, by the way, except I designed our version to be compatible with lower resolutions without the need to scroll. It’s still temporary, but I think its’ a good bare-bones placeholder.

With that out of the way, regular programming will now resume…

Next Tribes of Mexica post.

Previous Tribes of Mexica post.

, , , , , , , , ,

5 Comments

The XNA to indie transition.

xnaheader The XNA to indie transition.

Details on Xbox Live’s XNA section transforming itself into an “indie” one have finally arrived.

The name change was announced a while ago and it seems like a fairly reasonable move. The word “indie” carries a lot more cachet than “XNA,” and “Indie Games” rolls off the tongue much more nicely than “XNA Community Games.” A bunch of nice new features were also announced such as tokens. These digital coupons come in a limited quantity and (presumably) can be sent to anyone you want, at which point (once again, presumably) they’ll be able to download your game for free.

With the oncoming user rankings, this could really improve the service, but I am very disappointed by the new price changes.

I was never big on the concept of price slots, and now they’re being shrunk down. What used to be the 800/400/200 scale is becoming a 400/240/80 one. This might be a result of so many XNA titles being little “trinkets” that resemble the $0.99 entries on iPhone AppStore, but I don’t see a reason to drop the ceiling as a whole. 800 points was not an astronomic number to begin with, and now the highest price that indie developers can charge for their XNA titles is $5. Won’t this simply increase the amount of games of dubious quality and further enlarge the rift between Xbox Live’s Indie and Arcade titles?

Then again maybe that’s the intention. Prices of Arcade games have been steadily going up, while there’ve been rumours of indie developers being shut out from the Arcade section. The lower price points might encourage experimentation, but, in the end, I don’t see them helping XNA games get closer to the overall polish and quality — at least a perceived one — of Arcade titles.

, , , ,

1 Comment

How I got art for my game, part 2.

art2header How I got art for my game, part 2.

With a concept artist in tow, it was time to get some in-game art.

I’ve always been a huge fan of pixel art, and not just due to nostalgia. I really like the style and its use of colours and textures, and its overall ability to convey visual information. To put it simply, I think it’s charming, and it would’ve made a great fit for Tribes of Mexica.

Over the span of the last decade, I’ve worked with about a dozen pixel artists at two professional game companies, and met countless others while pursuing hobbyist projects. I even enjoyed my own time with DPaint; I was decent enough with tilesets, but horrible at animations. Unfortunately, all these artists were either too busy or were working under non-competitive clauses that prevented them from helping me out.

As such, I had to find someone new for the job.

sbcollection How I got art for my game, part 2.

A group of 2D games that were never meant to be. The above list contains mocked-up screenshots from various pitches we worked on at my last company (art by Eric Vedder, Ben Henry and Joe Pendon).

Before that could happen, though, I was determined to tick off a few goals that would hopefully aid me in my search. First, I wanted to hire a concept artist to do some work that would serve as a reference and a token of my dedication to the project. Next, I wanted to code a “tech demo” that would not only be tangible proof of ToM, but would also help me figure out some of the art requirements (such as dimensions and animations). I also wanted to get a single music track for the demo and make a video out of it as it’d be a useful tool for showing off the game.

Finally, I needed to do some research.

One of the reasons I thought pixel art would be a good fit for ToM were the sizes of the in-game entities. They ranged from 36×36 all the way to 200×200, making them very suitable for pixel art. However, the backgrounds weren’t. My prototype ran at a 1280×720 resolution, which was huge even without any scrolling. I certainly didn’t need a tilemap, but this would still be a potential problem. I discussed it with some artists I knew, though, and they assured me that it was easy enough to draw and scale a background, and then paint over it with a somewhat limited palette while avoiding smooth gradients, blotchy brush strokes and anti-aliasing. This would give the background a somewhat pixelated look that would blend in fairly well with the entities.

With all that out of the way, I posted a job ad on the Pixelation, Pixel Joint and IndieGamer forums.

My initial request consisted of the following:

  • 4 backgrounds, 1740×720, with some decorative objects that could be moved around.
  • One “unit” type consisting of 16 angles. Well, 9 angles, really, as the other 7 could be flipped/mirrored without any extra work. Each angle would contain 4 animations, 2 of them single frames, and the other 2 comprising 2-3 frames. Each unit would be 36×36 in size and would need to be provided in 4 coloured versions via palette swapping.
  • 6 enemy types with 4 animations each. Once again, 2 of the animations would consist of single frames, and the other 2 would be 2-3 frames each. Enemies ranged in size from 36×36 to 200×200.
konjak How I got art for my game, part 2.

Konjak made a name for himself with Noitu Love 2 and various other hobbyist and professional games. Although we never talked before, and he was quite busy when I sent him an e-mail, he was also nice enough to quickly respond in a cordial manner.

I didn’t post a specific fee for these as neither I nor the other Incubator Games guys were sure of what the price ranges should be. We didn’t have a specific budget set aside for the in-game art either, so we decided to roll with the punches. If the offers we received involved sums that we could immediately afford, then great. If not, we’d either have to scale down or look to pool together some more money.

The lack of a specific fee in my post probably meant that we wouldn’t get as many offers as we did via my concept art ad (at least not initially), but I was OK with that. I also noted that if artists were only interested in doing the backgrounds or the animations, they should still apply. Obviously I would’ve preferred to have a single artist do all the work, but I knew that some would be experts in only one area and would want to avoid the other.

What quickly became apparent is that most pixel artists judged the budget of a work strictly by the amount of pixels it involved. What this meant is that the price tag of an image grew exponentially with its sizes. For example, if a 50×50 image cost $10, a 100×100 image would cost $40. This lead to quite a few misunderstandings over the backgrounds. I would’ve been crazy to expect artists to create these large images one pixel at a time, but that seemed to be the overall impression I had made. I was forced to repeatedly explain that I did not want these to be pixel art, but rather drawn/painted, and then touched up to blend in with the pixel work.

Following the first batch of offers we received, I decided to scale down my request. It wasn’t so much an issue of money as of time. Despite the 5-week deadline, some artists expressed concern with the amount of work involved. To accommodate for this, I changed my requirements to include only 1 background and 4 enemies. Ultimately, I also took down the background size to 1280×720 and the amount of angles for the units from 16 to 8 (for a total of 5 angles per unit if you don’t count the flipped versions).

jimjansen How I got art for my game, part 2.

Of all the artists who expressed interest in the project, I was particularly fond of Jim Jansen's work.

Since I posted on multiple forums, it was a bit difficult to track all the responses via Private Messages and e-mail. All in all, though, I received roughly 25 offers via Pixelation, 15 via Pixel Joint, and 5 via IndieGamer. I also personally contacted about 20 artists, although only 5 of them responded. The monetary estimates in the responses ranged from $400 to $1100 at rates of $15 to $40 an hour, with one or two that were significantly lower. The breakdown for my requested assets was generally the same: the units cost the least, followed by the enemies (the 200×200 enemy was more than all the units combined), and finally the background. Based on these estimates (and feedback from artists I knew saying that the work shouldn’t take more than two weeks to complete), I edited my original posts to include an $800 price point.

Adam Saltsman, the admin of Pixelation and a somewhat prominent figure in the indie games community, did not agree.  When I added $800 to my ad, he responded by saying “I could smell your cheap, exploitative rates from a mile away…” following which he moved my post to the “unpaid” forum. Pixelation is his to run as he sees fits so I didn’t complain too much, but this is my blog so I’ll briefly state the issues I had with this:

  • Right off the bat, Adam claimed that this work was worth $3000, or even 2-4 times that amount. This wasn’t even close to the estimates I received, so it’s hard not to think of it as an inflated number. I even discussed this with some of the artists I’ve worked with, some of whom Adam knows personally, I think, and they all seemed to agree.
  • Despite being rather friendly and self-effacing on his blog, Adam’s comments on my post were pretty snarky. I’m a big boy so they didn’t really phase me, but they did seem rather unwarranted.
  • The $800 was called exploitative and not a competitive figure, and yet it was based purely on what the artists themselves offered. It wasn’t a lowballed amount either as $15-$40 an hour isn’t a bad rate, but Adam ignored all of this. Considering this number was derived from competing artists, I’d say “competitive” was a very apt term for it. I’d also go so far as to say that the process by which I settled on this amount was very fair and didn’t exploit the employee or the employer.
  • $800 is long way from $0, so I wouldn’t consider the offer to be “unpaid.”

Anyway, in the end we had about 10 or so artists that we thought could be a good fit for ToM. This list included Jim Jansen, Miguel Angel PerezJoshua Astorian and various others, but we didn’t pick any of them. The reason for this is that the commission was for only one part of the whole game, and we wanted to hire someone that would end up doing a lot more work. The pixel stuff was doable for a demo, but ultimately it would require too much time and money for what we had in mind.

Instead, we decided to go with a different approach, which I’ll talk about more in the next post.

Next Tribes of Mexica post.

Previous Tribes of Mexica post.

, , , , , , , , ,

35 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