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).