Jump to content

Photo

Non-Scripter's Custom Boss Kit


  • Please log in to reply
98 replies to this topic

#31 Alucard648

Alucard648

    Wizard

  • Members
  • Location:castle Dracula

Posted 25 January 2014 - 06:47 PM

Tried new version.

 

1. Animation bug is still here:

zelda011_zpsfaeaf9ff.png

The enemy in question is Octorok+Spear Grape-Shooter

2. If you place multiple BigEnemies with diffrernt sizes and kill one, the other becomes glitched.

3. Teleporting enemies: the shooter is still working even when Wizzrobe is invisible.

Updated test quest: https://www.mediafir...jpft57k0wvgok31


Edited by Alucard648, 25 January 2014 - 07:13 PM.


#32 kurt91

kurt91

    Follower of Destiny

  • Members
  • Real Name:Kurtis
  • Location:Eastern Washington University

Posted 26 January 2014 - 04:22 AM

Okay, I'm looking through your quest right now.

 

First off, could you show an example of issue #2 regarding multiple BigEnemies of different sizes? I checked in your sideview area where you had a 1x2 and 2x1 enemy, and didn't see any problems?

 

Second, regarding the Octorok, I noticed two things. One was the animation glitch that you mentioned, and I think that's a problem regarding having Enemy->Extend activated without actually using it. That shouldn't be too difficult to fix, I just have to re-arrange the BigEnemy portions of the script so they only are brought up if Size is used. The other thing that I noticed is that the invisible Arrow shooter is not latching onto the Octorok's coordinates. I'm not entirely sure what's causing that.

 

Finally, I had no idea while writing the script on what would happen if a teleporting enemy were to be used. Apparently, they aren't compatible with the script as it is right now, so that's going to have to just be a limitation until I can figure out a better way to handle it.

 

On an unrelated note, you do realize that if you use a blank tile for your Freeform Combo, as long as it isn't Combo 0, you can just leave it there invisibly instead of trying to incorporate it into your screen design, right? At least, that's how I usually handle them, so seeing them used as actual decoration seemed slightly odd.

 

Anyways, it's 1:30 in the morning where I'm at, so let me get some sleep first, and I'll try to take a look into fixing these. I'm pretty sure that I can fix the graphics issue, but I'm not sure about the positioning problem.

 

EDIT: Okay, it turns out the fix was much simpler than I thought. I simply put "EnemyMove->Extend = 3" inside an "if (Size > 0)" conditional statement. That fixed the graphical glitches with your Octorok as well as the positioning problems it had. The Wizzrobe may still be glitched, but that thing was a challenge to kill with the Arrow spray. I think for everybody's sanity, it might be best if I don't try fixing it. I can't imagine a battle where that works correctly! (I joke, of course. I'll try to figure out a way to fix it so Wizzrobes work.)

 

Anyways, here's the script with the fix. I'm thinking that future updates should just be MediaFire links, given the length of the script. Unless you don't mind doing it this way?

 


Edited by kurt91, 26 January 2014 - 04:40 AM.


#33 Alucard648

Alucard648

    Wizard

  • Members
  • Location:castle Dracula

Posted 26 January 2014 - 03:36 PM

First off, could you show an example of issue #2 regarding multiple BigEnemies of different sizes? I checked in your sideview area where you had a 1x2 and 2x1 enemy, and didn't see any problems?

Kill the zombie in that area and the dog will have glitchy animation.

Tested with various combinations of built-in ZC enemies and found following oddities with splitting enemies:
1. Split-on-hit enemies (Digdoggers, Vires) - one enemy does not move (and still possesses working projectile shooter) while other behave normally.
2. Split-on-death enemies (L3 Darknuts, Zols): all offsprings die instantly. As well as projectile shooter.
3. Tribble enemies: Grown-up enemy does not move while still shooting projectiles.

Updated test quest: http://filesmelt.com/dl/100tombs.qst

As for suggestions for next version: you should add support for all BigEnemy size combinations that work properly(like (1-2)x(1-4). This allows me to test TripleEnemy mode properly and put the script at good use in my quest (making large sideview enemies and, of course, bosses).

Edited by Alucard648, 26 January 2014 - 03:50 PM.


#34 kurt91

kurt91

    Follower of Destiny

  • Members
  • Real Name:Kurtis
  • Location:Eastern Washington University

Posted 26 January 2014 - 03:52 PM

Okay. I'll look into the zombie/dog problem, but I had mentioned before that splitting and tribble enemies would most likely not work. The script works by using the enemy list to figure out which enemies to attach together. If an enemy splits/tribbles, then I believe that the offspring enemies would take up the space on the enemy list that the original enemy took up, causing issues. Because of the way the script works, I don't think that a method to fix it is something I'd be able to do.

 

EDIT: Thinking about it for a bit, I remember having read that if one enemy is killed, the later enemies on the enemy list would move up to take the space. If that's true, then I'll need to look for a way to prevent that behavior or have the script shift alongside them. If that works, it would probably also fix the splitting/tribble problems as well. A quick and dirty solution would be to make an additional enemy (I believe an unarmed projectile shooter has no collision data if it has no graphic, and should work well) with no graphics to act as the death state, and have all the components of the boss that you could split on death into the appropriate number of these enemies, thus preventing later enemies from moving up the list.

 

So, the limitations on this script are that you can't use Wizzrobe enemies or splitting/tribble effects. However, if it's being used for a boss, then the splitting/tribble effect could easily be faked using multiple screens in the same way that a custom boss made in 1.90 would work. (Actually how I made a multi-phase custom boss in my quest, and the effect works seamlessly)



#35 Alucard648

Alucard648

    Wizard

  • Members
  • Location:castle Dracula

Posted 26 January 2014 - 05:32 PM

A quick and dirty solution would be to make an additional enemy (I believe an unarmed projectile shooter has no collision data if it has no graphic, and should work well) with no graphics to act as the death state, and have all the components of the boss that you could split on death into the appropriate number of these enemies, thus preventing later enemies from moving up the list.

Not feasible - only walking enemies can have option to split on death.

So, the limitations on this script are that you can't use Wizzrobe enemies or splitting/tribble effects.

Splitting/tribble enemies limitation isn`t that problematic. But inability to use teleporting enemies as base for bosses is a very bad thing. :swelter: As wizard-like bosses, whose pattern is "teleport-attack-teleport-attack" are quite common in video games. And Dracula, who will be penultimate boss in my quest, is not exception. And if you can think about this... Maybe Ghosted teleporting enemy, if you have expirence with Autoghost.  :eyebrow:



#36 kurt91

kurt91

    Follower of Destiny

  • Members
  • Real Name:Kurtis
  • Location:Eastern Washington University

Posted 26 January 2014 - 07:50 PM

So, what about if a walking enemy with no weapon were to be used as the collision base, and then it splits into the matching number of death-state enemies, two if two enemies were used, and three if three enemies were used? That would keep the enemy list balanced, wouldn't it?

 

I've never used AutoGhost before, and have been meaning to learn as my next side-project after this was finished. Then, if I'd learned anything that could be useful in this, I planned on coming back to this and updating it further. It seems that, although there are a few issues, there's enough done here that it could be ready to be released as a Version 1.0 or something. You think? After possibly fixing Wizzrobe movements at some point, I could release that as a 1.1, the weapon and shot-type selector feature would become 2.0, and after learning how to use ghosted features, bring it up to 3.0. (first number would be added features, second number would be bug-fixing)



#37 Alucard648

Alucard648

    Wizard

  • Members
  • Location:castle Dracula

Posted 26 January 2014 - 10:48 PM

It seems that, although there are a few issues, there's enough done here that it could be ready to be released as a Version 1.0 or something. You think?

I think the support for sizes larger than 2x2 makes the script ready for RC testing. And once I can confirm proper functionality of TripleEnemy mode. Haven`t tested triple bosses because there are no built-in enemies with sizes > 2x2 (Manhandla, Moldorm, Lanmola and Gleeok don`t make script working when used as base ("Movement")). Although Digdogger can be used as base, Triple Enemy works best with sizes like 4x4 or 2x4. 3x3 also works well. Another problem is position of  shooter and collision part relative to base boss part . If the position is wrong, the boss will have weak spot at wrong place. Or shoot from wrong position. Both instances are too odd.

 

Dog and zombie bug. Did you tried to make the BigEnemy portion of the script run only once? I have examined code and found out that script updates BigEnemy settings every frame! This is, maybe, the source of the bug... 



#38 kurt91

kurt91

    Follower of Destiny

  • Members
  • Real Name:Kurtis
  • Location:Eastern Washington University

Posted 27 January 2014 - 02:18 AM

So, I need to add support for 2x4, 3x3, and 4x4, and see about setting up the BigEnemy portion to only run once instead of every frame? That doesn't seem too difficult, except that I'm not entirely sure how to lay out the tiles for such large enemies. Even if they do work, the single-row animation limitation would reduce your boss to flip, 2-frame, and possibly 3-frame animation.

 

I thought the positioning problem was fixed when I edited the EnemySize->Extend line to only trigger when BigEnemy was needed. At least, when I tested it with the quest file you gave me, it was working properly once I had done that. Is there still a problem with that part?

 

Wait... You're wanting to use BOSSES as individual components?! I never thought of that when I wrote the script! I'm not saying it's a bad idea, but when I came up with the idea, the furthest extent I had planned out was a Weapon component to shoot things, and a Collision so you could add in Jinx effects or Eat effects to the same enemy. Still, it could be pretty neat if it works out.

 

I'm going to need a bit of time to get the added sizes put in. I've got to make 6 more sets of settings (3 for top-down, 3 for side-view). It's not difficult, but rather time-consuming.



#39 Alucard648

Alucard648

    Wizard

  • Members
  • Location:castle Dracula

Posted 27 January 2014 - 03:00 AM

So, I need to add support for 2x4, 3x3, and 4x4, and see about setting up the BigEnemy portion to only run once instead of every frame? That doesn't seem too difficult, except that I'm not entirely sure how to lay out the tiles for such large enemies. Even if they do work, the single-row animation limitation would reduce your boss to flip, 2-frame, and possibly 3-frame animation.

 

I thought the positioning problem was fixed when I edited the EnemySize->Extend line to only trigger when BigEnemy was needed. At least, when I tested it with the quest file you gave me, it was working properly once I had done that. Is there still a problem with that part?

 

Wait... You're wanting to use BOSSES as individual components?! I never thought of that when I wrote the script! I'm not saying it's a bad idea, but when I came up with the idea, the furthest extent I had planned out was a Weapon component to shoot things, and a Collision so you could add in Jinx effects or Eat effects to the same enemy. Still, it could be pretty neat if it works out.

 

I'm going to need a bit of time to get the added sizes put in. I've got to make 6 more sets of settings (3 for top-down, 3 for side-view). It's not difficult, but rather time-consuming.

Damn! Checked scripting roadmap for my quest project and found out that Giant Bat requires 3x1 size setup and Monster Frankenstein requires 1x3 one! Awww...  :snide:



#40 kurt91

kurt91

    Follower of Destiny

  • Members
  • Real Name:Kurtis
  • Location:Eastern Washington University

Posted 27 January 2014 - 03:19 AM

No problem. Like I said, it's not difficult, just time consuming. The list of requested sizes is:

 

2x4 Top-Down

2x4 SideView

3x3 Top-Down

3x3 SideView

4x4 Top-Down

4x4 SideView

1x3 Top-Down

1x3 SideView

3x1 (should work in both)

 

for a total of nine additional entries, am I right?



#41 Alucard648

Alucard648

    Wizard

  • Members
  • Location:castle Dracula

Posted 27 January 2014 - 04:34 PM

No problem. Like I said, it's not difficult, just time consuming. The list of requested sizes is:

 

2x4 Top-Down

2x4 SideView

3x3 Top-Down

3x3 SideView

4x4 Top-Down

4x4 SideView

1x3 Top-Down

1x3 SideView

3x1 (should work in both)

 

for a total of nine additional entries, am I right?

Yes.



#42 kurt91

kurt91

    Follower of Destiny

  • Members
  • Real Name:Kurtis
  • Location:Eastern Washington University

Posted 27 January 2014 - 05:42 PM

Probably going to be too busy to work on the script today, but I wanted to bounce a thought out there and get a second opinion. I mentioned before on how one of the features I want to add is to be able to use two arguments to give a single enemy additional weapons and shot types that it will cycle through randomly. If something like that were applied to a Wizzrobe enemy in Single Enemy Mode, then have the BigEnemy function activated to make the enemy larger, wouldn't that manage to result in the same effect you're trying to achieve? It's a bit of a work-around, but it should work for making teleporting bosses.



#43 Alucard648

Alucard648

    Wizard

  • Members
  • Location:castle Dracula

Posted 28 January 2014 - 02:12 PM

Probably going to be too busy to work on the script today, but I wanted to bounce a thought out there and get a second opinion. I mentioned before on how one of the features I want to add is to be able to use two arguments to give a single enemy additional weapons and shot types that it will cycle through randomly. If something like that were applied to a Wizzrobe enemy in Single Enemy Mode, then have the BigEnemy function activated to make the enemy larger, wouldn't that manage to result in the same effect you're trying to achieve? It's a bit of a work-around, but it should work for making teleporting bosses.

I am waiting for...

EDIT: Just in case if you have arguments shortage, please, check out this awesome header made by ZoriaRPG. It`s already used in my quests anyway,

http://www.purezc.ne...showtopic=60565


Edited by Alucard648, 28 January 2014 - 11:23 PM.


#44 kurt91

kurt91

    Follower of Destiny

  • Members
  • Real Name:Kurtis
  • Location:Eastern Washington University

Posted 29 January 2014 - 05:34 AM

Okay, I took a couple days off of working on this, but I'm doing a full rewrite of the BigEnemy part of the script. The way I was doing it was long and tedious, putting the same numbers in time and time again for each individual setting. Now, I'm not done, and I'm going to need to do a fair bit more math this time around, but...

if((Size >= 1)&&(Size <= 6)){  //If Size is between 1 and 6
    EnemyMove->HitWidth = 16;  //Movement Enemy Hitbox - 16 Pixels Wide
    EnemyMove->TileWidth = 1;  //Movement Enemy Sprite - 1 Tile Wide
}
if((Size >= 7)&&(Size <= 13)){  //If Size is between 7 and 13
    EnemyMove->HitWidth = 32;   //Movement Enemy Hitbox - 32 Pixels Wide
    EnemyMove->TileWidth = 2;   //Movement Enemy Sprite - 2 Tiles Wide
}
if((Size >= 14)&&(Size <= 20)){  //If Size is between 14 and 20
    EnemyMove->HitWidth = 48;    //Movement Enemy Hitbox - 48 Pixels Wide
    EnemyMove->TileWidth = 3;    //Movement Enemy Sprite - 3 Tiles Wide
}
if((Size >= 21)&&(Size <= 27)){  //If Size is between 21 and 27
    EnemyMove->HitWidth = 64;    //Movement Enemy Hitbox - 64 Pixels Wide
    EnemyMove->TileWidth = 4;    //Movement Enemy Sprite - 4 Tiles Wide
}

...I think I may have found a better way. (See if you can catch the major change other than formatting :))


Edited by kurt91, 29 January 2014 - 05:36 AM.


#45 anikom15

anikom15

    Dictator

  • Banned
  • Real Name:Westley
  • Location:California, United States

Posted 29 January 2014 - 12:03 PM

The widths can be calculated simply this way.

 

const int TILE_SIZE = 16;
 
EnemyMove->TileWidth = Size / 6 + 1;
EnemyMove->HitWidth = EnemyMove->TileWidth * TILE_SIZE;

 

This only works if Size is greater than or equal to zero.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users