Jump to content
  • Advertisement

manderson99

Member
  • Content Count

    5
  • Joined

  • Last visited

Community Reputation

113 Neutral

About manderson99

  • Rank
    Newbie
  1. manderson99

    2d vs. 3d: cost analysis

    Hmm! Interesting concept.  I like the idea.  Thanks for taking the time to answer my question and read my verbose blather.
  2. manderson99

    2d vs. 3d: cost analysis

    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 . . .
  3. manderson99

    2d vs. 3d: cost analysis

        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.       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.       Yes.  3d engine design is beyond the scope of what we are doing.        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.       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.       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.       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.       It would be the angle restrictions that would break us, or at least make the game look/feel wrong.        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.        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.        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.
  4. manderson99

    2d vs. 3d: cost analysis

    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. 
  5. manderson99

    2d vs. 3d: cost analysis

    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).
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!