Jump to content

Photo

Scripted enemies: Tiles VS Combos


  • Please log in to reply
12 replies to this topic

Poll: Scripted enemies: Tiles VS Combos

Do you prefer combos, or tiles?

You cannot see the results of the poll until you have voted. Please login and cast your vote to see the results of this poll.

Would you use a header that removed enemy combo animation in favor of tiles?

You cannot see the results of the poll until you have voted. Please login and cast your vote to see the results of this poll.
Vote Guests cannot vote

#1 Deedee

Deedee

    Bug Frog Dragon Girl

  • Moderators
  • Real Name:Deedee
  • Pronouns:She / Her, They / Them
  • Location:Canada

Posted 04 April 2021 - 07:15 PM

Ghosted enemies have existed for a long time, and the main way of setting animations for them to use has been with combos.

Now, with NPC script on the rise, tile-based animations might see a higher usage, cause they are the only animation-type built into ZC, and ghost will be getting a revamp for 2.55 that could possibly not include combo-based animation.

What's your preference for enemy animations? Do you prefer tiles, or combos?



#2 Mitchfork

Mitchfork

    no fun. not ever.

  • Contributors
  • Real Name:Mitch
  • Location:Alabama

Posted 04 April 2021 - 07:27 PM

Combos are more trouble to set up, but once they are it's pretty painless to set script-side. I wouldn't really mind using tiles if Ghost 3 had an automated way to set up animation parameters, though.

#3 Russ

Russ

    Caelan, the Encouraging

  • Administrators
  • Location:Washington

Posted 04 April 2021 - 07:32 PM

Setting up tile animations for a lot of the stuff I do would be a nightmare. I'm not gonna be touching 2.55's ghost if it doesn't include combo animation. Or rather, I'd probably just hack up ghost and make my own branch with combo animations.



#4 Mani Kanina

Mani Kanina

    Rabbits!

  • Members

Posted 04 April 2021 - 07:36 PM

Combos are practical in the sense that you don't need to do the leg work in the script itself for what animation you want. But, they have some disadvantages, one of them is if you want to insert combos earlier in the tileset then, oops, now you need to reconfigure every single ghosted enemy.

I don't have a preference for either or, but whatever solution is used it should be *practical* and easy to configure. Configure animation frames in ZC is currently rather easy. One note to consider if you want to have animation configuration be tile based and to help people out is allowing easy math helps to deal with line breaks in the tile page editor. This can come up when wanting to use, say, an animation that is 5 frames long and your enemy is 3x3 or 5x5, it would not fit neatly into one tile page line, unless you split up the tiles in the tile editor by 16x16 chunk. (but this makes it harder to get an overview picture when editing the graphics.) Obviously you can just do the math yourself, but if we are speaking of features to help you out here.


Edited by Mani Kanina, 04 April 2021 - 07:37 PM.

  • Jared likes this

#5 Evan20000

Evan20000

    P͏҉ę͟w͜� ̢͝!

  • Members
  • Real Name:B̵̴̡̕a҉̵̷ņ̢͘͢͜n̷̷ę́͢d̢̨͟͞
  • Location:B̕҉̶͘͝a̶̵҉͝ǹ̵̛͘n̵e̸͜͜͢d҉̶

Posted 04 April 2021 - 08:07 PM

I had to rescript combo animation for a very specific edge case for a boss in Evan6th. It was a massive pain in the ass. I would prefer to use an out of date old header than one that asked me to do that for almost every enemy.



#6 Orithan

Orithan

    Studying Scientist - Commission from Silvixen

  • Members
  • Location:Australia

Posted 04 April 2021 - 08:10 PM

I much prefer tile-based animation because I like to have fine control over my animations. That said I would really like to see combo-based animation be a thing because its a much easier thing to set up and people demand to have it kept.



#7 Moosh

Moosh

    Tiny Little Questmaker

  • ZC Developers

Posted 04 April 2021 - 09:31 PM

I much prefer combo animation for keeping track of frames, but that doesn't mean I particularly like ghost's sidestepping of the enemy's actual graphics in favor of script draws, or the awkward looping problems that come with it. I'd begrudingly use a header that doesn't include a combo animation option but as Russ said I'd inevitably end up creating my own system to make it work.



#8 Emily

Emily

    Scripter / Dev

  • ZC Developers

Posted 07 April 2021 - 07:26 PM

Question; both to the crowd, and also specifically @Russ

How would you feel if it didn't include standard combo animation, but allowed you to use a combo ID and have it fetch the tile animation information from that combo for you automatically? That should be readily doable in 2.55.



#9 Russ

Russ

    Caelan, the Encouraging

  • Administrators
  • Location:Washington

Posted 07 April 2021 - 08:09 PM

Question; both to the crowd, and also specifically @Russ
How would you feel if it didn't include standard combo animation, but allowed you to use a combo ID and have it fetch the tile animation information from that combo for you automatically? That should be readily doable in 2.55.

I think that'd basically solve the problem? Depending on how robust the behind the scenes handling is. Like... I guess to illustrate why I really like the current setup:

unknown.png

Basically, with current Ghost, I can set up 12 combos. Standing still (up, down, left, right), walking animation, attacking animation. I set Ghost_Data to the first combo and set the ghost flag GHF_4WAY. With that flag, the combo is automatically incremented based on the enemy's direction. If I want the enemy to start moving, I do Ghost_Data += 4. Attack animation, Ghost_Data += 8. I don't ever have to worry about setting its tiles or directions or whatnot; ghost handles that.

As I understand, your solution is I'd give ghost a combo and it would grab that combo's associated tile, aframes, and aspeed and set that up for the enemy. That seems totally fine. I don't ultimately care if it's doing DrawCombo or if it's setting the NPC's tile, so long as I don't have to manually set up the tile animations. Ideally though, it would keep the ease of use with laying out 4 directional combos and being able to quickly tab through animations with a single line. Whether that's done the same way by incrementing a combo variable and having ghost automatically fetch the tile data or by feeding the combos for the different animation states in at the start of the script and just changing an animation state variable mid-script, I don't really care. I guess again, my answer is I don't care what's happening under the hood so long as it remains really easy to set up and use like it currently is.

#10 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 09 April 2021 - 06:38 AM

FWIW, Ghost.zh v3 is using tiles. It does not use ffcs, and uses normal enemy animations; and animation commands based on tiles by setting the actual enemy tile; but this is 2.55+ exclusive. It is perfectly possible to use a combo via combodata to get its base tile, sizes, number of frames, and the ike, but IDK how this is more useful than what is already planned, as it merely wastes combo space.

 

Note that exporting a .znpc file package as a complete set of data will honestly only ever work with tiles. This means that if you use combos you will also need to manually import the combo file and have it set to the proper tile IDs and also use a combo label. The npc data has no way to know what combo you want to use, and the idea here is a fully modular import and export system for enemies and items as complete packages. Using combos would break that

 

It is a much better solution for the script to have a set_animation(...) type of function that takes a base tile ID and adjusts the present draw based on a clock, which is how enemies tend to work everywhere else. 

 

@Russ As you are effectively not doing aught more than refining the same quest and codebase over and over, fret not: <ghost2> and <ghost3> are not mutually exclusive (they can be run in parallel), so there is no requirement to port things if you cannot. 



#11 Deedee

Deedee

    Bug Frog Dragon Girl

  • Moderators
  • Real Name:Deedee
  • Pronouns:She / Her, They / Them
  • Location:Canada

Posted 09 April 2021 - 09:27 PM

FWIW, Ghost.zh v3 is using tiles. It does not use ffcs, and uses normal enemy animations; and animation commands based on tiles by setting the actual enemy tile; but this is 2.55+ exclusive. It is perfectly possible to use a combo via combodata to get its base tile, sizes, number of frames, and the ike, but IDK how this is more useful than what is already planned, as it merely wastes combo space.

 

Note that exporting a .znpc file package as a complete set of data will honestly only ever work with tiles. This means that if you use combos you will also need to manually import the combo file and have it set to the proper tile IDs and also use a combo label. The npc data has no way to know what combo you want to use, and the idea here is a fully modular import and export system for enemies and items as complete packages. Using combos would break that

 

It is a much better solution for the script to have a set_animation(...) type of function that takes a base tile ID and adjusts the present draw based on a clock, which is how enemies tend to work everywhere else. 

 

@Russ As you are effectively not doing aught more than refining the same quest and codebase over and over, fret not: <ghost2> and <ghost3> are not mutually exclusive (they can be run in parallel), so there is no requirement to port things if you cannot. 

While it does not use ffcs, I object to any version of ghost3 that does not offer the option built-in to define it's tiles, animation, and etcetera using combodata. People *prefer* to set up their enemies using combos; the people that don't are a minority but I have stuff in ghost3 for them as well. Just because you see it as a waste of space, does not mean most people do. Combos, by their definition, are tiles with data (a "combo", if you will). Combos hold frame count, animation speed, etc, on a per combo basis; this makes it absurdly useful to set up an enemy's animation per-direction (directions, by sheer coincidence, are evenly divisible by 4; the combo page is oriented in rows of 4), and see the animation play out in editor.

More importantly, combos allow you to easily and efficiently set up variations of an enemy that uses the same script, but may look different. My go-to example would be my wizzrobe enemies in Hyrule Fantasy. I have a generic wizzrobe script that uses the same behavior for all enemies using it, minus what weapons they fire, and what combos they use. One such option they have is a custom teleport animation, that allows you to define what combo they use when they teleport in and out. My windrobes, for example, I decided to have their teleport animation be a whirlwind, cause it's fancy and it immediately catches the players eye "hey, avoid this" (whether or not you think windrobes are bad design, I digress, isn't the point here). I was able to do this by having the wizzrobe's combos be the exact same as my other wizzrobes except for the teleport animation, which was replaced with wind. While you would say this was a waste of combo space, I would argue that it saved tile space; instead of having to copy however many rows the wizzrobe tiles used and have redundant copies of already existing sprites, I was able to just point the combos that I needed to completely different sprites. Not only that, but my wizzrobes use 4 frames for their walking animation per direction, while the whirlwind animation only uses 2, and is omnidirectional (the same sprite for every direction).  I would need to copy the whirlwind animation 8 times to have it fit with the other animation, and that is wasteful, especially as tile space is infinitely more valuable than combo space. With combos, I only need 18 tiles; 16 for the walking, and 2 for the whirlwind. This does not factor in firing animations and standing animations; the standing animation can be taken from a still frame of the walking animation, so that adds 0 frames, and the firing animation I have is only 1 frame per direction, so that adds 4 new tiles, for a total of 22 tiles total for this enemy, as opposed to the 64 the current enemy editor approach would force upon me. All these tiles are also redundant, as those 16 walking tiles and 4 firing tiles can be grabbed from another wizzrobe and just recolored, and the whirlwind can be grabbed from an already existing wind weapon, for a grand total of 0 new tiles to make this enemy, whereas the enemy editor would require 64. This is just one example, of many, where the combo approach helps; I could go into my antifairy vs bouncing star, beamos variations, stalfos variations, etcetera etcetera.

 

You might counter those points, such as the tile efficiency that combo-based approach gives, with "well scripters can just hardcode that stuff or use constants into their scripts to make it more efficient", and to that I argue: but what if the user doesn't want *all* their wizzrobe variants to use a 2 frame animation for their teleport animation; what if they wand a 4 frame multi-directional teleport animation? What if they want a 4 frame animation on the up and down facing teleport animations but only a 3 frame animation for left and right? This isn't an edge case, this stuff happened to me a lot whenever I was making enemies, and almost certainly happens to a lot of people; not only that, but forcing a consistent frame count for all directions is stifling to the end-user's creativity. So you might think "well, just have options for this somewhere that the user can tweak, like in attributes" and to that, I counter that there's already a perfect system in place for handling this exact type of issues: combos. Why overcomplicate this issue, when combos are just the most optimal way of handling this problem?

I also think there's something you are disregarding when you talk about packaging enemies in a nice little bundle that's easy to import: tileset differences. One enemy is not gonna look great in every tileset; a classic enemy won't look good in DoR, a Pure enemy won't look good in instrumentality, etc. I am not sure how you expect this plan to be feasible in the long-term.

@Zoria, I highly recommend watching TabletPillow stream their development sometime (they do it in their development discord server for the RoseMaster). How they use enemies, mechanics, and etc has been a huge eye opener as to the potential of ZC for the non-scripter and how creative you can be using already-existing scripts, and makes me realize just how stifling forcing tile-based enemy setup on the end-user would be creatively. Hell, their use of your thunder-rod script is the most creative use I have seen of it, it's incredible.



#12 Sans

Sans

    Hey kid wanna buy hot dogs ?

  • Members
  • Location:Judgement Hall

Posted 10 April 2021 - 02:15 PM

Personally i prefer the combo functions. Not that i don't like the tiles scripts as many of you does and would think that the tiles scripts would be easier but in my option i think that the combos scripts is much easier to set even through that the combos script would be a little bit much limited then the tiles one. Well it's just my opinion. :) Plus on many scripts you only have usually to set the invisible combos which is always Combo number 1 for example if they requires the invisible combos. Plus the animations on the combos that uses the tiles is much easier too but the problem comes with the limited freefrom combos that only uses a limit of 4x4 tiles maximum which would make the tiles scripts functions much useful if example a boss or a script would requires more then 4x4 tiles. 



#13 Timelord

Timelord

    The Timelord

  • Banned
  • Location:Prydon Academy

Posted 11 April 2021 - 05:36 AM

[...]

@Zoria, I highly recommend watching TabletPillow stream their development sometime (they do it in their development discord server for the RoseMaster). How they use enemies, mechanics, and etc has been a huge eye opener as to the potential of ZC for the non-scripter and how creative you can be using already-existing scripts, and makes me realize just how stifling forcing tile-based enemy setup on the end-user would be creatively. Hell, their use of your thunder-rod script is the most creative use I have seen of it, it's incredible.

 

I won't stop combo implementation, but it should be an alternative, not a default. In theory, every value should be available to the new script type direct from the enemy editor. The library having a set anim style command with number of frames, skips and such, would solve a lot of this. 

 

As for tileset differences, they can of course either recolour or replace tiles; which they would need to do whether you use combos or not. The benefit of using tiles is that the enemy editor itself can insert them as needed, while it cannot do so with combos, at all, ever, I prefer to focus on portability, first.

 

Furthermore, people can make NPC packages with the same basic properties for different tilesets, that can be imported into compatible tilesets. That is a key issue, and again, as soon as you involve combos, you make this more complicated. Use combos if you want, but they should be a line of last resort, and weshould never drawcombo for it. We can read data from combos to animate the enemy's ScriptTile and sizes, but we should not be drawing the npc itself with anything other than its tile data. 

 

If the user wants to do this, they can code DrawCombo calls, which will be entirely on them, and not a support issue for us

 

You are thinking backward here: Once people learn to use the new toolkits, they can adapt to it. Ghost v3 is effectively an entirely new library that is similar in name only, and focusing on what people did in Ghost v2, specifically combos due to it using ffcs, is a huge timesink. People always cringe at new things or different approaches, but even Ghost.zh originally did not support combos. If we create a set of anim styles that the user can set with simple commands, then the point is basically moot. Users can adapt them and submit expansion packs to use additional styles and so forth.

 

Insofar as making an enemy invisible you can now do that with one flag bit: You do not need to change its tile at all to do that. If you want it to flicker, you can toggle this bit on and off with a clk.

 

WRT Rosemaster, using my lightning wand is probably unwise as it is a very dated script, it has no practical benefits, and it can now be done with normal wands using basic settings. I do not recall anything special n that script that cannot be done in the item editor w/o scripts at this time. Its main benefit was assigning a special weapon type, and that is now an editor property. Even if you want to cause the screen to flash on use or something, you can now do that with far smaller script.

 

This again, falls into backwards-thinking and not knowing how to use all of the new features in the core engine. 




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users