Final Fantasy VI SDK - Going Social!
- Thread starter Dargor
- Start date
And now, FX Commands!
Note that this list is very incomplete. Suggestions are welcome.
Play Sound: Play a specific sound
Tint Screen: Tint the whole screen
Flash Screen: Flash the whole screen
Shake Screen: Shake the whole screen
Tint Terrain Layer: Tint a specific terrain layer
Wave Terrain Layer: Wave effect on a specific terrain layer
Trigger FX:Trigger a specific Effect
Perform Action: Makes a target perform a specific character animation
Deal Damage: Deal damage based on the attack/spell from which this FX is called
Change Sprite: Alter a specific sprite, can be: user, allies, user + allies, all
Slice Sprite: Makes a sprite slice horizontally
Wave Sprite: Applies wave effect on a sprite
Tint Screen: Tint the whole screen
Flash Screen: Flash the whole screen
Shake Screen: Shake the whole screen
Tint Terrain Layer: Tint a specific terrain layer
Wave Terrain Layer: Wave effect on a specific terrain layer
Trigger FX:Trigger a specific Effect
Perform Action: Makes a target perform a specific character animation
Deal Damage: Deal damage based on the attack/spell from which this FX is called
Change Sprite: Alter a specific sprite, can be: user, allies, user + allies, all
Slice Sprite: Makes a sprite slice horizontally
Wave Sprite: Applies wave effect on a sprite
Note that this list is very incomplete. Suggestions are welcome.
Let's see...
To the screen section, you need to add "Scroll layer". It's possible for the event script to scroll any layer with a vector value (so it can go 2 x 1, for instance).
For audio, you should be able to increase/decrease volume of sounds.
For parties, you need to be able to add/remove a vehicle for the party.
----
In FX, you also need a Tint Sprite command, and also a Change Spriteset (think of Locke's scenario, and the Moogle Suit).
To the screen section, you need to add "Scroll layer". It's possible for the event script to scroll any layer with a vector value (so it can go 2 x 1, for instance).
For audio, you should be able to increase/decrease volume of sounds.
For parties, you need to be able to add/remove a vehicle for the party.
----
In FX, you also need a Tint Sprite command, and also a Change Spriteset (think of Locke's scenario, and the Moogle Suit).
Thanks for the input.
Scroll Layer is already there, in the Map category and the vector value has been taken into conssideration.
And you're right, I forgot about vehicles! I'll add a "Set Vehicle" command in the Character category.
So 2 new commands:
- Set Vehicle: Make a character board a vehicle (Magitek, Chocobo, Raft).
- Change Audio Volume: Change the volume of the currently playing SFX/BGM
For vehicles, If Chocobo is set to the party and the map has Mode7 Enabled, then the Chocobo worldmap movement will be enabled. Otherwise, it will simply display the normal chocobo sprite below the character.
About FX commands.
Tint Sprite is indeed a must. However, I think that Change Spriteset could simply be done in battle events using the Change Character event command. But maybe I can go even further and make it an FX command too.
Since we're talking about altering characters, here's a little update on the editor!
There's a couple of things in the game that alter various aspect of an actor.
For example:
Character Set - The Morph Command changes an actor into an Esper form.
Spells - The Imp status disables all spells except Imp
Battle Commands - Gem Box changes Magic to X-Magic
These changes requires a user friendly system and interface and this is why I have created Character/Spell/Command Actions.
These actions will allow to Add/Remove/Replace With/Enable/Disable and Hide various aspects of an Actor (Mainly Characters, Spells and Battle Commands) and are reverted when the object containing the action is removed.
Right now, only Equipment and Status have the above Actions, but this could also be added to the FX editor.
I'm still working on the concept a little bit but it seems to work well that way!
- Dargor
Scroll Layer is already there, in the Map category and the vector value has been taken into conssideration.
And you're right, I forgot about vehicles! I'll add a "Set Vehicle" command in the Character category.
So 2 new commands:
- Set Vehicle: Make a character board a vehicle (Magitek, Chocobo, Raft).
- Change Audio Volume: Change the volume of the currently playing SFX/BGM
For vehicles, If Chocobo is set to the party and the map has Mode7 Enabled, then the Chocobo worldmap movement will be enabled. Otherwise, it will simply display the normal chocobo sprite below the character.
About FX commands.
Tint Sprite is indeed a must. However, I think that Change Spriteset could simply be done in battle events using the Change Character event command. But maybe I can go even further and make it an FX command too.
Since we're talking about altering characters, here's a little update on the editor!
There's a couple of things in the game that alter various aspect of an actor.
For example:
Character Set - The Morph Command changes an actor into an Esper form.
Spells - The Imp status disables all spells except Imp
Battle Commands - Gem Box changes Magic to X-Magic
These changes requires a user friendly system and interface and this is why I have created Character/Spell/Command Actions.
These actions will allow to Add/Remove/Replace With/Enable/Disable and Hide various aspects of an Actor (Mainly Characters, Spells and Battle Commands) and are reverted when the object containing the action is removed.
Right now, only Equipment and Status have the above Actions, but this could also be added to the FX editor.
I'm still working on the concept a little bit but it seems to work well that way!
- Dargor
clockworkbutterfly
Member
You'd also need the command to give a sprite an additional "glowing aura" (rather than tinting) as many FFVI conditions involve this. For example, slow is white, stop is pink, wall is light blue, shell is green, haste is red, and safe is yellow...... if I recall correctly.
-- CB
-- CB
Another thing I thought about was a Pan Camera command. I'm not sure if it's necessary, as I think the original game does it as a sprite-less sprite (lock view on a totally transparent sprite). Speaking of which, do you have commands to hold/free the screen motion? Usually in the game progression, the "camera" is tied to the party, but in cinema scenes it is usually static (but moveable to "look" at something, for instance). Just thought I'd throw that out there.
For collisions, does that also include launching of a script when a collision occurs? I'm thinking of the 3-party scenarios where you may be controlling party A but a monster collides with party C and it automatically centers on party C and launches into battle.
Which brings up another thought: How about enabling the Y-button switching for 2/3-party mode? Not sure if that rises to a full command, as it can be done via a global event bit, but just thought I'd mention it.
Another thing that is needed (for both in battle and out of battle) is a command to modify a particular color in a sprite's palette. The scene where Celes is blushing is what I'm thinking about, but of course there are other applications too.
For flow control, do you have a "call subroutine" command? It's certainly a useful thing to have.
I was thinking about a certain routine the original game uses to count how many people are in the party (you can see how that would be useful). It's not a separate command, just a subroutine that sets certain (multipurpose) bits depending on how many people are in the party.
And how about hide/show object? Sometimes you need to do it mid-event, so there should be a command (and of course, a bit to make sure they stay shown/hidden).
For collisions, does that also include launching of a script when a collision occurs? I'm thinking of the 3-party scenarios where you may be controlling party A but a monster collides with party C and it automatically centers on party C and launches into battle.
Which brings up another thought: How about enabling the Y-button switching for 2/3-party mode? Not sure if that rises to a full command, as it can be done via a global event bit, but just thought I'd mention it.
Another thing that is needed (for both in battle and out of battle) is a command to modify a particular color in a sprite's palette. The scene where Celes is blushing is what I'm thinking about, but of course there are other applications too.
For flow control, do you have a "call subroutine" command? It's certainly a useful thing to have.
I was thinking about a certain routine the original game uses to count how many people are in the party (you can see how that would be useful). It's not a separate command, just a subroutine that sets certain (multipurpose) bits depending on how many people are in the party.
And how about hide/show object? Sometimes you need to do it mid-event, so there should be a command (and of course, a bit to make sure they stay shown/hidden).
MagitekElite
Member
Wow, time to post! :3
Dargor, the post you made with all the features/spoiler buttons, awesome. I can't think of anything to ask about or notice any feature that might need adding from the old game. I was going to ask what Imzogelmo said about tinting the sprites, but it seems that's already been answered :P
Dargor, the post you made with all the features/spoiler buttons, awesome. I can't think of anything to ask about or notice any feature that might need adding from the old game. I was going to ask what Imzogelmo said about tinting the sprites, but it seems that's already been answered :P
clockworkbutterfly
Member
Imzogelmo":3u7wwm7m said:
I was going to say that this could be done by just creating a different sprite, but now that I think about it, this is entirely necessary for characters who get berserked. I could see making a special sprite for the one or two characters who blush during the game, but a different form of every battle sprite for every character would be too much......
-- CB
Yeah, I thought about that too, CB, but, for instance in the blushing scene, it doesn't happen all at once--the blushing is done gradually. So it's not an on/off situation, it's adding redness up to a certain point. And I'm not sure, but it may be effecting more than one of her palette entries.
To use a different sprite, you'd have to have a new sprite for each step, and couple this with the fact that the character may move or change directions while this is going on... it would get cumbersome very quickly.
To use a different sprite, you'd have to have a new sprite for each step, and couple this with the fact that the character may move or change directions while this is going on... it would get cumbersome very quickly.
Thank you for all the input everyone, it's really appreciated! 
@Imzogelmo
About cameras: I probably forgot to add this in my list but the camera pan feature is already in. I also added a feature to attach the camera on any characters in the map, including the player. It is also possible to detach the camera. I added this feature back when I was working on the whelk barrier scene in the gameplay demo that has never been released.
But you bring a good point with multiple parties, something I completely forgot; I would need to add options in the the Pan Camera command that would automatically move the camera to a certain position. I could make it possible to scroll to a certain character or position automatically.
However, I'm not entirely sure how I will handle these kind of collision events yet.
Also, Enabling/Disabling party switching could be easily done using a single line of code with the Call Script command.
But it would not be hard to make a command for this, in fact it should be really easy!
Now, about pallets: I don't have a palette system yet, but I definitely need one. Like CB said, for status like Berserk or Poison. It will also be needed for the glowing frame (Haste, Slow, etc.) and everything else you mentioned. I don't really know how pallets work in the game (how does the code knows which color goes where?) and I don't know how I could make this user friendly. So if you have any ideas, let me know.
The Subroutine: It could simply be a Global Event that runs all the time in whatever the map your in.
Basically, global events are normal events, but they do not belong to a map, they do not have characters associated to them or anything like that.
It's only a list of commands that runs whenever you want.
It is already possible to show/hide an object (it would be characters in this case) in the Move command but it is not very elegant.
Right now, the only way to do it is to assign an empty character to the event. Eventually, I'll add a way to simply show/hide the character sprites.
I like the idea of having variables to check if a character is visible or not.
By the way, speaking of character movement, I'll have to make a list for Movement Command!
RPG Maker has sub commands called Move Commands within the Move Character event command.
The basic commands would be something like: Move Up/Down/Up-Left..., Jump, etc.
@Imzogelmo
About cameras: I probably forgot to add this in my list but the camera pan feature is already in. I also added a feature to attach the camera on any characters in the map, including the player. It is also possible to detach the camera. I added this feature back when I was working on the whelk barrier scene in the gameplay demo that has never been released.
But you bring a good point with multiple parties, something I completely forgot; I would need to add options in the the Pan Camera command that would automatically move the camera to a certain position. I could make it possible to scroll to a certain character or position automatically.
However, I'm not entirely sure how I will handle these kind of collision events yet.
Also, Enabling/Disabling party switching could be easily done using a single line of code with the Call Script command.
But it would not be hard to make a command for this, in fact it should be really easy!
Now, about pallets: I don't have a palette system yet, but I definitely need one. Like CB said, for status like Berserk or Poison. It will also be needed for the glowing frame (Haste, Slow, etc.) and everything else you mentioned. I don't really know how pallets work in the game (how does the code knows which color goes where?) and I don't know how I could make this user friendly. So if you have any ideas, let me know.
The Subroutine: It could simply be a Global Event that runs all the time in whatever the map your in.
Basically, global events are normal events, but they do not belong to a map, they do not have characters associated to them or anything like that.
It's only a list of commands that runs whenever you want.
It is already possible to show/hide an object (it would be characters in this case) in the Move command but it is not very elegant.
Right now, the only way to do it is to assign an empty character to the event. Eventually, I'll add a way to simply show/hide the character sprites.
I like the idea of having variables to check if a character is visible or not.
By the way, speaking of character movement, I'll have to make a list for Movement Command!
RPG Maker has sub commands called Move Commands within the Move Character event command.
The basic commands would be something like: Move Up/Down/Up-Left..., Jump, etc.
Palettes in RM are determined by the image they are drawn from. You can use the get_color() method of a bitmap (or is it from the sprite?) to find specific colors and replace them. IIRC the outline is just outside the black outline of the character, so your best bet would be to go through the sprite horizontally, adding a color over the transparent point before get_color() returns a color, and after (to get the sides) then again vertically, making sure to ignore any of the new stuff you have drawn. This could be a memory intensive way of doing it, though. In fact, with 4 party members, it could be really memory intense. I think you would only need to draw it and not redraw it every frame except for the frames where the person is attacking, or when they change position, because I don't think any of the frames actually animated in FF6, except the casting animation (which was a facial animation, the sprite remained constant) although I could be wrong!
For berserk and poison, you'd just need to find skin tones and add green to them. Since FF6 used a limited palette, I don't think it would be against the rules to hard-code the skin tones as Color objects and use those to change the colors. Or you could just have a 'Poisoned'/'Berserk' battler image.
For berserk and poison, you'd just need to find skin tones and add green to them. Since FF6 used a limited palette, I don't think it would be against the rules to hard-code the skin tones as Color objects and use those to change the colors. Or you could just have a 'Poisoned'/'Berserk' battler image.
There are at least 2 problems with sprite palettes.
1) The #get_pixel and #set_pixel methods are really slow, so using them multiple times is really hard on the system. It's even worse on large images. Thw following code shows how I would do it in Ruby:
The larger the image is, the slower the process is. And it can get reeeeeeally slow.
2) Even if the above method wasn't slow, it would still be a pain to figure out the src_color that we want to change. I don't want to go in paint each time to get the color infos. The colors would need to be indexed, thus the need of a palette system.
I think the "most simple" way of doing it would be to write a couple of functions in C++ and then call them in Ruby. I have tried a couple of things like that about a year ago and it went well, but I know very little about C++. The function would be simillar to the code above.
The other solution would be to have my own sprite and palette editor.
Let me go into more details here.
The idea would be to have some sort of sprite database. It would be possible to create a sprite from an image file.
When importing a sprite, the editor would automatically go through all the pixels and map them into an array or a table just to know which colors goes where and then create a new palette object with all the colors encountered during the process.
Once the sprite is created, the size of the palette cannot be change, but it would be possible to assign a new palette with the same size to this sprite. Now, each time an image is required (for tilesets, characters, icons, ...) instead of browsing for an image file, you would browse for a sprite created earlier in the editor.
Finally, I could have event commands, functions, methods or whatever that would change a sprite palette on the go. That way, all sprites and palettes can easily be previewed. The color indexes are already mapped so changing a specific color would be faster since the code would know exactly where to go when changing the pixel.
But the performance issue is still there, so I would need to write these functions in C++ anyway.
I really don't see any easy solution here.
1) The #get_pixel and #set_pixel methods are really slow, so using them multiple times is really hard on the system. It's even worse on large images. Thw following code shows how I would do it in Ruby:
for x in 0...bitmap.width
for y in 0...bitmap.height
pixel = bitmap.get_pixel(x,y)
if pixel == src_pixel
bitmap.set_pixel(x,y,dest_pixel)
end
end
end
for y in 0...bitmap.height
pixel = bitmap.get_pixel(x,y)
if pixel == src_pixel
bitmap.set_pixel(x,y,dest_pixel)
end
end
end
2) Even if the above method wasn't slow, it would still be a pain to figure out the src_color that we want to change. I don't want to go in paint each time to get the color infos. The colors would need to be indexed, thus the need of a palette system.
I think the "most simple" way of doing it would be to write a couple of functions in C++ and then call them in Ruby. I have tried a couple of things like that about a year ago and it went well, but I know very little about C++. The function would be simillar to the code above.
The other solution would be to have my own sprite and palette editor.
Let me go into more details here.
The idea would be to have some sort of sprite database. It would be possible to create a sprite from an image file.
When importing a sprite, the editor would automatically go through all the pixels and map them into an array or a table just to know which colors goes where and then create a new palette object with all the colors encountered during the process.
Once the sprite is created, the size of the palette cannot be change, but it would be possible to assign a new palette with the same size to this sprite. Now, each time an image is required (for tilesets, characters, icons, ...) instead of browsing for an image file, you would browse for a sprite created earlier in the editor.
Finally, I could have event commands, functions, methods or whatever that would change a sprite palette on the go. That way, all sprites and palettes can easily be previewed. The color indexes are already mapped so changing a specific color would be faster since the code would know exactly where to go when changing the pixel.
But the performance issue is still there, so I would need to write these functions in C++ anyway.
I really don't see any easy solution here.
I guess you're right. Maybe I'm over thinking the whole thing...
The only problem I see with this solution is that the developer would end up with way to many sprites.
If we take the example of FF6; There is at least 3 status that changes the colors of the actors and there is something like 16 actors that can have their skin color changed. That makes at least 48 different sprites. Now, if we multiply this by the number of battle animations required (Idle, Attack, Magic Victory, etc.) we would end up with hundreds of character animations.
But, this would be good enough for specific scene (like the blush we spoke about earlier).
The only problem I see with this solution is that the developer would end up with way to many sprites.
If we take the example of FF6; There is at least 3 status that changes the colors of the actors and there is something like 16 actors that can have their skin color changed. That makes at least 48 different sprites. Now, if we multiply this by the number of battle animations required (Idle, Attack, Magic Victory, etc.) we would end up with hundreds of character animations.
But, this would be good enough for specific scene (like the blush we spoke about earlier).
Actors in battle:
Regular cast:
Terra, Locke, Shadow, Cyan, Edgar, Sabin, Celes, Setzer, Relm, Strago, Mog, Gau, Gogo, Umaro;
PC special use:
Soldier (Wedge/Vicks), Soldier Locke (same but green), Merchant Locke, Leo, Banon, Ghost, Esper Terra, Imp;
NPCs seen in battle:
Kefka, Gestahl
----------------
Statuses:
Outline-changing:
Safe (yellow), Shell (green), Haste (red), Slow (white), Stop (magenta), Reflect (blue)
Palette-effecting:
Poison (also changes the pose), Berserk (also changes the pose), Zombie (may change pose?), Vanish (all colors but outline become transparent, yet poses still occur), Freeze (not sure, but this appears to be a tint overlay), Petrify (gray- pose frozen at standing position)
Head-effecting: Dark (glasses), Poison (bubbles), Rage (little dots), Mute (thought-balloon), Condemned (timer overhead), Muddle (birdies overhead), Sleep (z's overhead, also pose is changed)
Body-effecting: Image/Blink (doubles image of sprite, alternating the views back and forth quickly), Imp (changes entire sprite set to Imp), Morph (changes sprite set to esper terra)
Pose-changing: Poison (kneels), Near Fatal (kneels), Wounded (face-down), Berserk (ready-stance), Control (spell-casting stance), Petrify (standing), Sleep (kneeling)
-----
So, at a minimum, you'd need all those status effects times all those battler sprites. Not to mention that many of these statuses can be applied on top of one another. For example, a vanished imp still has the imp outline, or a petrified person with reflect will still have the blue outline. Some things are not stacked (things in different categories above will stack, whereas things in the same category don't--you can't have z's for Sleep and a Mute balloon).
My point is that having separate sprites for all of those would add up exponentially, particularly if someone wants to add new sprites and new statuses. (someone like me) :P
Regular cast:
Terra, Locke, Shadow, Cyan, Edgar, Sabin, Celes, Setzer, Relm, Strago, Mog, Gau, Gogo, Umaro;
PC special use:
Soldier (Wedge/Vicks), Soldier Locke (same but green), Merchant Locke, Leo, Banon, Ghost, Esper Terra, Imp;
NPCs seen in battle:
Kefka, Gestahl
----------------
Statuses:
Outline-changing:
Safe (yellow), Shell (green), Haste (red), Slow (white), Stop (magenta), Reflect (blue)
Palette-effecting:
Poison (also changes the pose), Berserk (also changes the pose), Zombie (may change pose?), Vanish (all colors but outline become transparent, yet poses still occur), Freeze (not sure, but this appears to be a tint overlay), Petrify (gray- pose frozen at standing position)
Head-effecting: Dark (glasses), Poison (bubbles), Rage (little dots), Mute (thought-balloon), Condemned (timer overhead), Muddle (birdies overhead), Sleep (z's overhead, also pose is changed)
Body-effecting: Image/Blink (doubles image of sprite, alternating the views back and forth quickly), Imp (changes entire sprite set to Imp), Morph (changes sprite set to esper terra)
Pose-changing: Poison (kneels), Near Fatal (kneels), Wounded (face-down), Berserk (ready-stance), Control (spell-casting stance), Petrify (standing), Sleep (kneeling)
-----
So, at a minimum, you'd need all those status effects times all those battler sprites. Not to mention that many of these statuses can be applied on top of one another. For example, a vanished imp still has the imp outline, or a petrified person with reflect will still have the blue outline. Some things are not stacked (things in different categories above will stack, whereas things in the same category don't--you can't have z's for Sleep and a Mute balloon).
My point is that having separate sprites for all of those would add up exponentially, particularly if someone wants to add new sprites and new statuses. (someone like me) :P
You wouldn't need them for any of the head effecting body effecting or pose-changing. Petrify is easy-ish. Morph would definitely use a separate battler because of how radical the change is. I wonder if you couldn't make some sort of C++ routine, Dargor. You'd know better than me (my range is limited to Java Ruby and Python.)
Good news!
I managed to make a C++ function that replaces an src_color with a dest_color in an RGSS bitmap.
Now I have my glowing frame function implemented and it works like a charm! It's very fast since it is written in C++.
It is also very easy to use. All you need to do is pass 2 arguments to Bitmap.set_color; src_color and dest_color.
The C++ code will go through all pixels in the image and if it finds a pixel with the same RGBA values as src_color, it will replace this pixel with dest_color.
There is still a couple of bugs since the order of the color values are different between RGSS and C++ but it's really easy to fix.
I managed to make a C++ function that replaces an src_color with a dest_color in an RGSS bitmap.
Now I have my glowing frame function implemented and it works like a charm! It's very fast since it is written in C++.
It is also very easy to use. All you need to do is pass 2 arguments to Bitmap.set_color; src_color and dest_color.
The C++ code will go through all pixels in the image and if it finds a pixel with the same RGBA values as src_color, it will replace this pixel with dest_color.
There is still a couple of bugs since the order of the color values are different between RGSS and C++ but it's really easy to fix.
Indeed, you're right. That's why I need a palette system.
If I have this, I can map the colors correctly and then easily find the src_color. But that would mean that the frame and skin colors should always have the same index in a palette, whatever the color.
Something like this:
EDIT:
I also have the vanish effect working perfectly well with the glowing frame effect!
If I have this, I can map the colors correctly and then easily find the src_color. But that would mean that the frame and skin colors should always have the same index in a palette, whatever the color.
Something like this:
Palette for Sprite #1
1: Frame (24,24,24)
2: Skin (128,128,128)
3: Something else (255,255,255)
Palette for Sprite #2
1: Frame (64,64,64)
2: Skin (255,128,218)
3: Something else (123,123,123)
1: Frame (24,24,24)
2: Skin (128,128,128)
3: Something else (255,255,255)
Palette for Sprite #2
1: Frame (64,64,64)
2: Skin (255,128,218)
3: Something else (123,123,123)
EDIT:
I also have the vanish effect working perfectly well with the glowing frame effect!