Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Swiper: Boss - Particles | 25€ Bounty #2125

Closed
Shusama opened this issue Mar 24, 2018 · 8 comments
Closed

Swiper: Boss - Particles | 25€ Bounty #2125

Shusama opened this issue Mar 24, 2018 · 8 comments

Comments

@Shusama
Copy link

Shusama commented Mar 24, 2018

Boss Swiper

We have several bosses already implemented which you should feel free to use as inspiration/reference. Also you can reference some other open source custom games on Github which have boss fights including Second Day of Frostivus where you will find our IO boss (designed by Yahnich). Files should follow the structure already established in the components subfolders (such as /abilities/, /boss/, etc).

See also:

Swiper: Boss - Model/Animations/Icons #2124
Swiper: Boss - Sound #2126
Swiper: Boss - Code #2123

Bug Bounty Guideline

Particles

Please take a look at the Model/Animations/Icons issue. Since the abilities are often have combined animations and particles we would like the people working on those to work together on these.

  • Thrust: A long, narrow targeting rectangle renders from the boss outward over the duration of the wind-up, indicating the precise location of impending damage. This particle should disappear after the wind-up but before the ability animation completes.

    Additionally, the Ability animation should emit a copy of his sword as a large, poking, sword particle.
  • Frontswipe: A targetting circle centered on the boss's position should begin as an expanding pie slice counter-clockwise until it reaches the total arc of the location of impending damage. This particle should disappear after the wind-up but before the ability animation completes.

    Additionally, the Ability animation should emit a trailing particle similar to juggernaut spin.
  • Backswipe: The frontswipe particle should play in reverse at the appropriate time. The particle should disappear before the ability animation completes.

    Additionally, the Ability animation should emit a trailing particle similar to juggernaut spin.
  • Rush: Two parallel targeting rectangles emit from the boss outward over the duration of the wind-up, indicating the precise location of impending damage. Once the boss begins moving a new indicator circle particle should appear at the target location indicating the total arc of the location of impending damage. The particle should dissappear before the ability animation completes.
@Toyoka
Copy link
Contributor

Toyoka commented Apr 21, 2018

Claimed.

@Toyoka
Copy link
Contributor

Toyoka commented Apr 21, 2018

Progress on Swiper:

Thrust: https://streamable.com/gln1g
99% Done (just requires custom sword model/sword origin adjustment, if anything)

Sword model is a placeholder (Sven default sword with material override). Sword model goes beyond target rectangle's endpoint due to sword model's origin not placed at the front end of the model (easily fixable; a custom model should have no issue with positioning as long as it's origin is placed at the front end. This may or may mean 2 versions of the sword are required: 1 for the boss to be held, one for the particle for proper placement).

System has the following CPs:

  • CP0 = Starting position (boss's current location) of rectangle and sword
  • CP1 = End point of targeting rectangle and sword (any distance is viable)
  • CP2 = Life duration of effect system (how long the rectangle and sword stays before the effect ends, in seconds), also affects fading-in of rectangle and sword.
  • CP3 = Emission scale of targeting rectangle (how fast it takes the rectangle to grow to full length). (1)
  • CP4 = Travel time of sword from starting point to end point. (2)

(1) The higher the input, the faster
(2) The lower the input, the faster

Note: For rectangle growth and sword travel time to match visually, you will need to do the following:
Chose a number for CP3. This will be how fast the rectangle grows. Now we need to obtain CP4's travel time. Divide 1 by CP3's input number to get CP4's input number. 1 is the base input for CP3 and CP4 (default grow and travel time, in seconds). Ie. If we want the rectangle to grow twice as fast as default, we will give CP3 an input of 2 and CP4 an input of 0.5. If we want the rectangle to grow twice as slow, we will give CP3 an input of 0.5 and CP4 an input of 2. Quick mafs!

Ideally you want CP2 to also have the same input as CP4 for better visual fade-in, but it's up to you!

@Toyoka
Copy link
Contributor

Toyoka commented Apr 22, 2018

Progress on Swiper:

Backswipe/Frontswipe (both work identically): https://streamable.com/g0blj
99% Done (again, just requires custom sword model. note that these systems have a newer sword skin; this has indeed been updated to all effects)
Lifetime change example: https://streamable.com/ywl5o

Both systems have the following CPs:

  • CP0 = Used to determine effect's position. Position takes x, y, z co-ordinates (for example 256, 256, 256).
  • CP1 = Used to determine the arc's forward facing direction, in relation to CP0. takes x and y co-ordinates (for example 100, 0, 0, or 0, 100, 0, or 100, 100, 0). This CP rotates the effect system so that the arc located at CP0 rotates to face the position of CP1.
  • CP2 = Life duration of the system (how long the sword and arc last before ending the effect +fading)
  • CP3 = Emission scale of sword and arc (how fast the systems emit before reaching their ending position)

Play around with CP2 and CP3 inputs. They work well without having to match!

@l34Um1
Copy link
Collaborator

l34Um1 commented Apr 22, 2018

sick

@Toyoka
Copy link
Contributor

Toyoka commented Apr 22, 2018

Updated Backswipe/Frontswipe so that orientation of the system is done separately in CP1, in relation to CP0. CP1's position determines position of the target of the attack, rotating the effect located at CP0 so that the arc faces the target properly. See first webm in previous post for an example of how the effect now works.

@Toyoka
Copy link
Contributor

Toyoka commented Apr 22, 2018

Progress on Swiper:
Rush
99% Done (again, just requires custom sword model)

Rush (Charge): https://streamable.com/wirgw
Rush (Charge) particles contain the following CPs (same as Thrust ability):

  • CP0 = Starting position (boss's current location) of both rectangles (movement and damage), and the sword.
  • CP1 = End point of targeting both rectangles, and the sword (any distance is viable)
  • CP2 = Life duration of effect system (how long both rectangles, and the sword stay before the effect ends, in seconds), also affects fading-in of both rectangles, and the sword.
  • CP3 = Emission scale of targeting rectangles (how fast it takes the rectangles to grow to full length). (1)
  • CP4 = Travel time of sword from starting point to end point. (2)
    (1) The higher the input, the faster
    (2) The lower the input, the faster

(See notes on Thrust for getting the rectangles and the sword to match)

Rush (Circle target): https://streamable.com/vdkvi
Rush (Circle target) contains the following CPs (same as Frontswipe/Backswipe):

  • CP0 = Used to determine effect's position. Position takes x, y, z co-ordinates (for example 256, 256, 256).
  • CP1 = Used to determine the circle's forward facing direction, in relation to CP0. takes x and y co-ordinates (for example 100, 0, 0, or 0, 100, 0, or 100, 100, 0). This CP rotates the effect system so that the circle located at CP0 rotates to face the position of CP1 similar to how it's shown in the design doc of the original issue post.
  • CP2 = Life duration of the system (how long the sword and circle last before ending the effect +fading)
  • CP3 = Emission scale of sword and circle (how fast the systems emit before reaching their ending position)

Note: Both the charge and circle systems are separate effects. The circle's position should be placed at the end-point of the charge.

@mikibun
Copy link

mikibun commented Jun 9, 2018

Toyoka needs to be paid @l34Um1

@Toyoka
Copy link
Contributor

Toyoka commented Jun 9, 2018

I've now been paid! This can be closed.

@Haganeko Haganeko closed this as completed Jun 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants