1. ## Luminous's Spectral Light

I was wondering how the game handles the skill named Spectral light. It just boggles my mind at every turn, it seems like it'd be impossible to make.

This is the skill in question:

As most of you probably know, you can swivel the skill in nearly a 180 degree range about the player (who acts as the axis). What I am curious about is how the hitboxes, rotation and animation loop code work.

1) Exactly how many 'points' or individual angles can the skill be fired from? For a better illustration of what I am referring to, here is a graphical representation of what I mean by 'points' at which the laser can be fired from.

The animation in question is rather smooth and as such I suspect a large number of points (perhaps around 15-20). Does anyone know for sure?

2) Hitboxes (obviously a normal rectangle isn't going to work for the various angles; did they re-plot a new polygonal hitbox that is associated with every point of rotation, or did Nexon use some other method?

3) Rotation- The actual 'loop' of the laser is 12 frames long. Are there 12 individual pictures in the data for every single 'point' from which Spectral Light can be fired? If this were true, there would be a staggering number of images within the data just for this one skill. Won't the method simply refuse to run/crash/suck up immense amounts of memory and then cause a crash? Does anyone have information on the extracted images within the files? How is this done?

4) Animation loop code- I understand that in Flash you can have an animated image that can be rotated while it loops its animation- however MapleStory is made in C++ and not Flash, so I was wondering how they accomplished this. Say frame 1 plays at point x, when you swivel to point y, how did the coder do it such that the game knows it must play frame 2 of point y and must not start again from frame 1 of point y? From the videos I've watched, the frames are looping as they should as you swivel the laser, and the laser's animation does not re-start from frame 1 when it is swiveled to a new 'point' of firing. How was this accomplished?

2. ## Re: Luminous's Spectral Light

Power of the black mage makes you do crazy things xD. I would like to know this too though

3. ## Re: Luminous's Spectral Light

No I don't see why it won't be possible. What they could do (sorry I suck at programming, I'm just giving possible ideas) is to have the animation loop set as a symbol (of sorts e.g. in Flash) and as an object, along with the hit box. Then set a pivot point, and just do a rotation with the angle changing linearly according to how long you depress the key (very standard thing I believe). I don't think it has to be any kind of complicated stuff such as having a pseudo-infinity (you get where I'm coming from) number of "hit-points". Whether it's rectangular or not is not an issue, and a polymorphic polygonal hit box or a polygonal hit box with some sort of mask just won't work as efficiently as a moving hit box.

From the information we have from Fiel (at least, what we see now), the hit box and animation images are fixed for both Spectral Light and the moving dark magic ball (forgot the name). The latter skill is much easier to code (obviously), but for spectral light you're just changing the angle rather than moving x/y so it's a different problem, not a more difficult problem.

Is C++ able to define a (grouped) object that has an internally playing action? Being a programming language it sounds very possible but I'm not versed in C++ so Eos or someone would have to enlighten you on the details.

My 2 cents, hope it helps. I'm focusing more on the thinking rather than the detail, but I do think that the thinking is more important than just the availability of the method.

4. ## Re: Luminous's Spectral Light

There are no symbols in C++. Not that I know of anyway. At the very least, what I've found being called 'symbols' for C++ looks like variables rather than an independent image.

5. ## Re: Luminous's Spectral Light

I've only ever used programming for math, so this might be completely impossible, but I think the easiest way to do it would be something like....

Define an angle variable. this always gets reset to 0 whenever the key for Spectral light is first pushed.
Have holding up increase the value of the variable angle, while the down key decreases it. (Limits obviously depend on how far the skill can go, if it's directly above or below, cap the values from -90 to 90)
Then just run a check for every frame of animation to see if the variable "angle" has changed. If it has, rotate the next frame of animation to the amount stored in "angle", and display it.
At the same time, check if monsters are within the range of Spectral light at the defined angle.

At the very least, I imagine something like that must be going on, to check for monsters within the hit range of the skill.

6. ## Re: Luminous's Spectral Light

If you define an object in C++ and command it to move (change x/y, change angle), then why would it attempt to revert back to the original position if as long the frame is the one that has been changed? I'm thinking of it like a physical picture frame that has been rotated, and the picture inside the frame is constantly looping (something like those bus stop advertisements that keep changing but you somehow move the entire advertisement box).

Also, hit checks are done based on the attack delay, so I don't think it will be at the same time as whenever the angle is changed. But of course it might just be that case for the initial hit when the angle is just changed. It'd be more convenient to code it directly tied to the delay, IMO.

7. ## Re: Luminous's Spectral Light

They have code in place to rotate sprites. I believe it was first used when they added the backflips for Pirates. It's just vector math and not that hard to do. They only need 1 set of animations for the skill. The same applies for most skills; for example they just flip sprites to get ones that face left and ones that face right, although flipping is much easier than rotating.

For the hitbox, it wouldn't be that hard to draw a rectangle at an angle and calculate whether it collides with another rectangle. Again, vector math. Another way they could have done it is to draw a ray from the character.

The animation is simple. Think of the .wz files as a bunch of folders that organize all the different data in the game. The animation for the skill is stored under a character animations folder, under the appropriate class, as an object which contains a series of images and data about how to display them. This data is incomplete; it knows the images it contains and the hitboxes for those images and it knows that if you use a skill at (X, Y), the animation should play at (X+200, Y), and it knows how long each frame lasts based on a speed S, but it doesn't know what those variables are. When the game wants to play an animation, it calls the parent object and provides it with the parameters on how it wants those images to be displayed. For example, it'll say, "I want frame 1 for skill number 00001234 to play at (400, 300) (where your character is) at angle 0 with speed 2." If it's not already in memory, it'll look up the appropriate object from the .wz file. Then the drawing engine will draw the appropriate sprites where they need to be at the right time, based on the general data provided by that object and the specific data provided by the game. If you're just holding down the skill and nothing's changing, the game will continue to ask for the animation to be played. If you change something, the game will say, "Okay, now draw frame 2 for skill number 00001234 at (400,300) at angle 15 with speed 2." So the game engine can feed information to the drawing engine on the fly and change whatever it wants at any time. The game animations aren't static things that have to play in their entirety every time.

8. ## Re: Luminous's Spectral Light

I'm fairly sure Sommersault only uses 90 degree rotations.

9. ## Re: Luminous's Spectral Light

This is vertically symmetric so it only has to cover 0 through 45 degrees and the rest can be handled by 90 degree rotations + mirrors - 5 different animations would give 32 angles, 6 would give 40, etc. with +8 for each new drawing. From what I can see in the video, they'd only need maybe 64 total angles to do it without rotating anything other than 90 degrees.

Then again it's not pixel art, so rotating intermediate angles wouldn't look ridiculous like it would with normal equipment.

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•