Questions about Spells

[WereAlpaca]

I've finally figured out how spells auto-rotate for the cast animation, however it's very confusing and doesn't line up well with the player. Will this be adjusted later, or will we have a very accurate description of how it lines up with the player and auto rotates? I understand how projectiles work quite well, but the spells cast and hit animation are very confusing. Much appreciated everyone, this community is really turning into something nice! 

[Kibbelz]

1 hour ago, PhenomenalDev said:

@WereAlpaca spells are a bit buggy and lackluster rn sadly

There are only so many bugs someone can fix which is why we have you guys to find them so we can squash them!

 

@PhenomenalDev There is a limit to what you can do without creating graphical reliance. What that means is, lets say we have a Zelda spin attack. You need the animation frames for the whole attack, even the character frames as well as the paperdoll/animations. Adding the ability to create such spells with no free to use graphics with enough resources to make a good game limits an extreme amount of people on this forum. Assuming you have no pixel talent, that would also include you. So now we have an engine that only ~1/100 users here at AGD (since we have barely any artists) can actually make something with, that is a terrible design flaw. 

 

If you're not satisfied with how combat works in Intersect, I suggest you go make your game in Eclipse or Orion+. Either that or release your own source tutorials of how you know combat should be done.

 

Quote

I've finally figured out how spells auto-rotate for the cast animation, however it's very confusing and doesn't line up well with the player. Will this be adjusted later, or will we have a very accurate description of how it lines up with the player and auto rotates? I understand how projectiles work quite well, but the spells cast and hit animation are very confusing. Much appreciated everyone, this community is really turning into something nice! 

@WereAlpaca This is probably because the animations you're using have a lot of "white space" between frames which can cause offsets. The animations are programmed to be in the centre of the tile, not the character. if the character is 64 pixels high and the projectile shoots out in a line in front of it, it will shoot out from the bottom of the character. This is because in an ideal world everyone would be using 32x32 sprites, of course thats never the case. Also depending on what animations you use and what sprites you use the positions of projectile to character will vary, By adding offsets in pixels in the source it will put the projectile in the right place! As stated many times before, we can't accommodate all graphic types which is the danger of advanced combat with more diverse graphics!

[Phenomenal]

@WereAlpaca spells are a bit buggy and lackluster rn sadly

[WereAlpaca]

15 hours ago, Kibbelz said:

NThere are only so many bugs someone can fix which is why we have you guys to find them so we can squash them!

 

@PhenomenalDev There is a limit to what you can do without creating graphical reliance. What that means is, lets say we have a Zelda spin attack. You need the animation frames for the whole attack, even the character frames as well as the paperdoll/animations. Adding the ability to create such spells with no free to use graphics with enough resources to make a good game limits an extreme amount of people on this forum. Assuming you have no pixel talent, that would also include you. So now we have an engine that only ~1/100 users here at AGD (since we have barely any artists) can actually make something with, that is a terrible design flaw. 

 

If you're not satisfied with how combat works in Intersect, I suggest you go make your game in Eclipse or Orion+. Either that or release your own source tutorials of how you know combat should be done.

 

@WereAlpaca This is probably because the animations you're using have a lot of "white space" between frames which can cause offsets. The animations are programmed to be in the centre of the tile, not the character. if the character is 64 pixels high and the projectile shoots out in a line in front of it, it will shoot out from the bottom of the character. This is because in an ideal world everyone would be using 32x32 sprites, of course thats never the case. Also depending on what animations you use and what sprites you use the positions of projectile to character will vary, By adding offsets in pixels in the source it will put the projectile in the right place! As stated many times before, we can't accommodate all graphic types which is the danger of advanced combat with more diverse graphics!

 

Thank you for the extremely thorough reply Kibbelz! Relevant information to the original post is at the bottom.

 

I definitely agree that low resource requirements are a must for tools that aim for ease-of-use, having too many required assets can also make modifying sources very tedious and adding new content overwhelming. I have seen game engines fall to feauture creep, and any experience with these engines has been mainly stripping away "features" and fixing what I broke by doing so, often finding it was all built on very weak and limited methods to begin with. I'm 110% with you guys on keeping everything accesible for new creators, because it puts all of the focus on having the key components working exactly as they should - at the same time it will also become a solid block that can be easier built upon. On the right path!  

 

It's also important for creators to consider that the amount of artwork that is needed for one unique action starts to grow exponentially as you try to develop your game. I'm still putting off drawing up basic outlines for my weapons, because I haven't decided between static or animated attacks. Even the basic shapes and conceptual designs need to be changed drastically to allow for a readable paperdoll to be made for a few different angles. That's not even considering that as soon as I make the decision to implement animated attacks, many other questions rise up and decisions have to be made:

 

Do I need separate player animations for each weapon type? How many frames should the attacks use? Should I sprite attack animations for every enemy? How will all of these graphics be organized and layed out in the resource folder? :S

 

This is just a small sample list of questions that can come up from one small addition, and it's only considering the graphics! Imagine creating all of the assets that most people feel is "required" to make a decent game nowadays - doesn't sound fun. Death. It's very important to establish strong core mechanics before adding the flare. I guess player animated attacks are still up in the air for me 

 

Anyways. Major sidetrack over - about the spell animations. Now... Uh. Yep, you basically told me every detail I needed to know, but I'll fill you in on the way my game is currently setup, ask for some insight and share how I plan to change things with the information you've given me:

 

I feel that the animations being aligned with the tiles and not the player is a great way to handle it, and I can already start planning out ways to adjust it with this in mind, so thank you for letting me know. My plaper dolls are 32x48y, and the way the sprite looks in the client is actually quite nice, I feel it provides a lot of depth and height to the characters. When using projectiles they are shot from the chest of the player when facing upwards, while still lining up in the other three directions, it looks very smooth this way  Instead of shooting from the forehead, the projectile is shown behind the player in the first few frames. So as far as the player behaviours go, I couldn't be happier.

 

However, the confusion that stems from the spaces between frames predicament is painful. I definitely have large blank spaces separating each frame, but I simply don't know how your system handles it so it baffles me. I'll mess with tightly framing my test animations later today. It also sounds like the size of my paperdoll might be messing with how it works, if that's the case I'll be waiting till open to mess with that. Cool!

 

It appears that personal changes for open-source will include simplifying in this case: specifically set animations angle of rotation for each direction, set permanent anchor of 32x32 tile mentioned, specifically set anchor for each direction of the animation. The intention is that the two anchors will always line up, that way I can change the exact position and angle of the animation for each direction. Not sure where I'll have these input, but I feel this is a really important level of control because it allows animations to go far off center from their origin and do all kinds of crazy stuff. This method is likely simpler than yours, and will require a lot of user input - but I'll need this level of control forsure. 

 

Question: Are you able to explain why large spaces between frames muck up animations? It's just for my sanity at this point  

 

Also, wow tl;dr. Why did I write so much?

[Kibbelz]

@WereAlpaca Firstly, I'd like to state you described my point very well. I myself am not the best when it comes to explaining but you sir I take my hat off to you. Now, I hope I can help explain to the best of my abilities. Using these 2 images:

 

The lines represent a 32x32 tile. Imagine the red rectangle representing the 32x48 sprite you have facing in the right direction. The way how all graphics are handled are for the base of the sprite to be centred around the tile that the entity is positioned on. Hence why the top 16 tiles of your 32x48 sprite aka the hairline will be rendered on the tile above. The blue square represents a 64x64 animation being fired right of the player as a projectile. The green square actually represents the middle of this animation and in this example, the actual animation you care about. The blue edges represent the redundant white space bordering the animation, as you can see its essentially buffering the animation into another spawning position and even overlapping with the player's graphic. There are three solutions, either remove the excess "white space buffer" on the animation graphic, change the spawn location in the projectiles editor or introduce an offset when source is released. Here is another image without the white spacing buffer in the animation file. You can see how its spawn position in pixels changes.

 

I hope this explains it for you as a more visual approach. My wording may be off so someone may have to hop in to help explain.

 

-Kibbelz

[WereAlpaca]

5 hours ago, Kibbelz said:

@WereAlpaca Firstly, I'd like to state you described my point very well. I myself am not the best when it comes to explaining but you sir I take my hat off to you. Now, I hope I can help explain to the best of my abilities. Using these 2 images:

 

The lines represent a 32x32 tile. Imagine the red rectangle representing the 32x48 sprite you have facing in the right direction. The way how all graphics are handled are for the base of the sprite to be centred around the tile that the entity is positioned on. Hence why the top 16 tiles of your 32x48 sprite aka the hairline will be rendered on the tile above. The blue square represents a 64x64 animation being fired right of the player as a projectile. The green square actually represents the middle of this animation and in this example, the actual animation you care about. The blue edges represent the redundant white space bordering the animation, as you can see its essentially buffering the animation into another spawning position and even overlapping with the player's graphic. There are three solutions, either remove the excess "white space buffer" on the animation graphic, change the spawn location in the projectiles editor or introduce an offset when source is released. Here is another image without the white spacing buffer in the animation file. You can see how its spawn position in pixels changes.

 

I hope this explains it for you as a more visual approach. My wording may be off so someone may have to hop in to help explain.

 

-Kibbelz

Ahh I totally get it now! The visualization helped a lot. Appreciate the hat tip! To help others understand better are you able to create a mock-up for the default animation position? Which is the upwards animation I believe. It may seem self explanatory but I think it will make a difference. Cheers!