No I don't have any screenshots, they would look somewhat the same as the old one.
However, as soon as I have enough features ready, I will make a gameplay video showcasing them. :)

Take care!
- Dargor

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

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

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?

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

Oh, I get it now!

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

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

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

Excellent Progress! If you ever need any GUI design or graphics, do not hesitate to contact me! :P
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

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

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

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

I remember they did this in FF9. It kind of always bugged me since I rarely ever saw the full animations for summons.

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

Such a feature is almost already possible with spells that call event commands. The proper way to implement the feature, in my opinion, is to make the spell target available as a variable to the event commands and then make it possible to automatically cast a new spell on the same target based on, for example, a fork statement based on a random variable. Event commands could also be used to make a spell take time to cast if they have control over the caster's animation and ATB bar.

I think It's a good idea. Not essential but it should be easy to implement but should remain entirely optional.
I remember FF10 also had a short and long summon animation option.
If I do this, it would be for each and every skill types, including summons since they are a type of skill.

About the iPhone/iPad port, the short answer is no. I had this idea before starting to rewrite the SDK but I decided to stick to Ruby as a scripting language and it can't be ported to other platforms, at least not without porting Ruby itself to the target platform. But if someone manages to port Ruby to another platform, I would be ready to take a look at it and see if I can port it. However, I could rewrite the SDK in C# with XNA and port it to Windows7 Phone and XBOX 360. But it's not likely to happen at this stage. :P

Take care!
- Dargor

EDIT: You know what? I think Rey's right.
It would be so much more simple for everybody to simply use common events for summon animations.
However, I would have to expose a few variables to know on which target the animation should play if it is done through an event command.
I'll think about it.

I found something called shinycocos a while ago. I haven't completely figured out how easy it would be to implement RGSS on top of it but it is a Ruby framework for mobile devices. Looking at it now, I have to say it's a shame it runs on 1.8.7, but maybe this is what you're looking for?

Never heard of that, I'll take a look at it!
It's indeed a shame that it doesn't run on ruby 1.9 now that I have ported the SDK to RGSS3 (which uses Ruby 1.9.2).

But besides that, I'm pretty sure I could come up with something eventually.

Thanks a lot Rey. :)
- Dargor

Dargor,

That's totally ok. As long as it's eventually possible to do. I figure that by the time the SDK is done AND some of us actually finish games that we make with the SDK, then someone will have written that add-on. I just think it would be nice to eventually make some of our games into playable apps.

Thanks for all your hard work!

-- C42

Hello Dargor (Sasha)! First of all let me say that I am thrilled to see you still working hard. Not sure if you remember me, as I see you have had many people coming and going following the progress of this project. I had ripped some spell animations, not sure if they ended up being something you used. I must say your continued work is as much of an inspiration to us (game makers) as we are to you. I'm glad to see so many people still checking in over the years. I know you will eventually complete this SDK, and I'm glad we can be here to encourage (or nag) you to finish.

I also have a few questions, and ideas for things that probably won't be implemented into your release. I know you don't want to release anything until you have it all finished, but how are the resources coming? I have been planning to make a game for years, but basically decided to wait for you. I want to make a true sequel to FFVI, taking place 20 years later. Basically I am working on the story of what happens to everyone in between games, and then the main conflict in the new game, and for the most part I don't even need to touch the computer until I have the SDK to start from. I plan of writing everything on paper until then. A few things I would like to start in advance however, are updated character sprites (everyone has to get older) plus a new world map. My idea was to basically take the World of Ruin and apply the World of Balance palette (with some changes). The SDK releases so far, I believe only had the World of Balance partially done. I know I can easily find character sprites and update them, but I feel like it would be such a waste of time to create a whole new world map, and then it end up being incompatible with your final release. So, I guess what I want to ask is, if it's all done, can you share your World of Balance/Ruin resource files, so that people can start working before the editor is complete?

A couple other things I plan to include in my game that will involve features not seen in VI-1 are: maybe a Picross mini-game (for Relm), a Collectible Card mini-game, and the main character would be customizable. When you start the game you will play as Duane and Katarin's child. You get to choose the name, gender, hair color, face type, etc. All those good things they have added to "modern" games, except it will be all pixelated.

I have seen various FFVI-based fan games pop up throughout the years, and so far nothing that compares to what I have in mind. (I did like the idea of a prequel telling the story of the War of the Magi.) I truly hope that I could completely create this game using your SDK and submit it to Square-Enix and have them port it to the FFXIII engine. They have been making all sort of spin-off and sequel/prequel games, but they seem scared to mess with their Masterpiece. Which reminds me of another feature I would like to include, the multi-bar battle gauge system from XIII.

I'm curious about what your plans are for once this is finally all finished. I know you are making this for the fans who want to make their own games, but have you ever considered working on an original story yourself? I feel like your opinions on my game would be as valuable as anyone else, since you clearly have strong feelings about FFVI. I didn't intend to make a post asking for help, but if there is anyone who feels like there should be a VI-2, and would like to have some input on how it turns out, contact me. This is not a project I expect to knock out in a few months. I would like people who are serious about making a long term commitment to developing a companion to one of the best RPGs of all time.

Anyway, good to know you are still there, as this is the first time I've been here in a few years.

[SDK UPDATE IN THE POST BELOW THIS ONE!]

Hello QuickMythril!

Of course I remember you, you made awesome videos on how to rip battle animations on youtube! :D
I do use the sprites you ripped, it helped me a lot and saved me a lot of time. It's truly appreciated.

About the SDK:
It's funny that you ask about the maps because I've been working on them this weekend! I will elaborate more below in the SDK update.
All I can tell you is that I will provide all the maps and tilesets from the game. So yes, you will have the world maps already done and I guess you could simply replace their tilesets to have the results you want.

As for the graphical and audio resources, I'm not focusing on them right now. Not enough actually. I must admit that I'm working mostly on the technical side of the SDK, all the code of the game and the editor, so I can release something that works within the time frame I've given myself.
However, I can safely say that I will be using the same sprite format as in FF6 for characters and battlers. This format:

I will also be using the same tileset format as in FF6, which is 16 tiles large (but they will be 32x32 px instead of 16x16 px).

As of my projects after the SDK:
My ultimate goal is to remake the entire game, merge the GBA features in it and tweak/fix/enhance many aspects of the game. Something like an "FF6 Remastered".
Back in 2003. I had an idea for a sequel, an original story which actually gave birth to this SDK instead, but I won't be doing it. And there's a chance I won't be doing the remake either. Anyway, I will see when I get there! I have plans for something bigger in 3D afterwards, not related to FF6 or RPG Maker in any way.

I do think a prequel or a sequel is a good idea, as long as it is consistent with the universe and style of FF6 and does not feel alien compared to it.
You have my full support and I hope it sees the light of day with my SDK. :)

Oh and, if I forgot to answer one of your questions or if I wasn't clear enough, please tell me. I will be happy to elaborate!

Take care,
- Dargor

It's been quiet here, so it's time for another update. :)

I will be honest, I haven't been working on the SDK very much lately, I had to take a little break.
But, something grabbed my attention this week end and I ended up doing more that I imagined!

A few years ago, someone (I don't remember the name) released a very very good level editor, the FF6LE. Recently, Lord J, the author of FF3usME released a "Rogue version" of this editor to increase compatibility with his editor. Then I remembered, the coder behind FF6LE released the source code and I happen to have it on my computer! Oh, it's in C#? Nice! I've been learning this language these few past months! :D

So what did I do?
Just a small exporter and converter... ... :D
Oh yeah, I did it! I added a function to FF6LE that allows the user to export all 3 Tilesets of a map to a PNG image, export the tilemap data and convert it to a Ruby RPG::Map object! Just to make sure it works, I tried with 2 maps. A chocobo stable and the Floating Continent. And you know what? It WORKS.

It is really not elegant right now and it is not possible to edit the map in RPG Maker without screwing it up, because RMXP tilesets are 8 tile wide while FF6 is 16 tiles wide. I also can't export animated tiles, it's all static, so there is still man work to be done once exported. But still, dumping the map and tileset files generated by this new function I made, directly in the right Project folder, will work. There still a lot of work to do with this like exporting collisions and priorities but I'm getting there. Also I am not saying that this will be a feature of the SDK, but with this I can guarantee you that I will be able to deliver all the game maps and tilesets like 100 times faster that I would have expected. :)

That's all for now!
- Dargor

I kept on working on this last night. The function now ask you to choose an RPGXP project to export to and it automatically exports the map and tileset data with the right IDs and it also exports the tileset images with the right format and size! I will eventually release my modified version of this editor so you can try it yourself. :)

Next thing I'll be working on is exporting the tilesets with the passage flags and priorities. It shouldn't take more than a day to figure out how to do that.
If all goes well, It would have taken me only 3 days to make a map exporter! This gives me another good reason to start working on my map editor as soon as possible.

Take care!
- Dargor

Ooooh everything sounds lovely! Do you think this will still come out around the beginning of next year or somewhere in there? You seem to be making wonderful progress! And although I don't post a lot, I still check on this every week. Happy to see you're working on it every time I come here =D It's been 6 years since you posted this thread!

Wow! Lots and lots of updates, and discussions! And I missed it! xD

Everything -- the parts I could understand with little to no knowledge of this, of course -- sound absolutely amazing! It all sounds great! Can't wait for more updates!