How do I know what I can get away with?

0 favourites
  • 1 posts
  • Best way I could phrase the question to fit the forum. But what URL's, discussion, etc, can whomever-that-knows offer up regarding HTML5 games and their limitations. In terms of memory, sprite use, what can/will bog the hell out of a game, etc.

    To make it more particular to why I'm asking? Ponder a game with your basic sword and shield warrior type character. Gotta have animations of walking, swinging a weapon, jumping, crouching, jump-swinging, crouch-swinging, crouch-walking, blah/yadda. If I'm trying for something "realistic"? I might want each at 30 frames a second. If I'm being kinder to systems, maybe 15 frames a second. But if we do a second each of walking-variations, half a second or so of jumping or swinging a weapon, we start getting staggering amounts of images involved.

    Well, can I reduce this? Isn't "swinging weapon" more an arm motion, so why even include the legs? I could use a halfish size sprite for just-the-legs, walking or crouch-walking or hanging-in-a-jump or whatever, and then pin that to the torso. Altering the angle intelligently thru program code to simulate crouches, etc. Keeping a sword arm swing animation pinned at the shoulder and always firing out at a 0 (or 180, by left or right facing) degree angle, but always at a height matching the crouch, etc... So then I have smaller images. But even more images. Well, maybe a few less, no whole-body crouch-walk-swing combo for example. But we're still having to draw the legs, the body, the weapon arm...

    Foes -- Zelda II had a lot of very simple foes, most of the animation variation was on the character where the player was constantly seeing it (good strategy). Some might just bounce-walk toward the playe holding a knife in front of them, low hps, collision causes minor damage. But it had a range of these, and over Construct 2 wanting everything there at the start of the layout -- I'm just wondering if having different foe types means the system slows for every type that exists, neverminding if there's only one (or zero) on the screen at the time.

    Is it better or worse (and how much) to have 2 50x50 sprites, or 1 100x50 sprite? If a character has 100 frames over 10 different possible animations, does the player have them all loaded always? Is every object loaded into memory, how many different foes can we reasonably create/use (assuming no event limit)? How many sprites can a lower-end HTML-5-compatible computer handle? Can systems handle a game with 1000 images, even if only 15 are showing at a time? Does pinning an arm on just not work as well as rendering a whole new arm for a whole new non-arm pose?

    Suffice right yet I'm thinking of this stuff. Not really sure where all the answers are. I can make it, test it, that says nothing about how it'd run on some mundane (non-computer) coworker's rig. Really I'm stuck on the basics not wanting to toss a week into finding out - should I be drawing arms, etc, or entire people all at once? Should I even plan on having more than a few foes, etc...? What can we get away with, what limits are peskily there...? Share insights, someone further-along-than-me.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)