I picked that as an example because it was a platformer and we are discussing a platformer. It does get more complex though as you progress and collect items to give you new abilities.

Anyways, I don't know what method you were thinking of for programming a transformation, but the way I would do it would be almost trivial to implement. Kind of a bad example if you wanted to point out how stencyl couldn't handle something.

Hmmm.... Well was bored and I kinda made a sprite of Hypno-tan. I know nothing about sprites so this is probably wrong and wouldn't work in the game but I figure it's cute anyway.

i.imgur.com/kADELrk.png

More aesthetically-pleasing than what I had envisioned when you said "<<oi61.tinypic.com/s3ke0w.jpg|Metroid>> <<i88.photobucket.com/album...r747/alucard.png~original|vania>>."

I'd say it's the opposite problem, that the programmers rule the roost, including telling the hardware design guys what to do. This can benefit, a la Wii, or plummet, a la Wii U, but aside from the rare misstep (Paper Mario Sticker Star, apparently, though i've yet to play it), their games generally sing because they put the fundamentals first, before thinking about story, characters, etc.

Really the rules for sprites are pretty loose these days. There used to be all kinds of color pallet limitations and quite a few tricks and techniques for getting the most detail out of the least pixels due to the graphical limitations of old computers or game consoles, but those limitations are pretty much non-existent with today's computers. So, as long as the sprites fit on screen with room to move around, it should work fine.

I'd love to hear about your ~trivial~ stencyl implementation that doesn't involve redrawing all sprites for every transformation.



The hardware design weirdness is definitely coming from the higher-up executives and marketing types. Every one of their consoles since the Gamecube has had some whacky gimmick that only served to make first-party games suck (Galaxy completely killed the 3D Mario series for old fans for the sake of advertising point-n-waggle) because they think gimmicks are what give consoles an "edge" over others on the market. Really, I think Wii U's screentroller thing was a lot better than the Wii's waggle crap since it doesn't actually make the games less fun.

But that's not really related - the point is, it's best to figure out your basic gameplay, define it as exactly as possible, implement it, then see what all content you can add around that.

*The sprite looks good, but she probably needs knees if she's going to be animated.

<<youtu.be/2hKpgzzyuH8?t=11m59s|No knees? No problem.>>

Okay, I am confused, are you saying that you believe the best way to handle transformations is to have the program actively manipulate the sprites into different shapes and colors? Because if so, that is a really stupid way to handle it. Not even professional games handle it that way. In Minish Cap, for instance, there is a different sprite sheet for each color of Link's tunic. The reason is simple; making the game re-color or tween a sprite in every single frame would slow the game down.

I think it would look nicer to draw a transformation animation that uses the default sprite as the mid-point, so that you can transform from one form to another without needing to draw a whole new animation for every combination of starts and endings. If you wanted to save drawing time though, you could also have an animation that obscures the sprite momentarily, such as a pillar of light appearing and rising up then dispersing to show the new form. Then you could use just that one animation to transition between all the others.

On the code side though, it would just be to tell the 'actor' (Stencyl calls objects actors for some reason) to play the first half of the transformation animation, then spawn the actor matching the transformed state at the same coordinates then, which will play the second half of the transformation animation, and have the old actor remove it's self.

Uhhh not really. Do it though a pixel shader and recolors etc are very cheap operations

A 2d animation system like the ones I've mentioned earlier would save time because the animations could be copied between transformations and some sort if attachment system (Drawing a hat sprite where her head is etc) could save time if you want to have items appear on the sprite for simple transformations

Hello, traveler. From what dimension do you hail?

I don't know, but I don't trust it. Only the knowledge that I'm on a friendly mind control board has kept me from going to my flamethrower.
Anyways it seems like people are putting together a bunch of different ideas on how to get this done. It seems that right now is a great time for things to proliferate. Is there any way to create a persistent list of ideas controlled by one or two people for awhile, before people start talking realities? Maybe by editting the parent post?

A shader to recolor a sprite would work, but a recolor doesn't quite strike me as transforming. Anyways, having clothing that stays over top the base sprite would be a good way to do it too. Would be neat for unlocking vanity items during play.

Yeah, that's what i was wondering. Even most folks who dislike the direction Nintendo's gone lately acknowledge the Galaxy games as superlative.

I swear to god every time you hit "Post" you kill three of my brain cells



Everyone I know who played SMS and SM64 around their release don't really like or didn't bother with the Galaxy series. Just like with OOT/MM/WW vs. SS, Metroid fans with Other M, everything, never really heard a distinction for the Mario series. You could apply the things I said to the Metroid series, anyhow, just swap hardware for heels. That's a tangent, though; my point is still that someone should figure out how to put together a demo before they go about typing up walls of text about what content could be added. I've seen a lot of projects I really like die to idea overload.

Play nice, children. I don't want to see an idea thread escalate out of hand here.