Layered sprites?

Solar2D General Questions/Discussion
#1

As I am completely unfamiliar with this engine and game development in general, I really hope this isn’t an easily known fact, my search didn’t turn up much (as I really have no clue what technical terms to search for). 

How feasible is it to run layered sprites in a top-down/isometric styled RPG game with CoronaSDK? 

I saw a forum post on some other site (that I sadly could not track down) where a guy making a mech tank style top down game used three layers on one sprite, so he could “angle” it’s perspective by shifting the layers and also make visual damage effects by removing one of the layers or replacing it with a damaged layer. I have no clue what engine he used for this or if he built it from scratch, but the effect was pretty cool and ingenious, and I could see it being applicable to all sorts of in game objects. 

My knee-jerk reaction would be that it seems like something completely do-able, however as I am no technical expert, I just wanted to seek clarification and see everyone’s thoughts/experience on it :) 

Thanks!

Carter

#2

Our framework supports layers in the traditional idea of a background and objects stacked on top of it.  It uses what’s known as the painters model where new things cover up older things as they are added.   What you are really looking for though is something we call sequences.  Your sprite can have multiple - multi-frame sequences.  You could have a sequence of your tank moving (tracks turning), then have a sequence with the tank on fire but with the tracks still moving and another sequence of the tank blown up.   Then you have the sprite play which ever sequence is correct for its given state (healthy, damaged, dead) and the engine takes care of it for you. 

Once you define the sprites, the code becomes pretty easy:

tank:prepare("healthy)

tank:play()

tank:prepare(“damaged”)

tank:play()

tank:prepare(“dead”)

tank:play()

or something like that.

To your other question… isometric.  With our current engine, isometric is going to be really tough to do because it’s a 2D engine and most isometric games have depth to them.  That is the tiles towards the back (i.e. top of the screen) are smaller than the ones closer to the front/bottom.

You could not use square tiles but would have to premake the tiles in their diamonds and then scale them as they go back in depth (and even then you are likely going to have alignment problems). 

We are working on our Graphics 2.0 engine that supports 2.5D where we can simulate depth by warping the squares into trapazoids.   With a little cleaver math and some rotation this will be come much easier (but still take work) to do.  Those features however are only going to be available to Pro and Enterprise subscribers.

But people have already mocked up faux-3D worlds using the 2.0 engine (currently in Beta to paid subscribers) and even Mode-7 style games, so there is a lot of possibility with the new engine.

If you’re okay with a pure top-down game with squares instead of diamonds, you can do that today with your Starter account.

#3

Thanks for such an informative Reply Rob :slight_smile: and forgive me if I used any incorrect terms that may have thrown you off. 

So to regurgitate hopefully correctly, your saying (with the tank sequences you described) it’s basically three entirely different sprites and I’m just telling it which one to display given a certain scenario, with the current engine, is that correct? 

I haven’t decided yet on how much more visually pleasing a 2.5D version would be compared to just the pure top down game, but by the time I figure that out I’m sure the Graphics 2.0 engine will already be available by then :) 

Carter

#4

I guess you could consider them separate sprites, though internally it’s one sprite with multiple sequences.

#5

Our framework supports layers in the traditional idea of a background and objects stacked on top of it.  It uses what’s known as the painters model where new things cover up older things as they are added.   What you are really looking for though is something we call sequences.  Your sprite can have multiple - multi-frame sequences.  You could have a sequence of your tank moving (tracks turning), then have a sequence with the tank on fire but with the tracks still moving and another sequence of the tank blown up.   Then you have the sprite play which ever sequence is correct for its given state (healthy, damaged, dead) and the engine takes care of it for you. 

Once you define the sprites, the code becomes pretty easy:

tank:prepare("healthy)

tank:play()

tank:prepare(“damaged”)

tank:play()

tank:prepare(“dead”)

tank:play()

or something like that.

To your other question… isometric.  With our current engine, isometric is going to be really tough to do because it’s a 2D engine and most isometric games have depth to them.  That is the tiles towards the back (i.e. top of the screen) are smaller than the ones closer to the front/bottom.

You could not use square tiles but would have to premake the tiles in their diamonds and then scale them as they go back in depth (and even then you are likely going to have alignment problems). 

We are working on our Graphics 2.0 engine that supports 2.5D where we can simulate depth by warping the squares into trapazoids.   With a little cleaver math and some rotation this will be come much easier (but still take work) to do.  Those features however are only going to be available to Pro and Enterprise subscribers.

But people have already mocked up faux-3D worlds using the 2.0 engine (currently in Beta to paid subscribers) and even Mode-7 style games, so there is a lot of possibility with the new engine.

If you’re okay with a pure top-down game with squares instead of diamonds, you can do that today with your Starter account.

#6

Thanks for such an informative Reply Rob :slight_smile: and forgive me if I used any incorrect terms that may have thrown you off. 

So to regurgitate hopefully correctly, your saying (with the tank sequences you described) it’s basically three entirely different sprites and I’m just telling it which one to display given a certain scenario, with the current engine, is that correct? 

I haven’t decided yet on how much more visually pleasing a 2.5D version would be compared to just the pure top down game, but by the time I figure that out I’m sure the Graphics 2.0 engine will already be available by then :) 

Carter

#7

I guess you could consider them separate sprites, though internally it’s one sprite with multiple sequences.