Celesinator
Member
Fantastic! Any screenshots soon?
Final Fantasy VI SDK - Going Social!
- Thread starter Dargor
- Start date
More update!
I've been working full time on the battle system, but almost only on the technical side of it. Algorithms, gameplay loop and logic, etc. so last weekend I decided to bring more life to it by working on the animation system.
Just like the latest versions, the animation system will be based on RPGXP's battle animation system.
The difference here is that you create the animations in the editor but the actual animation you see in-game is not a battle animation.
And this is the part where I go deeper into technical details.
[WARNING-Technical stuff here!!!]
The Sprite_Battler class (if the battler is an actor) will update its source rect (sprite.src_rect) based on the data found in a battle animation (cell_data).
For this to work properly, the battler's spritesheet must have the exact same format as the animation spritesheet. The advantage here is that the battler's spritesheet will overwrite the animation spritesheet, allowing multiple actors to share the exact same animations but using their own graphics.
As of now, there is a limitation with this system.
Normally, RPGXP's animations can have up to 16 sprites (or cells) shown per frames. In this case, battlers animations only uses the first cell (cell[0]) of each animation frames to animate the battler. This is actually part of the design as I don't want it to be the exact same system. Eventually, battler animations and other animations (or special effects as I like to call them) will be 2 different things.
This system has some features that allows the user to specify how the animation will be played. In the Game_Battler class, the start_animation method can use the following arguments:
- id : [Integer] ID of the animation to play
- loop_max : [Integer] how many time the animation will loop (-1 is infinite loop, 0 is play once, 1+ is play more than once)
- loop_range : [Array] at which frame the loop starts (index 0) and at which frame the loop ends (index 1).
- start_frame: [Integer] at which frame the animation starts
- timescale : [Integer] At which rate the animation will be updated (1 = every frames, 5 = every 5 frames, and so on)
The system currently supports a few basic poses such as the idle, dead, weak, "ready" and victory poses.
The next step is to implement custom poses for battle commands, items, spells, etc.
Later on, I will make it so certain states, items, spells, etc. can overwrite a specific animation. For example, poison could overwrite the idle animation too have the weak animation playing there instead.
It's a very complicated system and the worst part is trying to make is user friendly and compatible with RPGXP. But I'm getting there, slowly but surely!
- Dargor
I've been working full time on the battle system, but almost only on the technical side of it. Algorithms, gameplay loop and logic, etc. so last weekend I decided to bring more life to it by working on the animation system.
Just like the latest versions, the animation system will be based on RPGXP's battle animation system.
The difference here is that you create the animations in the editor but the actual animation you see in-game is not a battle animation.
And this is the part where I go deeper into technical details.
[WARNING-Technical stuff here!!!]
The Sprite_Battler class (if the battler is an actor) will update its source rect (sprite.src_rect) based on the data found in a battle animation (cell_data).
For this to work properly, the battler's spritesheet must have the exact same format as the animation spritesheet. The advantage here is that the battler's spritesheet will overwrite the animation spritesheet, allowing multiple actors to share the exact same animations but using their own graphics.
As of now, there is a limitation with this system.
Normally, RPGXP's animations can have up to 16 sprites (or cells) shown per frames. In this case, battlers animations only uses the first cell (cell[0]) of each animation frames to animate the battler. This is actually part of the design as I don't want it to be the exact same system. Eventually, battler animations and other animations (or special effects as I like to call them) will be 2 different things.
This system has some features that allows the user to specify how the animation will be played. In the Game_Battler class, the start_animation method can use the following arguments:
- id : [Integer] ID of the animation to play
- loop_max : [Integer] how many time the animation will loop (-1 is infinite loop, 0 is play once, 1+ is play more than once)
- loop_range : [Array] at which frame the loop starts (index 0) and at which frame the loop ends (index 1).
- start_frame: [Integer] at which frame the animation starts
- timescale : [Integer] At which rate the animation will be updated (1 = every frames, 5 = every 5 frames, and so on)
The system currently supports a few basic poses such as the idle, dead, weak, "ready" and victory poses.
The next step is to implement custom poses for battle commands, items, spells, etc.
Later on, I will make it so certain states, items, spells, etc. can overwrite a specific animation. For example, poison could overwrite the idle animation too have the weak animation playing there instead.
It's a very complicated system and the worst part is trying to make is user friendly and compatible with RPGXP. But I'm getting there, slowly but surely!
- Dargor
rey meustrus
Sponsor
It sounds like you're implementing the battler animations from RM2k3? It would probably be easier to describe a format for battler animations and separate them from normal animations.
I'm not sure I understand what you mean by having separate formats but, it is indeed similar to RM2K3. Right now battler animations and normal animations are the same with some small differences I described above. Eventually, both formats will be different but the system will remain the same. The reason why I'm using the animation data made in XP is because I want my system to be compatible and usable with XP since I don't have an editor yet. The map characters will also use that same system.
Time for another update!
I started last week to port the SDK to RGSS3, using the newest RGSS Library (RGSS300.dll) and RGSS Player. It took me at least a day to figure out how to make it work with RPG Maker XP but I think I have finally been able to make it work! I haven't tested it very thoroughly yet but at the moment, the game runs very well at 60 FPS, no crash, and I'm happy.
There are still a couple of issues I have to fix.
The Font and Window classes differ a bit from RGSS1 and RGSS2 and some windows and text are not displaying correctly, but it should be rather easy to fix.
The only RGSS3 feature I have tester so far is the Audio#bgm_pos feature, allowing you to memorize the current position of a playing BGM and start a BGM at any position.
It works like a charm! :D
There's a couple of other cool features such as:
- The use of Ruby 1.9 which is a lot faster than Ruby 1.8 used by RGSS1 and RGSS2
- The Graphics module can play movies in the game screen (only the Ogg Theora format is allowed)
RGSS3 contains more features than what I have listed above but nothing I can't do in RGSS2 or even RGSS1, so I don't really see the point of mentioning them.
There's the RGSS console which is a really cool addition but I already have my own since 2006 so... :P
Besides that, porting the SDK to RGSS3 forced me to get rid of all the RPG data I had modified. Now I have to use only my own FF6 data.
This is a really good thing because eventually, when the editor is done, only the FF6 data will be used and all the RPG data will be obsolete.
Well, I guess that's all for now! Back to work.
- Dargor
I started last week to port the SDK to RGSS3, using the newest RGSS Library (RGSS300.dll) and RGSS Player. It took me at least a day to figure out how to make it work with RPG Maker XP but I think I have finally been able to make it work! I haven't tested it very thoroughly yet but at the moment, the game runs very well at 60 FPS, no crash, and I'm happy.
There are still a couple of issues I have to fix.
The Font and Window classes differ a bit from RGSS1 and RGSS2 and some windows and text are not displaying correctly, but it should be rather easy to fix.
The only RGSS3 feature I have tester so far is the Audio#bgm_pos feature, allowing you to memorize the current position of a playing BGM and start a BGM at any position.
It works like a charm! :D
There's a couple of other cool features such as:
- The use of Ruby 1.9 which is a lot faster than Ruby 1.8 used by RGSS1 and RGSS2
- The Graphics module can play movies in the game screen (only the Ogg Theora format is allowed)
RGSS3 contains more features than what I have listed above but nothing I can't do in RGSS2 or even RGSS1, so I don't really see the point of mentioning them.
There's the RGSS console which is a really cool addition but I already have my own since 2006 so... :P
Besides that, porting the SDK to RGSS3 forced me to get rid of all the RPG data I had modified. Now I have to use only my own FF6 data.
This is a really good thing because eventually, when the editor is done, only the FF6 data will be used and all the RPG data will be obsolete.
Well, I guess that's all for now! Back to work.
- Dargor
MagitekElite
Member
So many updates! :D
Wow, the memorizing music part sounds absolutely amazing! Very handy! What do you mean by "RPG data"? You mean all the default tilesets, interface, music etc etc, right? :blush:
Wow, the memorizing music part sounds absolutely amazing! Very handy! What do you mean by "RPG data"? You mean all the default tilesets, interface, music etc etc, right? :blush:
By RPG Data I mean the default data structure of RPG Maker XP. Classes such as RPG::Weapon, RPG::Enemy, RPG::Skill, etc.
These classes are included in the RGSS library (the RGSS dll) so if someone wants to modify them, he has to redefine them in the script editor, re-save and finally re-load the data (Weapons.rxdata, Items.rxdata, etc.) for the modifications to be taken into consideration. But this is a very risky operation. If it is not done well, the editor could freakout when reopening project because the data differs from what the editor sees in the RGSS Library. It would most likely results in a "Data is corrupted" message box and the project would not load.
This is why I have made a Patcher and Backup system that reads/writes RPG and FF6 Data and do all the operations on its own.
Eventually, this won't be a problem with the Editor since it will not be expecting RPG Data but my own FF6 Data. I'm doing all this to increase compatibility with RPG Maker XP.
As of today, there is no more reference to any RPG objects in the game. Only the FF6 data structure is used.
Here's a part of the Patcher documentation to help you understand how it all works.
More information about the RPG structure can be found in RMXP help file.
Take care!
- Dargor
These classes are included in the RGSS library (the RGSS dll) so if someone wants to modify them, he has to redefine them in the script editor, re-save and finally re-load the data (Weapons.rxdata, Items.rxdata, etc.) for the modifications to be taken into consideration. But this is a very risky operation. If it is not done well, the editor could freakout when reopening project because the data differs from what the editor sees in the RGSS Library. It would most likely results in a "Data is corrupted" message box and the project would not load.
This is why I have made a Patcher and Backup system that reads/writes RPG and FF6 Data and do all the operations on its own.
Eventually, this won't be a problem with the Editor since it will not be expecting RPG Data but my own FF6 Data. I'm doing all this to increase compatibility with RPG Maker XP.
As of today, there is no more reference to any RPG objects in the game. Only the FF6 data structure is used.
Here's a part of the Patcher documentation to help you understand how it all works.
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# To enssure 100% compatibility with RPGXP, the patcher must backup the
# original data saved by RPG Maker XP somewhere else before patching it.
# Once the game is closed, these files are then taken back into the Data
# folder. Otherwise, the files in the Data folder will be patched with
# FF6SDK data and won't be readable by RPG Maker XP, making it impossible
# to open the game with the editor and thus loosing your work.
#
# To make things simple:
#
# 1) [Data/]---Backup-To---------->[Data/RPGXP]
# 2) [Data/]---Patched-To-FF6SDK
# 3) [Data/]---Backup-To---------->[Data/FF6SDK]
# 4) Game Start
# ...
# 5) Game End
# 6) [Data/RPGXP]---Move-Back-To-->[Data/]
#
# To make sure the data is always clean, it is very important that you
# save your project before closing it.
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# To enssure 100% compatibility with RPGXP, the patcher must backup the
# original data saved by RPG Maker XP somewhere else before patching it.
# Once the game is closed, these files are then taken back into the Data
# folder. Otherwise, the files in the Data folder will be patched with
# FF6SDK data and won't be readable by RPG Maker XP, making it impossible
# to open the game with the editor and thus loosing your work.
#
# To make things simple:
#
# 1) [Data/]---Backup-To---------->[Data/RPGXP]
# 2) [Data/]---Patched-To-FF6SDK
# 3) [Data/]---Backup-To---------->[Data/FF6SDK]
# 4) Game Start
# ...
# 5) Game End
# 6) [Data/RPGXP]---Move-Back-To-->[Data/]
#
# To make sure the data is always clean, it is very important that you
# save your project before closing it.
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
More information about the RPG structure can be found in RMXP help file.
Take care!
- Dargor
MagitekElite
Member
Oh, I get it now! :smile:
Thank you for the reply Dargor. I understand what you mean by DATA now. I completely forgot about those classes (you mentioned them to be a bit ago, I do believe). >.>
It sounds fantastical, Dargor! It is impressive how far it has progressed, very impressive!
As usual, I will keep an eye on the thread! Good luck again! :D
Thank you for the reply Dargor. I understand what you mean by DATA now. I completely forgot about those classes (you mentioned them to be a bit ago, I do believe). >.>
It sounds fantastical, Dargor! It is impressive how far it has progressed, very impressive!
As usual, I will keep an eye on the thread! Good luck again! :D
Update!
I'm done testing the RGSS3 port and it works perfectly fine! I got rid of the font and window issues I had.
Remember I told you about the battler animation system using RMXP Battle Animation system? (You can read more about it in one of my posts above)
Well now the characters on the map are also using this system!
This allows the user to create complex animations for any characters on the map, including the player. You could for example have an "Idle Down"
animation with the character blinking or scratching his head after a few seconds. You can have as many animation frames as you want!
It is also possible to force a character to play a specific animation.
Note that the old RMXP character animation system is still supported so the old image format (4x4 frames) will still work.
The new format is the same as battle animations (and battlers).
Also, this system currently supports 3 properties of the Battle Animation system (the ones you see when editing a cell properties).
1) X-Offset
2) Y-Offset
3) Horizontal Flip
Eventually, I will support Zoom, Angle, Opacity and Blending modes.
But having the X-Y Offset means that you can animate a character very precisely on the map or in battle, exactly as you would do in the Animation Editor.
That's it for now!
- Dargor
I'm done testing the RGSS3 port and it works perfectly fine! I got rid of the font and window issues I had.
Remember I told you about the battler animation system using RMXP Battle Animation system? (You can read more about it in one of my posts above)
Well now the characters on the map are also using this system!
This allows the user to create complex animations for any characters on the map, including the player. You could for example have an "Idle Down"
animation with the character blinking or scratching his head after a few seconds. You can have as many animation frames as you want!
It is also possible to force a character to play a specific animation.
Note that the old RMXP character animation system is still supported so the old image format (4x4 frames) will still work.
The new format is the same as battle animations (and battlers).
Also, this system currently supports 3 properties of the Battle Animation system (the ones you see when editing a cell properties).
1) X-Offset
2) Y-Offset
3) Horizontal Flip
Eventually, I will support Zoom, Angle, Opacity and Blending modes.
But having the X-Y Offset means that you can animate a character very precisely on the map or in battle, exactly as you would do in the Animation Editor.
That's it for now!
- Dargor
Another update! :D
I have improved the character/battler animation system a lot.
All the animation processing is now handled in a new Game_Animation class that unifies everything related to character animation.
Besides the animation system, I have (re-)implemented the Terrain system I had in previous versions.
This system allows the user to create more complex battle backgrounds. It can have up to 3 layers, 2 for the background and 1 for the foreground.
It also supports X-Y scrolling , waving (the wave effect introduced with RGSS2) and all other sprite effects.
This system is meant to work hand in hand with the Terrain Tag system that comes with RPG Maker XP.
With this system also comes a more or less new class, the Sprite_Plane class, that is meant to replace the RGSS Plane class.
By default, the Plane class doesn't support the wave effect sprites have. Now, with the Sprite_Plane class, they can!
Planes are special sprites that tile bitmap patterns across the entire screen and are often used to display panoramas and fog.
Other than that, I have rewritten the random encounters algorithm which is now exactly the same as in FF6.
It's a very subtle change but the nice thing about it is that it now supports the "Less & No Encounters" features (this is set on Armors).
But wait, there's more!
I have also added the possibility to modify maps in real time. It is now possible to change a specific tile or blit (copy) a portion from one map to another.
Note that in the map blit process, the source map should have the same tileset as the destination map. Multiple tilesets are not supported yet.
In the future, I will also try to implement a "Map Layering" system that would be used to stack multiple maps on top of each others.
I will explain this one a bit layer since it is not done yet and is a bit confusing.
Everything is coming along very well and very fast!
Take care!
- Dargor
I have improved the character/battler animation system a lot.
All the animation processing is now handled in a new Game_Animation class that unifies everything related to character animation.
Besides the animation system, I have (re-)implemented the Terrain system I had in previous versions.
This system allows the user to create more complex battle backgrounds. It can have up to 3 layers, 2 for the background and 1 for the foreground.
It also supports X-Y scrolling , waving (the wave effect introduced with RGSS2) and all other sprite effects.
This system is meant to work hand in hand with the Terrain Tag system that comes with RPG Maker XP.
With this system also comes a more or less new class, the Sprite_Plane class, that is meant to replace the RGSS Plane class.
By default, the Plane class doesn't support the wave effect sprites have. Now, with the Sprite_Plane class, they can!
Planes are special sprites that tile bitmap patterns across the entire screen and are often used to display panoramas and fog.
Other than that, I have rewritten the random encounters algorithm which is now exactly the same as in FF6.
It's a very subtle change but the nice thing about it is that it now supports the "Less & No Encounters" features (this is set on Armors).
But wait, there's more!
I have also added the possibility to modify maps in real time. It is now possible to change a specific tile or blit (copy) a portion from one map to another.
Note that in the map blit process, the source map should have the same tileset as the destination map. Multiple tilesets are not supported yet.
In the future, I will also try to implement a "Map Layering" system that would be used to stack multiple maps on top of each others.
I will explain this one a bit layer since it is not done yet and is a bit confusing.
Everything is coming along very well and very fast!
Take care!
- Dargor
More updates! I'm on a roll.
And today I'm talking about my researches for the editor!
Last night I went back to Visual Studio and tried a couple of things in C# and IronRuby.
I do not have a lot of experience with C# so I had to learn a couple of things, especially how to embed IronRuby and work with it.
But within about 30 minutes, I was able to create a small and simple program that loads the States data, allows the user to change a few properties such as the name, and save it back to .rxdata, readable by RPG Maker XP. This 30 minutes includes everything from creating the C# project to GUI design and writing the code.
Back when I was working with wxRuby, doing this would have taken me twice the time since I had to go through many steps AND many different programs.
Now with Visual Studio, all is done in the same place. GUI design, coding, debugging, etc.
The next step is to work with graphics using XNA. This is one of the main reasons why I'm switching to C# for the editor.
Working with graphics through XNA will be both faster and more elegant. I still have to learn more about how XNA works but in the end, I know the results will be very very good. It has already proved itself, just look at all the map editors on the net that are using XNA!
IMPORTANT NOTE:
I am not officially working on the editor. I am just learning C#, XNA and IronRuby so that when I'm ready to start working on it, I already have the necessary experience and knowledge to do so. The focus Is still on RPG Maker XP and the script library, which is doing great by the way.
Take care!
- Dargor
And today I'm talking about my researches for the editor!
Last night I went back to Visual Studio and tried a couple of things in C# and IronRuby.
I do not have a lot of experience with C# so I had to learn a couple of things, especially how to embed IronRuby and work with it.
But within about 30 minutes, I was able to create a small and simple program that loads the States data, allows the user to change a few properties such as the name, and save it back to .rxdata, readable by RPG Maker XP. This 30 minutes includes everything from creating the C# project to GUI design and writing the code.
Back when I was working with wxRuby, doing this would have taken me twice the time since I had to go through many steps AND many different programs.
Now with Visual Studio, all is done in the same place. GUI design, coding, debugging, etc.
The next step is to work with graphics using XNA. This is one of the main reasons why I'm switching to C# for the editor.
Working with graphics through XNA will be both faster and more elegant. I still have to learn more about how XNA works but in the end, I know the results will be very very good. It has already proved itself, just look at all the map editors on the net that are using XNA!
IMPORTANT NOTE:
I am not officially working on the editor. I am just learning C#, XNA and IronRuby so that when I'm ready to start working on it, I already have the necessary experience and knowledge to do so. The focus Is still on RPG Maker XP and the script library, which is doing great by the way.
Take care!
- Dargor
RadethDart
Sponsor
Excellent Progress! If you ever need any GUI design or graphics, do not hesitate to contact me! :P
radethproductions.com
radethproductions.com
Here you go Dargor. Here are some examples to get XNA to render as a control in a Windows Form. This can be used for your map editor. I've done it various times and it works great.
http://create.msdn.com/en-US/education/ ... s_series_1
http://create.msdn.com/en-US/education/ ... s_series_2
http://create.msdn.com/en-US/education/ ... s_series_1
http://create.msdn.com/en-US/education/ ... s_series_2
Thank you for the links! I've already came across those but started using this control only yesterday.
I created by own control derived from GraphicsDeviceControl but I'm having trouble understanding how to load content outside the of ContentPipeline.
Do you have any suggestions as of how to do that? Otherwise I'll keep looking on the net.
EDIT:
Actually, after taking a closer look at the second sample, it seems that this could be done using their custom ContentBuilder class.
Gotta try this tonight.
Thanks!
- Dargor
I created by own control derived from GraphicsDeviceControl but I'm having trouble understanding how to load content outside the of ContentPipeline.
Do you have any suggestions as of how to do that? Otherwise I'll keep looking on the net.
EDIT:
Actually, after taking a closer look at the second sample, it seems that this could be done using their custom ContentBuilder class.
Gotta try this tonight.
Thanks!
- Dargor
Also, if you later want to lean away from forcing developers from installing the XNA Redist, there is always AgateLib. It uses either DirectX, OpenGL, or SDL. It can either render to its own window, to a surface, or to a control. This was my alternative to my map editor because I can't install XNA redist onto school computers.
Thanks for the tip. I doubt I will be using it but it's always nice to know there alternatives.
I managed to load RPGXP data and load/display graphics at runtime on a custom control using the FileStream method.
Microsoft's custom ContentBuilder method ended up being to slow because each time it loads content, it has to (re-)build it so it can be used and loaded properly through the Content Pipeline.
So now I know how to embed IronRuby into a C# application, I know how to load, edit and save Ruby data through that and I can display graphics on a custom XNA control into a WinForm. I think that's good enough for now!
Take care,
-Dargor
I managed to load RPGXP data and load/display graphics at runtime on a custom control using the FileStream method.
Microsoft's custom ContentBuilder method ended up being to slow because each time it loads content, it has to (re-)build it so it can be used and loaded properly through the Content Pipeline.
So now I know how to embed IronRuby into a C# application, I know how to load, edit and save Ruby data through that and I can display graphics on a custom XNA control into a WinForm. I think that's good enough for now!
Take care,
-Dargor
clockworkbutterfly
Member
Dargor,
Sorry I've been away for awhile. With the lack of updates awhile back, I stopped checking this thread compulsively, but I'm glad to see everything you've done since I was last here.
Thanks for sticking with the project. I am really eager for it to be completed, especially if you're expecting the editor to be finished in 2013 now!
As much as I hate to reply to something you said a long time ago, I do have a question. Awhile ago, you said:
I think this is a fantastic idea, but I'm wondering if we can use it in a certain way. Say that we have a two-minute summon (think Knights of the Round from FF7). Would it be possible to create a long version of the summon and a short version? The long version would always play the first time you use it, but then maybe you can set the frequency for how often you see the short version (0-100%)? Having more than one animation per summon might be important, especially seeing what FF7 did with Odin (one animation for instant death, another for general damage).
Also, once the editor is done, will you try to find a way to export the games we make to an iPhone/iPad app? I'm not sure if this has been asked before, but that would be really cool if it were possible.
Thanks! Keep up the good work!
-- CB
Sorry I've been away for awhile. With the lack of updates awhile back, I stopped checking this thread compulsively, but I'm glad to see everything you've done since I was last here.
Thanks for sticking with the project. I am really eager for it to be completed, especially if you're expecting the editor to be finished in 2013 now!
As much as I hate to reply to something you said a long time ago, I do have a question. Awhile ago, you said:
On a side note, I added a new value to battle actions; the wait count. It is possible to specify a delay before performing an action.
By default it's 3 seconds (180 frames) but you could make it so Ultima takes 6 seconds to cast!
I think this is a fantastic idea, but I'm wondering if we can use it in a certain way. Say that we have a two-minute summon (think Knights of the Round from FF7). Would it be possible to create a long version of the summon and a short version? The long version would always play the first time you use it, but then maybe you can set the frequency for how often you see the short version (0-100%)? Having more than one animation per summon might be important, especially seeing what FF7 did with Odin (one animation for instant death, another for general damage).
Also, once the editor is done, will you try to find a way to export the games we make to an iPhone/iPad app? I'm not sure if this has been asked before, but that would be really cool if it were possible.
Thanks! Keep up the good work!
-- CB
clockworkbutterfly
Member
game_guy":a8wg4e6g said:
That's why I figured it'd be good to control how often you see the full one. If you hate having enough time during a summon to make yourself a sandwich, then you can set it to 100% and only see the "long version" the very first time it is ever cast. After that, it will always always always be the short version (well, unless you change the control). If you set it to 0%, then you'll have sandwich time every time the summon is cast. However, if you set it at 50%, then the game just chooses at random which one to use.
Actually, this multiple animation effect might be fantastic for normal spells too. Could you imagine if "Fire 3" had three different animations it could cycle through at random, each with a different effect? (Like a normal, super, and death-of-the-gods version?)
Sounds like something that could be very useful to implement. Dargor, what do you think?
-- CB