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.

You offered payment for teaching -- loverly. But then you mention you want us to make half a level of something you told us nothing about, instead. Which is it? I can teach. Making stuff for profit's not allowed. Unless you buy me a license, perhaps.

Maybe your algorithm does the whole cube, I don't see it. I merely said it would be tedious and cumbersome, you respond with a line that -- doesn't seem to prove to me it does the whole cube. And it seems like altering/reusing that line over and over -- would get tedious. And if we model it how *I* would model it, each side facing me would have the horizontal side be X, 0-2, or 1-3, or whatever. Height would be Y, same ranges. And the cube on the table, I solve white first (just over my nickname, nothing deeper), at the bottom. But I'd call the front face 1, go clockwise up to 4, top's 5, bottom 6, all as Z-axis arrays. But if I turn the cube to the bottom, and base this all off 1-3 integer counts? I'm moving the middle Y row on the bottom face away from me to the back face -- (2,1,6), (2,2,6), (2,3,6) -- those would all swap with (2,1,3), (2,2,3), (2,3,3). That seems easy. That grid 6 swaps with grid 3, 3 swaps with 5, and 5 swaps with 1 -- that's NOT entirely first-thought obvious. Gotta think thru each motion/make each button carefully. Bet me guy makes at least one bungle over which side is up/etc. But I do think I said "tedious, not impossible" or something. It's just that it's a chore. Hell, I'm happy my first thoughts were to use one array *and* to avoid making a 3x3x3 array -- how many people did that the first time?

What a sweet thing to say. I think more people should make comments about strangers' abilities with limited personal experience, saying exactly what they already said. Years of PHP/web design, now going into HTML games, however could I possibly have more proficiency with that? I know, I'll get over it, at some point PHP will lose the zillion built in functions it has and the 8-10 notions present in construct2 for array manipulation will be all that's left.

But since that sounds like a really sad day, I'd still rather my text allow PHP breaks. No lie, I was trying "<BR>" before I'd heard of "newline". I had to drop what I was doing and go hunt-down that (seemingly overly-long) expression, even. And I get why web designers will turn off text's ability to be interpreted, it's a security risk, etc. Being on the server/development side, being able to make tweaks to user input to guard against misuse, One can only figure scirra's not letting me put PHP in over...

Nevermind. I can't think of a good reason. Even geniuses have limitations sometimes. I figure saying that what doesn't make sense actually does? That must be event 101.

I stopped at r95 for now, always leery higher versions will change/break things. But on the note of "reason" -- in r97 am I still having to put my global variables in an otherwise-unused (or totally used/never destroyed) sprite called "global" so that they don't cost 1% each of my 100 events? And is it still too costly to have a remotely organized program that doesn't look like crap (ie, are groups still events?)? The PHP authors never did this. But how lovely they were kindly folk wanting an improved world and released their stuff so that the world could use it freely to create joyous derivative works... Like that 80$ game editor program.

Nope. New to game design. Only met one unsupportive *** so far, even. And the tools are limited with odd workarounds. Unlike PHP, where you could always throw in more pre-written functions, or write your own even. Addons? I admit, haven't bothered, but maybe this function addon would be one I'd never work without once I try it. When I try it. While I see the joy in a program supporting addons, never quite figured why so many people don't expect more from the program, we don't all have whatever addon, and traversing/summing *just Y* has no array function, really? Damn, Construct 2... But yeah, I've only fiddled with Construct 2 for now. Addons take forever to dig thru, sort out, demo, trying is quick, grokking isn't. Hearing of one in particular over others? That lets me target it quicker. Having never installed an addon? I'm not super eager for the headache. Even if once I learn a path it's probably as simple as unzipping there. Feh, I'll look into it, no need to teach. It's just not today's priority, girlfriend over 'n such. Plus she just woke up... So I'm done ranting for now.

I am curious what you meant by faking rotation thru non uniform scaling. The words are pretty, and offer hope, but I've gotten no vibe of exactly what algorithm you mean. 3 blocks on a row, the right one's 2x the size of the left? -- But it's still not moving. Eh, fine, we're faking it/not moving it. But I'm not sure how that fakes it even. My point, didn't "get" that part of your posting.

How adorable. I thought about making this very program. I've only learned to solve the damn cube in the past couple months. Bought one even.

Trouble with Construct2/making this (the set of all-of-that-combined) is that it's not really 3d. 2D cube pic, background panels showing the "unseen" side/arrangement, color swaps for an unmoving cube? Easy enough. But you get no joyful motions of turning the cube, no free rotations of the cube where it just spins around and you marvel at it, blah. Not saying the 2d just-color-moving notion couldn't make a lovely tutorial to teach others to solve cubes, or whatever... But as to solving one? If the one newly on my desk were in use, I still have a touch based 3d fully movable/rotatable ipod cube.

Plus, can we get function-writing in construct? Seems a pain reuse the same notions of code. But, reusing it for EVERY button by rewriting it for EVERY button, why not an array that swaps values? Yeah, won't be super-intuitive to code, wouldn't be for me at least, swap this with that with the other type stuff. 6 colors on each of 6 sides, 36 things to know. 3x3x3 array, wow, that's 9x3, 27, so hopefully you won't make the array badly. 3x3x3 *cubes*, but the cubes have more than one side/blah. The model I've pulled out my -- mind -- in a few secs of thought? I'm thinking 3x3 faces, 6 of them, so why not have a 3x3x6 array? But then you'll have to make very-specific and very-seemingly-non-intuitive calls -- (0,2,0), (1,2,0), (2,2,0) rotate to the right, which if that's face one those prior locations get moved to (0,2,1), (1,2,1), (2, 2, 1) or such. Assuming that in your mind is face one, or even that "turning right" meant clockwise, blah.

A working cube is very possible. 3x3x6 array seems best tho, not 3x3x3, to me at least. Swapping some locations with others is gonna get tedious/require lots of checking. And once it works? The cube still doesn't move. Or you could add animations -- but even at perfect(ly bland) angles where the rotation animation worked (looked right) for all tiers -- You have any of 6 colors, next to any of 6, next to any of 6 rotating *on one side* -- and what about the side you're moving away? We're already at 150+ animations. I dig photoshop, actions, automated scripts, blah. I'm not gonna make that many animations. Hell, adding a few different-angle asteroids to my asteroid game, 30ish frames each, the game quit loading 100% of the time. I'd click preview and screw around rerereclicking -- 2 mins later I might see my preview. Nah, ripped all that out. I'll add it in at the end maybe. When I don't wanna preview more basic stuff. Point -- too many frames bogs construct, it's seemed. And that 150? Was how many combinations. My bad. But if 10 frames per animation? Now we're at 1500...

Basically Rubik didn't seem like it was the "right" thing for this environment. Last night I made a random number generator gamer-friends could use -- 6 rolls of 2d6+6 for AD&D type stats, or whatever. Got my first real taste of arrays. Kept wondering where the hell the "sum of array row/column" feature was. Wondered why I can do foreach style loops on X, XY, or XYZ -- but why not *just Y*? -- it does what it does. Show me ONE damn spreadsheet table where you can't *super-easily* get the value of Y axis data... Suffice, no, I *did* get it working -- but I also noticed if I just closed construct 2 and went into full-bore PHP writing on notepad I'd have gotten a lot more done, faster. Yeah, the layout moves quicker in construct, etc, but I can write and reuse functions, do the math with lots more built-in functions via PHP, etc... Point, some things just lend themselves better to certain environments. Rubik seemed tedious and unrewarding. That said, prove it wrong/good luck.

Amazingly helpful. Thanks.

All that stuff I wrote out last time. With the added question of what imbecile would want "system security" on a web forum about game design such that, gasp, if I'm away several minutes (perhaps working on code) it logs me out *and* opts to not remember my damn post...

Shorter-than-last-time-version -- I'm wanting segmented/blocky motion. Type of thing where a 50x50 pixel player will move *fluidly* (standard 8 direction type stuff), but upon key release the player continues at the same speed until they stop on the next tick. 50x50 goes forward 35? It stops at 50. 51? Stops at 100. That sort of thing. I'm wanting it for (decently) fast motion, active/live gameplay, not a chessboard. If *how* the pieces might move might be easy to think of with chess.

A lot of games have this. I think zelda did. I'm sure zelda 2's world map did. Zoop. Zelda 2 had a "character square" moving over "terrain squares" and "encounter squares" that would appear/move around/if they touched you, you'd switch to their encounter screen/fight. But you were always in one square, or moving out of it into another, you weren't half in one or the other, you couldn't sit on a corner and be in 4 squares at once. Zoop? Far more constrained, it had a grid type setup, 4x4 square in the middle that the player could move in. Clearing rows/tetris style game. But while you'd fluidly move from one row to the other in whatever direction you pushed, you'd stop in the next row unless you held your key down. Where-ever you release, you'll end up in the middle of the row you're going into. But never over to the side... Get it?

But how's that done? I've tried a few tricks, setting an instance variable for the player, having keypresses store goal coordinates and when the player coords aren't at goal, move. Trouble is I'm then an nth lil' space past, which sets off the condition in the other direction, I end up going back and forth on whatever (horizontal/vertical) axis. I could figure when it's very-close and do an exact position move, but then there's a jump that doesn't feel like it should be there. Etc, tried a few things. Someone's figured it out, too many games use it. What am I not thinking of?