VANIT'S PROFILE

author=Rowan
My virus protection went off and blocked it from working. Yeah...

It'll do that because its an exe packed within an exe, which some virus protectors will think is suss (in this case its the rm2k3 runtime exe thats packed). I can assure you there's no actual virus, but its up to you ofcourse.

I'm happy to announce... my first public demo of my 2D remake of FF7, which is now available for download!

http://dl.dropbox.com/u/5226139/FF72DR_R1.zip (8.5mb)

The main purpose of this release is to achieve 2 things:

1) Find out if I've successfully captured the feeling of FF7 in 2D
2) Find any bugs I've missed

Please, please, please tell me if you have any thoughts on what you see! Its a very small demo with only 2 areas, but it should be enough to achieve these small goals. I should also mention there are a few things missing, like announcements in battle for items and announcements for limits are currently NYI, and the Change and Defend functions currently do nothing so you need not report these issues. :)

Also to clarify, this release is moleboxed as I only require black box testing at this time, so if you're keen to poke around inside this isn't the release you're after. :(

Screenshots:

@Nessiah: If Cloud acted like his sword weighed anything he'd be dragging it along the floor. :P Seriously though, I see where you're coming from and if this project was anything else I may agree with you, but its not what this games about for a few reasons. 1) This game is kind of meant to be "what FF7 would've looked like if it was on the snes", and that means the animation really isn't supposed to have that many moving parts. 2) the animations were lifeless and stiff in the original, and similarly while you're going "make the animation fluid with more moving parts!", others would go "his hair didn't move in the original!", etc. My remake is designed to be as nostalgic as possible, and part of that is having 1:1 animations that are the same as the original, for better or worse.

@Zephyr: Ah I see what you mean now. I'll have to tweak things a bit when I get the chance, thanks for pointing that out!

@WCouillard: I initially was going to leave the bounce of the sword out as its so subtle in the real animation I thought a closer proximation would be to not have it rather than having him move the sword too much. But I'll attempt it again at some point, thanks for the feedback!

@LockeZ: Aye the limit break charge animation is a placeholder just so there's something for the sound effect to go with until I can get the proper one to look just right. I spent so much time being anal about it that I was getting nothing else done, so placeholder for now! Similarly the casting animation is missing the green effect until I can come up with something that looks good. Also the EXP can be skipped as in the real screen, I was just showing off how it'll automatically skip after 10 levels. :)

author=bulmabriefs144

2) Reduce overhead with common events

I think what you mean is reduce code redundancy, which is definitely good practice, but it is not always the best solution when it comes to executing calculation-intensive events. Ironically what you have suggested, while reducing the size of the code, has increased the execution overhead of the event thats calling your common event.

He means overhead. Imagine having the same event on every map. Parallel process a common event, or outright make it switch activated. Not only did this just reduce thousands of hours of code edit if something goes wrong (you just edit the common event), but it actually does speed the execution up. I've got hundreds of common events.

Uhhh ... Thats called reducing redundancy. When you have redundant code it means you have code that does the same thing written in multiple places, when you could've put the code in one place and have everywhere reference that one place (in this case a common event), which is what you described but are calling the wrong thing. When you reduce overhead it means things run faster, which using "Call: Common Event" DOES NOT do.

I think you've misunderstood the distinction I was making between a parallel process and CALLING an event. When you have a loop and you put Call: Event, the code that loads the event will lag the loop. If you're doing stuff in a loop it'll run faster if the code is right there rather than off someone else in a different event. It can make things a little bit more difficult when you have to fix code, but if you absolutely want to push rm2k3 to the limit in terms of execution speed its a necessary evil.

I suggest you check out my full tutorial here: http://rpgmaker.net/tutorials/451/.