NOTE: This post is not meant to be a solicitation of any kind. We are not ready to begin that process, either. Thanks!

I am not an artist, but I have some important art-related decisions to make for a tiny startup working on a client/server game that currently is in development on the server side. Eventually, we are going to need client software, and that means acquiring art assets (or a staff artist) to make it look good enough for people not to turn away in horror once they have loaded the application. If they actually like the art, hey, even better. But, I do not expect art quality to be chief among the game's merits.

The game itself will feature fairly-detailed action RPG-style combat between two or more combatants in a closed space (think arena floor). Everything will be calculated and handled server-side. The plan is to compose a playback file of the action which can be sent to the client (probably target platform(s) will be Android, and maybe HTML5/CSS/js web client). In order to simplify the game, everything will take place on a two-dimensional grid. Even if we opt for 3d graphics, the game client will not recognize or make use of a z-axis (or anything else of the sort), nor will the server when calculating results. So, the result would be a 2d game with a 3d skin.

I checked out your "Creating Good Game Art When You're Not an Artist" article, which merely reinforced my decision to eventually bring in an artist as a contractor and/or pay for assets on a need basis. The question is: what is going to wind up costing us the most money in the long run?

If we go 2d, we already have a fairly simple and descriptive perspective in mind: a "true" top-down (not isometric) perspective that would show all combatants from directly above their heads. Unlike an isometric perspective, we'd only need one set of sprites per animation sequence, since we could simply rotate the sprites when changing direction. We have done some in-house tests with a primitive set of sprites using this technique, and while it worked out fairly well for us, our art is not all that impressive.

If we go 3d, I am going to recommend that we go for a "pan & zoom" system with fairly long draw distances and low poly count, so people can see the fighting from any angle/depth they want. Think old-school MMO like Everquest.

My initial thought was that 2d would be obviously cheaper and easier to use. Stepping back and taking another look at the situation, however, I can see some circumstances where 2d costs could get out of control if we are paying-per-sprite. Every time we add a new armor or weapon (and we will have a lot of both) to the game, we may need a plethora of new sprites based on who can wear/wield this new equipment. Even if we go to Fiverr and pay $5 per sprite, the costs could mount rapidly. 3d games have the advantage of just being able to reskin an existing model, or adjusting a small part of an existing model. Whoever winds up working on/with the client software will have the burden of figuring out what to do with all those 3d models. While I could theoretically handle creating a simple 2d engine myself (I'm already doing the server software), 3d is currently out of my league. We could possibly simplify that process by using a 3rd-party 3d engine.

Sure, if we go 2d, we could probably do some simple tweaks such as pallette swaps for equipment that is going to look somewhat similar to existing gear, but that isn't always going to suffice. If we go 3d, our general inability to edit/adjust 3d models might be a serious problem.

So, in your in opinion(s), which way should I go? 2d or 3d? Obviously our best solution would be to hire someone on a contract basis, pay a lump sum for a particular duration (or pay per hour), and get as much work as we can out of them before our art budget dries up. We may just not have a big enough budget to bring in an artist who can produce AND curate content. So, there is the very real possibility that we will be buying assets and figuring out what to do with them on our own (with or without the help of someone hired/contracted to work on client software).

If we go 2d, we already have a fairly simple and descriptive perspective in mind: a "true" top-down (not isometric) perspective that would show all combatants from directly above their heads. Unlike an isometric perspective, we'd only need one set of sprites per animation sequence, since we could simply rotate the sprites when changing direction. We have done some in-house tests with a primitive set of sprites using this technique, and while it worked out fairly well for us, our art is not all that impressive.

This perspective is not a good choice for several reasons.

1. It is nearly impossible for players to relate to the characters, because a top view shows so little actual "character". It is the least effective view on a humanoid. Great for space ships and tanks, but no good for characters.

2. Some things are actually very difficult for the player to resolve and comprehend from the top. Think about it: Do we typically see environment, objects, characters from the side or the top? When you're drawing roofs instead of more recognizable houses, this also creates environmental issues.

3. Artists don't like it. Which means you'll pay more for less, and get less passion and interest out of the artist (which is like free bonus quality for the cash).

Yes, it's easier in some ways, but choosing this perspective is a great example of "penny smart, pound foolish"

You'll seem to save money and complexity, but the end result will be less popular, complicate finding and motivating an artist, and generally cause all kinds of headaches in the long run.

This is the reason side-scroller games are so popular for indies (the top-down angled view, like older Zelda games, is also very popular, but implementation is much more difficult).

It's the best combination of easy/cheap, and graphical/visual presentation.

I suggest either you go side-scroller, or 3d.

Just use 2d skeletal animation. With a 2d side-scroller, this is the modern indie standard (with the exception of pixel art) for a good reason.

It's easier for an artist to draw new "pieces" than to re-skin a 3d model (which has to take into account the complexity of the UV map), so the savings are actually higher.

If you can give me an idea of the quality you're after, I can give you a better idea of price, but for something simple $1 a piece would not be difficult to find.

Your feedback wrt our planned 2d perspective is understandable. The issue of object occlusion in what is mostly meant to be a tactical interface can be frustrating. Since our product will be largely AI-driven, that may not be a big issue. Losing fluid facing could be problematic. We also want the game to work on some systems with fairly small amounts of system memory, which makes smaller sprite sets desirable (we've even considered 8-bit sprites, though that makes alpha very difficult to deal with, at least under Android anyway).

I understand that there have been tactical games that have used isometric to some degree of effectiveness. Warcraft 2 and Kohan: Immortal Sovereigns come to mind. It is possible. It's just not 100% what we want. It would probably be better to go 3d at that point, unless it just isn't in our budget at all to do that.

As far as character relation goes, we expect that, due to the nature of the game, people will be seeing their character in a character configuration/customization screen, looking at a paper doll and/or other perspectives the vast majority of the time. This product will be a lot closer to something like MyBrute, only with more intricate battle sequences, potential for more objects on the screen (possibly a great many, which is another vote in favor of something that reduces the size of sprite sets to one third or one fourth of its isometric equivalent), and some other differences not necessarily germane to this discussion. So, from my point-of-view anyway, so long as we make the paperdoll/avatar art sufficiently engrossing/compelling to the user, that relation will flow naturally from that. Maybe I'm just wrong there.

And, yes, I think that many artists really don't like it, which has been a stumbling block for us up to this point. Another problem involved the technical aspects of using 8-bit images in Android which is very difficult, especially when you have draw something moving over a background. Normally you can use alpha to take care of this problem, but there is very little room for an alpha channel when you are restricted to 8 bits. Android doesn't even seem to officially support 8-bit images for anything but alpha masks, though it can be made to work. Sort of.

We can't make the rules set work with a side-scroller either (though it would be a lot easier, it would be far less satisfying). Maybe if we were doing the next Maple Story, that would work, but under the circumstances, it won't. Your mention of 2d skeleton animation is interesting, however, and I'll be sure to look into that. Our previous methods were more primitive than that.

As far as quality goes, if we could get a look similar to Kohan, I'd be pretty happy. Or close to it. When it comes to 3d, some of the hardware we're running on may be running Android API 10, so I am expecting some fairly weak 3d capabilities. Still, games like Arcane Legends can run on that hardware.

We also want the game to work on some systems with fairly small amounts of system memory, which makes smaller sprite sets desirable (we've even considered 8-bit sprites, though that makes alpha very difficult to deal with, at least under Android anyway).

Well, that's where skeletal animation can really help you, but it only works reasonably well in side scrollers. In skeletal animation, you don't have all the frames drawn out, just a few body pieces. We're talking very small character art footprint, with no appreciable increase in size for animations.

Those are some very expensive sprites.

FYI, stylization is cheaper than realism. Choose and exaggerated style you're comfortable with, and see your art budget cut in half, or better. Or, better yet, work with an artist on developing a style for your game, and one that they're passionate in drawing.

The same goes for 3d, often benefiting your poly count too.

Indie artists don't cost that much.

Cost per sprite is a good way to do it, because that's almost always how you'll be charged (when you're not hiring somebody full time).

To that end, it depends on the complexity of the sprite, the quality you need, the speed of production (if you need it faster, it will cost more, a hobbyist can be extremely cheap but slow), and it also depends on the subject matter and amount of creative control you give to the arts.

"Cheap, Fast, Good - choose two" is close, but there is a fourth element: Creative control.

You can get free art, good, and fast, if you give up creative control.

It all depends on what you're willing to give up to reach the quality you want on your budget constraints. For many indies, that can be an important area of flexibility.

Well, that's where skeletal animation can really help you, but it only works reasonably well in side scrollers. In skeletal animation, you don't have all the frames drawn out, just a few body pieces. We're talking very small character art footprint, with no appreciable increase in size for animations.

I ran across an example of someone using Spine for top-down skeletal animation. Apparently it can be done. Are there many artists who will want to go this route? Maybe not.

3d is likely to be cheaper for art than isometric, but more expensive than a side scroller perspective or top view.

That may be the #1 reason why we'll wind up going 3d, since isometric would be the most logical choice if we don't go top-down view.

Programming, well, you'll have to use an engine. Unity is popular, and works on many mobile platforms. You'll need to consider licensing costs, but those are usually trivial for one seat, and you can get more games off it in the future.

Yes. 3d engine design is beyond the scope of what we are doing.

Yeah... see, here is where you're basically doubling your character art load, because now you have these configuration/customization screens using completely different art from the battle portion.



I guess that kind of works, but it's not efficient.

That's another reason why 3d will probably win out. We can use the same models for combat that we use for the character screen.

Assuming your items are static and don't need to spin or anything, they're not necessarily going to be larger in isometric.

For inert objects, this is true. For anything that can move, it'll be different. Though based on your feedback, I think we'd be better off going 3d than going isometric anyway.

I don't know why you're trying to compress that much. Are you having issues with too many animation frames?

One of the long-term possibilities is enabling large battle scenarios with a lot of moving actors. And yeah, we may wind up with a fairly large number of animation frames per actor. It's more a precaution than anything else. I still have doubts about how many things we'll be able to have moving on-screen at once with a 3d solution, but if it proves to be the best solution in every other respect, then we'll just have to suck it up and compromise.

Please give me an idea of the number of assets you're talking about, and the file size limitations. I think you're worrying yourself over nothing here.

Hmm. I'll try to come up with a reasonable estimate. Without client software done just yet, it's hard to tell exactly what kind of memory footprint we're looking at before taking sprites into account.

Why?



You can get away with a little bit of vertical ground in a side scroller. Think Double Dragon or Battletoads. Characters just always need to be facing left or right, and the angle can't be too strong.

It would be the angle restrictions that would break us, or at least make the game look/feel wrong.

Please explain your gameplay in more detail, and maybe we can help you resolve these problems.

You get to create a character that (by default) has a random distribution of stats and semi-random advancement (it's up in the air how we'll handle customization, but it is also planned). The character is stored on our server, and the player can call up the character via the app to change equipment loadout, buy/sell stuff, change behavioral settings for combat, etc. Every so often, the server queues up a battle involving that character and an opponent according to a limited set of criteria set by the player. More-intricate battles involving multiple opponents with obstacles, barriers, and suchlike will be possible.

The fight happens server-side, probably in the course of a few seconds. The combatants are placed on a 2d grid and they battle it out action-RPG style, except that I'm grafting on "auto-target" MMO-style combat conventions. We do hit/miss rolls, checks for parry/shield block/counterattack, AI-driven body location targeting, and some other stuff. A winner is declared based on whose hitpoints go to 0 and whose don't. The entire series of actions is recorded in a file, and a notification is sent to the client somehow telling the user that a battle has finished and that they can download the fight to watch it. If they do, they get the playback file, which the client then translates into a fight using whatever graphics engine we use.

The grid-based combat is intended to be very sensitive to facing, weapon/body area collision, and so forth. I really don't want a Double Dragon/TMNT/Final Fight scenario where people have to slide around and can only attack left or right or at very narrow angles. For multi-combatant fights, we need a situation where a single fighter could, conceivably, be surrounded on all angles, with clipping being a factor. Combatants (friendly or hostile) will not have the ability to just walk through one another.

Those are some very expensive sprites.

Hmm, really? I had always thought of Kohan as having very respectable, but not overly ambitious, game art. It definitely wasn't anything as complex as Diablo 2.

FYI, stylization is cheaper than realism. Choose and exaggerated style you're comfortable with, and see your art budget cut in half, or better. Or, better yet, work with an artist on developing a style for your game, and one that they're passionate in drawing.

The same goes for 3d, often benefiting your poly count too.

Thanks for that tip. I sort of have a "tin eye" anyway (as opposed to a tin ear), so I prefer to trust in the stylistic advice/input of artists to pursuing my own vision.

I ran across an example of someone using Spine for top-down skeletal animation. Apparently it can be done. Are there many artists who will want to go this route? Maybe not.

Lots of things are possible, but shouldn't be recommended. Note that even in such a simple animation, they have two versions of the feet (they change while under the body). Swapping out arm versions would not be as discrete; they're going to have quite a headache with any more complicated animations.

It's an attempt at optimization, and it's premature.

Have you ever heard the quote: "Premature optimization is the root of all evil."?

There are plenty of ways to compress (and stream) graphics if you need to. Don't worry about this.

Again... why? Why do you need any of this?

The player has nothing to do with the fight. It's not like you're creating game mechanics for the player to experience. This is just a visualization. All you need is for it to look cool. And be plausible for your budget.

That should mean flashy sword swings and particle effects, motion blur, the camera panning and zooming around chaotically, lots of blood spray and gibs.

None of that should care that they're technically standing side by side Double Dragon style.

I suggest you put your money where it matters, and just ignore things that are irrelevant to player experience or gameplay.

Thank you for your feedback. Based on what you have said, I think you've helped me narrow down some options that will fit our budget expectations. Time will tell whether or not I've made the right choices.

Ultimately we'll do whatever it is that's in budget. Any recommendation that I bring forward that amounts to hundreds of thousands of dollars is going to be sent back for revision. There are several reasons why we'd like to have a graphics engine that can accommodate something more visually descriptive of what's going on than a Double Dragon-style "beat-em-up" environment, mostly related to where the product will be in the future. Though perhaps we can save that as an upgrade.

re: player engagement

You ever play Age of Wonders? Think back to the autocombat vs tactical combat screens. If you remember, you'll know that autocombat could produce drasticly different (and often silly) outcomes simply because the game had to guess who would have the tactical advantage (and why) and then approximate that advantage using rules like "archers get two free rounds to fire, except against cavalry, where they only get one". There were plenty of occasions where autocombat outcomes were drastically different from tactical combat situations. Archers were far less powerful in tactical combat on most occasions, since players and AI alike knew how to use terrain and the turn-based system to prevent archers from getting off more than one volley before coming under melee attack from just about any kind of unit (not just cavalry). Conversely, really good tactical players could, upon occasion, use terrain or troop formations to give some of their ranged units more than 2 uninterrupted shots. In autocombat, all you really had to do was stack archers with dragons (there was a stupid rule about enemy missile fire being directed towards flying units first) and you'd defeat anything. That simply did not work in tactical. The big mistake AoW did was allow players to use autocombat to bypass tactical combat altogether, and allow them to exploit stuff like dragons&archers. So yeah, they really did give people the option to push a button to sabotage their own gameplay experience.

(or, then there was ProgressQuest which literally played itself for you, and became far more popular than it ever should have)

What I am doing is (sort of) mixing AoW's autocombat and tactical feature, forcing the game to use a tactical map but using AI to produce the result. The engagement comes from tweaking AI settings and seeing what is the result. Sure, they can skip the playback, but if they do they'll never know how their latest AI settings performed (nor will they see how old AI settings might have fared against a new style of opponent or scenario). Assuming I do my job properly on the server side of things, people will be curious about not just the end result, but the whys of how the fight reached such a conclusion. They will not be able to just stick with default AI (or even the same AI, over and over) and expect good win percentages, especially at higher levels of player. If they can, then that means I've done a poor job on the back end.

I can see how a faux-isometric system could work here, though there are obvious situations where it could be pretty jarring. Polearms with substantial reach will look pretty bad when making attacks up/North when, graphically, everyone is facing east or west. I guess it could work. If low-poly 3d is simply way out of budget, that may be where we wind up, at least in the short term. I'm still going to look at low-poly 3d to see what we can accomplish.

To cite an example of why I'd be hesitant to go with a Double Dragon-style approach: compare Double Dragon to Gauntlet. Gauntlet gave you 4 directions, Double Dragon gave you basically 8 when moving, but 2 when jumping/attacking. The gameplay was wildly different. Our rules set calls for something closer to Gauntlet than Double Dragon. We want combatants getting in either other's way. We want people to get surrounded and beat down with no plausible escape path if they screw up somehow (not without some awesome special ability, anyway). We don't want like 3+ guys stacked up on each other, all getting hit at once ala Double Dragon/TMNT/Final Fight. Could you translate Gauntlet into a Double Dragon-type graphics environment? Maybe. It would certainly save on sprite budget not having to draw so many angles. There might be some other advantages as well, such as making client software development simpler and cheaper . . .

I understand now.

Your best bet is to use 2d isometric tiles, and use non-animated token sprites.

Make them look like chess pieces, or something, and only "animate" with translation based movement. Abstracting well looks better than a half-assed jab at more precise representations. You just don't have the budget for the latter, unless you stick with side-scroller view.

Abstracting like that makes making high quality assets trivial. Rotation is also trivial. The assets could be sculpted in Zbrush or something, and rotations rendered out. Without having to UV map or rig, you can afford that without problem. And you'll have no worries at all about file size.

$10 an asset would look great. You'd have to make some kind of script to load the assets, and render them appropriately, and then assemble them into a sprite sheet. I can tell you from experience, nobody wants to do that by hand and even trying will triple your production costs (tedious tasks demand a premium).

Then you can spend most of your budget on the detailed profile pics, which will show all of the weapon and armor configurations, and some nice icons for your AI behaviors. Animate those with skeletal animations, and it will look really slick.